无状态微服务和数据库

Question

我们需要构建依靠数据库集群来保存数据的无状态微服务。

对于使用数据库集群的冗余无状态微服务（为了高可用性和可伸缩性），推荐使用什么方法。例如：运行版本1.0的多个副本付款服务。

如果所有冗余微服务使用一个共享数据库架构还是应该有自己的模式？在冗余服务之间可能存在独立的DB架构不一致的情况下。

还怎么能模式升级中常见的数据库架构的情况下，如何处理？

Answer 1

这是一个超级广泛的话题，并比较硬笼统回答。

但是......

中的微服务架构的一个关键要求是，每个服务应该是独立于他人。您应该能够独立于其他人部署，修改，改进和扩展您的微服务。

这意味着你不希望共享比API定义的任何其他。你当然不想共享一个模式;每个服务都应该能够定义自己的模式，发布新版本，更改数据类型等，而无需与其他服务进行核对。使用共享模式几乎不可能。

您可能不想共享物理服务器。共享服务器意味着您无法对可扩展性和正常运行时间做出独立承诺;微服务方法的很大一部分意味着构建它的团队也负责运行它。你真的想要避免“好，它在开发中的作用，所以如果它没有扩大生产规模，这是运营团队的问题”的态度。数据库 - 特别是集群冗余数据库 - 可能很昂贵，所以如果你真的需要这个，你可能会在这个问题上妥协。

由于大多数微服务解决方案采用集装箱化和云托管，这是相当不可能的，你必须在“一个数据库服务器来统治他们”坐在一旁。您可能会发现让每个微服务运行自己的持久性服务而不是共享会更好。

处理不一致的常见方法是接受它们 - 但要使用CQRS在微服务之间分发数据，并确保微服务处理其内部一致性要求。

这也涉及“当我发布新版本时应该升级数据库吗？”题。如果你的观察者了解每条消息的版本，他们可以决定如何存储它们。例如，如果版本1.0使用与版本1.1不同的一组属性，则侦听器可以执行映射。

在评论中，你问的是一致性。这是一个超级复杂的话题 - 尤其是在微服务体系结构中。

如果你有，例如，一个“大客户”服务和“订单”的服务，你必须确保所有的订单有一个有效的客户。在单一应用程序中，使用单个数据库和专门的同步交互，可以很容易地在数据库级别实施。

在微服务体系结构中，您可能拥有大量数据存储，彼此之间没有依赖关系，同时还有异步和异步调用的组合，这确实很难。这是减少微服务之间依赖关系的不可避免的副作用。

最常用的方法是“eventual consistency”。这通常需要稍微不同的应用程序设计。例如，在“订单”屏幕上，您将首先调用客户端微服务（获取客户端数据），然后调用“订单”服务（以获取订单详细信息），而不是通过单个（大型）服务调用来检索一切。