• 背景
• 被忽视的软件工程环节 – 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 规则引擎 中抽象出业务方营销活动的返回信息，同时打通个性化营销活动与公共交易、结算环节，形成一个完整的业务流。

有了 mock facade 之后就需要 request 定义 mock parameter 参数了。

我们暂且忽略通用型之类的设计，这里只是我们在赶项目的情况下做的一个迭代尝试，等我们把这整个流程都跑通了再来考虑重构提取框架。

有了输入参数，我们就可以根据参数判断来动态注入 mock facade。

自动化测试阶段 mock 需求

我们继续向前推进，过了连调阶段紧接着就进入测试环节，现在基本上大多数互联 公司都是自动化的测试，很少在有手动的，尤其是后端系统。

那么在 autoTest 阶段面临的一个问题就是，我们需要一个公共的 autoTest 地址，这个测试地址是不变的，我们在自动化测试下 mock 的 facade bean 的地址就是这个地址，这个地址输出的值需要能够对应到每次自动化脚本执行的上下文中。

我们有很多微服务系统来组成一个平台，每个服务都有依赖的第三方接口，原来在自动化测试这些服务的时候都需要去了解业务方系统的接口、DB、前台入口等，因为在编写自动化脚本的时候需要同步创建测试数据，最后才能 Assert。

这个跨部门的沟通和协作效率严重低下，而且人员变动、系统变动都会直接影响上线周期，这里绝对值得创新来解决这个效率严重阻塞问题。

这里的 mockUrl 就是我们抽象出来的统一的 autoTest 地址，在前面的 mock parameter 中有一个 useAutoTestMock Boolean 类型的参数，如果当前请求此参数为 true，我们将动态注入自动化测试 mock bean ，后续的所有调用都会走到 mockUrl 指定的地方。

autoTest Mock Gateway 浮出水面

到目前为止，我们遇到了自动化测试统一的 mock 地址要收口所有微服务在这方面的需求。现在最大的问题就是，所有的微服务对外依赖的 response 都不相同，自动化脚本在执行的时候预先创建好的 response 要能适配到当前测试的上下文中。

比如，营销规则引擎，我们的自动化脚本在创建一个订单的时候需要预先构造好当前商品（比如，productID：101010），在获取外部营销中心提供的活动信息和抵扣信息的 response ，最后才能去 Assert 订单的金额和活动信息记录是否正确，这就是一次 autoTest context 。

MockGateway 是一个支点，我相信这个支点可以撬动很多测试空间和创新能力。

轻量级版本实现

接下来我们将展示在 marketing-cloud 营销规则引擎 中的初步尝试。

整体逻辑架构

自动化脚本在每跑一个 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 处理。