滴滴线下仿真环境实践：从方案设计到持续运营

在软件开发的过程中，测试环境无疑是一个关键的组成部分，其为开发、测试团队提供一个安全、隔离的环境来验证软件的功能、性能和稳定性。

通常在业务发展的早期，整体的系统复杂度不高，可以依靠几个人或者一个团队维护一个专用的测试环境容器。然而，随着业务的不断成长, 一个业务场景可能会包含成百上千个依赖服务，至此问题变得复杂起来，这也成为许多大公司所面临的痛点。

滴滴作为一家有一定体量的互联网公司，也会遇到类似的问题，本文将介绍滴滴的测试环境选型，及我们如何实现快速、低成本的建设“无限套”测试环境。

为什么做线下仿真环境？

在生产环境中，各个业务线的 RD、SRE、DBA 等角色各司其职，最终构建成一个稳定的系统，然而这个系统并不是一成不变的，通常会伴有高频的需求变更及业务迭代。如果这些改动不经过充分的测试，势必会对生产环境的稳定性造成很大的影响，而测试环境的易用性则极大程度地决定了对这些改动验证的效果。

测试环境很简单 -- All in one

在业务初期整体依赖并不复杂的时候，通常都会采用这种方式——将所有需要用到的服务及依赖都打包到一个测试镜像中，并在镜像中维护一个命令行构建工具来方便 RD、QA 构建测试所需环境，这种方式我们称之为 All in one 模式。

这种模式可以在学习和理解成本都不高的情况下，随时拉取一个自己独享的测试环境，RD 就可以快速迭代需求，互不干扰。

但随着业务发展，当这个容器承载数百个服务的时候，这种模式反而开始制约研发效率，我们经常会听到这样的声音：

-“我花了 1 整天才调通的链路，才 1 周就不能用了？”

-“XXX服务怎么还没有啊？”

-“怎么和线上的路由规则怎么不一样啊?”

-“这次BUG因为测试环境 Redis 和生产环境版本不一致....”

测试环境很复杂 -- Simulation

总结上面的问题，主要原因有三点：维护成本高、使用成本高、仿真度低。

维护成本高：当一个镜像需要承载几百个服务后，需要验证的场景也更多。

• 需要专门团队维护，验收所有已知场景、配置、基础服务依赖，并能保障定期发版

• 有新服务增加时，需要及时补充新服务，必须保障时效性

• 需要维护命令行工具支持各式各样的场景，支持各种编译环境

• 几乎所有服务之外的环节都需要测试环境独有的知识经验

使用成本高：需要熟悉本环境独有的“坑”。

• 受限于资源，边界场景覆盖有限，此时需要使用者自行调通

• 服务间资源抢占严重，导致超时等问题

• 随着各个依赖服务的正常迭代，只能重新申请环境

仿真度低：与生产环境有较大差异从而无法保障有效验收。

业务侧：

• 由于都是先上线业务，再定期维护到镜像中，各服务版本势必落后生产环境

• 由于资源所限，部分业务和生产的逻辑是不一致的，甚至单独维护一套独立的代码

• 开关城、黑白名单、规则引擎等配置不一致，会导致部分场景很难构造，影响面不好评估

基础平台侧：

• 与生产环境版本、配置、限制不一致

• 基础平台的使用和默认行为与生产环境不一致

很自然地，大家会想到，和生产环境保持一致是不是就可以了？于是这就是演变出第二种思路，和生产环境一样的链路，这也就是 Simulation，即仿真模式。

但是这套链路一样的测试环境，需要比较高的基建成本，于是会有人提出在生产环境围出一个逻辑隔离的机房用于测试，也会有人提出的要在线下搭一套完整链路。

这里的线上代指生产环境，线下代表与生产环境隔离的测试环境。

线上还是线下

首先聊聊线上模式，采用的是流量隔离的方式。如果公司有比较扎实的多集群方案，就可以很轻松地圈出一个测试专用的集群，除了仅包含测试流量外其余和生产环境一致，维护成本也会非常低，很多时候甚至可以直接依赖上下游的生产环境，然后通过试账号等策略保持数据的逻辑隔离。

听起来比较美好，甚至不用维护出一套全链路就可以开始使用。不过这套方案的核心问题是会伴随常态的风险，因为待测代码本质上是不稳定的，操作不当极可能会导致线上BUG。比如：将生产环境服务打限流、误删了生产环境缓存之类的操作，这类问题不仅极难定位，且无法从根本上避免。

而在线下架设专门的测试环境是否可以解决上面说到的安全问题？当然可以，但是也会面临很大的挑战，且需要各个方向的支持：

• 常用基础平台支持线下能力：线下仿真的核心建设工作是需要各个基础平台支持线下环境，并提供一致的能力，比如配置下发、服务发现、日志采集、表结构变更等

• 各业务方构建稳定服务：需要面对如同套娃般的业务依赖，各个子方向都要像生产环境一样维护测试环境，否则底层的不稳定将会导致大面积的环境不可用

• 效能平台整合差异化需求：需要将与生产环境差异的操作和行为封闭在该平台统一管控，减轻大家的认知成本

早先滴滴也采用在线上仿真的方案，而一个又一个的偶发线上问题，让我们不得不调整方向，目前正努力建设线下仿真环境。 

多个需求怎么办

很显然出于成本和维护的考虑，不可能每个需求都单独起一套环境，退而求其次只能是提供若干套全链路互相隔离的测试环境，然后各个业务自行协商使用。虽然也可以解决比较多场景的问题，但还是会有问题：