转转测试环境平台解决方案
一、引言
对每一个前来公司面试的同学笔者都会有“工作过程中遇到过哪些影响产品质量和工作效率的事情？”这样一个问题与其交流探讨，发现绝大数同学都会向我抱怨“测试环境不好用最影响工作效率，时常导致联调不充分引起线上Bug，但是一直都没有什么改善”这样一个问题，笔者所在的转转公司之前也深受此问题所困扰和折磨，出现此问题的根源是每一家互联网公司，都会不断的为了适应变化的市场做出业务的调整，这就需要项目不断的快速迭代上线提供相应的功能，在整个迭代过程中，不仅需要相关的PM、RD和QA高超的技术及良好的配合，也需要可用和稳定的测试环境提供最基础的保障，接下来笔者将会带领读者详细的分析一下这个问题及笔者所在公司最终是怎么解决的，提供给各位读者一个解决此问题的一个思路。
二、问题分析
下面就以上面这个比较典型的互联网公司技术分层架构为例说明（笔者所在公司也是采用这样的架构），搭建这样一套环境不仅需要了解整个系统包含的所有的组件（例如Nginx等）、服务（Tomcat及Rpc服务等）、缓存（Redis缓存等）、数据库（Mysql数据库等），知道各个服务模块的依赖关系、部署和启动顺序，最后需要申请服务器资源，开通各种访问权限，安装基础组件，部署服务，调试环境。整个搭建过程不仅需要熟悉整个系统而且还要熟悉公司的工作流程，最后可能还会花费大量的时间进行调试。由于数据的唯一性，我们通常会对tomcat及rpc服务有以下几种环境搭建方案：
1、共用一套测试环境
优点：只需要有一个同学熟悉整个系统和公司的工作流程即可搭建环境。
缺点：由于每个服务都可自由的部署不同的测试分支，如果某些服务部署了有Bug的分支，就会导致依赖服务不可用，从而导致整个测试环境不能用的问题。
2、每个业务线都搭建独立的并且部署了所有的Tomcat及Rpc服务的测试环境。
优点：由于业务线都在独立的测试环境上部署测试分支，就不会存在依赖的其他业务线的服务不可用的问题。
缺点：由于依赖的外部服务会有不断的迭代上线，这样就需要加强沟通，实时或者定期去维护这些依赖服务升级到最新版本，这就会加大测试环境的维护成本，有时也会存在沟通或者升级不到位时环境不可用的问题。
3、首先搭建一套完整的Tomcat和Rpc服务作为共享环境，然后每个业务线再搭建只部署本业务相关的Tomcat和Rpc服务的测试环境，再依赖共享环境。
优点：只需要有一个同学去维护这个共享环境，其他同学则不用关心所依赖的服务的稳定性。
缺点：由于同一个服务的不同分支只能按顺序部署测试，就会存在测试环境不够用的问题。
4、每个同学都搭建只部署本业务相关的Tomcat和Rpc服务的测试环境，再依赖共享环境。
优点：可以随时部署随时测试。
缺点：需要每个同学都要熟悉整个系统和公司的工作流程，环境搭建成本比较高。还会存在没有测试分支时用于搭建环境的服务器闲置的情况，资源利用率比较低的问题。
三、解决方案
以上每一种方案或存在测试环境不能用、或存在测试环没有充分使用导致不够用、或存在测试环境不好维护、或存在测试环境搭建困难等问题，都没有彻底的解决问题。如果能随时、快速拥有一套专属的并且搭建过程不需要亲自动手的测试环境，就不用担心测试环境不够用不会搭建的问题。如果只需要关心待测服务，不用担心依赖服务的稳定性，那就不存在测试环境不好维护的问题了。如果测试完了能方便的归还服务器，那就解决了资源利用率的问题了。接下来就详细讲一讲，我们是怎么用一个环境管理平台来实现以上的几个如果，彻底的解决环境问题。
平台系统架构
整个环境平台有平台端和Agent代理端两部分组成，平台负责发送命令（包含环境初始化、环境回收、部署服务、同步服务等命令），Agent代理负责处理命令并且把结果返回给平台端，以下将主要介绍平台端的模块功能，Agent代理可参考浅析测试环境远端Agent工作模式上、浅析测试环境远端Agent工作模式下两个系列文章。
平台模块介绍
1、服务管理模块
用于管理Tomcat服务配置、访问Tomcat服务需要的Nginx文件、Rpc服务配置、Rpc服务部署启动顺序等，部分页面如下：
新建Tomcat服务配置
新建Nginx文件
新建Rpc服务
Rpc服务部署启动顺序列表
2、机器管理模块
用于管理所有用于部署环境的服务器资源，根据用途不同，可以分为：
测试环境：专门用于被动态申请的服务器，在这里可以查看到能被动态申请的空闲状态的机器及机器的硬件配置信息，还可以查看到已经被申请的占用状态的机器、申请人及申请和到期时间。机器列表如下：
稳定测试环境：一套测试共享环境，用于部署所有的Tomcat和Rpc服务并且连接线下数据库及缓存，动态机器申请后，其上所部署的服务就可以通过机器上的host连接到
这些服务（平台会自动更新host）。这里的机器不能被动态申请，每台机器上都固定部署不同的服务，服务会定期的自动更新与线上保持一致，也可以手动的在平台上进行更新。机器列表如下：
服务部署情况如下
稳定沙箱环境：一套预上线共享环境，用于部署所有的Tomcat和Rpc服务并且连接线上数据库及缓存，动态机器申请后，其上所部署的服务就可以通过机器上的host连接到这些服务（平台会自动更新host）。这里的机器不能被动态申请，每台机器上都固定部署不同的服务，服务会定期的自动更新与线上保持一致，也可以手动的在平台上进行更新。机器列表如下：
服务部署情况如下
服务交互：测试机被申请后，机器中的host文件中的IP与Rpc服务域名的对应关系会自动更新，如果依赖的Rpc服务在本机，则会自动连接本地，如果依赖的Rpc服务不在本机，则会自动连接到稳定测试或者稳定沙箱环境中的Rpc服务。如果所示：
3、Host管理模块
用于管理所有的域名与IP的映射关系，包含部署的数据库、缓存及第三方服务，这些映射关系在机器被申请后，自动写到机器的host配置文件中，机器上的服务就可以通过host来访问，列表如下：
4、申请环境模块
在这里我们可以瞬间就能拥有专属自己的测试环境，随心所欲的部署服务，我们还可以延长机器的使用时间（默认一周）、对机器的使用人员进行授权，用完之后还可以一键进行回收，申请流程如下：
选择部署Tomcat服务
选择部署Rpc服务
选择机器配置
经过以上三步，系统就会自动分配一台机器，我们不仅可以查看服务的部署结果、部署日志，还可以动态的添加或者删除服务，效果如下：
目前覆盖了公司的所有业务线，一共管理60+tomcat服务，200+的rpc服务，150+的服务器，服务300多用户。
五、 未来展望
稳定（测试、沙箱）环境上的共享服务还不能实时的与线上环境保持一致，需要与公司的CI平台的上线系统整合，待到服务上线后就自动更新。（CI平台具体请参考文章效能提升的江湖路--转转Beetle平台百天记）
提高有限的机器资源的使用效率，机器被申请后，在用户主动回收或者系统自动回收之前，无法知道用户是否还在用于测试。
高效的监控机器的硬件及部署的服务状态，目前使用第三方开源的Falcon系统来监控，新增机器或者服务都需要去在去操作Falcon系统，这样增加了额外的维护工作量。
采用Docker动态的去管理机器资源及第三方组件。