微服务架构设计模式笔记--第九章 微服务架构中的测试策略（上）
1. 微服务架构中的测试策略概述
1.1 什么是测试
1.2 微服务架构中的测试挑战
1.3 部署流水线
2. 为服务编写单元测试


传统的测试方法通常都在开发完成后执行，开发人员将他们的代码扔给隔壁的QA团队，QA团队验证软件是否按预期工作。更糟糕的是，他们的大多数测试都是手动执行的。这种测试方法现在不管用了，原因有两个：


手动测试效率极低：你永远不应该让人类去做一台机器可以做得更好的事情。与机器相比，手动测试执行的速度很慢，不能全天候工作。如果依赖手动测试，你将无法快速且安全地交付高质量的软件。编写自动化测试至关重要。
在交付流程中才进行测试为时已晚：在编写应用程序之后，确实应该通过测试来找出软件潜在的问题，但经验表明这些测试不够充分。一种更好的方式是让开发人员编写自动化测试，以此作为开发的一部分。自动化测试可以提高开发人员的工作效率，例如，当他们在修改代码时，自动化测试用例可以给他们提供及时的反馈。


1. 微服务架构中的测试策略概述
1.1 什么是测试

如图所示，测试的目的是验证被测系统的行为。在这个定义中，系统只是一个泛称，它指的是被测试的软件元素。它可以小到一个类，大到整个应用，或者介于两者之间，例如一组相关的类、模块或单个服务。一组相关的测试用例集构成一个测试套件。



编写自动化测试的4个阶段：

设置环境：将被测系统以及其他相关元素组成的测试环境初始化为所需的状态。例如，创建测试中的类，并将其初始化为呈现特定行为所需的状态。
执行测试：调用被测系统，例如，在被测试的类上调用一个方法。
验证结果：对调用的返回结果和被测系统的状态进行判断。例如，验证方法的返回值

和被测试类的新状态与预期一致。
清理环境：必要时清理测试环境。许多测试省略了这个阶段，但是某些类型的测试，

比如涉及数据库的测试可能需要在这个阶段将数据库的状态回滚到设置环境阶段前的初始状态。

使用模拟和桩进行测试：Mockito是一种流行的Java模拟对象框架。

测试的不同类型：

单元测试：测试服务的一小部分，例如类。
集成测试：验证服务是否可以与基础设施服务（如数据库）或其他应用程序服务进行交互。
组件测试：单个服务的验收测试。
端到端测试：整个应用程序的验收测试。

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


1.2 微服务架构中的测试挑战
消费者驱动的契约测试：



消费者驱动的契约测试通常使用样例测试。消费者和提供者之间的交互由一组样例定义，称为契约。每个契约都包含在一次交互期间交换的样例消息。

例如，RESTAPI的契约包含示例HTTP请求和响应。从表面上看，使用例如Open API或JSON编写的模式来定义这些交互似乎很有用。但事实证明，在编写测试时，模式并不是那么有用。测试可以使用模式来验证响应，但仍需要使用样例请求调用提供者程序。
使用Spring Cloud的契约测试服务：Spring Cloud Contract
1.3 部署流水线


部署流水线通常使用持续集成(Continuous Integration)服务器(如Jenkins)实现。

图中显示的示例部署流水线包含以下阶段：

提交前测试阶段：执行单元测试。这是由开发人员在提交代码更改之前执行的。
提交测试阶段：编译服务，执行单元测试，并执行静态代码分析。
集成测试阶段：执行集成测试。
组件测试阶段：执行服务的组件测试。
部署阶段：将服务部署到生产环境中。

2. 为服务编写单元测试


如图所示，单元测试是测试金字塔的最低级别。它们是面向技术的测试，目标是协助开发。单元测试验证单元（服务的很小的一部分）是否正常工作。单元通常是一个类，此单元测试的目标是验证这个类的行为是否符合预期。

有两种类型的单元测试：

独立型单元测试：使用针对类的依赖性的模拟对象隔离测试类。
协作型单元测试：测试一个类及其依赖项。



类的职责决定是使用独立型单元测试还是协作型单元测试。

为实体编写单元测试
为值对象编写单元测试
为Saga编写单元测试
为领域服务编写单元测试
为控制器编写单元测试Spring Mock Mvc
为事件和消息处理程序编写单元测试

