测试环境对于任何一个软件公司来讲，都是核心基础组件之一。转转的测试环境伴随着转转的发展也从单一的几套环境发展成现在的任意的 docker 动态环境 +docker 稳定环境环境体系。期间环境系统不断的演进，去适应转转集群扩张、新业务的扩展，走了一些弯路，但最终我们将系统升级到了我们认为的终极方案。下面我们介绍一下转转环境的演进和最终的解决方案。

1 测试环境演进
1.1 单体环境
    转转在 2017 年成立之初，5 台 64G 内存的机器，搭建 5 个完整的测试环境。就满足了转转的日常所需。一台分给开发，几台分给测试。通过沟通协调就能解决多分支并行开发下冲突问题。图片

1.2 动态环境 + 稳定环境
    随着微服务化的进行，转转的服务数量是急速扩充的。分支并行开发增多，共用环境造成的互相影响也逐渐增多。单体环境已经不能满足我们的需求。新的组织形式被提了出来。动态环境部署修改的服务和一些必要服务。稳定环境部署和线上一致的服务。同时我们开发了一个环境平台去管理环境的申请到回收的整个生命周期。阶段性的满足了我们诉求。图片    存在问题：请求进入到稳定环境之后，调用将会在稳定环境中，无法调用到动态环境的服务。导致被测服务之前的所有服务、mq 的生产方都要部署到当前测试机上，即使这些服务没有任何变化，随着集群规模的继续扩大，对资源的消耗飞速增加。

1.3 动态环境 + 稳定环境（ip 路由）
    对于上面的问题，我们期望能做成请求的流量是动态环境下优先，如果没有的情况下再请求到稳定环境上，这样测试机上只部署发生了变化的服务和入口服务（必需）就可以了。随后和架构运维一起实现了 ip 路由的功能，就是将 ip 作为泳道名称向下传递。图片    这个方案上线后，资源使用量下降 30% 左右。在 2019 年上线后的两年内，转转经历了和找靓机合并，芯片供应紧张导致机器长时间无法采购到，在这个背景下，保证了转转环境的应用。但是问题也日益的凸显。

2 环境使用中的问题
图片    从大的方面来讲：系统稳定性，资源成本，使用效率三个方面互相制衡。在成本（包括采购困难）这个限制下，旧机器无法淘汰导致稳定性问题。资源不足，现存的测试机使用率就降不下来，稳定环境就无法保持内存 30% 空闲率的下限，稳定性就会成问题。测试环境就需要严格的回收策略，导致用户的使用体验和使用效率下降，如：到期回收和资源空闲回收，肯定会导致部分使用中的环境被回收掉，尤其是大的内存环境，对应大的项目，恢复起来慢，影响也大。已有的架构下不能做到三者兼得，或者说不能做到我们希望的妥协。具体的问题如下：

2.1 资源的不足
    业务的增长和集群数量的增长，叠加服务器采购不到的情况，机器资源很紧张。测试资源池 3.8T, 高峰占用率 80%。剩余资源散落在 20 几台物理机上，导致超过 40G 内存的机器都是比较难申请的。

2.2 资源的浪费
    在机器资源不足的情况下，还存在机器资源浪费的情况，现有的方案，机器申请下来内存是固定的，不能自动的扩容和缩容，随着环境中被测服务的逐渐上线，最新版本会被同步到稳定环境中，动态环境和稳定环境中重复的服务会越来越多。但是无法将测试资源回收到资源池之中。

2.3 稳定性问题
机器的稳定性
    众所周知，测试环境的机器基本都是线上过保的机器，年龄不一，但是一般比较大，损坏是常有的事情，我们高峰期一个月损坏了 5 台物理机。对业务产生直接影响。

部署过程简要介绍
先简单介绍下机器启动部署过程：图片

系统的稳定性
整个初始化部署，流程 7-8 步，各个环境都可能出现问题，日常稳定性不足。
在上面 3 个方案的历史迭代中，积累了大量的历史包袱。每次部署都要要对测试配置文件中的数据库、redis、mq、zk 等配置进行替换，易出错，不易维护，工程规范化不足。
在环境的构成中，环境中每次添加删除服务，都要重新计算 nginx 和 host，依赖长，容易出错。
日常使用中，内存不足的情况下，无法自动扩容，只能重新申请环境，时间成本高。
Kvm 资源方案生态差，维护成本高。
    以上这些过程中的问题，每周会有 25 个左右环境问题反馈，我们每周都需要 8h 左右的运维时间。为了解决上面的问题，我们开发了系统错误分析工具，虚拟机重启工具、机器资源报警工具、机器存活监控、稳定环境整体迁移工具等众多管理员工具帮助用户和我们解决日常问题。整体来讲日常的维护成本是很高的。用户用着有很多问题，也很不爽。

