微服务架构设计模式思维导图模板_ProcessOn思维导图、流程图

1、了解微服务和单体

1、单体架构的好处

1、应用开发简单

2、易于对应用程序进行大规模更改

3、测试相对简单直观

4、部署简单明了

5、横向扩展不费吹灰之力

2、单体架构的弊端

1、敏捷开发和部署问题

2、过度的复杂性会影响开发

3、开发速度缓慢、IDE

4、从代码提交到实际部署周期长、且容易出现问题

5、不同业务模块对资源需求不一样、横向扩展后会导致资源浪费

6、交付可靠性、无法进行全面彻底的测试

7、需要长期依赖某个过时的技术栈

3、微服务架构的好处

1、使大型的复杂应用程序可以持续交付和持续部署

1、特性：可测试性、可部署性、自主松耦合

2、价值：缩短了产品的上市时间，快速响应客户；给客户提供可靠的服务；员工满意度更高，提供价值而不是担当救火队

2、每个服务都相对较小并容易维护

3、服务可以独立部署、独立扩展

4、微服务架构可以实现团队自治

5、更容易实验和采纳新的技术

6、更好的容错性

4、微服务架构的弊端

1、服务的拆分和定义

噩梦：一个包含了一大堆互相之间紧耦合的服务，却又必须部署在一起的所谓的分布式系统

2、分布式系统带来的复杂性，使开发、测试、部署变得更困难

进程通信机制；分布式事务；API组合或CQRS视图；IDE开发；自动化测试；运维系统

3、当部署跨越多个服务的功能时需要谨慎地协调更多的开发团队

谨慎制定发布计划，依赖排序后进行发版

4、开发者需要思考到底应该再应用的什么阶段使用微服务架构

5、模式和模式语言

1、模式概述

1、模式是针对特定上下文中发生的问题的可重用解决方案

2、模式必须描述它适用的上下文场景

3、结构

1、需求

1、必须解决的问题

2、围绕这个问题的特定上下文环境

2、结果上下文

采用模式后可能带来的后果，好处、弊端、引入的新问题

3、相关模式：存在五种不同类型的关系

1、前导：前置条件、是催生这个模式的需求

2、后续：解决当前问题引入的新问题

3、替代：提供了另外的可替代的解决方案

4、泛化：针对一个问题的一般性解决方案

5、特化：针对特定问题的具体解决方案

2、模式语言概述（1.6.3 图1-10）

1、服务拆分的相关模式

2、通信相关模式

通信风格；服务发现；可靠性；事务性消息；外部API

3、实现事务管理的数据一致性相关模式

4、在微服务架构中查询数据的相关模式

5、服务部署的相关模式

6、可观测性的相关模式

健康检查Api；日志聚合；分部式追踪；异常追踪；应用指标（CPU，MEM）；审计日志

7、实现服务自动化测试的相关模式

1、消费端驱动的契约模式：验证服务满足客户端所期望的功能

2、消费端契约模式：验证服务的客户端可以正常与服务通信

3、服务组件测试：在隔离的环境中测试服务

8、解决基础设施和边界问题的相关模式

可观测性模式、服务发现模式、外部化配置模式，微服务基底模式

9、安全相关模式

访问令牌模式JWT

6、流程和组织

1、软件开发和交付的组织：自治团队，部门团队、组织团队

2、软件开发和交付的流程：瀑布式开发、面接开发

3、采用微服务架构时的人为因素

2、微服务拆分策略

1、什么是微服务架构

1、软件架构的4+1视图模型

1、逻辑视图：类和包之间的关系，包括继承、关联、依赖

2、实现视图：由模块和组件组成，微服务之间的关系

3、进程视图：进程间的关系

4、部署视图：进程如何映射到机器、机器之间的网络关系

5、场景：比如一次请求，即需求

2、架构的重要性

1、功能性需求：用例或者用户故事

2、非功能性需求：质量属性，可维护性，可测试性，可扩展性和可部署性

3、架构风格

1、分层式架构

1、层级

1、表现层：用户界面或外部API代码

2、业务逻辑层

3、数据持久化层

2、弊端

1、单一表现层：无法展现应用程序可能不仅仅有单个系统调用的事实

2、单一数据持久化层：无法展现应用程序可能与多个数据库进行交互的事实

3、将业务逻辑层定义为一拉与数据持久化层：这样的依赖性会妨碍在没有数据库的情况下测试业务逻辑

2、六边形架构

可以有多个入站和出站的适配器 gateway 各个微服务

将业务逻辑与表示层和数据访问层分离

4、微服务架构风格

1、共享类库 maven npm

2、单个微服务

3、松耦合

4、服务大小并不重要，不能聚焦到微上

2、为应用程序定义微服务架构

1、设计三步骤

1、定义系统操作

2、定义服务

3、定义服务API和协作方式

2、识别系统操作

1、定义系统操作

1、创建抽象领域模型

2、定义系统操作

1、命令型：创建更新或删除