自动化测试是快速、安全地交付软件的重要基石。更重要的是，由于微服务架构固有的复杂性，要从微服务架构中充分受益，必须实现自动化测试。

高性能微服务架构设计模式

主讲：霞落满天

现在企业开发都是微服务架构，但是有很多问题，比如分布式定义，分布式的微服务怎么拆分，什么时候拆分，怎么做到高性能，中台怎么设计，读写分离模式难道仅仅是MySQL做主从就够了么？分库分表怎么使用，缓存和数据库之间怎么保持一致性，领域模型中的CQRS模式又应该怎么结合自己公司的业务呢？面试过程老是被问题一些系统架构相关的问题，怎么面对新问题可以在面试中短短的时间征服面试官？针对这些问题我录制了一期学习视频。有任何学习问题可以给我留言

视频地址：https://edu.csdn.net/course/detail/27256/

 

课程大纲

开篇 高性能系统架构的分布式理论基础

模型 可无限扩展的AKF立方

问题 亿级QPS的电商网站遇到的问题

模式 CQRS模式进行架构设计

模式 事件溯源模式进行架构设计

结尾 新问题


课程收益

高性能：亿级QPS的电商网站怎么做到高性能？是不是用了分库分表就万事大吉了？如果还不行是不是扩容加机器就可以了？Kafka为什么可以做到那么高性能？怎么实现可以系统接近无限扩容等等。

开发效率：产品提出一个需求，往往改一发而动全身。怎么样既要做到高性能也要做到易维护易扩展？

技术选型：异步解耦，微服务拆分，领域驱动模型设计这些理论怎么用。

面试：突击押宝，短时间帮你把面试常见知识点提纲挈领。

听懂：只有精心设计的课程才能让人听懂。

分布式系统的定义和特征

缘起：首先只有先学习优秀的分布式架构自己才可以做出优秀分布式架构，第二不管多么炫的技术架构，后面的一些分布式思想和理论都是很多年前的，最少也是15年前的。

现状：关于分布式系统的定义其实现阶段也并没有得到普及，一些分布式的经典著作有定义，但是不统一。大家都在说分布式系统，但是很多人包括一些架构师并没有理解分布式，做系统架构并不是分布式的，如果访问量很小不会显现出问题，如果访问量很大就会暴露很大问题，这时候可能会用一些不太好的方案来解决问题，比如乱加机器，甚至有时候加机器也解决不了问题。

定义：分布式系统是其组件分布在联网的计算机上，组件之间通过传递消息进行通信和协调的系统。

特征：组件的并发性，缺乏全局时钟，组件故障的独立性。

关键技术：名字服务，间接通信，复制技术，分布式事务。

正交性设计：

定义：两条直线相交成直角，就是正交的。正交也就是两条直线互不依赖。如果一个系统的变化不影响另一个系统这些系统就是正交的。

直接应用正交性原则，构建的系统的质量可以得到很大提高，可以让你的系统易于设计、开发、测试及扩展上线。

高内聚：每个服务是功能独立单一的。系统与系统之间，服务与服务之间是独立互相独立，隔离的。

正交的好处：提高开发效率，降低风险。

 

举例Kafka为什么是分布式的

Kafka 是最流行的消息中间件，有别于RabbitMQ, RabbitMQ不是真正意义上的分布式系统，因为他没有做到分布式，他只是做了镜像。阿里巴巴开源的RocketMQ也是分布式的系统。

Kafka的消息通过Toplic（主题）进行分类，这就好比数据库的表，或者文件系统里的文件夹。 Toplic可以被分为若干个Partition(分区)，一个分区就是一个提交日志。消息以追加的方式写入分区。

分区可以并发读写，提高性能。数据在多节点之间复制提高可用性。

 

间接通信：对于分布式系统，间接的概念也越来越多地应用于通信范型。间接通信被定义为在分布式系统中实体通过中介者进行通信，没有发送者和接受者之间耦合，中介者的确切特性随方法的不同而不同。

空间解耦：发送者不知道也无需知道接收者，接收者也同样无需知道发送者，因为空间解耦使得系统开发者有很大的自由去处理改变：参与者可以被替换，更新，复制甚至迁移。

时间解耦：发送者和接收者可以有独立的生命周期，也就是说发送者和接收者不需要同时存在才可以通信，发送者可以随时进入离开。

tips：所有计算机问题，都可以通过引入一个新的间接层次来解决，那些已经有过多间接层次的问题除外。（1965年剑桥Titan项目）

 

