在软件开发的过程中,测试环境无疑是一个关键的组成部分,其为开发、测试团队提供一个安全、隔离的环境来验证软件的功能、性能和稳定性。
通常在业务发展的早期,整体的系统复杂度不高,可以依靠几个人或者一个团队维护一个专用的测试环境容器。然而,随着业务的不断成长, 一个业务场景可能会包含成百上千个依赖服务,至此问题变得复杂起来,这也成为许多大公司所面临的痛点。
滴滴作为一家有一定体量的互联网公司,也会遇到类似的问题,本文将介绍滴滴的测试环境选型,及我们如何实现快速、低成本的建设“无限套”测试环境。
为什么做线下仿真环境?
在生产环境中,各个业务线的 RD、SRE、DBA 等角色各司其职,最终构建成一个稳定的系统,然而这个系统并不是一成不变的,通常会伴有高频的需求变更及业务迭代。如果这些改动不经过充分的测试,势必会对生产环境的稳定性造成很大的影响,而测试环境的易用性则极大程度地决定了对这些改动验证的效果。
测试环境很简单 -- All in one
在业务初期整体依赖并不复杂的时候,通常都会采用这种方式——将所有需要用到的服务及依赖都打包到一个测试镜像中,并在镜像中维护一个命令行构建工具来方便 RD、QA 构建测试所需环境,这种方式我们称之为 All in one 模式。
这种模式可以在学习和理解成本都不高的情况下,随时拉取一个自己独享的测试环境,RD 就可以快速迭代需求,互不干扰。
但随着业务发展,当这个容器承载数百个服务的时候,这种模式反而开始制约研发效率,我们经常会听到这样的声音:
-“我花了 1 整天才调通的链路,才 1 周就不能用了?”
-“XXX服务怎么还没有啊?”
-“怎么和线上的路由规则怎么不一样啊?”
-“这次BUG因为测试环境 Redis 和生产环境版本不一致....”
测试环境很复杂 -- Simulation
总结上面的问题,主要原因有三点:维护成本高、使用成本高、仿真度低。
维护成本高:当一个镜像需要承载几百个服务后,需要验证的场景也更多。
需要专门团队维护,验收所有已知场景、配置、基础服务依赖,并能保障定期发版
有新服务增加时,需要及时补充新服务,必须保障时效性
需要维护命令行工具支持各式各样的场景,支持各种编译环境
几乎所有服务之外的环节都需要测试环境独有的知识经验
使用成本高:需要熟悉本环境独有的“坑”。
受限于资源,边界场景覆盖有限,此时需要使用者自行调通
服务间资源抢占严重,导致超时等问题
随着各个依赖服务的正常迭代,只能重新申请环境
仿真度低:与生产环境有较大差异从而无法保障有效验收。
业务侧:
由于都是先上线业务,再定期维护到镜像中,各服务版本势必落后生产环境
由于资源所限,部分业务和生产的逻辑是不一致的,甚至单独维护一套独立的代码
开关城、黑白名单、规则引擎等配置不一致,会导致部分场景很难构造,影响面不好评估
基础平台侧:
与生产环境版本、配置、限制不一致
基础平台的使用和默认行为与生产环境不一致
很自然地,大家会想到,和生产环境保持一致是不是就可以了?于是这就是演变出第二种思路,和生产环境一样的链路,这也就是 Simulation,即仿真模式。
但是这套链路一样的测试环境,需要比较高的基建成本,于是会有人提出在生产环境围出一个逻辑隔离的机房用于测试,也会有人提出的要在线下搭一套完整链路。
这里的线上代指生产环境,线下代表与生产环境隔离的测试环境。
线上还是线下
首先聊聊线上模式,采用的是流量隔离的方式。如果公司有比较扎实的多集群方案,就可以很轻松地圈出一个测试专用的集群,除了仅包含测试流量外其余和生产环境一致,维护成本也会非常低,很多时候甚至可以直接依赖上下游的生产环境,然后通过试账号等策略保持数据的逻辑隔离。
听起来比较美好,甚至不用维护出一套全链路就可以开始使用。不过这套方案的核心问题是会伴随常态的风险,因为待测代码本质上是不稳定的,操作不当极可能会导致线上BUG。比如:将生产环境服务打限流、误删了生产环境缓存之类的操作,这类问题不仅极难定位,且无法从根本上避免。
而在线下架设专门的测试环境是否可以解决上面说到的安全问题?当然可以,但是也会面临很大的挑战,且需要各个方向的支持:
常用基础平台支持线下能力:线下仿真的核心建设工作是需要各个基础平台支持线下环境,并提供一致的能力,比如配置下发、服务发现、日志采集、表结构变更等
各业务方构建稳定服务:需要面对如同套娃般的业务依赖,各个子方向都要像生产环境一样维护测试环境,否则底层的不稳定将会导致大面积的环境不可用
效能平台整合差异化需求:需要将与生产环境差异的操作和行为封闭在该平台统一管控,减轻大家的认知成本
早先滴滴也采用在线上仿真的方案,而一个又一个的偶发线上问题,让我们不得不调整方向,目前正努力建设线下仿真环境。
多个需求怎么办
很显然出于成本和维护的考虑,不可能每个需求都单独起一套环境,退而求其次只能是提供若干套全链路互相隔离的测试环境,然后各个业务自行协商使用。虽然也可以解决比较多场景的问题,但还是会有问题: