【问题标题】：Data Consistency Between Microservice Instances微服务实例之间的数据一致性
【发布时间】：2022-10-12 21:47:43
【问题描述】：
我的问题类似于this 和this，但都没有真正回答我的问题。前者是关于不同服务之间的数据一致性，后者是关于只接收一次消息。
在设计微服务架构时，重要的是每个服务都管理自己的数据，并且每个服务都可以独立地扩展每个过度服务。
但是，我们应该如何处理与该服务的每个实例相关的数据持久性的扩展？在我看来，有两种选择：
选项 A：
您可以使用分片或其他方式独立于服务扩展数据持久层。
乍一看，这似乎是明智的……但是许多数据库（至少据我所知）不能在运行时有效地水平扩展，而至少在发生时不会显着降低性能。
选项 B：
服务的每个实例都有自己的持久性数据库副本。
如果我们忽略增加的数据复制（因为现在存储很便宜），我看到的主要问题是确保数据在服务的不同实例之间保持一致。
人们通常如何处理这个问题？
【问题讨论】：
标签：
architecture
microservices
【解决方案1】：
最终一致性之类的东西可以帮助解决这个问题，但是是的，数据的集中存储绝对会成为瓶颈。许多云解决方案通过利用在块级别而不是数据库级别复制的大型分布式数据存储来解决这个问题，从而允许即时复制（dynamodb、firestore、cosmos）。
这些类型的解决方案很难在本地解决方案中复制，cassandra 和 mongo 有不错的复制选项，但是，扩展新服务器肯定会对现有容量产生影响，并且需要仔细设计以确保您有足够的容量来进行扩展事件.
您通常不想尝试设置自己的最终一致性复制。这是可能的，但如果您当前的数据库不支持此功能，而您需要它，请切换数据库。在我的职业生涯中，我已经做过一两次（增加了复制），每次我都非常后悔。您绝对应该使用非常好的开箱即用解决方案。
TLDR；最终，使用第一个解决方案，使用可以优雅扩展的数据库并使用它的扩展功能。