作者：Grey
原文地址: 微服务架构设计模式概述
说明
本文内容是《微服务架构设计模式》这本书的学习笔记
单体应用转换成微服务可以考虑的几个维度
SOA和微服务的区别
| SOA | 微服务 | |
|---|---|---|
| 协议 | 重量级（SOAP,WS*) | REST或者RPC |
| 数据管理 | 共享数据库 | 每个服务都有自己的数据模型和数据库 |
| 典型服务规模 | 较大的单体 | 较小的服务 |
模式之间的基本关系和符号表示
前导(Predecessor)
前导模式是催生这个模式的需求的模式，例如，微服务架构模式是除单体架构模式以外整个模式语言中所有模式的前导模式。
后续（Successor)
后续模式是指用来解决当前模式引入的新问题的模式，例如，如果你采纳了微服务架构模式，你需要一系列的后续模式来解决诸如服务发现、断路器等微服务带来的新问题。
替代(Alternative)
当前模式的替代模式，提供了另外的解决方案，例如，单体架构和微服务架构就是互为替代的模式，它们都是应用的架构风格。你可以选择其一
泛化（Generalization)
针对一个问题的一般性解决方案。例如: “每主机单个服务”这个模式存在多种不同的技术实现。
特化（Specialization）
针对特定模式的具体解决方案。例如: 将服务部署为容器模式是针对“每主机单个服务”的具体解决方案。
符号说明：
基于上述符号，我们可以用图例来表示微服务架构中各个环节的相关模式
服务拆分的相关模式
-
按功能组织服务
-
根据子域分解服务（DDD）
示例图
服务通信模式
通信风格
使用哪一类进程间通讯机制
服务发现
客户端如何获得服务具体实例（如HTTP请求）的IP地址
可靠性通信
在服务不可用的情况下，如何确保服务之间的可靠通讯
事务性消息
如何将消息发送，事件发布这样的动作与更新业务数据库的数据库事务集成
外部API
应用程序的客户端如何与服务进行通信
实现事务管理的数据一致性相关模式
为了保证松耦合，每个服务必须拥有自己的数据库，因此，需要使用Saga模式来确保数据一致性
在微服务架构中查询数据的相关模式
有两种：
-
API组合
微服务部署的相关模式
可观测的相关模式
健康检查API
可以返回服务健康状态的APIO
日志聚合
把服务产生的日志写人一个集中式的日志服务器，这个服务器可以提供日志搜索，也可以根据日志情况触发报警。
分布式追踪
为每一个外部请求分配一个唯一的ID，用于在各个服务之间追踪外部请求。
异常跟踪
把程序异常发送到异常跟踪服务，这个服务会排除重复异常，给开发者发送告警并且跟踪每一个异常的解决。
应用指标
供维护使用的指标，例如计数器等，导出到指标服务器。
审计日志
记录用户的行为。
实现服务自动化测试的相关模式
消费端驱动的契约测试
验证服务满足客户端所期望的功能
消费端契约测试
验证服务的客户端可以正常与服务通信
服务组件测试
在隔离的环境中测试服务。
解决基础设施和边界问题的相关模式
该模式在运行时向服务提供数据库凭据等配置参数。在开发新服务时，从头开始重新实现这些功能是在太费时间了。
安全相关的模式
在微服务架构中，用户身份验证的工作通常由API Gateway完成。然后，它必须将有关用户的信息（例如身份和角色）传递给它调用的服务。常见的解决方案是应用访问令牌模式。API Gateway将访问令牌（例如JWT，即JSON web令牌）传递给服务，这些服务可以验证令牌并获取有关用户的信息。