无状态微服务和数据库
Stateless Micro services and database
我们有一个构建无状态微服务的需求，它依赖于数据库集群来持久化数据。
对于使用数据库集群的冗余 无状态微服务（用于高可用性和可伸缩性），推荐的方法是什么。例如：运行多份1.0版本支付服务
所有的冗余微服务应该使用一个共同的共享数据库架构还是应该有自己的架构？在独立的数据库模式的情况下，冗余服务之间可能存在不一致。
另外，在普通数据库模式的情况下如何处理模式升级？
这是一个非常宽泛的话题，很难笼统地回答。
然而...
微服务架构的一个关键要求是每个服务都应该独立于其他服务。您应该能够独立于其他服务部署、修改、改进和扩展您的微服务。
这意味着您不想共享 API 定义以外的任何内容。您当然不想共享模式；每个服务都应该能够定义自己的模式、发布新版本、更改数据类型等，而无需检查其他服务。这对于共享模式几乎是不可能的。
您可能不想共享物理服务器。共享服务器意味着您不能对可扩展性和正常运行时间做出独立承诺；微服务方法的很大一部分意味着构建它的团队也负责 运行 安装它。你真的想避免 "well, it worked in dev, so if it doesn't scale on production, it's the operations team's problem" 态度。数据库——尤其是集群的、冗余的数据库——可能很昂贵，所以如果你真的需要它，你可能在这方面妥协。
由于大多数微服务解决方案都使用容器化和云托管，因此您不太可能 "one database server to rule them all" 坐在那里。您可能会发现让每个微服务 运行 拥有自己的持久性服务比共享要好得多。
处理不一致的常用方法是接受它们 - 但使用 CQRS 在微服务之间分发数据，并确保微服务处理其内部一致性要求。
这也涉及 "should I upgrade my database when I release a new version?" 问题。如果您的观察者了解每条消息的版本，他们就可以决定如何存储它们。例如，如果 1.0 版使用与 1.1 版不同的一组属性，则侦听器可以进行映射。
在评论中，您询问一致性。这是一个超级复杂的话题——尤其是在微服务架构中。
例如，如果您有一个 "customers" 服务和一个 "orders" 服务，您必须确保所有订单都有一个有效的客户。在具有单个数据库和完全同步交互的单体应用程序中，这很容易在数据库级别实施。
在微服务架构中，你可能有很多数据存储，彼此之间没有依赖关系，并且是同步和异步调用的组合，这真的很难。这是减少微服务之间依赖的必然副作用。
最常见的方法是“eventual consistency”。这通常需要稍微不同的应用程序设计。例如，在 "orders" 屏幕上，您将首先调用客户端微服务（以获取客户端数据），然后调用 "orders" 服务（以获取订单详细信息），而不是有一个（大）检索所有内容的服务调用。
我们有一个构建无状态微服务的需求，它依赖于数据库集群来持久化数据。
对于使用数据库集群的冗余 无状态微服务（用于高可用性和可伸缩性），推荐的方法是什么。例如：运行多份1.0版本支付服务
所有的冗余微服务应该使用一个共同的共享数据库架构还是应该有自己的架构？在独立的数据库模式的情况下，冗余服务之间可能存在不一致。
另外，在普通数据库模式的情况下如何处理模式升级？
这是一个非常宽泛的话题，很难笼统地回答。
然而...
微服务架构的一个关键要求是每个服务都应该独立于其他服务。您应该能够独立于其他服务部署、修改、改进和扩展您的微服务。
这意味着您不想共享 API 定义以外的任何内容。您当然不想共享模式；每个服务都应该能够定义自己的模式、发布新版本、更改数据类型等，而无需检查其他服务。这对于共享模式几乎是不可能的。
您可能不想共享物理服务器。共享服务器意味着您不能对可扩展性和正常运行时间做出独立承诺；微服务方法的很大一部分意味着构建它的团队也负责 运行 安装它。你真的想避免 "well, it worked in dev, so if it doesn't scale on production, it's the operations team's problem" 态度。数据库——尤其是集群的、冗余的数据库——可能很昂贵，所以如果你真的需要它，你可能在这方面妥协。
由于大多数微服务解决方案都使用容器化和云托管，因此您不太可能 "one database server to rule them all" 坐在那里。您可能会发现让每个微服务 运行 拥有自己的持久性服务比共享要好得多。
处理不一致的常用方法是接受它们 - 但使用 CQRS 在微服务之间分发数据，并确保微服务处理其内部一致性要求。
这也涉及 "should I upgrade my database when I release a new version?" 问题。如果您的观察者了解每条消息的版本，他们就可以决定如何存储它们。例如，如果 1.0 版使用与 1.1 版不同的一组属性，则侦听器可以进行映射。
在评论中，您询问一致性。这是一个超级复杂的话题——尤其是在微服务架构中。
例如，如果您有一个 "customers" 服务和一个 "orders" 服务，您必须确保所有订单都有一个有效的客户。在具有单个数据库和完全同步交互的单体应用程序中，这很容易在数据库级别实施。
在微服务架构中，你可能有很多数据存储，彼此之间没有依赖关系，并且是同步和异步调用的组合，这真的很难。这是减少微服务之间依赖的必然副作用。
最常见的方法是“eventual consistency”。这通常需要稍微不同的应用程序设计。例如，在 "orders" 屏幕上，您将首先调用客户端微服务（以获取客户端数据），然后调用 "orders" 服务（以获取订单详细信息），而不是有一个（大）检索所有内容的服务调用。