微服务架构常用十种设计模式
《微服务架构常用十种设计模式》共 0.7 万字，通篇围绕 微服务、架构、数据库、安全 展开，归在「推理、部署与算力」这一层。
适合要把模型跑起来，还得跑得起的人
目录骨架（8 节）
- 独享数据库（Database per Microservice）
- 事件源（Event Sourcing）
- 命令和查询职责分离（CQRS）
- 面向前端的后端 （BFF）
- API 网关
- Strangler(扼杀者)
- 外部化配置
- 消费端驱动的契约测试
目录 · 7 节
本次分享内容
- 微服务架构
- 微服务架构的优点
- 微服务架构的缺点
- 何时使用微服务架构
- 微服务架构常用十种设计模式(包括其优缺点、用例、上下文、技术栈示例)
- 总结
微服务架构
什么是微服务架构？
微服务架构指的是将大型复杂系统按功能或者业务需求垂直切分成更小的子系统，这些子系统以独立部署的子进程存在，它们之间通过轻量级的、跨语言的同步（比如 REST，gRPC）或者异步（消息）网络调用进行通信。
下面是基于微服务架构的商业 Web 应用的组件视图：
微服务架构的重要特征：
- 整个应用程序被拆分成相互独立但包含多个内部模块的子进程。
- 与模块化的单体应用（Modular Monoliths）或 SOA 相反，微服务应用程序根据业务范围或领域垂直拆分。
- 微服务边界是外部的，微服务之间通过网络调用（RPC 或消息）相互通信。
- 微服务是独立的进程，它们可以独立部署。
- 它们以轻量级的方式进行通信，不需要任何智能通信通道。
微服务架构的优点
- 更好的开发规模。
- 更快的开发速度。
- 支持迭代开发或现代化增量开发。
- 充分利用现代软件开发生态系统的优势（云、容器、 DevOps、Serverless）。
- 支持水平缩放和细粒度缩放。
- 小体量，较低了开发人员的认知复杂性。
微服务架构的缺点
- 更高数量级的活动组件（服务、数据库、进程、容器、框架）。
- 复杂性从代码转移到基础设施。
- RPC 调用和网络通信的大量增加。
- 整个系统的安全性管理更具有挑战性。
- 整个系统的设计变得更加困难。
- 引入了分布式系统的复杂性。
何时使用微服务架构
- 大规模 Web 应用开发。
- 跨团队企业级应用协作开发。
- 长期收益优先于短期收益。
- 团队拥有能够设计微服务架构的软件架构师或高级工程师。
微服务架构常用十种设计模式
独享数据库（Database per Microservice）
当一家公司将大型单体系统替换成一组微服务，首先要面临的最重要决策是关于数据库。单体架构会使用大型中央数据库。即使转移到微服务架构许多架构师仍倾向于保持数据库不变。虽然有一些短期收益，但它却是反模式的，特别是在大规模系统中，微服务将在数据库层严重耦合，整个迁移到微服务的目标都将面临失败（例如，团队授权、独立开发等问题）。
更好的方法是为每个微服务提供自己的数据存储，这样服务之间在数据库层就不存在强耦合。这里我使用数据库这一术语来表示逻辑上的数据隔离，也就是说微服务可以共享物理数据库，但应该使用分开的数据结构、集合或者表，这还将有助于确保微服务是按照领域驱动设计的方法正确拆分的。
优点
- 数据由服务完全所有。
- 服务的开发团队之间耦合度降低。
缺点
- 服务间的数据共享变得更有挑战性。
- 在应用范围的保证 ACID 事务变得困难许多。
- 细心设计如何拆分单体数据库是一项极具挑战的任务。
何时使用独享数据库
- 在大型企业应用程序中。
- 当团队需要完全把控微服务以实现开发规模扩展和速度提升。
何时不宜使用独享数据库
- 在小规模应用中。
- 如果是单个团队开发所有微服务。
可用技术示例
所有 SQL、 NoSQL 数据库都提供数据的逻辑分离（例如，单独的表、集合、结构、数据库）。
事件源（Event Sourcing）
在微服务架构中，特别使用独享数据库时，微服务之间需要进行数据交换。对于弹性高可伸缩的和可容错的系统，它们应该通过交换事件进行异步通信。在这种情况，您可能希望进行类似更新数据库并发送消息这样的原子操作，如果在大数据量的分布式场景使用关系数据库，您将无法使用两阶段锁协议（2PL），因为它无法伸缩。而 NoSQL 数据库因为大多不支持两阶段锁协议甚至无法实现分布式事务。
在这些场景，可以基于事件的架构使用事件源模式。在传统数据库中，直接存储的是业务实体的当前 “状态”，而在事件源中任何“状态” 更新事件或其他重要事件都会被存储起来，而不是直接存储实体本身。这意味着业务实体的所有更改将被保存为一系列不可变的事件。因为数据是作为一系列事件存储的，而非直接更新存储，所以各项服务可以通过重放事件存储中的事件来计算出所需的数据状态。
优点
- 为高可伸缩系统提供原子性操作。
- 自动记录实体变更历史，包括时序回溯功能。
- 松耦合和事件驱动的微服务。
缺点
- 从事件存储中读取实体成为新的挑战，通常需要额外的数据存储（CQRS 模式）。
- 系统整体复杂性增加了，通常需要领域驱动设计。
- 系统需要处理事件重复（幂等）或丢失。
- 变更事件结构成为新的挑战。
何时使用事件源
- 使用关系数据库的、高可伸缩的事务型系统。
- 使用 NoSQL 数据库的事务型系统。
- 弹性高可伸缩微服务架构。
- 典型的消息驱动或事件驱动系统（电子商务、预订和预约系统）。