具有普通用户表的微服务

Question

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

Answer 1

不建议在微服务之间共享数据库或表。他们应该有明确的，明确的职责，只能使用网络进行沟通;协议必须隐藏微服务中使用的技术：例如，您可以使用JSON进行请求/响应。

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

如果您需要来自另一个微服务的数据，您可以制作：

• 同步调用：这更容易实现，但容易发生级联故障

• 异步调用：难以实现但会导致系统更具弹性

Answer 2

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

• 只有此服务才能访问users表并提供读取/修改数据的端点
• 其他服务应该对该服务发出请求，并且对用户表一无所知

我主要使用基于REST的微服务（因此这部分答案主要是基于意见的），在大多数情况下，我们在需要读取/修改数据时使用直接HTTP请求进行服务。当我们希望该服务通知不同组件有关数据修改时，我们使用基于队列的消息通信（发布 - 订阅模式）：

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

消息队列优于简单消息广播的一个好处是它自动支持重试机制（并在失败时延迟重试）。

Answer 3

微服务 - 就像服务一样，应尽可能自主。共享数据库表阻碍了这一点，因为这意味着服务与可用性相关联，更重要的是与彼此的内部结构相结合。

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

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