2、查询型：查询和读取

2、根据业务能力进行微服务拆分

1、业务能力定义了一个组织的工作

2、识别业务能力

3、从业务能力到服务

3、根据子域进行拆分

DDD、限界上下文

4、拆分指导原则

1、单一职责原则

2、闭包原则

5、拆分难点

1、网络延迟

2、同步进程间通信导致可用性降低

3、在服务之间维持数据一致性

4、获取一致的数据视图

5、上帝类阻碍拆分

6、定义服务API

1、把系统操作分配给服务

2、确定支持服务协作所需要的API

3、微服务架构中的进程间通信

1、微服务间的进程通信

1、交互方式

1、维度1：指的时微服务处理数量，每个客户端请求由一个服务实例来处理还是多个

1、一对一

1、请求/响应

2、异步请求/响应

3、单向通知

2、一对多

1、发布/订阅方式

2、发布/异步响应方式、比如数据处理结果回更数据状态等

2、维度2：同步和异步

客户端请求需要服务端实时响应还是非实时响应、保证最终一致性

2、在微服务架构中定义API

API设计优先，进程间通信机制。比如：使用http，使用消息机制

3、API的演化

1、语义化版本控制

1、MAJOR：当你对API进行不兼容更改

2、MINOR：当你对API进行向后兼容的增强

3、PATCH：当你进行向后兼容的错误修复

2、进行次要并且向后兼容的改变

1、添加可选属性

2、向响应添加属性

3、添加新操作

3、进行主要并且不向后兼容的改变

4、消息的格式

1、基于文本的消息格式：JSON和XML

2、二进制消息的格式

1、Protocal Buffers：使用tagged fields（带标记的字段）

2、Avro：需要消费者解析消息之前知道它的格式

2、基于同步远程过程调用模式的通信

1、使用REST

1、REST成熟度模型

1、Level0：只是向服务端点发起HTTP POST请求，进行服务调用，每个请求都指明了需要执行的操作

2、Level：引入了资源的概念。要执行对资源的操作，客户端需要发出指定要执行的操作和包含任何参数的POST请求

3、Level3：基于HATEOAS原则设计

2、定义REST API：使用接口定义语言（IDL）定义API

3、在一个请求中获取多个资源的挑战

1、GraphQL

2、Netflix Falcor

4、把操作映射为HTTP动词的挑战

5、REST的好处

1、简单熟悉

2、使用拓展插件、比如Postman或者curl来测试

3、支持请求/响应方式的同信

4、HTTP对防火墙比较友好

5、不需要中间代理，简化了系统架构

6、REST的弊端

1、只支持请求/响应方式的通信

2、可能导致可用性降低，需要保持在线

3、客户端必须要知道服务实例的位置

4、在单个请求中获取多个资源具有挑战性

5、有时很难将多个更新操作映射到HTTP动词

2、使用gRPC

1、好处

1、设计具有更复杂更新操作的API非常简单

2、具有高效、紧凑的进程间通信机制、尤其时在交换大量消息时

3、支持在远程过程调用和消息传递过程中使用双向流式消息方式

2、弊端

1、与基于REST的API机制相比、JavaScript客户端使用基于gRPC的API需要做更多的工作

2、旧式防火墙不支持HTTP/2

3、使用断路器模式处理局部故障

1、开发可靠的远程过程调用代理

1、网络超时问题

2、限制客户端向服务器发出请求的数量

3、断路器模式

2、在服务失效故障中恢复

4、使用服务发现

1、实现服务发现的两种主要方式

1、应用层服务发现模式：服务及其客户直接与服务注册表交互

1、自注册模式，监测心跳，防止过期

2、客户端发现模式，可进行负载平衡

4、优势：可以处理多平台部署的问题、可跨环境

5、劣势：若有其它编程语言，就必须找到其他一些服务发现的框架

2、通过部署基础设施来处理服务发现

1、第三方注册模式：由第三方负责也就是注册服务器，

2、服务端发现模式：DNS名称发出请求，对该DNS名称的请求被剖析路由

3、基于异步消息模式的通信

1、什么时消息传递

1、关于消息

1、构成

1、消息头部

2、消息主题

2、类型

1、文档：仅包含数据的通用消息，接收者决定如何使用

2、命令：指定要调用的操作及其参数

3、事件：发送方发送事件。表示领域对象状态的更改

2、关于消息通道

1、点对点通道

2、发布-订阅通道

2、使用消息机制实现交互方式

1、实现请求/响应和异步请求/响应

2、实现单向通知

3、实现发布/订阅

4、实现发布/异步响应

3、为基于消息机制的服务API创建API规范

1、记录异步操作

1、请求/异步响应式API

2、单向通知式API

2、记录事件发布

4、使用消息代理

1、无代理消息

1、好处

1、允许更轻的网络流量和耕地的延迟

2、消除了消息代理可能成为性能瓶颈或单点故障的可能性

3、具有较低的操作复杂性

2、弊端