3 解决方案：动态环境 + 稳定环境（标签路由）
3.1 解决方案
系统底层架构修改
    由于以上的问题，我们和架构运维重新设计了环境平台的方案。我们最终采用了 docker + 稳定环境的方案。ip 路由变成了标签路由，一个环境不再是一台机器上部署多个服务，而是一个环境下，多个 docker 组成，多个 ip 组成，如下：环境 yyy 由服务 B 和 D 组成，ip 分别为 192.168.5.1 和 192.168.6.1。图片    这样镜像初始化、agent 初始化过程被干掉。环境的大小限制不再是一个宿主机大小决定，极限情况下一个环境可以包含转转所有的服务。单个环境容量不再是问题。    通过 k8s 的特性，部署时会新启动一个节点，并且新节点启动成功之后，下线旧节点。保证了服务在部署过程中，服务不中断。

工程规范化
推动 rd 升级服务，将测试配置修改为正常的配置，从而下掉平台的配置替换。

nginx 中心化
去掉每个环境上的 nginx，消灭 ng 部署生成过程的问题。通过系统联动使用运维的中心化 nginx。

host 配置
推动删除不必要的公共 host，在服务升级的过程中推动 RPC 的 host 调用方式升级为服务管理平台，剩余公共 host 采用内部 dns 能力进行解决。

新问题
在制定新方案的过程中，一个目标是解决之前的依赖问题，一个就是尽量减少新方案带来的使用方式上变动，减少用户使用成本。环境 docker 化之后最大的影响是什么呢？一、ip 变成了标签，不再是唯一 ip。

二、服务每部署一次，ip 变一次。

ip 没了，那么入口 host 怎么配置？ip 变了，那么如何登录到机器上？如何查看历史日志？如何进行单元测试？解决方案：

转转之前有泛域名解析的能力,如 app.zhuanzhuan.com 带标签可以写为 app-${tag}.zhuanzhuan.com。
请求 whistle 配置中 增加：192.xxx.xxx.xxx app.zhuanspirit.com excludeFilter://*/api reqHeaders://(Global-Route-Tag:test1234)。注：192.xxx.xxx.xxx 为中心化 nginx。
增加 webshell 解决 ip 变动带来的登录成本增加。
增加历史日志查询功能，解决 ip 销毁后历史日志查询问题。
增加本地化标签路由的功能，解决单元测试每次输入 ip 的问题。变成标签设置。注：在后面的 docker 推广过程中，我们发现方案中，我们漏掉了远程 debug 场景下，ip 变动的问题。最后通过开发了一个 idea 插件和环境平台联动解决。
新的运营方式
    新的技术方案中，资源的最小管理节点由之前的一个 kvm 变为标签中的一个服务。在测试服务上线之后，环境平台会自动同步最新代码到稳定环境，之后将测试标签中刚刚上线的服务删除，回收资源。从而避免资源的浪费。图片

成果
部署过程缩减为：服务镜像启动 + ng 配置同步。步骤极大的缩减。稳定性、效率提高。在宿主机挂掉的情况下，k8s 自动调度到新的节点。进一步保证稳定性。资源成本、稳定性和使用效率三方的制衡被打破。三方面充分的得到了提高。目前：

用户问题：减少 95%，并且大项目测试中，环境问题消失了。
申请时间：由 28 分钟到 5 分钟以内。
资源占用：3200G 到 1200G。
总结
在制定了这个方案之后，转转在架构、运维和工程效率三个部门互相配合情况下，1 个月内完成开发，3 个月内完成了服务升级。1 年内完成了整体功能的推广。取得了丰硕的成果。
docker 化之后，改变了整个环境的使用生态。现在，要用一个测试环境，申请则立即可用。过程中不再有任何心力消耗，不再有中断。并且资源管理的最小节点变为一个服务。环境系统的底层技术架构在我们看来处于业内目前的最优的方案，在系统、用户层面上做到了资源，性能和效率三者的整体性提升和平衡。整个系统是相对成熟的，可以预见的是，在未来很长一段时间内系统不需要再进行系统结构上的升级。

更多技术实现细节

关于作者

陈秋，转转工程效率负责人，主要负责配置管理和 devops 体系建设。欢迎大家留言、交流互相学习。

转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。
关注公众号「转转技术」（综合性）、「大转转 FE」（专注于 FE）、「转转 QA」（专注于 QA），更多干货实践，欢迎交流分享~