分布式系统在电商微服务中台的表现

电商业务中台微服务拆分为商品中心(商品详情+商品列表)，购物车中心，订单中心，用户中心。

微服务镜像部署在不同的服务器上。

好处：高内聚，低耦合，易维护，易扩展。

问题：分布式事务，调用链复杂，一致性问题等…

 

标准CQRS模式

实现：标准CQRS由命令模型和查询模型组成，这是按照领域模型来设计的，命令模型实现新增，更新，删除操作，查询模型订阅命令端发布的事件并更新查询视图，最终视图是最新的，有时候需要添加新视图来支持不同的查询类型。

查询模型使用的数据库不限于MySQL也可以是ES，Redis，MongoDB等。


事件溯源模式简介

Event Sourcing Pattern代表事件溯源模式也有称为事件源模式。使用仅追加存储来记录描述在域中对数据执行的操作的完整系列事件，而不是仅存储当前状态，以便可以使用该存储来实现域对象。

通过避免同步数据模型和业务域的需求，该模式可以简化复杂域中的任务。提高性能，可伸缩性和响应能力；提供交易数据的一致性；并保持完整的审计追踪和历史记录，以支持采取补偿措施。

下面是课程的一些精彩截图：





 

微服务与传统单体服务
单体服务
一个项目中包含了所有的服务叫做单体服务



优点：

开发简单，对技术栈要求不高
部署、运维方便，只需要对一台机器、一个服务进行部署、运维
服务监控、问题排查简单，只需要对一台机器的监控与日志分析

缺点:

可以对多个模块化组件的整体JVM进程进行水平扩展，而无法单独对某个模块化组件进行水平扩展
当仅修改某个模块时，需要所有模块进行编译、打包和上线
模块间相互依赖、相互耦合

微服务
微服务是把每一个职责单一的功能放在独立的服务中，且每个服务运行在一个单独的进程中，每个服务都有自己的数据存储（如缓存、消息队列）



优点：

每一个服务可以有多个实例，当运行在容器化的平台，可以平滑伸缩
资源的有效隔离：每一个微服务拥有独立的数据资源，服务间调用只能通过暴露的接口来完成
团队组织架构的调整：可以根据不同服务让不同的小组负责，分工明确

缺点：

微服务把原有的项目拆分成多个独立工程，增加了开发、测试、运维、监控等的复杂度。
微服务架构需要保证不同服务之间的数据一致性，引入了分布式事务和异步补偿机制，为设计和开发带来一定挑战

微服务与SOA区别
SOA（面向服务的架构）：SOA是一个组件模型，将不同功能单元通过定义好的接口和契约进行关联。使得构建在各种各样的系统中的服务可以以一种统一和通用的方式交互。
微服务：将一个单体应用作为一套小型服务开发的方法，每个服务都在自己的进程中运行。同行使用轻量级（通常是HTTP）机制通信。每个服务可以使用不同的编程语言编写，并使用不同的数据存储技术。
区别如下：





SOA服务
微服务




目标
强调异构服务之间协作和集成
拆分模块、快速拓展开发团队


管理
着重中央管理理
重在分散管理理


粒度
通常粒度粗
拆分粒度更更细，职责单⼀


通信
ESB企业服务总线
HTTP（REST API）


划分
前、后端、数据库、测试等类别划分
业务边界做细粒度的拆分


六种常见微服务架构设计模式
聚合器微服务设计模式


类似于数据库中的聚合查询一样，聚合器调用多个服务实现应用程序所需的功能。

它可以是一个web页面，将所有微服务的数据进行处理后展示；也可以是对多个微服务进行组合，发布成为一个新的微服务（符合DRY（Don’t Repeat Yourself）原则）
代理理微服务设计模式


代理和聚合的主要区别是：代理不做聚合数据，仅仅做代理。

代理模式会根据需求的差别调用不同的微服务，代理可以仅仅做请求委派，也可以对数据进行转换
链式微服务设计模式
各种服务之间具有逻辑上的执行顺序，需要串行操作



在这种情况下，服务A（SA）接收到请求后会与服务B通信，服务B会与服务C通信。所有服务都是用同步消息传递。在整个链式调用结束之前，客户端会一致阻塞等待响应，因此服务调用链不宜过长，避免客户端长时间等待。
分支微服务模式