1、服务需要了解彼此的位置

2、会导致可用性降低，因为需要保证发送方和接收方同时在线

3、在实现例如确保消息能够成功投递这些复杂功能是的挑战性更大

2、基于代理的消息

1、开源代理

1、Apache ActiveMQ

2、RabbitMQ

3、Apache Kafka

4、Alibaba RoceketMQ

5、AWS Kinesis

6、AWS SQS

2、考虑因素

1、支持的编程语言

2、支持的消息标准：AMQP和STOMP，或者特有的消息标准

3、消息排序

4、投递保证

5、持久性：崩溃恢复

6、耐久性：如果接收方重新连接消息代理，是否会收到断开连接时发送的消息

7、可拓展性

8、延迟：端到端

9、竞争性（并发）接收方：是否支持竞争性接收方

3、使用消息代理实现消息通道

1、队列

2、主题

3、交换+队列

4、流

4、好处

1、松藕合

2、消息缓存

3、灵活通信

4、明确的进程间通信，比如：宕机

5、弊端

1、潜在的性能瓶颈

2、潜在的单点故障

3、额外的操作复杂性

5、处理并发和消息顺序

1、分片通道由两个或多个分片组成，每个分片类似于一个通道

2、发送方在消息头部指定分片键。消息代理使用分片键将消息分配给特定的分片

3、消息代理将接收方的多个实例组合在一起。Kakfa的消费者组

6、处理重复消息

1、编写幂等消息处理程序

2、跟踪消息并丢弃重复项

7、事务性消息

1、使用数据库表作为消息队列

2、通过轮询模式发布事件：轮询会造成昂贵的开销

3、使用事务日志拖尾模式发布事件

1、Debezium

2、LinkedIn Databus

3、DynamoDB streams

4、Eventuate Tram

8、消息相关的类库和框架

1、使用类库的问题

1、客户端将发布消息的业务逻辑耦合导消息代理API

2、消息代理的客户端库通常是非常底层的，需要多行代码才能发送或接收消息

3、客户端库通常只提供发送和接收消息的基本机制，不支持更高级别的交互方式

2、使用框架需要实现两个重要机制

1、事务性消息机制、将消息作为数据库事务的一部分发布

2、重复消息检测机制

3、基础消息API

4、领域事件发布API

5、基于命令/回复的消息

4、使用异步消息提供可用性

1、同步消息降低可用性

2、消除同步交互

1、使用异步交互模式

2、复制数据：维护数据副本

3、先返回响应、再完成处理

4、使用Saga事务ACD

1、微服务架构下的事务管理

1、微服务架构对于分布式事务的需求

2、分布式事务的挑战

1、NoSQL并不支持XA标准的分布式事务

2、同步进程间通信会降低分布式系统的可用性

3、使用Saga模式维护数据一致性

Saga使用补偿事务来回滚所做出的改变

2、Saga的协调模式

1、协同式Saga：把Saga的决策和执行顺序逻辑分布在Saga的每一个参与方中，通过交换时间的方式来进行沟通

1、可靠的事件通信

1、确保Saga参与方将更新其本地数据库和发布事件作为数据库事务的一部分

2、确保Saga参与方必须能够将接收到的每个事件映射到自己的数据上

2、好处

1、简单：服务在创建、更新或删除业务对象时发布事件

2、松耦合：参与方订阅事件并且彼此之间不会因此而产生耦合

3、弊端

1、难以理解：因为Saga的逻辑分布在每个服务的实现中

2、服务之间的循环依赖关系

3、紧耦合的风险

2、编排式Saga：把Ssaga的决策和执行顺序逻辑集中在一个Saga编排器中，中控、代理

1、把Saga编排器视作一个状态机

2、Saga编排和事务性消息

3、好处

1、更简单的依赖关系

2、较少的耦合

3、改善关注点隔离，简化业务逻辑

4、弊端

1、存在集中过多业务逻辑的风险

2、缺乏隔离

3、解决隔离问题

1、缺乏隔离导致的问题

1、丢失更新

2、脏读

3、模糊或不可重复读

2、Saga模式下的实现隔离的对策

1、对策

1、语义锁：应用程序级的锁

2、交换式更新：把更新操作设计成可以按任何顺序执行，比如：责任链模式

3、悲观视图：重排Saga步骤、一最大限度地降低业务风险

4、重读值：通过重新数据来防止脏写，以在覆盖数据之前验证它是否保持不变

5、版本文件：将更新记录下来，以便可以对它们重新排序

6、业务风险评级：使用每个请求的业务风险来动态选择并发机制

2、结构

1、可补偿性事务

2、关键性事务

3、可重复性事务

4、微服务间的设计

1、Saga编排器

2、Proxy代理

3、Saga框架

4、Handlers

5、Configuration

5、微服务架构中的业务逻辑设计

1、业务逻辑组织模式

1、使用事务脚本模式设计业务逻辑

2、使用领域模型模式设计业务逻辑

1、实体

2、值对象

