? Java学习：Java从入门到精通总结

? Spring系列推荐：Spring源码解析

? 绝对不一样的职场干货：大厂最佳实践经验指南


? 最近更新：2022年4月8日

? 个人简介：通信工程本硕?、Java程序员?。我的故事充满机遇、挑战与翻盘，欢迎关注作者来共饮一杯鸡汤

? 点赞 ? 收藏 ⭐留言 ? 都是我最大的动力！

纵观淘宝和京东，国内的电商业务都有两个典型的技术难点：

1. QPS和TPS的压力大
2. 业务玩法花样多，要求支持复杂业务的扩展性

迈巴赫营销优惠计算系统

迈巴赫系统是天猫早期的营销计算引擎。在淘系应用早期，营销优惠也就只有满减和优惠券两种，再往后发展出现了满送玩法，赠送的可能是积分、商品等等。

如果把这些营销玩法合在一起，就会增加核销的复杂度，这里就涉及了求解背包问题，还有拆单（将优惠拆到不同的订单上），还有退单（用掉的优惠券如何还原，退货之后不满足满减了等等非常复杂的业务逻辑）。

从上面的分析可以看出，随着业务越来越多花样的出现，迈巴赫的线上故障迟早要来：

• 回归复杂
  牵一发而动全身，每次改动都需要进行全链路的回归

• 自动化率低
  强依赖于手工测试，每次引入新的规则后都需要手动进行全链路的测试，不仅费时费力，准确性还差

• 开发节奏紧
  由于互联网企业中的工作方式是倒排期，所以很难保证回归质量

在互联网公司，自身的业务是在急速变化的，所以很难给到足够的时间从架构层面思考系统应该是怎么做的，所以很多功能都是急速上线，也留有一定的隐患：很难达到100%的代码测试覆盖率

这就达到了一个悖论：代码测试覆盖率越高，业务变更成本越大；代码覆盖率越低，故障越多。

作为架构师，我们的任务就是破解技术难题，而破解技术难题的基础思路，就是上图所示的三步走战略，下面将以天猫的双引擎回归测试框架为例来进行说明。

双引擎回归测试框架

上面提到迈巴赫系统的缺陷在于：业务极度复杂，牵一发而动全身；测试成本高；资损问题频繁发生

下面就以“三步走”的眼光来看看天猫是如何破局的吧~

step1：以大化小

TM双引擎回归测试框架的顶层设计，可以被抽象成两个业务场景：

1. 测试样本的构建
2. 在回归用例中，将改动部分和线上代码运行部分进行比对

上述场景要求无人力介入，用自动化的手段将线上的测试用例全部包括

step2：职责领域划分

对于测试样本构建，构建了两个角色：

1. 金丝雀
   角色 = 新代码部署的机器
   边界 = 线上影子机（copy线上流量，而不真实承接线上流量）
   功能 = 执行真实流量，跑出结果

2. 数据工厂
   角色 = 采样器（数据从线上采样而来）
   边界 = 网关层 / 线上服务机器（部署位置）
   功能 = Copy线上百分比的流量

对于改动前后比对的需求，构建了如下角色：

• 数据比对工具
  角色 = response比对器（Api执行结果比对）
  边界 = 数据工厂（就在数据工厂这里比对，copy的流量在金丝雀机器里跑出的数据 vs 线上真实结果）
  功能 = 比对线上结果和金丝雀结果的不同

step3：分层构建细化方案
正常的机器和金丝雀机器两个执行的引擎，所以就叫双引擎，具体的执行步骤如下图所示：

首先在网关层做了一些手脚，采样器来采集线上流量（采集的比例尽量匹配单台机器能承载的峰值压力），采样器将采集到的流量发送给金丝雀机器，同时要将运行结果发到数据比对工具对比执行结果。

我们对数据比对工具也有一些功能上的要求，可以通过一些管理界面去标记某些字段不需要进行测试。

综上所述，我们可以看到一个规律，所有的困难问题都可以通过廉价的技术手段来组合完成。