具有公共用户表的微服务

Question

有没有可能设计一个基于微服务的架构，每个微服务都有单独的独立数据库和公共用户表？

Answer 1

不建议在微服务之间共享数据库或表。它们应该有明确的、明确定义的职责，并且应该只使用网络进行通信；协议必须隐藏微服务内部使用的技术:例如，您可以使用JSON进行请求/响应。

这样做的原因是，微服务不应该依赖于另一个微服务的技术，因为微服务应该很容易地替换为使用其他技术堆栈但实现相同目的的其他微服务。

如果您需要来自一个微服务中另一个微服务的数据，您可以执行以下操作：

• synchronous call:这更容易实现，但容易受到级联failure
• asynchronous调用的影响:更难实现，但会导致更具弹性的system

Answer 2

考虑创建一个额外的微服务，它封装了与用户详细信息相关的所有逻辑：

• 仅此服务应具有对users表的访问权限，并提供端点以读取/修改数据
• 其他服务应向该服务发出请求，但对users表

一无所知

我主要有基于REST的微服务的经验(所以我的答案的这一部分主要是基于意见)，在这里，在大多数情况下，当需要读取/修改数据时，我们使用直接的HTTP请求来提供服务。当我们想让服务通知不同的组件数据修改时，我们使用基于队列的消息通信(发布-订阅模式)：

• 服务，即数据所有者，将有关修改事件的消息发送到队列；
• 其他服务订阅该队列并在新消息到达时执行操作；
• 如您所见，通信是异步进行的。

与简单的消息广播相比，消息队列的优点之一是它自动支持重试机制(并在失败时延迟重试)。

Answer 3

微服务--比如服务，应该尽可能的自治。共享数据库表阻碍了这一点，因为它意味着服务耦合到可用性，更重要的是彼此的内部结构。

也就是说，有时将单个服务分解为多个可执行文件是有意义的，以获得与开发速度、技术适用性或任何其他有意义的原因相关的优势。我想将这些称为aspects (在同一服务的不同方面)。

理解(和尊重)服务边界仍然是非常重要的，否则你会得到一个分布式的混乱，但是一旦你确定了一个边界，你也可以构建几个组成服务的组件(方面)。例如，在我最近工作的系统中，我们有一个服务，它对处理传入数据(实时流)和消费数据(基于graphql的查询)有完全不同的要求。第一个方面是用Scala实现的，并且是高度分布式的，而后者是用node.js实现的(为了使用友好的库，比如express-graphql)，这两个方面都使用相同的DB，但是DB与系统中的其他服务(例如，用户服务，它使用自己的服务和DB)是隔离的。