3、工厂

4、存储库

5、服务

2、使用聚合模式设计领域模型

1、模糊边界锁带来的问题

1、概念模糊

2、必须始终强制执行的业务规则

2、聚合拥有明确的边界

1、聚合代表了一致的边界

2、识别聚合是关键

3、聚合的规则（贫血）

1、只引用聚合根

2、聚合间的引用必须使用主键

3、在一个事务中、只能创建或更新一个聚合

4、聚合的颗粒度

5、使用聚合设计业务逻辑

3、发布领域事件

1、为何需要发布变更事件

1、使用基于编排的Saga维护服务之间的数据一致性

2、通知维护数据副本的服务

3、按顺序通知同一应用程序的不用组件

4、向用户发送短信或电子邮件通知

5、监控领域事件以验证应用程序是否正常运行

6、分析领域事件、为用户行为建模

2、什么是领域事件

1、动词命名事件，比如：订单新增

2、具有元数据、例如：id和时间戳

3、事件增强

1、让事件接收方查询聚合服务

2、事件包含接收方需要的信息

4、识别领域事件

1、事件风暴

1、头脑风暴

2、识别事件触发器

1、用户操作

2、外部系统

3、另一个领域事件

4、事件的流逝

3、识别聚合：请求领域专家识别那些使用命令的聚合并发出相应的事件

5、生成和发布领域事件

1、生成领域事件

1、聚合和调用它的服务或类之间分配职责

2、聚合根在一个内部字段中累积保存事件，然后服务检索这些事件并发布它们

2、如何可靠地发布领域事件

使用事务性来进行有效发布

6、消费领域事件

6、使用事件溯源开发业务逻辑

1、使用事件溯源开发业务逻辑概述

1、传统持久化技术的问题

1、对象与关系的阻抗失调

关系型数据的表格结构模式与领域模型及其复杂关系的图状结构之间，存在基本的概念不匹配问题

2、缺乏聚合历史

聚合更新后、会将先前的状态丢失

3、实施审计功能将非常繁琐且容易出错

4、事件发布凌驾于业务逻辑上

不支持发布领域事件

2、什么是事件溯源

1、通过事件来持久化聚合

子主题 5

1、概述

事件溯源通过加载事件和重放事件来重建聚合的内存状态

2、加载聚合的步骤

1、加载聚合的事件

2、使用其默认的构造函数创建聚合实例

3、调用apply()方法遍历事件

3、使用乐观锁处理并发更新

4、事件溯源和发布事件

5、使用快照提升性能

6、幂等方式的消息处理

1、基于关系型数据库事件存储库的米等消息处理

2、基于非关系型数据库事件存储库的幂等消息处理

7、领域事件的演化

1、事件结构的演化

1、层次

1、由一个或多个聚合组成

2、定义每个聚合发出的事件

3、定义事件的结构

2、级别

1、聚合的结构

2、移除聚合

3、重命名聚合

4、聚合

5、移除事件

6、重命名事件

7、事件

8、删除字段

9、重命名字段

10、更改字段的数据类型

2、通过向上转换upcasting来管理结构的变化

8、事件溯源的好处

1、可靠的发布领域事件

2、保留聚合的历史

3、最大限度的避免对象与关系的“阻抗失调”问题

4、为开发者提供一个“时光机”

9、事件溯源的弊端

1、这类编程模式有一定的学习曲线

2、基于消息传递的应用程序的复杂性

3、处理事件存在一定的难度聚合、版本

4、删除数据存在一定难度 GDPR

5、查询事件存储库非常有挑战性

2、实现事件存储库

事件存储库推荐选择

1、Event Store

2、Lagom

3、Axon

4、Eventuate

1、Eventuate Local事件存储库的工作原理

1、事件数据库结构

1、events：存储事件

2、entities：每个实体一行

3、snapshots：存储快照

2、通过订阅Eventuate Local的事件代理接收事件：基于kafka

3、Eventuate Local的事件中继把事件从数据库传播到消息代理

2、Eventuate的Java客户端框架

1、通过聚合基类定义聚合

2、定义聚合的命令

3、定义领域事件

4、使用聚合配置类创建、查找和更新聚合

5、订阅领域事件

3、同时使用Saga和事件溯源

1、使用事件溯源实现协同式Saga

1、消息传递的进程间通信

2、消息去重

3、原子化状态更新和消息发送

2、创建编排式Saga

1、当关系型数据库作为事件存储库时、应该如何创建Saga编排器

2、当非关系型数据库作为事件存储库时、应该如何创建Saga编排器

3、实现基于事件溯源的Saga参与方

1、命令式消息的幂等处理，检测和丢弃重复消息

2、以原子方式发送回复消息

4、实现基于事件溯源的Saga编排器

1、如何持久化一个Saga编排器

2、如何以原子方式更改编排器的状态并发送命令式消息

3、如何确保Saga编排器只处理一次回复消息

7、在微服务架构中实现查询