SA服务的分支为SB、SC两个服务，也就意味着SA可以与SB、SC两个服务进行交互，很多的业务模型可以通过此模型进行处理
数据共享微服务设计模式
在单体应⽤用到微服务架构的过渡阶段，可以使⽤用这种设计模式



在这种情况下，部分微服务可能会共享缓存和数据库存储。不过只有在两个服务间存在强耦合关系才可以。
异步消息传递微服务设计模式
虽然REST规范非常流行，但它是同步的，会造成客户端阻塞。因此部分基于微服务的架构可能会选择使用消息队列来代替REST的请求/响应，因为消息队列可以是异步的。



如图可知，SA、SB、SC之间通过消息队列进行异步消息通信，服务之间不需要等待请求结束
除了以上几种微服务设计模式，我们还可以基于几种基础的设计模式进行组合，如分叉+链式组合、链式+异步消息传递组合等
SpringCloud

Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的⼯具（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线）。

分布式系统的协调板模式, 使用SpringCloud开发人员可以快速地支持实现这些模式的服务和应用程序

SpringCloud微服务的生态圈




微服务技术栈
实现技术




服务开发
SpringBoot, SpringMVC


服务配置
Config


服务注册与发现
Eureka


服务调用
Ribbon, Feign


服务路由
Zuul


服务熔断
Hystrix


服务全链路监控
Sleuth + Zipkin


服务部署
Docker、K8s


SpringCloud的技术栈应用


基本过程：

客户端发送请求后，经过网关Zuul、熔断器Hystrix、负载均衡器Ribbon/Feign
然后请求会被负载均衡器发送到某一个服务
服务中会根据配置中心的配置对请求进行处理
调用过程中，调用链监控Sleuth+Zipkin会对服务全链路进行监控

这边有一个服务注册中心集群，它是负责所有服务的管理，比如网关、熔断器、订单服务等对于注册中心来说都是客户端，而注册中心就是服务端。图中由三个Eureka注册中心组成一个集群，它们各自拥有者对方的副本(Replicas)。
微服务实践思考
微服务如何合理拆分？

把当前所有的服务列举出来，拿着清单和产品去对，比如产品未来规划、走向，如未来3年或5年的要求
梳理服务中所有的东西，服务需要拆的粒度、服务的边界值，这些最好是大家一起定
数据库是每一个微服务都有一个库，还是有区分主库、从库？
业务量的大小，需要多少服务器资源、需要承受多大的并发量

服务拆分也是微服务中比较难的一块，需要考虑的东西较多。
单体服务如何平滑过渡到微服务？

评估当前代码是否需要调整？如果模块之间耦合性高，则调整可能性就很高
服务的分类，哪些是核心服务、哪些是重量服务，服务之间的优先级是怎么样的？
服务拆分先从边界业务开始拆分，然后慢慢靠近核心服务。
边拆边上线，根据经验，一般拆需要1~2年， 3年稳定
中间件是否符合需求、部署、运维等多方面考虑
微服务也涉及到了架构调整，那么多份代码需要合并，多久合并一次？如何合并？都是需要考虑的

当以上都清楚了，你就可以开始着手进行重构了
微服务架构如何正确复盘？

架构选型是否符合未来的几个服务
未来服务扩容是否没问题？
运维成本是否增加了？
拆解完成后微服务是如何管理的？是所有人都有权限管理还是有专人负责管理微服务？

无论什么事情，我们都需要复盘，优化过程与总结经验
参考

springcloud中文教程

代理设计模式
在微服务架构中 代理服务 是必然存在的，常用的代理服务是 网关服务。
微服务的各个服务是没有状态的，需要通过统一的入口（代理服务）经过权限的校验、请求的过滤（非法请求、SQL注入等），然后请求具体的服务。


聚合设计模式
聚合设计模式常用于 报表服务，在微服务系统中报表服务是肯定存在的。

链条设计模式

聚合链条设计模式

数据共享设计模式
后台管理系统一般采用 数据共享设计模式 ，其可以直连多个数据库，但是操作的数据涉及到缓存，必须调接口，因为缓存被子服务用到，还被后台管理系统用到，管理起来会非常麻烦，一个缓存一般只涉及到一个服务。

异步消息设计模式
验证订单信息、验证产品信息、验证用户消息为同步，Push和短信服务对实时性要求不高为异步。
验证用户消息为同步，Push和短信服务对实时性要求不高为异步。