独享数据库（DatabaseperMicroservice）
当一家公司将大型单体系统替换成一组微服务，首先要面临的最重要决策是关于数据库。单体架构会使用大型中央数据库。即使转移到微服务架构许多架构师仍倾向于保持数据库不变。虽然有一些短期收益，但它却是反模式的，特别是在大规模系统中，微服务将在数据库层严重耦合，整个迁移到微服务的目标都将面临失败（例如，团队授权、独立开发等问题）。
更好的方法是为每个微服务提供自己的数据存储，这样服务之间在数据库层就不存在强耦合。这里我使用数据库这一术语来表示逻辑上的数据隔离，也就是说微服务可以共享物理数据库，但应该使用分开的数据结构、集合或者表，这还将有助于确保微服务是按照领域驱动设计的方法正确拆分的。
优点
数据由服务完全所有。
服务的开发团队之间耦合度降低。
缺点
服务间的数据共享变得更有挑战性。
在应用范围的保证ACID事务变得困难许多。
细心设计如何拆分单体数据库是一项极具挑战的任务。
何时使用独享数据库
在大型企业应用程序中。
当团队需要完全把控微服务以实现开发规模扩展和速度提升。
何时不宜使用独享数据库
在小规模应用中。
如果是单个团队开发所有微服务。
可用技术示例
所有SQL、NoSQL数据库都提供数据的逻辑分离（例如，单独的表、集合、结构、数据库）。
事件源（EventSourcing）
在微服务架构中，特别使用独享数据库时，微服务之间需要进行数据交换。对于弹性高可伸缩的和可容错的系统，它们应该通过交换事件进行异步通信。在这种情况，您可能希望进行类似更新数据库并发送消息这样的原子操作，如果在大数据量的分布式场景使用关系数据库，您将无法使用两阶段锁协议（2PL），因为它无法伸缩。而NoSQL数据库因为大多不支持两阶段锁协议甚至无法实现分布式事务。
在这些场景，可以基于事件的架构使用事件源模式。在传统数据库中，直接存储的是业务实体的当前“状态”，而在事件源中任何“状态”更新事件或其他重要事件都会被存储起来，而不是直接存储实体本身。这意味着业务实体的所有更改将被保存为一系列不可变的事件。因为数据是作为一系列事件存储的，而非直接更新存储，所以各项服务可以通过重放事件存储中的事件来计算出所需的数据状态。
图片
优点
为高可伸缩系统提供原子性操作。
自动记录实体变更历史，包括时序回溯功能。
松耦合和事件驱动的微服务。
缺点
从事件存储中读取实体成为新的挑战，通常需要额外的数据存储（CQRS模式）。
系统整体复杂性增加了，通常需要领域驱动设计。
系统需要处理事件重复（幂等）或丢失。
变更事件结构成为新的挑战。
何时使用事件源
使用关系数据库的、高可伸缩的事务型系统。
使用NoSQL数据库的事务型系统。
弹性高可伸缩微服务架构。
典型的消息驱动或事件驱动系统（电子商务、预订和预约系统）。
何时不宜使用事件源
使用SQL数据库的低可伸缩性事务型系统
在服务可以同步交换数据（例如，通过API）的简单微服务架构中。
可用技术示例
事件存储：EventStoreDB，ApacheKafka，ConfluentCloud，AWSKinesis，AzureEventHub，GCPPub/Sub，AzureCosmosDB，MongoDB，Cassandra.AmazonDynamoDB
框架：Lagom，Akka，Spring，akkatecture，Axon，Eventuate
命令和查询职责分离（CQRS）
如果我们使用事件源，那么从事件存储中读取数据就变得困难了。要从数据存储中获取实体，我们需要处理所有的实体事件。有时我们对读写操作还会有不同的一致性和吞吐量要求。
这种情况，我们可以使用CQRS模式。在该模式中，系统的数据修改部分（命令）与数据读取部分（查询）是分离的。而CQRS模式有两种容易令人混淆的模式，分别是简单的和高级的。
在其简单形式中，不同实体或ORM模型被用于读写操作，如下所示：
它有助于强化单一职责原则和分离
转载请注明：http://www.0431gb208.com/sjszjzl/1528.html