1、使用API组合模式进行查询

1、查询出的视图需要从各个微服务中获取数据

2、什么是API组合模式，多微服务分别依次调用后获取数据组装视图

1、API组合器

2、数据提供方服务

3、API组合模式的设计缺陷

1、由谁来担任API组合器的角色

4、API组合模式的弊端

1、增加了额外的开销

2、带来可用性降低的风险

3、缺乏事务数据一致性

2、使用CQRS模式（命令查询职责隔离）

1、为何要使用CQRS

1、API组合器的两种方式及隐患

1、检索和链接大规模的数据集，比较低效

2、匹配id后再检索，网络流量过大

2、单一服务查询的挑战

1、拥有数据的服务不适合实现查询

2、服务的数据模型不能有效支持查询

3、隔离问题的必要性

1、拥有数据的服务有时不是实现查询的服务

2、什么是CQRS，读写分离数据仓库

1、微服务架构中实现查询时遇到的问题

1、使用API组合模式检索分散在多个服务中的数据会导致昂贵、低效的内存中链接

2、拥有数据的服务将数据存储在不能有效支持所需查询的表单或数据库中

3、隔离问题的考虑意味着、拥有数据的服务不一定时会实现查询操作的服务

2、CQRS隔离命令和查询

3、CQRS和查询专用服务

3、CQRS的好处

1、在微服务架构中高效地实现查询

2、高效地实现多种不同地查询类型

3、在基于事件溯源技术地应用程序中实现查询

4、更进一步地实现问题隔离

4、CQRS的弊端

1、更加复杂的架构

2、处理数据复制导致的延迟，数据版本

3、设计CQRS视图

1、视图结构

1、事件处理程序和查询API

2、数据访问模块实现数据访问

3、视图数据库

2、开发视图模块时，设计决策

1、选择合适的底层数据库，并设计数据库结构

1、SQL还是NoSQL

2、支持更新操作

2、设计数据访问模块时、必须解决各种问题，包括更新幂等，并发更新等

1、并发处理

2、幂等事件处理程序

3、在现有应用程序中实现新视图或更改现有应用程序的模式时，必须实现一种机制、以有效的构建或重建视图

1、使用归档事件构建CQRS视图

2、增量式构建CQRS视图，两步增量算法

4、设计视图的客户端，以应对前面描述的复制延迟

4、实现基于AWS DynamoDB的CQRS视图

8、外部API模式

1、外部API的设计难题

概述

1、使用服务API的客户端

1、web应用程序

2、在浏览器中运行的JavaScript

3、移动应用程序，一个供消费者使用，另一个供送餐员使用

4、由第三方开发人员编写的应用程序

2、调用单体应用程序API方式弊端

1、细粒度服务API要求客户端发出多个请求以检索所需的数据，这样做效率低，并且可能导致糟糕的用户体验

2、由于客户端了解每项服务以及服务的API从而导致封装不足（紧耦合），因此今后很难更改服务的架构和API

3、服务可能使用对客户端而言不便或不能使用的进程间通信机制，尤其是防火墙外的客户端

1、FTGO移动客户端API的设计难题。：浏览器直接访问对应应用的微服务

1、多次客户端请求导致用户体验不佳

2、缺乏封装导致前端开发做出的代码修改影响后端

3、服务可能选用对客户端不友好的进程间通信机制

2、其它类型客户端API的设计难题

1、web应用程序的API设计难题

2、基于浏览器的JavaScript应用程序的API设计难题

3、为第三方应用程序设计API

2、API Gateway模式

1、什么是API Gateway模式

1、请求路由

2、API组合

3、协议转换

4、能够为每一个客户端提供它们的专用的API

5、实现边缘功能

1、身份验证

2、访问授权

3、速率限制

4、缓存

5、指标收集

6、请求日志

6、API Gateway的架构

1、API层

1、移动设备API

2、浏览器API

3、公共API

2、公共层

7、API Gateway的所有者模式

8、后端前置模式

2、API Gateway模式的好处和弊端

1、好处：封装了应用程序的内部结构

2、坏处：必须开发、部署和管理的高可用组件

3、以Netflix为例的API Gateway

4、API Gateway的设计难题

1、性能和可扩展性

2、使用响应式编程抽象编写可维护的代码

回调地狱->使用响应式编程

3、处理局部故障

1、负载均衡

2、断路器

4、成为应用程序架构中的好公民

1、监控应用程序得行为并解决问题

2、必须实现整个架构中选择得各种模式

3、实现一个API Gateway

1、使用现成的API Gateway产品或服务

1、AWS API Gateway

1、不支持API组合

2、仅支持HTTP/HTTPS

3、非常依赖JSON

2、AWS Application Load Balancer

2、开发自己的API Gateway

1、关键设计问题

1、实现定义路由规则的机制以简化复杂的代码

2、正确实现HTTP代理行为，包括如何处理HTTP标头

2、使用Netflix Zuul

过滤器，只能实现基于路径的路由

