Keynote 原件地址
帮助架构师使用微服务构建应用程序的一组模式
模式应用过程
1. 需求分析
- 确定必须要解决的问题
- 并按优先级进行排序
注意：并不是所有需求都必须要解决，可能有些需求之间是有冲突的，此时优先解决高优先级的需求
2. 候选模式
根据需求分析结果，结合各个模式所适用的上下文场景，选择合适的模式。作为进一步评估的候选项。
软件模式：通过定义一组互相协作的软件元素来解决软件架构或设计问题
3. 评估结果
对候选模式进行评估：
- 好处：这个模式的好处和它解决了什么需求
- 弊端：这个模式的弊端和它没有解决哪些需求
- 问题：使用这个模式所引入的新问题
4. 确定模式
结合评估结果和模式关系，确定最终(一组)模式
模式关系：
- 前导：催生当前模式需求的模式
- 后续：解决当前模式引入的新问题的模式
- 替代：当前模式的替代模式
- 泛化：针对某个问题的一般性解决方案
- 特化：针对特定模式的具体解决方案
微服务架构设计模式
如何拆分服务？
拆分方法：
- 识别系统操作
- 根据业务能力/子域进行服务拆分
- 定义服务API
根据业务能力进行服务拆分
- 描述：定义与业务能力相对应的服务
- 业务能力：能够为公司产生价值的商业活动
根据子域进行服务拆分
- 描述：根据DDD的子域设计服务
服务间如何进行通信？
同步远程过程调用模式
- 通信方式：REST、gRPC
- 配套设施：断路器，服务发现
异步消息模式
- 通信方式：点对点、发布订阅
- 配套设施：消息代理
- 弊端：需要保障顺序；处理重复消息、事务
如何管理事务？
分布式事务
- 描述：基于二阶段提交的XA
- 弊端：不支持NoSQL，降低可用性
Saga事务
- 描述：通过使用异步消息来协调本地事务
- 弊端：缺少默认隔离性，需要额外实现。例如：语义锁、交换式更新、悲观视图、重读值、版本文件、业务风险评级
如何组织业务逻辑？
事务脚本模式
- 描述：将业务逻辑组织为面向过程的事务脚本的集合，每种类型的请求都有一个脚本
- 弊端：仅适用于简单的业务逻辑
领域模型模式
- 描述：将业务逻辑组织为由具有状态和行为的类构成的对象模型
- 弊端：适用较复杂业务；高复杂业务需要借助DDD
如何持久化数据？
传统持久化
- 描述：将类与数据表进行映射
- 弊端：类模型与表模型不匹配、缺乏历史、审计繁琐、不支持发布领域事件
事件溯源
- 描述：使用一系列表示状态改变的领域事件来持久化聚合
- 弊端：实现复杂，学习难度高
- 前导模式：DDD中的领域事件
如何查询数据？
API组合
- 描述：查询每个服务的API并组合结果
- 弊端：额外开销，降低可用性，缺少事务
CQRS
- 描述：适用事件来维护多个服务复制数据的只读视图
- 弊端：架构复杂、数据复制导致延迟
- 前导模式：事件溯源
如何对外提供服务？
API网关
- 描述：针对API的外观模式。提供路由、API组合、协议转换、专用API、边缘功能（身份认证、访问授权、速率限制、缓存、指标收集、请求日志）
- 弊端：可能成为瓶颈
如何部署服务？
编程语言特定的发布包格式
- 描述：例如Java中的Jar、War
虚拟机
- 描述：作为虚拟机镜像部署
容器
- 描述：作为容器镜像部署，例如：Docker
Serverless
- 描述：使用公共云提供的Serverless部署
如何进行测试？
消费者驱动的契约测试
- 描述：验证服务是否满足它的消费者的期望
如何保障非功能性约束？
安全性
- 描述：基于安全令牌实现安全性
可配置性
- 描述：基于推送/拉取实现可配置性
可观测性
- 描述：基于健康检查API、日志聚合、分布式跟踪、异常跟踪、应用程序指标、审核日志记录实现可观测性
如何将单体重构为微服务？
绞杀者应用
- 描述：在遗留系统周围逐步开发新的（绞杀）应用