技术团队对测试环境治理的高效能实践（上）

lsekfe

转转测试环境治理历经3个版本的迭代，环境搭建耗时及资源占用大幅度下降，在此过程中积累了丰富的实践经验。本文将从测试环境的需求及背景出发，介绍转转测试环境治理各个版本的原理、技术、优缺点，毫无保留地将转转的实践经验分享给各位读者。
　　背景及需求
　　系统架构的发展
　　很久很久以前，在并发量较低时系统大多采用单体架构，由单个web服务直接连接数据库，由nginx在多个web服务节点间做负载均衡。

单体架构

　　随着系统并发量的提高，单体架构无法满足性能需求，需要对单体服务进行拆分，于是来到了微服务架构。微服务架构与单体架构显著的不同在于链路更长更复杂了。

微服务架构

　　测试环境的需求
　　测试环境与线上环境的典型不同在于线上环境各节点一般情况下代码是一致的，各节点是对等的，请求到达任意节点业务逻辑都是一致的；而测试环境一般是多分支并行开发，每个节点的逻辑是不一致的，既然要测试本次所开发的功能，那就要求请求能精准地到达所部署的节点。
　　在单体架构下，该需求是很容易实现的，通过采用修改nginx配置，在upstream中仅包含目标测试节点可以很容易实现对目标节点的精准测试，或者不使用nginx直接通过IP+port的形式进行调用也同样可以实现请求精准到达目标节点。如下图所示的A'及A''属于两个不同的需求，分别通过固定nginx upstream及IP+port的形式实现了请求的精准控制。

单体架构测试

　　而在微服务架构下，该需求实现起来就没那么简单了。如下图所示，链路上包括服务A、B、C，图中A'、B'、C'属于同一个需求，而A''、B''、C''属于另一个需求。采用在单体架构下的解决方案只能控制请求精准地到达A'或者A''，无法实现请求精准地到达B'、C'及B''、C''。

微服务架构测试

　　传统的测试环境解决方案-物理隔离
　　为了实现请求精准地到达被测服务节点，传统的做法是提供多套完全互相隔离的测试环境，每套测试环境包含全量的服务及注册中心、MQ broker等。每个需求分配一套测试环境，只需将被测服务部署至该环境内即可实现请求精准地到达被测节点，这种做法也称作物理隔离。

物理隔离

　　物理隔离在公司服务数量较少时（20个服务以下）称得上是完美的解决方案，非常简单可靠。但是随着服务数量的增长，物理隔离的缺点逐渐显露——资源浪费太严重。假设整个系统有100个服务，而每次需求仅修改其中的1-3个服务，资源浪费率高达97%-99%。而且服务数量的增长，往往也意味着公司业务的发展壮大，同时进行中的需求数量也在增长，需要提供更多的测试环境，资源消耗巨大。
　　转转测试环境V1-改进的物理隔离
　　转转公司传统的测试环境解决方案属于改进型的物理隔离。
　　稳定环境
　　在转转有一套稳定环境包含全量的服务并且与线上代码一致。在测试环境不使用注册中心，而是为每一个服务分配唯一的域名并通过修改机器host映射的方式手动控制服务发现。默认情况下，如果服务A部署在稳定环境的192.168.1.1上，那么所有测试环境机器的host文件中都存在一项配置192.168.1.1 A.zhuaninc.com。
　　动态环境
　　每次需求所申请的环境称为动态环境，为一台kvm虚拟机。假设某动态环境的IP为192.168.2.1，在该动态环境部署服务A时，同时将该机器的host文件中192.168.1.1 A.zhuaninc.com（假设稳定环境服务A的IP为192.68.1.1）映射，修改为127.0.0.1 A.zhuaninc.com。
　　如下图所示的动态环境192.168.4.1，其中A'及E'即为本次需求所修改的服务。

　　初始化过程如下：
　　申请动态环境192.168.4.1，申请完成后该机器的host文件中包含全量的服务域名映射，默认映射到对应的稳定环境所在的IP，该例中仅展示了F服务的域名映射为192.168.5.1 F.zhuaninc.com （假设稳定环境服务F的IP为192.168.5.1）。
　　部署服务E'，同时将127.0.0.1写入host文件。
　　部署服务D，同时将127.0.0.1写入host文件。
　　部署服务C，同时将127.0.0.1写入host文件。
　　部署服务B，同时将127.0.0.1写入host文件。
　　部署服务A'，同时将127.0.0.1写入host文件。
　　部署Entry。

　　部署nginx，同时将服务A的upstream修改为仅包含127.0.0.1。
　　如此以来，就像焊接管道一样，从服务E至nginx倒序焊接出一条没有分叉的管道。测试时只需要通过host映射将被测域名映射到该IP，即可实现请求精准地到达A'及E'，E'以后的链路（从F开始的链路）则使用稳定环境。
　　对于MQ，则通过在动态环境topic添加IP前缀的方式实现与稳定环境的物理隔离，如下图所示不同的topic在broker上存在着不同的队列，稳定环境的消息和动态环境的消息不能互通。

MQ消息物理隔离

　　如在测试过程中发现需要修改更多的服务，例如需要修改服务F，则在将F服务部署在该动态环境的同时，需要重启服务E'，因为E'已经与稳定环境的F建了tcp连接，修改F服务的域名映射并不会导致E'与F之间重新建立tcp连接，所以需要重启E'。如F服务的调用方不仅有E'，则都需要重启。
　　3.3 优缺点
　　该解决方案近似于物理隔离，但较物理隔离有所改进，改进的地方在于动态环境并没有包含全量的服务，动态环境仅包含了从nginx开始至最后一个被测的服务，而使用稳定环境充当被测链路的尾巴。
　　3.3.1 优点
　　隔离性强，近似于物理隔离。
　　链路简单，流量封闭在同一台机器上。
　　3.3.2 缺点
　　需要部署从nginx开始至最后一个被测的服务，存在未修改服务部署在动态环境中的情况，造成资源浪费。
　　由于部署过程依赖服务的调用关系，导致部署效率低下，极端情况下需要数天调试测试环境。
　　host管理复杂。
　　topic添加IP前缀易出错，代码与环境相关。
　　单台机器内存有限，链路过长无法满足。