3、关于Spring Cloud Gateway

1、将请求路由到后端服务

2、实现执行API组合的请求处理程序

3、处理边缘功能、例如身份验证

3、使用GraphQL实现API Gateway

1、模式驱动的API技术

1、GraphQL

2、Netflix Falcor

2、GraphQL的关键部分

1、GraphQL模式

2、解析器函数

3、代理类

3、定义GraphQL

1、对象类型

2、枚举类型

4、执行GraphQL查询

5、把模式连接到数据源

解析器函数

1、对象

2、查询参数

3、上下文

6、使用批处理和缓存优化负载

7、在Express Web框架中集成Apollo GraphQL服务器

9、微服务架构中的测试策略（单元测试）

1、微服务架构中的测试策略概述

1、什么是测试

1、编写自动化测试

1、设置环境

2、执行测试

3、验证结果

4、清理环境

2、使用模拟和桩进行测试

3、测试的不同类型

1、单元测试

2、集成测试

3、组件测试

4、端到端测试

4、使用测试象限进行分类

1、测试象限维度

1、测试是面向业务还是面向技术

2、测试的目标是协助开发还是寻找产品缺陷

2、定义的测试类别

Q1：协助开发/面向技术，单元和集成测试

Q2：协助开发/面向业务，组件和端到端测试

Q3：寻找产品缺陷/面向业务，易用性和探索性测试

Q4：寻找产品缺陷/面向技术，非功能性验收测试，如性能测试

5、使用测试金字塔指导测试工作

1、单元->测试业务逻辑

2、集成->验证服务与它依赖方的通话

3、组件->服务的验收测试

4、端到端->应用程序的验收测试

2、微服务架构中的测试挑战

1、消费者对 API 的交互性质

1、REST 客户端->服务

2、领域事件使用者->发布者

3、命令式消息请求方->回复方

2、消费者驱动的契约测试

1、具有预期的 HTTP 方法和路径

2、接受预期的 HTTP 头部

3、接受请求主体

4、返回预期中的响应，包括状态代码、头部和主体

3、使用 Spring Cloud的契约测试服务

4、针对消息传递 API 的消费者契约模式

3、部署流水线

提交前测试阶段

1、提交测试阶段

2、集成测试阶段

3、组件测试阶段

4、部署阶段

2、为服务编写单元测试，验证单元是否正常工作

1、为实体编写单元测试

1、独立型单元测试

2、协作型单元测试

2、为值对象编写单元测试

3、为Saga编写单元测试

1、编写使用真实数据库和消息代理以及桩服务的测试

2、编写模拟与数据库和消息代理交互的类测试

4、为领域服务编写单元测试，mock

1、设置：配置服务依赖项的模拟对象

2、执行：调用服务方法

3、验证：验证服务方法返回的值是否正确、以及是否正确调用依赖项

5、为控制器编写单元测试

6、为事件和消息处理程序编写单元测试

10、微服务架构中的测试策略（集成测试）

1、编写集成测试，服务间通信

0、策略

1、测试每个服务的适配器

2、使用契约

1、消费者测试

2、提供者测试

1、针对持久化层的集成测试

1、设置：通过创建数据库结构设置数据库，并将其初始化为已知状态，也可能开始执行一些必要的数据库事务

2、执行：执行数据库操作

3、验证：对数据库的状态和从数据库中检索的对象进行断言

4、拆解：可选阶段，可以撤销对数据库所做的更改。例如：回滚

2、针对基于REST请求/响应式交互的集成测试

3、针对发布/订阅式交互的集成测试

4、针对异步请求/响应式交互的集成契约测试

2、编写组件测试，黑盒的 API 验证行为

1、定义验收测试

2、使用Gherkin编写验收测试

3、设计组件测试

4、为FTGO的Order Service编写组件测试

3、端到端测试

1、设计端到端测试

2、编写端到端测试

3、运行端到端测试

11、开发面向生产环境的微服务应用

1、开发安全的服务

1、传统单体应用程序的安全性

1、会话

1、客户端向FTGO应用程序发出登录请求

2、登录请求由LoginHandler处理，LoginHandler验证凭据，创建会话，并在会话中存储有关主体的信息

3、LoginHandler将会话令牌返回给客户端

4、客户端在后续每次调用请求中都包含会话令牌

5、这些请求首先由SessionBaseSecurityInterceptor处理。拦截器通过验证会话令牌来验证每个请求并建立安全上下文。安全上下文描述了主体及其角色

6、请求处理程序使用安全上下文来获取其身份，并凭此确定是否允许用户执行请求的操作

2、安全上下文

2、在微服务架构中实现安全性

1、单体安全在微服务中不适用点

1、内存中的安全上下文

2、集中会话

2、由API Gateway处理身份验证

1、正确性

1、各个服务分别对用户进行身份验证、它允许未经身份验证的请求进入内部网络，需要每个服务正确实现安全性

2、不同的客户端以不同的方式进行身份验证，会处理多种不同的身份验证机制

