一、Swagger端微服务长相
1、微服务分类
每一个名字代表一个微服务，对应数据库中的一个或多个数据库，也可能是一个数据库的不同版本（有的版本正在用，有的版本被废弃）
2、一个微服务内有多个接口场景
微服务里面一个接口场景对应该具体库下的几张表
3、每个接口场景内部有许多具体接口
其中每个数据库表的名称对应具体接口的最后一个/后的名字，表里面的一个字段就是接口的一个入参
二、微服务概念
1、定义：
1）将整个Web应用拆分为一系列小的Web服务
2）每一个小的Web服务可以独立地编译、部署及扩展
3）各个微服务之间通过各自暴露的API接口相互通讯
4）彼此协作，作为一个整体为用户提供功能
2、基本思想：
1）围绕着业务来创建应用
2）简化了开发，将创建复杂系统的任务切分为上百个小服务，这些小服务易于被开发团队理解和开发
3）微服务并未真正的消除复杂性，而是将复杂性迁移到对大量微服务的连接、管理和监控上
4）每个微服务都至少公开了一些API点，因此有更多可测试的点需要覆盖
5）开发团队可以为他们的微服务选择最好的语言，在一个大系统中，我们不太可能找到一个适用于所有组件的单一测试框架
6）微服务可以独立部署并由自制团队构建，所以需要额外检查和边界来确保他们在部署时仍能够正常运行
3、传统服务与微服务的区别
1、部署区别
1）左边的传统服务是所有的功能都部署在一台机器上，通过增加服务器熟了来扩容
2）右边的微服务是以业务为单位进行部署，不同的业务部署在不同的服务器上，业务使用频繁地可以使用更多的资源进行部署（比如，橘黄色部署了5个单元，而粉色只部署了一个单元）
2、数据库区别
1）左边的传统服务的所有功能对应一个数据库
2）右边的微服务可以根据不同的业务设计不同的数据库，比如可以一个微服务对应一个独立的数据库
三、微服务架构
谈到微服务架构，一定会谈到Devops（即测试开发和部署运维的一体化)，微服务的独立部署需要有CI、CD的支持，跟DevOps实践分不开
1、架构设计核心
1、把整个系统根据业务拆分成几个子系统，每个子系统可以部署多个应用，多个应用之间使用负载均衡
2、需要一个服务注册中心，所有的服务都在注册中心进行注册，负载均衡也是通过在注册中心注册的服务使用一定策略来进行实现
3、所有的客户端都通过同一个网关地址访问后台服务，通过路由配置来判断一个URL请求具体由哪个服务处理，请求转发到具体服务上的时候也通过负载均衡
4、服务之间需要互相访问，比如有一个用户模块，其它服务在处理一些业务的时候需要获取用户服务的用户数据
5、需要一个断路器，及时处理服务调用时的超时或者错误，防止由于一个服务的问题而导致整个系统的瘫痪
6、需要一个监控功能，监控调用每个服务花费的时间
2、微服务框架：
1、包括：Dubbo、Spring Cloud、 Istio等
2、关于Spring Cloud
是基于SpringBoot的一整套实现微服务的框架，官网：https://springcloud.cc/
提供了微服务开发所需一系列组件：分布式/版本化配置管理、服务注册和发现、路由、服务调用、负载均衡、断路器、分布式消息传递等
四、微服务测试
1、测试重点
微服务架构下，既要保证各个微服务内部每个模块的完整性，还要关注各个模块间、各个微服务之间的交互性
2、测试难点
1）关联性：微服务通常情况下会与多个微服务进行交互，当某服务发生变化时，会直接影响到依赖它的其它服务
2）可靠性：为了尽可能降低微服务间通信对网络的高度依赖，设计微服务架构时会设计隔离机制
3）数据一致性：微服务是基于分布式系统设计的，所以需要考虑分布式系统数据一致性的问题
3、测试策略1：前端测试+服务端测试
1、前端测试
与传统测试无区别，只做功能测试的话其实感受不到架构的变化
2、服务端测试
微服务架构中，一般使用的是轻量级的通信方式，也就是基于HTTP的REST，即基于应用层的协议。
微服务通常使用http的rest来暴露，因此微服务的测试等价于接口测试，所以就是对微服务提供的接口进行功能、性能、安全等测试，具体方法如下：
1）通过构建请求调用各个微服务的接口，可以通过工具或者编码的方式实现
编码：python (requests + pytest)
工具：JMeter、Postman等
2）请求的验证：除了验证接口的返回值之外，还要关注负载均衡，即请求是否分发到多点应用
3）监控：通过工具 SpringCloud Sleuth、 Turbine、Prometheus进行监控
4）日志：通过ELK( ElasticStack )来集中化管理日志
4、测试策略2：测试金字塔模型
1、测试金字塔分层：
由底层到上层依次为：
1）单元测试（Unit Testing)
单独且独立的处理微服务内的每个组件，可以通过使用测试替身来切断组件之间的依赖关系（比如mock依赖项的响应）
2）合同测试（Contract Testing)
- 验证两个微服务之间的API兼容性，检查这些微服务的边界和交互，并将它们存储在合约中，要求双方就允许的交互集达成一致，并允许随着时间的推移而改变
- 每当两个微服务通过接口耦合时，就会形成合同，合同约定了所有可能的输入输出及其数据结构和副作用
- 服务的生产者和消费者必须同时遵守合同中的规定的契约才能进行通信，其中各个微服务互为生产者和消费者，相对而言的
- 根据服务之间的关系，合同测试可以由生产者、消费者或者两者同时运行
- 生产者端合同测试在上游服务中运行，这种类型的测试模拟来自客户端发出的各种API请求，验证生产者是否与合同匹配
- 消费者端合同测试由下游团队编写和执行，在测试期间，连接到生产者微服务的虚假或者模拟版本，以检查它是否可以使用其API
- 如果合同双方测试通过，则生产者和消费者是兼容的，可以互相通信，合同测试应该始终在持续集成中运行，以在部署前检测代码的兼容性
- 合同测试的特点是：总是模拟生产者或者消费者一侧
3）集成测试(Integration Testing)
验证微服务之间、或者微服务与其它比如数据库服务或者第三方服务之间的交互是否正常，以此来识别接口缺陷
集成测试使用的是真实的微服务双方
4）组件测试(Component Testing)
- 组件是在更大的系统中完成一个角色的一个微服务或者一组微服务
- 是一种验收测试，通过用模拟资源或者模拟替换服务来孤立的检查组件的行为
- 比集成测试更彻底，比如组件如何响应模拟的网络中断或格式错误的请求
- 组件测试对一组微服务执行端到端的测试，组件范围之外的服务会被模拟
- 有两种执行组件测试的方法：进程内和进程外
5）端到端测试(End-to-End Testing,简称E2E测试)
- 最终测试阶段，验证整个应用程序的行为，一般仅针对超关键流进行，仅用于特定微服务之间的关键交互
- 可确保系统满足用户需求并实现其业务目标，涵盖应用程序中的所有微服务
- 应在尽可能接近生产的环境中运行，通常情况下，将包括应用程序通常需要的所有第三方服务，一般可以模拟这些服务来降低成本或者防止滥用
- 一般E2E的数量越少越好，因为最难运行和维护
2、备注：
1）组件测试和合约测试是在原来三层自动化测试模型的基础上新增的2种类型
2）组件测试和合同测试两者的顺序在具体每一个公司可能放置的位置不一致，但遵循的思想都是一致的，是一个指导方针，而不是一成不变的东西
5、两种测试策略的关系
互相作用、互相嵌套、互相交互
