我们需要构建依赖数据库集群来保存数据的无状态微服务。
使用数据库集群推荐用于冗余无状态微服务（用于高可用性和可伸缩性）的方法是什么。例如：运行版本1.0的多个副本付款服务。
是否所有冗余微服务都使用通用的共享数据库架构，或者它们应该有自己的架构？在独立DB模式的情况下，可能存在冗余服务之间的不一致。
如何在通用数据库架构的情况下处理架构升级？
答案 0 :(得分：4)
这是一个超级广泛的主题，而且一般来说很难回答。
...然而
微服务架构的一个关键要求是每个服务应独立于其他服务。您应该能够独立于其他服务部署，修改，改进，扩展您的微服务。
这意味着您不希望共享API定义以外的任何内容。你当然不想共享架构;每个服务都应该能够定义自己的模式，发布新版本，更改数据类型等，而无需检查其他服务。使用共享架构几乎是不可能的。
您可能不想共享物理服务器。共享服务器意味着您无法在可伸缩性和正常运行时间方面做出独立承诺;微服务方法的很大一部分意味着构建它的团队也负责运行它。你真的想避免“好吧，它在开发中工作，所以如果它不能在生产上扩展，那就是运营团队的问题”的态度。数据库 - 尤其是群集的冗余数据库 - 可能很昂贵，因此如果您确实需要，可能会对此进行攻击。
由于大多数微服务解决方案都使用容器化和云托管，因此您不太可能拥有“一个数据库服务器来统治它们”。您可能会发现让每个微服务运行自己的持久性服务而不是共享更好。
处理不一致的常用方法是接受它们 - 但要使用CQRS在微服务之间分配数据，并确保微服务处理其内部一致性要求。
这也涉及“我在发布新版本时应该升级数据库吗？”题。如果您的观察者了解每条消息的版本，他们可以决定如何存储它们。例如，如果版本1.0使用1.1版的不同属性集，则侦听器可以执行映射。
在评论中，您询问一致性。这是一个非常复杂的主题 - 尤其是在微服务架构中。
例如，如果您有“客户”服务和“订单”服务，则必须确保所有订单都有有效客户。在单个应用程序中，使用单个数据库和专门的同步交互，这很容易在数据库级别强制执行。
在微服务架构中，您可能拥有大量数据存储，彼此之间没有依赖关系，以及同步和异步调用的组合，这真的很难。这是减少微服务之间依赖关系的不可避免的副作用。
最常见的方法是“eventual consistency”。这通常需要稍微不同的应用程序设计。例如，在“订单”屏幕上，您将首先调用客户端微服务（以获取客户端数据），然后调用“订单”服务（以获取订单详细信息），而不是单个（大）服务调用来检索一切。