背景
从 SOA 架构到现在大行其道的微服务架构，系统越拆越小，整体架构的复杂度也是直线上升，我们一直老生常谈的微服务架构下的技术难点及解决方案也日渐成熟（包括典型的数据一致性，系统调用带来的一致性问题，还是跨节点跨机房复制带来的一致性问题都有了很多解决方案），但是有一个环节我们明显忽略了。
在现在的微服务架构趋势下，微服务在运维层面和自动化部署方面基本上是比较完善了。从我个人经验来看，上层的开发、测试对微服务架构带来的巨大变化还在反应和学习中。
开发层面讨论微服务的更多是框架、治理、性能等，但是从完整的软件工程来看我们严重缺失分析、设计知识，这也是我们现在的工程师普遍缺乏的技术。
我们经常会发现一旦你想重构点东西是多么的艰难，就是因为在初期构造这栋建筑的时候严重缺失了通盘的分析、设计，最终导致这个建筑慢慢僵化最后人见人怕，因为他逐渐变成一个怪物。（比如，开发很少写 unitTest ，我们总是忽视单元测试背后产生的软件工程的价值。）
被忽视的软件工程环节 — DEVTESTOPS
我们有没有发现一个现象，在整个软件过程里，测试这个环节容易被忽视。任何一种软件工程模型都有 QA 环节，但是这个环节似乎很薄很弱，目前我们绝大多数工程师、架构师都严重低估了这个环节的力量和价值，还停留在无技术含量，手动功能测试低级效率印象里。
这主要是测试这个角色整个技术体系、工程化能力偏弱，一部分是客观大环境问题，还有一部分自身问题，没有让自己走出去，多去学习整个工程化的技术，多去了解开发的技术，生产上的物理架构，这会有助于测试放大自己的声音。
导致测试环节在国内整个设计创新薄弱的原因还有一个主要原因就是，开发工程师普遍没有完整的工程基础。在国外IT发达国家，日本、美国等，一个合格的开发工程师、测试工程师都是边界模糊的，自己开发产品自己测试，这需要切换思维模式，需要同时具备这两种能力，但是这才是整个软件工程的完整流程。
我们有没有想过一个问题，为什么现在大家都在谈论 DevOps，而不是 DevTestOps，为什么偏偏跳过测试这个环节，难道开发的系统需要具备良好的可运维性就不需要可测试性吗，开发需要具备运维能力，运维需要具备开发能力，为什么测试环节忽略了。
我们对 QA 环节的轻视，对测试角色的不重视其实带来的副作用是非常大的。
微服务架构下测试复杂度和效率问题
微服务的拆分粒度要比 SOA 细了很多，从容器化镜像自动部署来衡量，是拆小了之后很方便，但是拆小了之后会给整个开发、测试环节增加很大的复杂度和效率问题。
在 SOA 时期，契约驱动 这个原则在微服务里也一样适用，跨部门需求定义好契约你就可以先开发上线了。但是这个里面最大的问题就是当前系统的部分连调问题和自动化回归问题，如果是新系统上线还需要做性能压测，这外部的依赖如何解决。
也许我们会说，不是应该依赖方先ready，然后我们紧接着进行测试、发布吗。如果是业务、架构合理的情况下，这种场景最大的问题就是我们的项目容易被依赖方牵制，这会带来很多问题，比如，研发人员需要切换出来做其他事情，branch 一直挂着，不知道哪天突然来找你说可以对接了，也许这已经过去一个月或者更久，这种方式一旦养成习惯性研发流程就很容易产生线上 BUG 。
还有一种情况也是合理的情况就是平台提供方需要调用业务方的接口，这里面有一般调用的 callback 接口、交易链路上的 marketing 接口、配送 routing 接口等。
这里给大家分享我们目前正在进行中的 marketing-cloud (营销云) 规则引擎 项目。
marketing-cloud 提供了一些营销类业务，有 团购、优惠券、促销 等，但是我们的业务方需要有自己个性化的营销活动玩法，我们需要在 marketing-cloud 规则引擎 中抽象出业务方营销活动的返回信息，同时打通个性化营销活动与公共交易、结算环节，形成一个完整的业务流。
这是一个 marketing-cloud 逻辑架构图，跟我们主题相关的就是 营销规则引擎 ，他就是我们这里所说的合理的业务场景。
在整个正向下单过程中，营销规则引擎要肩负起既要提供 marketing-cloud 内的共用营销活动，还需要桥接外部营销中心的各类营销玩法，外部的营销中心会有多个，目前我们主要有两个。
由于这篇文章不是介绍营销平台怎么设计，所以这里不打算扩展话题。主要是起到抛砖引玉的目的，平台型的业务会存在各种各样的对外系统依赖的业务场景。文章接下来的部分将展开 marketing-cloud 规则引擎 在打通测试链路上的实践。
开发阶段 unitTest mock 外部依赖
在开发阶段，我们会经常性的编写单元测试来测试我们的逻辑，在编写 unitTest 的时候都需要 mock 周边的依赖，mock 出来的对象分为两种类型，一种是不具有 Assert 逻辑的 stub 桩 对象，还有一种就是需要支持 Assert 的 mocker 模拟对象。
但是我们也不需要明显区分他们，两者的区别不是太明显，在编码规范内可能需要区分。
我们关心的是如何解决对象之间的依赖问题，各种 mock 框架其实提供了很多非常好用的工具，我们可以很轻松的 mock 周边的依赖。
given(marketingService.mixMarketingActivity(anyObject())).willReturn(stubResponse); RuleCalculateResponse response = this.ruleCalculatorBiz.ruleCalculate(request); 这里我们 mock 了 marketingService.mixMarketingActivity() 方法。 |
Java 世界里提供了很多好用的 mock 框架，比较流行好用的框架之一 mockito 可以轻松 mock Service 层的依赖，当然除了 mockito 之外还有很多优秀的 mock 框架。
这些框架大同小异，编写 unitTest 最大的问题就是如何重构逻辑使之更加便于测试，也就是代码是否具备很好的可测试性，是否已经消除了绝大多数 private 方法，private 方法是否有某些指责是我们没有捕捉到业务概念。
连调阶段 mock 外部依赖
在我们完成了所有的开发，完善的单元测试保证了我们内部的逻辑是没有问题的（当然这里不讨论 unitTest 的 case 的设计是否完善情况）。
现在我们需要对接周边系统开发进行连调了，这个周边系统还是属于本平台之类的其他支撑系统。比如我们的 marketing-cloud 规则引擎系统 与 下单系统 之间的关系。在开发的时候我们编写 unitTest 是顺利的完成了开发解决的验证工作，但是现在面对连调问题。
系统需要正式的跑起来，但是我们缺乏对外部营销中心的依赖，我们怎么办。其实我们也需要在连调阶段 mock 外部依赖，只不过这个 mock 的技术和方法不是通过 unitTest 框架来支持，而是需要我们自己来设计我们的整个服务的开发架构。
首先要能识别本次 request 是需要 mock 的，那就需要某种 mock parameter 参数来提供识别能力。
我们来看下 marketing-cloud 营销规则引擎 在这块的一个初步尝试。
public interface CCMarketingCentralFacade { CallResponse callMarketingCentral(CallRequest request); } |
public interface ClassMarketingCentralFacade { CallResponse callMarketingCentral(CallRequest request); } |
营销规则引擎使用 RestEasy client api 作为 rest 调用框架。这两个 Facade 是营销平台对 CCTalk 、沪江网校 沪江两大子公司营销中心发起调用的 Facade。
(为了尽量还原我们的工程实践干货同时需要消除一些敏感信息的情况下，整篇文章所有的代码实例，我都删除了一些不影响阅读且和本文无关的代码，同时做了一些伪编码和省略，使代码更精简更便于阅读。)
在正常逻辑下，我们会根据营销路由 key 来决定调用哪个公司的营销中心接口，但是由于我们在开发这个项目的时候暂时业务方还没有存在的地址让我们对接，所以我们自己做了 mock facade，来解决连调问题。
public class CCMarketingCentralFacadeMocker implements CCMarketingCentralFacade { @Override public CallResponse callMarketingCentral(CallRequest request) { CallResponse response = ... MarketingResultDto marketingResultDto = ... marketingResultDto.setTotalDiscount(new BigDecimal("90.19")); marketingResultDto.setUseTotalDiscount(true); response.getData().setMarketingResult(marketingResultDto); return response; } } |
public class ClassMarketingCentralFacadeMocker implements ClassMarketingCentralFacade { @Override public CallResponse callMarketingCentral(CallRequest request) { CallResponse response = ... MarketingResultDto marketingResultDto = ... marketingResultDto.setUseCoupon(true); marketingResultDto.setTotalDiscount(null); marketingResultDto.setUseTotalDiscount(false); List<MarketingProductDiscountDto> discountDtos = ... request.getMarketingProductTagsParameter().getMarketingTags().forEach(item -> { MarketingProductDiscountDto discountDto = ... discountDto.setProductId(item.getProductID()); ... discountDtos.add(discountDto); }); ... return response; } } |
我们定义了两个 mock 类，都是一些测试数据，就是为了解决在连调阶段的问题，也就是在 DEV 环境上的依赖问题。
有了 mock facade 之后就需要 request 定义 mock parameter 参数了。
public abstract class BaseRequest implements Serializable { public MockParameter mockParameter; } |
public class MockParameter { /** * mock cc 营销调用接口 */ public Boolean mockCCMarketingInterface; /** * mock class 营销调用接口 */ public Boolean mockClassMarketingInterface; /** * 是否自动化测试 mock */ public Boolean useAutoTestMock; /** * 测试mock参数 */ public String testMockParam; } |
我们暂且忽略通用型之类的设计，这里只是我们在赶项目的情况下做的一个迭代尝试，等我们把这整个流程都跑通了再来考虑重构提取框架。
有了输入参数，我们就可以根据参数判断来动态注入 mock facade。
自动化测试阶段 mock 需求
我们继续向前推进，过了连调阶段紧接着就进入测试环节，现在基本上大多数互联网公司都是自动化的测试，很少在有手动的，尤其是后端系统。
那么在 autoTest 阶段面临的一个问题就是，我们需要一个公共的 autoTest 地址，这个测试地址是不变的，我们在自动化测试下 mock 的 facade bean 的地址就是这个地址，这个地址输出的值需要能够对应到每次自动化脚本执行的上下文中。
我们有很多微服务系统来组成一个平台，每个服务都有依赖的第三方接口，原来在自动化测试这些服务的时候都需要去了解业务方系统的接口、DB、前台入口等，因为在编写自动化脚本的时候需要同步创建测试数据，最后才能 Assert。
这个跨部门的沟通和协作效率严重低下，而且人员变动、系统变动都会直接影响上线周期，这里绝对值得创新来解决这个效率严重阻塞问题。
@Value("${marketing.cloud.business.access.url.mock}") private String mockUrl; |
/** * 自动化测试 mocker bean */ @Bean("CCMarketingCentralFacadeTestMock") public CCMarketingCentralFacade CCMarketingCentralFacadeTestMock() { RestClientProxyFactoryBean<CCMarketingCentralFacade> restClientProxyFactoryBean ... restClientProxyFactoryBean.setBaseUri(this.mockUrl); ... } /** * 自动化测试 mocker bean */ @Bean("ClassMarketingCentralFacadeTestMock") public ClassMarketingCentralFacade ClassMarketingCentralFacadeTestMock() { RestClientProxyFactoryBean<ClassMarketingCentralFacade> restClientProxyFactoryBean ... restClientProxyFactoryBean.setBaseUri(this.mockUrl); ... } |
这里的 mockUrl 就是我们抽象出来的统一的 autoTest 地址，在前面的 mock parameter 中有一个 useAutoTestMock Boolean 类型的参数，如果当前请求此参数为 true，我们将动态注入自动化测试 mock bean ，后续的所有调用都会走到 mockUrl 指定的地方。
autoTest Mock Gateway 浮出水面
到目前为止，我们遇到了自动化测试统一的 mock 地址要收口所有微服务在这方面的需求。现在最大的问题就是，所有的微服务对外依赖的 response 都不相同，自动化脚本在执行的时候预先创建好的 response 要能适配到当前测试的上下文中。
比如，营销规则引擎，我们的自动化脚本在创建一个订单的时候需要预先构造好当前商品（比如，productID：101010），在获取外部营销中心提供的活动信息和抵扣信息的 response ，最后才能去 Assert 订单的金额和活动信息记录是否正确，这就是一次 autoTest context 。
有两种方式来识别当前 autoTest context ，一种是在 case 执行的时候确定商品ID，最后通过商品ID来获取 mock 的 response 。还有一种就是支持传递 autoTest mock 参数给到 mockUrl 指定的服务，可以使用这个参数来识别当前测试上下文。
一个测试 case 可能会穿过很多微服务，这些所有的依赖服务可能都需要预设 mock response，这基本上是一劳永逸的。
所以，我们抽象出了 autoTest Mock Gateway（自动化测试mock网关服务） ，在整个自动化测试环节还有很多需要支持的工作，服务之间的鉴权，鉴权 key 的 mock，加解密，加解密 key 的 mock，自动化测试 case 交替并行执行等。
作为工程师的我们都希望用系统化、工程化的方式来解决整体问题，而不是个别点状问题。有了这个 mock gateway 我们可以做很多事情，也可以普惠所有需要的其他部门。
在一次 autoTest context 里构造好 mock response，然后通过 mock parameter 来动态识别具体的来源服务进行路由、鉴权、加解密等操作。
MockGateway 是一个支点，我相信这个支点可以撬动很多测试空间和创新能力。
轻量级版本实现
接下来我们将展示在 marketing-cloud 营销规则引擎 中的初步尝试。
整体逻辑架构
自动化脚本在每跑一个 case 的时候会创建当前 case 对应的 autoTestContext，这里面都是一些 meta data，用来表示这个 case 中所有涉及到的微服务系统哪些是需要走 mock gateway 的。
在 mockGateway 中所有的配置都是有一个 autoTestContext 所对应，如果没有 autoTestContext 说明是所有 case 共用。
将 mock parameter 纳入服务框架标准 request contract
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
