https://www.cnblogs.com/wangiqngpei557/p/9279984.html

微服务架构—自动化测试全链路设计

• 背景
• 被忽视的软件工程环节 – DEVTESTOPS
• 微服务架构下测试复杂度和效率问题
• 开发阶段 unitTest mock 外部依赖
• 连调阶段 mock 外部依赖
• 自动化测试阶段 mock 需求
• autoTest Mock Gateway 浮出水面
• 轻量级版本实现
  • 整体逻辑架构
  • 将 mock parameter 纳入服务框架标准 request contract
  • 使用 AOP + RestEasy HttpClientRequest SPI 初步实现 Mock
• 总结

背景

从 SOA 架构到现在大行其道的微服务架构，系统越拆越小，整体架构的复杂度也是直线上升，我们一直老生常谈的微服务架构下的技术难点及解决方案也日渐成熟（包括典型的数据一致性，系统调用带来的一致性问题，还是跨节点跨机房复制带来的一致性问题都有了很多解决方案），但是有一个环节我们明显忽略了。

在现在的微服务架构趋势下，微服务在运维层面和自动化部署方面基本上是比较完善了。从我个人经验来看，上层的开发、测试对微服务架构带来的巨大变化还在反应和学习中。

开发层面讨论微服务的更多是框架、治理、性能等，但是从完整的软件工程来看我们严重缺失分析、设计知识，这也是我们现在的工程师普遍缺乏的技术。

我们经常会发现一旦你想重构点东西是多么的艰难，就是因为在初期构造这栋建筑的时候严重缺失了通盘的分析、设计，最终导致这个建筑慢慢僵化最后人见人怕，因为他逐渐变成一个怪物。（比如，开发很少写 unitTest ，我们总是忽视单元测试背后产生的软件工程的价值。）

被忽视的软件工程环节 — DEVTESTOPS

我们有没有发现一个现象，在整个软件过程里，测试这个环节容易被忽视。任何一种软件工程模型都有 QA 环节，但是这个环节似乎很薄很弱，目前我们绝大多数工程师、架构师都严重低估了这个环节的力量和价值，还停留在无技术含量，手动功能测试低级效率印象里。

这主要是测试这个角色整个技术体系、工程化能力偏弱，一部分是客观大环境问题，还有一部分自身问题，没有让自己走出去，多去学习整个工程化的技术，多去了解开发的技术，生产上的物理架构，这会有助于测试放大自己的声音。

导致测试环节在国内整个设计创新薄弱的原因还有一个主要原因就是，开发工程师普遍没有完整的工程基础。在国外IT发达国家，日本、美国等，一个合格的开发工程师、测试工程师都是边界模糊的，自己开发产品自己测试，这需要切换思维模式，需要同时具备这两种能力，但是这才是整个软件工程的完整流程。

我们有没有想过一个问题，为什么现在大家都在谈论 DevOps，而不是 DevTestOps，为什么偏偏跳过测试这个环节，难道开发的系统需要具备良好的可运维性就不需要可测试性吗，开发需要具备运维能力，运维需要具备开发能力，为什么测试环节忽略了。

我们对 QA 环节的轻视，对测试角色的不重视其实带来的副作用是非常大的。

微服务架构下测试复杂度和效率问题

微服务的拆分粒度要比 SOA 细了很多，从容器化镜像自动部署来衡量，是拆小了之后很方便，但是拆小了之后会给整个开发、测试环节增加很大的复杂度和效率问题。

在 SOA 时期，契约驱动 这个原则在微服务里也一样适用，跨部门需求定义好契约你就可以先开发上线了。但是这个里面最大的问题就是当前系统的部分连调问题和自动化回归问题，如果是新系统上线还需要做性能压测，这外部的依赖如何解决。

也许我们会说，不是应该依赖方先ready，然后我们紧接着进行测试、发布吗。如果是业务、架构合理的情况下，这种场景最大的问题就是我们的项目容易被依赖方牵制，这会带来很多问题，比如，研发人员需要切换出来做其他事情，branch 一直挂着，不知道哪天突然来找你说可以对接了，也许这已经过去一个月或者更久，这种方式一旦养成习惯性研发流程就很容易产生线上 BUG 。

还有一种情况也是合理的情况就是平台提供方需要调用业务方的接口，这里面有一般调用的 callback 接口、交易链路上的 marketing 接口、配送 routing 接口等。

这里给大家分享我们目前正在进行中的 marketing-cloud (营销云) 规则引擎 项目。

marketing-cloud 提供了一些营销类业务，有 团购、优惠券、促销 等，但是我们的业务方需要有自己个性化的营销活动玩法，我们需要在 marketing-cloud 规则引擎 中抽象出业务方营销活动的返回信息，同时打通个性化营销活动与公共交易、结算环节，形成一个完整的业务流。

有两种方式来识别当前 autoTest context ，一种是在 case 执行的时候确定商品ID，最后通过商品ID来获取 mock 的 response 。还有一种就是支持传递 autoTest mock 参数给到 mockUrl 指定的服务，可以使用这个参数来识别当前测试上下文。

一个测试 case 可能会穿过很多微服务，这些所有的依赖服务可能都需要预设 mock response，这基本上是一劳永逸的。

所以，我们抽象出了 autoTest Mock Gateway（自动化测试mock 关服务） ，在整个自动化测试环节还有很多需要支持的工作，服务之间的鉴权，鉴权 key 的 mock，加解密，加解密 key 的 mock，自动化测试 case 交替并行执行等。

作为工程师的我们都希望用系统化、工程化的方式来解决整体问题，而不是个别点状问题。有了这个 mock gateway 我们可以做很多事情，也可以普惠所有需要的其他部门。

自动化脚本在每跑一个 case 的时候会创建当前 case 对应的 autoTestContext，这里面都是一些 meta data，用来表示这个 case 中所有涉及到的微服务系统哪些是需要走 mock gateway 的。

在 mockGateway 中所有的配置都是有一个 autoTestContext 所对应，如果没有 autoTestContext 说明是所有 case 共用。

将 mock parameter 纳入服务框架标准 request contract

要想打通整个微服务架构中的所有通道，就需要在标准 request contract 定义 mockParameter ，这是这一切的前提。

服务与服务之间调用走标准微服务 request contract，服务与外部系统的依赖可以选择走 HTTP Header，也可以选择走标准 request ，就要看我们的整个服务框架是否已经覆盖所有的产线及一些遗留系统的问题。

BaseRequest 是所有 request 的基类，这样才能保证所有的请求能够正常的传递。

使用 AOP + RestEasy HttpClientRequest SPI 初步实现 Mock

整个系统的开发架构分层依赖是：facade->biz->service，基本的所有核心逻辑都是在 service 中，请求的 request dto 最多不能越界到 service 层，按照规范讲 request dto 顶多滞留在 biz 层，但是在互联 的世界中一些都是可以快速迭代的，并不是多么硬性规定，及时重构是偿还技术债务的主要方法。

前面我们已经讲过，我们采用的 RPC 框架是 RestEasy + RestEasy client ，我们先来看下入口的地方。

再看下 service 对象。

我们重点看下 @MockFacade annotation 声明。

通过这个 annotation 我们的主要目的就是将 mockParameter 放到 ThreadLocal 中去和请求处理完时的清理工作。还有一个功能就是 service 层的 mock bean 处理。