正在上传…重新上传取消
【以下为分享实录，有删节】
测试环境管理之困
正在上传…重新上传取消
互联网产品的服务通常是由 Web 应用、中间件、数据库和许多后台业务程序组成，一套运行环境就是一个自成一体的小生态。部署软件产品的正式发布版本，为用户提供持续可靠的服务的环境为“正式环境”，而开发者用于日常的开发和验证的运行环境，就是我们说的“测试环境”，它是包含完成软件测试工作所必需的计算机硬件、软件、网络设备、历史数据的总称。
我们为什么要关注“测试环境”呢？因为测试环境出故障的几率非常高，大大影响软件研发的效率，这主要是由于由于频繁的版本变更，以及部署未经充分验证的代码等因素引起的。此外测试环境也是开发者使用最频繁的一种环境，数据表明，测试和联调任务通常占开发者日常工作时间的50%以上，稳定而易用的测试环境能够极大提高开发者的工作效率和幸福感。
理想的测试环境是怎样的？我们认为理想的测试环境需要做到以下几点：
一、本地直连，双向访问互通。开发者的大部分工作是在本地（自己的电脑）中完成的，然后通过测试环境验证所做的工作是否符合预期。如果“本地”和“测试环境”之间，不能够互通的话，开发者要验证自己开发的软件功能就会变得十分困难。
二、独占式随意使用，可重启，可调试，可断点。当团队有多名开发者进行多人并行开发的时候，如果共用一套测试环境就会出现相互干扰的情况。比如当我正在重启测试环境的时候，就可能影响到其它开发者的测试工作。因而理想的测试环境应该是“独占式”的，你使用你的环境，我使用我的环境，彼此不干扰。
三、多人随意组合协作，多服务联调不串流量。当多位开发者在同一个项目上进行合作的时候，开发者之间又是希望互通的。比如我的一个请求，希望调用对方本地的一个服务。同样对方也可以调用我本地的服务。同时，又希望非项目内的开发者的请求不要进来，即做到多服务联调不串流量。
四、多个依赖服务版本同时在线，想测哪个随时切换。当进行大版本更新的时候，我们可能既要测试新版本的兼容性，又要测试老版本的兼容性， 这就要求多个依赖服务版本同时在线，并且可以随时切换。
简单总结一下，理想的测试环境应该是：自由连接、随时可用、互访可控。
那么现实中的测试环境又是怎样的呢？所谓“理想很丰满，现实很骨感”，在一线工作的开发者可能会发现，真实的测试环境并非这么理想。
一、在中小企业，本地的开发机往往是不具有公网IP的机器，大多会使用内网IP地址，这样测试环境要回到本地环境时候是不通的。特别是在 在Kubernetes集群中，每个Pod都会被赋予一个Cluster IP，Cluster IP是一个在Kubernetes集群中特有的内网IP，我们在本地访问Cluster IP也是调不通的。这就造成了本地/集群双向均不通。
二、在中小企业，测试环境通常是共用的，这就会造成前文提到的相互干扰、调用和消息互串等问题。
三、如果开发者想独立拉起一套专用测试环境，不仅费时费力，而且资源成本也是难以招架的。
总之，现实中的测试环境：无法直连、稳定性差、流量混杂。
阿里巴巴的测试环境实践
以上提到的测试环境管理之困，总结一下主要有两点：一是本地和集群之间网络互通的问题；一个是多人协作开发时，路由的可访问性控制问题，比如谁和谁相连，谁和谁不相连，怎样做到相互间不干扰这些问题。
在阿里巴巴内部，我们主要通过两个机制来解决以上痛点：扁平的内网IP和项目环境。
扁平的内网IP主要是基于CNI(Conteinre Network Interface) 机制改造Kubernetes的IP逻辑实现的，可以使集群中的每个Pod分配到的IP与本地机器分配到IP处于一个大的网络环境下，这样就可以解决本地环境和集群之间互通的问题。但是这种方式实施起来比较复杂，而且通用性不高，因为每个企业内部的网络情况都不同，本次分享对这个方法不做详细的展开。
下面我们重点讲解“项目环境”。项目环境是基于RPC、消息中间件的虚拟环境，从表面上看，每个项目环境都是一套独立完整的测试环境，由一系列服务组成集群，而实际上，除了个别当前使用者想要测试的服务，其余服务都是通过路由系统和消息中间件虚拟出来的，指向公共基础环境的相应服务。
如上图所示，在某个开发项目中，我们有公共基础环境和三个独立的项目环境（项目环境）。服务A、服务B、服务C、服务D共同组成了完整的公共基础环境，在项目环境-2中只部署了“服务C”，但对于项目环境-2的使用者而言，他可以通过路由调用公共基础环境中的其它服务，因此他会认为项目环境-2就是一个完整的独立的测试环境。同样的道理，对于开发者而言，他们认为项目环境-1和项目环境-3也同样是完整的独立的测试环境。
我们创建一套“项目环境”肯定是比创建一套包含所有服务的测试环境的成本要低。本质上是基于消息路由的控制，实现集群中部分服务的复用。在这种机制下，许多外表庞大的独立测试环境实际只需要消耗极小的额外基础设施资源，即使给每个开发者配备一套专用的测试环境都是可行的。
为进一步提升测试效率，我们又捣鼓出一种开脑洞的玩法：将本地开发机加入项目环境。在阿里巴巴集团内部，由于开发机和测试环境都使用内网IP地址，稍加变通其实不难将特定的测试环境请求直接路由到开发机。这意味着，使用项目环境的开发者，在进行一项测试时，其服务调用链路上的服务，既可以来自公共基础环境，也可以来自项目环境，甚至来自本地环境。现在，调试集群中的服务变得非常简单，再也不用等待漫长的流水线构建，就像整个测试环境都运行在本地一样。
通过以上介绍的阿里巴巴关于测试环境的解决方案，能给开发者带来怎样的测试体验呢？
正在上传…重新上传取消
- 开发者会觉得自己坐拥整个服务集群，所有测试服务IP地址都可以由本地直接访问，随时进行断点、单步调试、重新部署服务等操作，而丝毫不会影响到其他人；
- 当多人协作研发软件时，每位开发者同一时刻只能属于同一个隔离域，同一个隔离域里面的服务相互可见，并且当出现服务调用的时候，会优先调用隔离域里面的服务。不同隔离域里面的服务相互之间不可见，是互不影响的；
- 由于我们是通过“染色”（打标签）的方式实现的隔离，这种隔离方式非常的灵活，假如某位开发者前面在跟第一个项目进行联调，调试结束后，他想把该服务放入第二个项目中进行调试，他只需要把自己的服务从一个项目环境退出，进入另一个项目环境即可，实现灵活组队协作。
总结
我们将测试环境管理遇到的问题归纳为两个主要问题，第一个是本地与集群互通互联的问题。在阿里巴巴集团内部主要通过基于CNI机制改造Kubernetes的IP逻辑实现的“扁平化的内网IP”这个方法来解决，这种方式更适合大型集团企业。对外，我们也推出了一个更轻量的开发解决方案，主要通过kt-connect这个工具实现，kt-connect是开源免费的，由阿里云·云效提供技术支持，在下一节的分享中我们会详细介绍该工具的使用。
正在上传…重新上传取消
第二个问题，是关于路由的控制，在阿里巴巴内部我们是通过“项目环境”与“隔离域”实现的。对外我们也推出了一个开源解决方案，主要通过kt-connect和kt-virtual-environment这两个开源工具来实现，具体方案会在本系列分享的第三节内容中讲述。
【下期预告】
【直播日期】4月22日 16:00
【直播主题】单人开发场景下的测试环境实践
【直播讲师】郑云龙 阿里巴巴技术专家
【观看方式】云效开发者交流群直播（钉钉群号：群号：23362009）
【关于云效】
云效，企业级一站式DevOps平台，源于阿里巴巴先进的研发理念和工程实践，致力于成为数字企业的研发效能引擎！云效提供从“需求 ->开发->测试->发布->运维->运营”端到端的在线协同服务和研发工具，通过人工智能、云原生技术的应用助力开发者提升研发效能，持续交付有效价值。
原文链接
本文为云栖社区原创内容，未经允许不得转载。
