Tec*_*ast 3 database high-availability distributed-computing stateless microservices
我们需要构建无状态微服务，该服务依赖数据库集群来持久化数据。
对于使用数据库集群的冗余无状态微服务（以实现高可用性和可伸缩性），建议使用哪种方法？例如：运行1.0版付款服务的多个副本。
所有冗余微服务都应该使用公共共享数据库架构还是应该有自己的架构？如果是独立的DB模式，则冗余服务之间可能存在不一致。
另外，在使用通用数据库模式的情况下，如何处理模式升级？
这是一个非常广泛的话题，而且很难用一般的术语回答。
然而...
对微服务体系结构的关键要求是每个服务应独立于其他服务。您应该能够独立于其他服务来部署，修改，改进，扩展您的微服务。
这意味着除了API定义之外，您不希望共享其他任何内容。您当然不希望共享模式。每个服务都应该能够定义自己的架构，发布新版本，更改数据类型等，而不必与其他服务进行核对。对于共享模式，这几乎是不可能的。
您可能不想共享物理服务器。共享服务器意味着您无法就可扩展性和正常运行时间做出独立的承诺。微服务方法的很大一部分意味着，构建微服务的团队还负责运行它。您真的想避免“很好，它可以在开发人员中使用，因此，如果不按生产规模扩展，那就是运营团队的问题”的态度。数据库-尤其是集群的冗余数据库-可能会很昂贵，因此如果您确实需要此功能，则可以妥协。
由于大多数微服务解决方案都使用容器化和云托管，因此您几乎不可能拥有“一台数据库服务器来统治所有服务器”。您可能会发现让每个微服务运行自己的持久性服务而不是共享会更好。
处理不一致的常见方法是接受它们-但使用CQRS在微服务之间分发数据，并确保微服务满足其内部一致性要求。
这也涉及“发布新版本时应该升级数据库吗？” 题。如果您的观察者了解每种消息的版本，则可以决定如何存储它们。例如，如果版本1.0使用与版本1.1不同的属性集，则侦听器可以执行映射。
在评论中，您询问一致性。这是一个非常复杂的主题，尤其是在微服务体系结构中。
例如，如果您具有“客户”服务和“订单”服务，则必须确保所有订单都具有有效的客户。在具有单个数据库和独占同步交互的单片应用程序中，这很容易在数据库级别上实施。
在微服务架构中，您可能有很多数据存储，彼此之间没有依赖关系，并且同步调用和异步调用相结合，这确实很困难。这是减少微服务之间的依赖性的不可避免的副作用。
最常见的方法是“ 最终一致性 ”。这通常需要稍微不同的应用程序设计。例如，在“订单”屏幕上，您将首先调用客户端微服务（以获取客户端数据），然后调用“订单”服务（以获取订单详细信息），而不是调用单个（大型）服务来检索一切。