Tim*_*sen 17 architecture microservices
我即将了解微服务架构的工作原理.到目前为止,我理解每个微服务都需要自己的数据库,这是有道理的.
因此,假设我们有一个客户微服务,负责创建客户并返回客户列表.该服务将拥有自己的客户数据库.
可以说我们对这个服务有很高的负担,所以我们选择扩展20倍.
我们有20个微服务,每个都有自己的数据库,所有服务都在负载均衡器后面.
现在客户想要创建客户,负载均衡器将客户端请求发送到服务9/20,并创建客户.
在下一个请求中,同一客户端希望确保创建客户并希望查看客户列表,请求LB将其发送给服务11/20.
现在,我如何确保服务9/20将新创建的客户同步到服务11/20的数据库？
在MSSQL中,有一些功能可以在进行初始提交之前保持数据库同步,以便首先将数据保存在所有其他数据库中,但是这种方法从长远来看会产生问题,因为有更多的服务需要更长的时间.承诺提交？
Bis*_*hoy 12
每个微服务都需要自己的数据库
每个微服务单独的DB不是先决条件(实际上也不是必需的).
您可以在同一个数据库上使用尽可能多的微服务,但例如使用不同的模式.
微服务的有界环境应该是边界.
假设我们对此服务的负载非常高,因此我们选择扩展20倍.
缩放到(X)同一微服务的实例并不意味着每个同一服务的每个实例都必须具有单独的数据库.
大多数数据库的设计都考虑了并发连接,用户和事务.单个数据库实例(具有一些乐观并发)可以优雅地处理数百个(如果不是数千个)并发连接.
如果您明确选择为同一服务的每个实例分配一个单独的数据库,则必须同步这些数据库.并且,很可能,数据一致性将受到影响.
以下是一些建议:
无论有多少实例使用它,每个微服务(不是每个实例)都使用一个数据库.当您确定单个数据库无法处理负载时,只考虑每个实例的数据库.
在数据库顶部使用共享缓存层(可能是redis缓存)
使用数据库集群来处理数据库的高负载/可用性.
Gun*_*nar 10
虽然对多个服务使用同一个数据库是可能的，但应该避免这样做，因为它会在服务之间创建比预期更高的耦合。例如，数据库停机将影响所有共享服务，但如果每个服务都有自己的服务，则只会影响一个服务。
为了避免相互同步调用的服务的“分布式整体”（例如使用 REST），您可以使用基于流的方法。每个服务都会在其数据更改时发布更改事件，其他服务可以订阅这些流。因此他们可以对与他们相关的数据更改做出反应，例如通过在他们自己的数据库中存储本地版本的数据（以适合他们需要的表示形式，例如他们感兴趣的列）。这样他们就可以提供他们的功能，即使其他服务在一段时间内不可用。自然地，这样的架构采用最终一致性的语义，但无论如何这在分布式系统中通常是不可避免的。
设置此类数据流的一种方法是更改数据捕获 CDC，它将跟踪数据库日志文件（例如 MySQL 中的 binlog）并为每个 INSERT、UPDATE 和 DELETE 发布相应的事件。Debezium是一种开源 CDC 工具它带有用于 MySQL、Postgres、MongoDB 以及（目前正在进行中的）Oracle 和 SQL Server 的连接器。它可以与 Apache Kafka 一起用作流主干或 Java 应用程序中的库，让您只需少量代码即可将数据更改流式传输到其他流层，例如 Pulsar 或 Kinesis。对变更事件使用持久主题的一个很好的优势，例如使用 Kafka，是新服务可以出现并重新读取整个变更流（取决于主题的保留策略）或只获取每条记录的当前状态来做他们本地数据库的初始种子。
（免责声明：我是 Debezium 的负责人）