3、处理访问授权

验证凭据后、需要再验证是否允许客户端执行所请求的操作

4、使用JWT传递用户身份和角色

1、两种令牌可供选择

1、使用不透明（无可读性）的令牌，UUID，需要发起同步的RPC调用获取用户信息

2、透明令牌 JWT，自包含且不可撤销，可发布短期JWT限制恶意第三方，弊端严重

2、在微服务架构中使用OAuth2.0

1、关键概念

1、授权服务器

2、访问令牌

3、刷新令牌

4、资源服务器：使用访问令牌授权访问的服务

5、客户端

2、事件顺序

1、客户端法求出请求、使用基本身份验证提供它的凭据

2、API Gateway向OAuth2.0身份验证服务器发出OAuth2.0密码授予请求

3、身份验证服务器验证API客户端的凭据，并返回访问令牌和刷新令牌

4、API Gateway在其对服务的请求中包含访问令牌。服务验证访问令牌并使用它来授权请求

2、设计可配置的服务

1、使用基于推送的外部化配置

限制1：重新配置正在运行得服务较难，需重启

限制2：配置属性值存在分散在众多服务定义中的风险

2、使用基于拉取的外部化配置

1、配置方法

1、版本控制系统，如git

2、SQL和NoSQL数据库

3、专用配置服务器，如：Spring Cloud Config Server

2、使用配置服务器的好处

1、集中配置

2、敏感数据的透明解密

3、动态重新配置

3、设计可观测的服务

1、使用健康检查API模式

1、实现健康检查接口

2、调用健康检查接口

2、使用日志聚合模式

1、服务如何生成日志

2、日志聚合的基础设施，如ELK

1、Elasticsearch：用作日志记录服务器

2、Logstash：聚合服务日志并将其写入Elasticsearch的日志流水线

3、Kibana：Elasticsearch的可视化工具

3、使用分布式追踪模式

1、使用追踪工具类库，如：Spring Cloud Sleuth

2、关于分布式追踪服务器，如：Open Zipkin

4、使用应用程序指标模式

1、收集服务层面的指标

2、把指标发送给指标服务

1、推送模型

2、拉取模型

5、使用异常追踪模式

1、一些问题

1、日志文件以单行日志条目为导向，而异常由多行组成

2、没有机制来追踪日志文件中发生的异常的解决方案

3、可能存在重复的异常，但没有自动机制将它们视为异常

2、几种方法

1、异常追踪服务

6、使用审计日志模式

1、向业务逻辑添加审计日志代码

缺点1：审计日志代码和业务逻辑交织在一起，降低了可维护性

缺点2：可能容易出错

2、使用面向切面编程，AOP

3、使用事件溯源

4、使用微服务基底模式开发服务

1、使用微服务基底

1、外部化配置

2、健康检查

3、应用程序指标

4、服务发现

5、断路器

6、分布式追踪

2、从微服务基底到服务网格

进入服务网络、断路器、分布式追踪、服务发现、负载均衡和基于规则的流量路由

12、部署微服务应用

0、概述

1、部署的两个概念

1、流程

2、架构

2、生产环境必须实现的四个关键功能

1、服务管理接口

2、运行时服务管理

3、监控

4、请求路由

1、部署模式：编程语言特定的发布包格式

1、好处

1、快速部署，复制

2、高效的资源利用

2、弊端

1、缺乏对技术栈的封装

2、无法约束服务实例消耗的资源

3、在同一台计算机上运行多个服务实例时缺少隔离

4、很难自动判定放置服务实例的位置

2、部署模式：将服务部署为虚拟机

1、好处

1、虚拟机镜像封装了技术栈

2、隔离的服务实例

3、使用成熟的云计算基础设施

2、弊端

1、资源利用效率较低

2、部署速度相对较慢

3、系统管理的额外开销

3、部署模式：将服务部署为容器

1、使用Docker部署服务

1、构建Docker镜像

2、把Docker镜像推送到镜像仓库，Docker Hub

3、运行Docker容器

2、好处

1、封装技术栈、可以用容器的API实现对服务的管理

2、服务实例是隔离的

3、服务实例的资源受到限制

3、弊端

需要承担大量的容器镜像管理工作，给操作系统和运行时打补丁

4、使用Kubernetes部署应用程序

1、什么是Kubernetes

1、Docker编排框架

1、资源管理：将一组计算机视为由CPU、内存和存储卷构成的资源池

2、调度：选择要运行的容器的机器

1、同一节点上部署的亲和性

2、不同节点之间的反亲和性

3、服务管理：实现命名和版本化服务的概念

2、Kubernetes的架构

1、1或者几个主节点

1、API服务器

2、Etcd：存储集群数据键值的NoSQL数据库，重要数据，包括配置信息、状态数据

3、调度器：选择要运行Pod的节点，监控集群中的资源使用情况

4、控制器管理器：运行控制器，确保集群状态与预期状态匹配。例如：一种称为复制控制器的控制器、通过启动和终止实例来确保运行所需数量的服务实例

