最近参与公司的项目研发，发现数据管理上的一些小问题。根据以往经验，微服务数据设计模式记录于此。微服务架构中的服务是松耦合的，可以独立开发、部署和扩展。每个微服务都需要不同类型的数据和存储，因此每个微服务都有自己的数据库。1、每个服务的数据库每个微服务都有自己的数据库，你可以自由选择如何管理数据。1.每个服务都有数据库的好处。松散耦合，每个服务可以更专注于自己的专业领域。自由选择数据库类型，如MySQL等RDBMS、Cassandra等宽列数据库、MongoDB等文档数据库、Redis等键值存储、Neo4J等图数据库。我是否需要为每个服务使用不同的数据库服务器？这不是硬性要求。让我们看看我们能做什么。2.如果您使用的是RDMS，则包括以下功能：私有表-每个服务都有一组只能由该服务访问的表。专用数据库模式-每个服务都有一个私有数据库模式。专用数据库服务器——每项服务都有自己的数据库服务器。3.每个服务拥有一个数据库的挑战需要连接到多个数据库的查询——以下数据模式可以克服这一挑战。EventSourcingAPIcompositionCommandQueryResponsibilitySeparation(CQRS)acrossmultipledatabasetransactions—为了解决这个问题，我们可以使用Saga模式。2.事件可追溯性通过事件可追溯性，业务实体的状态由一系列状态变化事件来跟踪。每当业务实体的状态发生变化时，都会将新事件添加到事件列表中。由于保存一个事件是一个单一的操作，它本质上是原子的。通过重放事件，应用程序重建实体的当前状态。应用程序将事件保存在事件存储中，这是一个事件数据库。可以使用其API从存储中添加和检索事件。事件存储还充当消息代理。服务可以通过它们的API订阅事件。当服务在事件存储中保存事件时，它会发送给所有感兴趣的订阅者。当实体有大量事件时，应用程序可以定期保存实体当前状态的快照以优化加载。应用程序查找最近的快照和自该快照以来发生的事件以重建当前状态。这减少了要重放的事件数。1.事件溯源的好处使用它解决了事件驱动架构的关键挑战之一，并在状态发生变化时实现了事件的可靠发布。通过持久化事件而不是域对象来避免对象关系阻抗失配问题。为实体提供100%可靠的审计日志。允许执行临时查询以确定实体在任何时间点的状态。基于事件溯源的业务逻辑涉及交换事件的松耦合实体。使从单体应用程序迁移到微服务架构变得更加容易。2、事件溯源的缺点是有一定的学习成本，目前还是一项不成熟的技术。查询事件存储很困难，需要典型的查询来重建实体状态。可能导致低效和复杂的查询。因此，应用程序必须使用命令查询责任分离（CQRS）来实现查询。反过来，这意味着应用程序必须处理最终一致的数据。3.APIComposition您可以使用API??Composition模式来实现从多个服务中检索数据的查询操作。在此模式中，查询操作是通过调用拥有数据的服务然后组合结果来实现的。1.API组合的好处在微服务架构中查询数据的一种便捷方式。2.API组合的缺点有时，查询会导致大型数据集的内存连接效率低下。4.命令查询职责分离（CQRS）RDBMS通常用作记录和文本搜索数据库的事务系统，例如用于文本搜索查询的Elasticsearch或Solr。一些应用程序通过同时写入两个数据库来保持数据库同步。其他人定期将数据从RDBMS复制到文本搜索引擎。基于此架构构建的应用程序利用了多个数据库、RDBMS的事务属性以及文本数据库的查询功能。CQRS概括了这种架构。微服务架构在实现查询时面临三个常见挑战。使用API组合模式检索分散在多个服务中的数据，从而导致内存中连接成本高且效率低下。数据以无法有效支持拥有数据的服务所需的查询的格式或数据库存储。关注点分离意味着拥有数据的服务不应该负责实现查询操作。这三个问题都可以通过使用CQRS模式来解决。CQRS的主要目标是分离或分离关注点。因此，持久化数据模型分为命令端和查询端两部分。创建、更新和删除操作由命令端模块和数据模型实现。查询由查询端模块和数据模型实现。通过订阅命令行发布的事件，查询端保持其数据模型与命令端同步1.CQRS实现高效查询的好处——如果使用API??组合方式实现查询，可能会遇到高成本对于大数据集，内存连接效率低下。对于这些查询，使用预先连接来自两个或多个服务的数据的CQRS视图会更有效。能够有效地实现多种类型的查询——通常很难用单一的持久数据模型支持所有查询。在CQRS中，定义了一个或多个视图以高效地实现特定查询，从而消除了单个数据存储的限制。启用基于事件溯源的应用程序内查询——CQRS还克服了事件溯源的一个重要限制。事件存储只支持基于主键的查询。CQRS模式通过定义一个或多个聚合视图来解决这一限制，这些视图通过订阅事件源聚合发布的事件流来保持最新。关注点分离改进——域模型和持久数据模型不支持命令和查询。CQRS将服务的命令端和查询端分离为单独的代码模块和数据库模式。2.CQRS的缺点更复杂的架构——为了更新和查询视图，开发者需要编写查询端服务。应用程序可能使用不同类型的数据库，增加了开发人员和DevOps的复杂性。处理复制滞后——在命令端发布事件与查询端处理事件和更新视图之间存在延迟。5.Saga模式使用sagas，可以在不使用分布式事务的情况下保持微服务架构中的数据一致性。您为跨多个服务更新数据的每个命令定义一个saga。saga是一系列本地事务。本地事务使用ACID事务框架更新单个服务中的数据。Sagas利用补偿事务来回滚更改。假设saga的第n个事务失败。必须撤消前(n-1)个事务。因此，将启动总共(n-1)个补偿事务以逆序回滚更改。1.Saga协调为了实现一个saga，它需要逻辑来协调它的步骤。一旦系统命令启动了一个saga，协调逻辑必须选择并指示第一个saga执行本地事务。一旦该事务完成，编排协调器就会选择并调用下一个saga参与者。这个过程一直持续到图例完成。如果本地事务失败，saga必须以相反的顺序执行补偿事务。2.有几种方法可以构建saga的协调逻辑：Orchestration：在saga的参与者之间分配决策和排序。他们主要通过交换事件进行交流。(1)基于编排的saga优势简单——服务在创建、更新或删除业务对象时发布事件。简单依赖-没有引入循环依赖。松散耦合——该服务实现了一个由编排器调用的API，因此它不需要了解saga参与者发布的事件。简化业务逻辑——在sagaorchestrator中，saga协调逻辑是本地化的。Domainobjects并不知道它们所涉及的sagas。(2)基于orchestration的缺点更难理解——orchestration将saga的实现分布在服务之间，每个服务都是独立的，这就需要每个管理了解每个服务。服务之间的循环依赖-saga参与者订阅彼此的事件，这通常会产生循环依赖。紧耦合的风险——saga中的参与者必须订阅影响他们的所有事件。Orchestration——saga的协调逻辑应该集中在sagaorchestrator类中。在saga期间，编排器向参与者发送命令消息，告诉他们应该执行什么操作。
