我即将了解微服务架构的工作原理。到目前为止，我理解每个微服务都需要自己的数据库，这是有道理的。
因此，假设我们有一个客户微服务，负责创建客户并返回客户列表。该服务将拥有自己的客户数据库。
让我们说我们对这个服务有很高的负担，所以我们选择扩展20倍。
我们有20个微服务，每个都有自己的数据库，所有服务都在负载均衡器后面。
现在客户想要创建客户，负载均衡器将客户端请求发送到服务9/20，并创建客户。
在下一个请求中，同一个客户端希望确保创建客户并希望查看客户列表，请求LB将其发送给服务11/20。
现在，我如何确保服务9/20将新创建的客户同步到服务11/20的数据库？
在MSSQL中，有一些功能可以在执行初始提交之前保持数据库同步，以便首先将数据保存在所有其他数据库中，但这种方法从长远来看会产生问题，因为有更多的服务需要更长的时间提交时间需要多长时间？
答案 0 :(得分：10)
每个微服务都需要自己的数据库
每个微服务单独的数据库不是先决条件（实际上也不是必需的）。
您可以在同一个数据库上使用尽可能多的微服务，但例如使用不同的模式。
微服务的有限环境应该是边界。
假设我们对此服务的负载非常高，因此我们选择扩展20倍。
缩放到（X）同一微服务的实例并不意味着每个同一服务的每个实例都必须有一个单独的数据库。
大多数数据库的设计都考虑了并发连接，用户和事务。单个数据库实例（具有一些乐观并发性）可以优雅地处理数百个（如果不是数千个）并发连接。
如果您明确选择为同一服务的每个实例分配一个单独的数据库，则必须同步这些数据库。并且，很可能，数据一致性将受到影响。
以下是一些建议：
每个微服务（不是每个实例）使用一个数据库，无论有多少实例使用它。当您确定单个数据库无法处理负载时，只考虑每个实例的数据库。
在数据库顶部使用共享缓存层（可能是redis缓存）
使用数据库集群来处理数据库的高负载/可用性。
答案 1 :(得分：3)
虽然可能为多个服务使用相同的数据库，但应避免使用它，因为它将在服务之间创建比期望的更高的耦合。例如。数据库停机将影响所有共享服务，但如果每个服务都有自己的服务，则仅会中断一个服务。
为避免彼此之间进行同步调用（例如使用REST）的服务的“分布式整体”，您可以使用基于流的方法。每当其数据更改时，每个服务都会发布一个更改事件，其他服务可以订阅这些流。因此，他们可以对与其相关的数据更改做出反应，例如通过将数据的本地版本（以适合其需求的表示形式，例如只是他们感兴趣的int列）存储在自己的数据库中。这样一来，他们便可以提供其功能，即使一段时间内其他服务都无法使用也是如此。自然地，这种架构采用了最终一致性的语义，但是通常无论如何在分布式系统中都是不可避免的。
设置此类数据流的一种方法是更改数据捕获CDC，它将跟踪数据库日志文件（例如MySQL中的binlog）并为每个INSERT，UPDATE和DELETE发布相应的事件。 Debezium是一种开源CDC工具，它带有MySQL，Postgres，MongoDB以及（和目前进行中的）Oracle和SQL Server的连接器。它可以与Apache Kafka一起用作流传输主干或作为Java应用程序中的库使用，从而使您仅需少量代码就可以将数据更改流式传输到其他流传输层，例如Pulsar或Kinesis。对变更事件使用永久主题的一个不错的优势，例如使用Kafka，是可以提出新服务并重新读取整个更改流（取决于主题的保留策略），或者只是获取每条记录的当前状态以为其本地数据库做初始种子。
（免责声明：我是Debezium的负责人）
答案 2 :(得分：0)
这可以使用CQRS设计模式来实现，这是通过遵循异步范例来分离创建和查看实体。
创建时，我们将实体持久性推送到Kafka / RabbitMQ并异步推送到数据库。可以在数据库上创建物化视图，从而加快检索速度。
答案 3 :(得分：0)
进入多个数据库只会改变一个分布式协调的软件体系结构问题，后者，恕我直言，这是一个更加困难的问题。
人们建议使用事件系统，这意味着每个单独的服务现在都必须拥有自己的用于数据的分布式协调的小解决方案，而ACID则无法使用。查看数据库情况，您会发现这不是一个容易解决的问题，也不是完全解决的问题。然后进入分布式协调交易...
很多时候，您宁愿停机而不是让N个数据库处于完全未知的不一致状态。另外，对正常运行时间的看法令人误解，是的，您的服务正常运行，但是如果它们对相同数据的视图不一致或缺少数据（丢失的事件），它们是否真的起作用？还是会产生不一致和错误的结果？
要么您有两个完全不依赖于拥有相同数据的服务，要么需要共享一致的数据层。但是，使用事件系统在N个数据库之间进行复制，并希望能做出最好的选择。
分发，持久性，一致性和可用性问题应在存储层处理，而不应由应用程序层中的每个服务专门处理。建立这样的系统需要很多人的精心照顾和专门的专业知识，即使这样，也存在各种折衷方案（CAP定理）。
最后：大多数人希望微服务能够比通过整体服务更快地开发和发展其应用程序。在每个微服务中处理分布式协调和存储的一致性将相反。