是否可以设计一个基于微服务的架构，其中每个微服务都有单独的独立数据库和一个公共用户表？
不建议在微服务之间共享数据库或表。他们应该有明确、明确定义的职责，并且应该只使用网络进行通信;协议必须隐藏微服务中使用的技术：例如，您可以将 JSON 用于请求/响应。
这样做的原因是，一个微服务不应该依赖于另一个微服务的技术，因为微服务应该很容易被使用其他技术堆栈但实现相同目的的其他微服务所取代。
如果需要来自另一个微服务的数据，可以创建：
-
同步调用：这更容易实现，但容易受到级联故障的影响
-
异步调用：更难实现，但会导致更具弹性的系统
考虑创建一个额外的微服务，它封装了与用户详细信息相关的所有逻辑：
- 只有此服务才能访问 Users 表，并提供端点来读取/修改数据
- 其他服务应该对该服务发出请求，并且对用户表一无所知
我主要有基于 REST 的微服务的经验(所以我的这一部分答案主要是基于意见的(，在大多数情况下，当需要读取/修改数据时，我们使用直接 HTTP 请求来服务。当我们希望该服务通知不同的组件有关数据修改时，我们使用基于队列的消息通信(发布-订阅模式(：
- 服务，即数据所有者，将有关修改事件的消息发送到队列;
- 其他服务订阅该队列并在新消息到达时执行操作;
- 如您所见，通信是异步进行的。
与简单消息广播相比，消息队列的优点之一是它自动支持重试机制(并在失败时延迟重试(。
微服务- 如服务，应该尽可能自治。 共享数据库表会阻碍这一点，因为这意味着服务与可用性相结合，更重要的是彼此的内部结构。
也就是说，有时将单个服务分解为多个可执行文件以获得与开发速度、技术适用性或任何其他有意义的原因相关的优势是有意义的。我想称这些方面(如同一服务的不同方面(。
理解(并尊重(服务边界仍然非常重要，否则你会得到一个分布式混乱，但是一旦你确定了边界，你也可以构建几个组件(方面(来构成服务。例如，在我这些天工作的系统中，我们有一个服务，它在处理传入数据(实时流式传输(和使用其数据(基于 graphql 的查询(方面具有完全不同的要求。第一个方面是在 Scala 中实现的，并且是高度分布式的，后者是在 node 中实现的.js(用于使用像 express-graphql 这样的友好库(这两个方面使用相同的数据库，但该数据库与系统中的其他服务隔离(例如用户服务，它使用自己的服务和 DB(