2、多个普通节点

1、Kubelet：创建和管理节点上运行的Pod

2、Kube-proxy:管理网络，包括跨Pod的负载均衡

3、Pods：应用程序服务

3、Kubernetes的关键概念

1、Pod：基本部署单元

2、Deployment：Pod的生命规范

3、Service：向应用程序服务的客户端提供的一个静态/稳定的网络地址

4、ConfigMap：名称与值对的命名集合，用于定义一个或多个应用程序服务的外部化配置

2、在Kubernetes上部署服务

3、部署API Gateway

4、零停机部署

5、使用服务网格分隔部署与发布流程

1、部署流程：让服务在生产环境中运行

2、发布流程：使最终用户可以使用服务

3、整体流程

1、将新版本部署到生产环境中，而不想其路由任何最终用户请求

2、在生产中进行测试

3、将其发布给少数最终用户

4、逐步将其发布给越来越多的用户，直到它处理的所有生产流量为止

5、任何时候出现问题，恢复旧版本。否则，一旦确信新版本正常工作，删除旧版本

4、Istio服务网络概述

1、流量管理：服务发现、负载均衡、路由规则和断路器

2、通信安全：使用传输层安全性（TLS）保护服务间通信

3、遥测（Telemetry）：捕获有关网络流量的指标并实施分布式跟踪

4、策略执行：强制实施配额和费率限制

5、部署模式：Serverless部署

1、使用AWS Lambda进行Serverless部署

2、开发Lambda函数

3、调用Lambda函数

1、HTTP请求

2、AWS服务生成的事件

3、定时调用

4、直接使用API调用

4、使用Lambda函数的好处

1、由许多的AWS服务可供集成

2、消除许多系统管理任务

3、弹性：运行应用程序所需的多个实例，以处理负载

4、基于使用情况的定价

5、使用Lambda函数的弊端

1、长尾延迟，因为动态运行代码，花费时间来配置应用程序实例和启动应用程序，对于某些请求具有高延迟

2、基于有限事件与请求的编程模型

6、使用AWS Lambda和AWS Gateway部署Restful服务

1、AWS Lambda版本的微服务

2、把服务打包为ZIP文件

3、使用Serverless框架部署Lambda函数

13、微服务架构的重构策略

1、重构到微服务需要考虑的问题

1、为什么要重构单体应用

1、交付缓慢：应用程序难以理解、维护和测试，开发效率很低

2、充满故障的软件交付

3、可拓展性差

2、绞杀单体应用

1、尽早并且频繁地体现出价值

2、尽可能少对单体做出修改

3、部署基础设施，这对微服务来说还为时过早

2、将单体应用重构为微服务架构的若干策略

1、将新功能实现为服务

1、把新的服务与单体集成

1、API Gateway：对新功能的请求路由到新服务，并将遗留请求路由到单体

2、集成胶水代码：将服务与单体结合，使服务能够访问单体所拥有的数据，并能够调用单体实现的功能

2、何时把新功能实现为服务

2、隔离表现层与后端、如前后端分离，SpringMVC

1、表现逻辑层：处理HTTP请求的模块组成，并生成实现WebUI的HTML页面

2、业务逻辑层：由实现业务规则的模块组成

3、数据访问逻辑层：包含访问基础设施服务（如数据库和消息代理模块）

3、提取业务能力到服务中

1、垂直切片

1、实现API端点的入站适配器

2、领域逻辑

3、出站适配器、如数据库访问逻辑

4、单体的数据库模式

2、提取服务的挑战

1、拆解领域模型

2、重构数据库

1、复制数据以避免更广泛的更改

2、确定提取何种服务以及何时提取

3、好处

1、加速开发

2、解决性能、可扩展性或可靠性问题

3、允许提取其它一些服务

3、设计服务与单体的协作方式

1、设计集成胶水

1、设计集成胶水的API

2、选择交互方式和进程间通信机制

3、实现反腐层、防止一个模型的概念污染另一个模型，必须转换而不是跨领域直接使用

4、单体如何发布和订阅领域事件

1、使用与服务相同的领域事件发布机制

2、在数据库级别发布领域事件

2、在服务和单体之间维持数据一致性

1、修改单体应用使其支持补偿事务的挑战

2、Saga并不总是要求单体应用支持补偿事务

3、选择合适的服务提取顺序，以避免在单体中实现补偿事务

3、处理身份验证和访问授权

1、单体的LoginHandler设置userinfo cookie

2、API Gateway把userinfo cookie映射到Authorization header

4、将新功能实现为服务：处理错误配送订单

1、Delayed Delivery Service的设计

2、为Delayed Delivery Service的设计集成胶水

5、从单体中提取某一功能

1、现有的送餐管理功能

2、Delivery Service概览

3、设计Delivery Service的领域模型

4、Delivery Service集成胶水的设计

5、修改FTGO单体使其能够与Delivery Service交互