最近参加公司我的项目研发，在其中发现对于数据的治理存在一些小问题，依据以往教训，在这里记录下微服务数据设计模式。
微服务架构中的服务是松耦合的，能够独立开发、部署和扩大。每个微服务都须要不同类型的数据和存储形式，也因为这样每个微服务都有本人的数据库。
一、每个服务的数据库
每个微服务都有本人的数据库，能够自由选择如何治理数据。
1.1 每个服务都有一个数据库的益处
松耦合，各自服务能够更加专一本人的业余畛域
自由选择数据库类型，如 MySQL 等 RDBMS、Cassandra 等宽列数据库、MongoDB 等文档数据库、Redis 等键值存储和 Neo4J 等图形数据库。
是否须要为每个服务应用不同的数据库服务器？这不是一个硬性要求。让咱们看看咱们能做些什么。
1.2 如果您应用的是 RDMS，那么就包含以下个性：
专用表—每个服务领有一组表，只能由该服务拜访。
专用数据库架构 —每个服务都有一个公有的数据库架构。
专用数据库服务器 —每个服务都有本人的数据库服务器。
1.3 每个服务都有一个数据库的挑战
须要连贯多个数据库的查问 —以下数据模式能够克服这一挑战。
事件溯源
API 组成
命令查问职责拆散 (CQRS)
跨多个数据库事务 —为了解决这个问题，咱们能够应用 Saga 模式。
二、事件溯源
通过事件溯源，业务实体的状态由一系列状态变动的事件跟踪。每当业务实体的状态发生变化时，都会将新事件增加到事件列表中。因为保留事件是一个繁多的操作，它实质上是原子的。通过重放事件，应用程序重建实体的以后状态。
应用程序将事件保留在事件存储中，事件存储是事件数据库。能够应用其 API 从存储中增加和检索事件。事件存储也充当音讯代理。服务能够通过其 API 订阅事件。当服务在事件存储中保留一个事件时，它会发送给所有感兴趣的订阅者。当实体有大量事件时，应用程序能够定期保留实体以后状态的快照以优化加载。应用程序查找最近的快照以及自该快照以来产生的事件以重建以后状态。这缩小了要重播的事件的数量。
2.1 事件溯源的益处
应用它解决了事件驱动架构的要害挑战之一，并使得在状态变动时牢靠地公布事件。
防止了对象关系阻抗不匹配问题，长久化事件而不是域对象。
对实体提供 100% 牢靠的审计日志。
容许执行确定实体在任何工夫点的状态的工夫查问。
基于事件溯源的业务逻辑波及替换事件的涣散耦合实体。使从单体应用程序迁徙到微服务架构变得容易得多。
2.2 事件溯源的毛病
有肯定学习老本，目前还是一种不太成熟的技术。
查问事件存储很艰难，须要一个典型的查问来重建实体状态。可能会导致低效和简单的查问。因而，应用程序必须应用命令查问职责拆散 (CQRS) 来实现查问。反过来，这意味着应用程序必须解决最终统一的数据。
三、API 组成
您能够应用 API 组合模式实现从多个服务中检索数据的查问操作。在这个模式中，通过调用领有数据的服务而后组合后果来实现查问操作。
3.1 API 组合的益处
在微服务架构中查问数据的一种便捷形式。
3.2 API 组合的毛病
有时，查问会导致大型数据集的低效内存连贯。
四、命令查问职责拆散 (CQRS)
RDBMS 通常用作记录事务零碎和文本搜寻数据库，例如用于文本搜寻查问的 Elasticsearch 或 Solr。一些应用程序通过同时写入两者来放弃数据库同步。其他人定期将数据从 RDBMS 复制到文本搜索引擎。基于此架构构建的应用程序利用了多个数据库的劣势、RDBMS 的事务属性以及文本数据库的查问能力。CQRS 概括了这种架构。
微服务架构在实现查问时面临三个常见挑战。
应用 API 组合模式检索扩散在多个服务中的数据，从而导致老本昂扬且效率低下的内存连贯。
数据以不能无效反对领有数据的服务所需查问的格局或数据库中存储。
拆散关注点意味着领有数据的服务不应该负责实现查问操作。
这三个问题都能够通过应用 CQRS 模式来解决。
CQRS 的次要指标是拆散或拆散关注点。因而，持久数据模型分为两局部：命令端和查问端。
创立、更新和删除操作由命令端模块和数据模型实现。查问由查问端模块和数据模型实现。通过订阅命令行公布的事件，查问端放弃其数据模型与命令端同步
4.1 CQRS 的益处
实现高效查问实现 —如果您应用 API 组合模式来实现查问，您可能会遇到大型数据集的高老本、低效的内存连贯。对于这些查问，应用事后来自连贯两个或更多服务数据的 CQRS 视图更无效。
可能无效实现多种查问 —通常很难应用繁多持久数据模型来反对所有查问。在 CQRS 中，定义一个或多个视图无效地实现特定查问，打消了单个数据存储的限度。
实现基于事件溯源的应用程序中查问 —CQRS 还克服了事件溯源的一个重要限度。事件存储仅反对基于主键的查问。CQRS 模式通过定义一个或多个聚合视图来解决此限度，这些视图通过订阅由事件源聚合公布的事件流来放弃最新。
关注点拆散改良 —域模型和持久数据模型不反对命令和查问。CQRS 将服务的命令和查问端拆散为独自的代码模块和数据库模式。
4.2 CQRS 的毛病
更简单的架构—为了更新和查问视图，开发者须要编写查问端服务。应用程序可能应用不同类型的数据库，这减少了开发人员和 DevOps 的复杂性。
解决复制提早 —在从命令端公布事件到由查问端处理事件以及更新视图之间存在提早。
五、Saga 模式
应用 sagas，您能够在不应用分布式事务的状况下放弃微服务架构中数据的一致性。您为跨多个服务更新数据的每个命令定义一个 saga。saga 是一系列本地事务。本地事务应用 ACID 事务框架更新单个服务中的数据。
Sagas 利用弥补事务来回滚更改。假如 saga 的第 n 个交易失败。必须吊销前 (n-1) 个事务。后果，总共 (n-1) 个弥补事务将被启动以以相同的程序回滚更改。
5.1 Saga 协调
为了实现一个 saga，它须要逻辑来协调其步骤。一旦系统命令启动了一个 saga，协调逻辑必须抉择并批示第一个 saga 执行本地事务。一旦该事务实现，编排协调就会抉择并调用下一个 saga 参与者。这个过程始终继续到传奇实现。如果本地事务失败，saga 必须以相同的程序执行弥补事务。
5.2 有几种办法能够构建 saga 的协调逻辑：
编排：在 saga 的参与者之间调配决策和排序。他们次要通过替换事件进行通信。
5.2.1 基于编排的 saga 劣势
简略性 —当创立、更新或删除业务对象时，服务会公布事件。
简略依赖关系 —不引入循环依赖关系。
松耦合 —服务实现由编排器调用的 API，因而它不须要晓得 saga 参与者公布的事件。
简化业务逻辑 —在 saga 编排器中，saga 协调逻辑是本地化的。畛域对象不晓得它们所波及的 sagas。
5.2.2 基于编排的毛病
更难了解 —编排将 saga 的实现散布在服务之间，每个服务都是独立的这就须要每个治理对每个服务都须要理解。
服务之间的循环依赖 —saga 参与者订阅彼此的事件，这通常会产生循环依赖。
严密耦合的危险 —saga 的参与者必须订阅所有影响他们的事件。
编排 —一个 saga 的协调逻辑应该集中在一个 saga 编排器类中。在 saga 期间，编排器向参与者发送命令音讯，通知他们应该执行哪些操作。