微服务架构及其重要的10个设计模式
软件设计模式 是解决 软件设计中 常见问题的通用、可复用的解决方案。
设计模式可以分享通用词汇并使用经实战检验的方案，以免重复造轮子。现在，我将介绍一系列设计模式来实现这些最佳实践。
微服务架构的设计模式
1. 独享数据库
单体架构迁移至微服务架构过程中，如果数据库不变。 虽然有一些短期收益，但它却是反模式的，特别是在大规模系统中，微服务将在数据库层严重耦合。
整体迁移的目标将面临失败。 团队授权、独立开发等问题不能解决.
优点： 数据由服务完全所有; 服务的开发团队之间耦合度降低。
缺点：服务间的数据共享变得更有挑战性； 在应用范围的保证ACID事物变得困难许多； 细心设计如何拆分单体数据库 是一项极具挑战的任务。
衍生阅读： 分布式数存储、微服务模式：独享数据库
2. 事件源(Event Sourcing)
在微服务架构中，特别使用独享数据库时， 微服务之间需要进行数据交换，对于弹性高可伸缩的和可容错的系统，它们应该通过交换事件进行异步通信。 在这总情况， 可能希望进行类似 更新数据库并发送消息这样的原子操作
将无法使用两阶段锁协议（2PL）,以为它无法伸缩。
而NoSql数据库因为大多不支持两阶段锁协议甚至无法实现分布式事务。
在这些场景，可以基于事件的架构使用事件源模式。在传统数据库中，直接存储的是业务体当前“状态”， 而在事件源中任何“状态” 更新事件或其他重要事件都会被存储起来，而不是直接存储实体本身。
优点： 为高可伸缩系统提供原子性操作； 自动记录实体变更历史，包括时序回溯功能； 松耦合和事件驱动的微服务。
缺点： 从事件存储中读取实体成为新的挑战，通常需要额外的数据存储(CQRS模式); 系统整体复杂性增加了，通常需要领域驱动设计； 系统需要处理事件重复（幂等）或丢失； 变更事件结构成为新的挑战。
衍生阅读： 事件驱动；事件驱动模式-云设计模式； 微服务模式：事件驱动。