免费动态域名解析软件_阿里巴巴是如何管理测试环境的？

作者 | 林凡（昵称：金吉）

正式环境的稳定性，除了软件本身的质量因素外，主要和运行主机、网络等基础设施有关，而测试环境的稳定性受人为因素影响较大。由于版本变更频繁，以及部署未经验证的代码，测试环境出现故障的情况屡见不鲜。本文就来介绍一下阿里巴巴是如何管理测试环境的。

阿里巴巴的很多做法看似简单，但背后却蕴藏着很多思考，比如对测试环境的管理。

互联网产品的服务通常由Web应用、中间件、数据库以及众多的后端业务程序组成，一套运行环境就是一个自成体系的小生态圈，最基础的运行环境是线上环境，产品正式发布版本部署在这里，为用户提供持续可靠的服务。

此外，还有许多不对外开放的运行环境，供产品团队日常开发、验证使用，统称为测试环境。正式环境的稳定性，除了软件本身质量因素外，主要与运行主机、网络等基础设施有关，而测试环境的稳定性受人为因素影响较大，由于版本变更频繁，以及部署未经验证的代码，测试环境故障屡见不鲜。

良好的代码提交习惯和恰当的变更前检查有助于减少故障的发生，但无法完全杜绝日后的问题。增加多套测试环境副本可以有效控制故障的影响，但企业的资源终究是有限的，降低测试环境成本和提高测试环境稳定性成为了矛盾的两面。

在这个领域，别出心裁的阿里巴巴研发效率团队设计了一项名为“特性环境”的服务级复用虚拟化技术，其巧妙之处让人惊叹。本文将围绕测试环境管理这个话题，聊聊这种阿里巴巴特有的工作方法。

测试环境管理的困境

测试环境的用途非常广泛，常见的测试环境有系统集成测试环境、用户验收测试环境、预发布测试环境、灰度测试环境等，它们体现了产品交付生命周期，也间接体现了整个团队的组织结构。

小型作坊式的产品团队的测试环境管理起来非常简单，每个工程师在本地启动全套软件组件进行调试即可，如果还是不放心，再加一个公共的集成测试环境就可以了。

随着产品规模扩大，在本地启动所有服务组件变得非常耗时且繁琐，工程师只能在本地运行部分待调试的组件，然后将剩余的组件放到公共测试环境上使用，组成完整的系统。

同时，团队规模的扩大使得每个团队成员的职责进一步细分，新的子团队不断产生，这意味着项目的沟通成本增加，公共测试环境的稳定性也变得难以掌控。在这个过程中，测试环境管理复杂性带来的影响不仅体现在服务联调的繁琐上，也直接体现在交付流程和资源成本的变化上。

在交付流程方面，一个显著的变化是测试环境种类的增多，工程师们针对不同的用途和目的设计了各种专用的测试环境，这些测试环境的组合形成了每个企业独有的交付流程，下图展示了一个大型项目的复杂交付流程。

从单体服务的角度看，环境之间通过流水线串联，通过自动化测试或者人工审批操作形成检查点，实现环境之间的流转。一般来说，级别越高的环境，部署频率越低，因此相对稳定性越高。相反，级别较低的环境，随时都有可能出现新的部署，这会扰乱正在使用该环境的其他人。有时候，为了复现某些特殊的问题场景，一些开发人员不得不直接登录服务器“捣乱”，进一步影响环境的稳定性和可用性。

面对随时可能崩溃的测试环境，小型企业会想方设法“堵”它：约束服务变更时间、设定严格的变更规范，而大型企业则善于“松”它：增加测试环境副本、隔离故障影响范围。显然，对超负荷的测试环境“堵”得越多，它就越“漏洞百出”。千百年前大禹治水的故事早已揭示出一个道理：刻意的控制无法挽救脆弱的测试环境。

近年来，文化的兴起让开发人员从端到端解放了双手，但这对测试环境的管理而言却是一把双刃剑。一方面，鼓励开发人员参与运维，了解产品的完整生命周期，有助于减少不必要的低级运维事故；另一方面，更多的手伸向测试环境，更多的变化，更多的出场。这些做法从全局来看利大于弊，但却无法缓解测试环境的动荡，简单的流程疏通也无法挽救脆弱的测试环境。

然后就是投入了，不同团队使用的底层测试环境是独立的，这时候每个团队看到的都是一个线性的流水线，从整体来看，会呈现出河流汇聚的形状。

理想情况下，每个开发人员都应该拥有一个独享的、稳定的测试环境，不受干扰地完成自己的工作。然而，由于成本因素，现实中，一个团队内部能够共享的测试资源非常有限，测试环境不同成员之间的干扰成为影响软件开发质量的隐患。增加测试环境副本数，本质上是一种以增加成本换取效率的做法。然而，许多试图寻找成本与效率最优平衡点的探索者，似乎在同一条不归路上越走越远。

由于客观的规模和体量，阿里巴巴的产品团队也难免会遇到管理上述测试环境的麻烦。

第一是测试环境类型的管理

阿里巴巴的测试环境也是种类繁多，各类测试环境的命名都和其功能息息相关，虽然业界有一些常用的名称，但是并没有一个权威的标准，其实环境的命名只是一种形式，关键是各类测试环境要适应具体的应用场景，场景之间要有一定的区别。

这些差异有些在于运行的服务类型，比如性能测试环境可能只需要运行压力测试相关的访问量最大的关键业务服务，运行其他服务会浪费资源；有些差异在于访问数据的来源，比如开发自测环境的数据源肯定和正式环境不一样，这样测试时使用的假数据才不会污染线上用户的请求；预发布环境（或用户验收测试环境）会使用和正式环境相同的数据源（或者是正式数据源的副本），以反映新功能对真实数据的操作；与自动化测试相关的环境会有一套单独的测试数据库，避免测试运行过程中受到其他人为操作的干扰。

有些区别还在于使用者的不同，比如灰度环境和预发布环境都使用官方数据源，但是灰度环境的使用者是少数真实的外部用户，而预发布环境的使用者都是内部人员。总之，没必要为了没有业务特异性的测试场景特意发明一个测试环境。

在集团层面，阿里巴巴对于流水线形态的约束相对宽松，客观来说，只有一线的开发团队才知道最适合自己团队的交付流程应该是什么样的。阿里巴巴的开发平台只是标准化了一些推荐的流水线模板，开发者在此基础上进行开发即可。下面列举几个典型的模板示例：

其中有几个外界不太常用的环境类型名，后面会详细介绍。

第二是测试环境成本的管理

成本管理问题非常棘手，值得探讨。与测试环境相关的成本主要包括管理环境所需的“人工成本”和购买基础设施所需的“资产成本”。通过自动化和自助服务工具，可以有效降低与人工相关的成本。自动化是一个很大的话题，应该在另一篇文章中讨论。我暂时就到此为止。

资产采购成本的降低依赖于技术的完善和进步（不包括大规模采购带来的价格变化），而基础设施技术的发展史包括硬件和软件两大领域。硬件发展带来的成本大幅降低，通常来自于新材料、新生产工艺、新的硬件设计思路；软件发展带来的基础设施成本大幅降低，目前来看，大多来自于虚拟化（即资源隔离与复用）技术的突破。

最早的虚拟化技术是虚拟机，早在上世纪 50 年代，IBM 就开始使用这种硬件级的虚拟化方式，实现了资源利用率的指数级提升。虚拟机上不同的隔离环境各自运行一个完整的操作系统，隔离性好，通用性强，但对于运行业务服务来说略显繁琐。2000 年以后，KVM、XEN 等开源项目让硬件级虚拟化得到广泛普及。

与此同时，另一种更轻量的虚拟化技术也出现了，以LXC为代表的早期容器技术，它基于操作系统内核实现了运行环境的虚拟化，减少了独立操作系统的资源消耗，以一定的隔离性为代价，实现了更高的资源利用率。

后来镜像封装、单进程容器等概念的诞生，将这项内核级虚拟化技术推向了百万人追捧的境界。阿里紧跟技术进步的步伐，很早就用上了虚拟机和容器。2017年双十一，在线业务服务的容器化率已经达到100%。但接下来的挑战是，基础设施资源的利用率能不能再高一些？

通过消除虚拟机的硬件指令转换和操作系统开销，容器中运行的程序与普通程序之间只有一层薄薄的内核隔离，运行时性能完全没有损耗。虚拟化似乎在这个方向上已经走到了极限。唯一的可能就是抛开通用场景，聚焦测试环境管理这个具体场景，继续寻找突破口。最终，阿里巴巴在这个领域发现了新的宝藏：服务级虚拟化。

所谓服务级虚拟化，本质上是基于消息路由的控制，实现集群中部分服务的复用。在服务级虚拟化模式下，很多看似庞大的独立测试环境其实只需要消耗非常小的额外基础设施资源，即使每个开发者都配备专用的测试环境集群，也不再是吹牛。

具体来说，阿里巴巴的交付流程中包含了两类特殊的测试环境：“公共基础环境”和“特性环境”，形成了阿里巴巴独有的测试环境使用方式。公共基础环境是全套的服务运行环境，通常运行一个比较稳定的服务版本。有些团队会一直把各个服务的最新版本部署在一个低级环境（称为“日常环境”）中作为公共基础环境。

这个方法最有意思的地方，就是特性环境，特性环境是一个虚拟环境。表面上看，每一个特性环境都是一个独立完整的测试环境，由一系列的服务组成。实际上，除了当前用户想要测试的服务外，其余的服务都通过路由系统和消息中间件虚拟出来，指向公共基础环境的对应服务。在阿里巴巴平时的开发流程中，开发任务需要经过特性分支、发布分支等诸多相关环节，才能发布上线。大部分环境都是从发布分支部署而来，但这个给开发者使用的虚拟环境是从代码特性分支的版本部署而来，因此可以称之为“特性环境”（阿里巴巴内部叫“项目环境”）。

例如一个交易系统的完整部署需要由认证服务、交易服务、订单服务、结算服务等十几个小系统以及对应的数据库、缓存池、消息中间件等组成，那么它的公共基础环境就是这样一个包含所有服务及周边组件的完整环境。假设此时有两个特性环境在运行，一个只启动了交易服务，另一个启动了交易服务、订单服务、结算服务。对于第一个特性环境的用户来说，虽然除了交易服务之外的所有服务其实都是由公共基础环境代理的，但是在使用的时候，就像是拥有了一个属于自己的完整环境：可以随意在环境中部署、更新交易服务的版本，并且进行调试，不用担心影响其他用户。对于第二个特性环境的用户来说，可以对环境中部署的三个服务进行联调验证。如果场景中使用了认证服务，那么公共基础环境的认证服务会做出响应。

乍一看，这不就是动态修改域名对应的路由地址，或者消息主题对应的投递地址吗？其实没有那么简单，因为公共基础环境的路由是无法针对某一特性环境进行修改的，所以单靠正统的路由机制只能实现单向的目标管控，即特性环境中的服务主动发起调用时才能够正确路由。如果请求的发起方在公共基础环境，根本无法知道该将请求发往哪个特性环境。对于 HTTP 类型的请求，甚至很难处理回调，当公共基础环境中的服务进行回调时，域名解析会将目标指向公共基础环境中的同名服务。

如何才能实现正确的双向数据路由和传递？我们回到这个问题的本质：请求应该进入哪个特性环境，是和请求的发起者相关的。因此，实现双向绑定的关键是识别请求发起者所在的特性环境，并进行端到端的路由控制。这个过程和“灰度发布”很相似，可以用类似的思路来解决。

得益于阿里巴巴在中间件领域的技术积累，以及鹰眼等路由追踪工具的广泛使用，识别请求的发起者并追溯回调链路并不是什么难事。如此一来，路由管控也就水到渠成了。用户在使用特性环境时，需要“加入”该环境，此操作会将用户标识（如 IP 地址或用户 ID）与指定的特性环境进行关联，每个用户同一时间只能属于一个特性环境。当数据请求经过路由中间件（消息队列、消息网关、HTTP 网关等）时，一旦识别出请求的发起者当前处于特性环境中，就会尝试将请求路由到该环境中的服务，如果该环境中没有与目标一致的服务，则会路由或投递到公共基础环境。

特性环境并不是孤立存在的，它可以构建在容器技术之上，从而获得更大的灵活性。正如在虚拟机上构建容器提供了基础设施获取的便利一样，在特性环境中，通过容器实现服务的快速动态部署，意味着用户可以随时将一个需要修改或调试的服务添加到特性环境中，也可以随时销毁环境中的某个服务并让公共基础环境自动接管。

另一个问题是服务集群调试

采用特性分支工作模式后，如果将若干服务的不同特性分支部署到同一份特性环境中，就可以实时调试多个特性，从而可以使用特性环境进行集成测试。不过，即使搭建特性环境的成本很低，毕竟服务是部署在测试集群上的。这意味着每次修改代码都需要等待流水线构建完成再部署，节省了空间开销却没有减少时间开销。

为了进一步降低成本、提高效率，阿里团队想出了一个创造性的玩法：将本地开发机器加入到特性环境中。在集团内部，由于开发机器和测试环境都使用内网 IP 地址，因此，只需稍微变通一下，就不难将特定的测试环境请求直接路由到开发机器上。这意味着，即使特性环境中的用户访问某个服务其实来自公共基础环境，但后续处理环节中有一部分服务也可以来自特性环境，甚至来自本地环境。现在，在集群中调试服务变得非常简单，不需要等待漫长的流水线搭建，就像整个测试环境都在本地运行一样。

DIY体验特色环境

你是否觉得服务级虚拟化太小众，离普通开发者太远？其实不然，你可以自己动手做一个试用版的功能环境来玩一玩。

阿里巴巴的特性环境针对各种常见的服务通信方式，包括 HTTP 调用、RPC 调用、消息队列、消息通知等，实现了双向路由的服务级虚拟化。要完成这么一个功能齐全的测试环境，难度有点大。从通用性的角度，我们不妨先从最合大众口味的 HTTP 协议入手，做一个支持单向路由的简易版本。

为了方便管理环境，最好有一个可以运行容器的集群。在开源社区中，功能齐全的集群是不错的选择。 中有一些与路由控制相关的概念，以资源对象的形式呈现给用户。

简单介绍一下，对象可以隔离服务的路由域（和用于容器隔离的内核不一样，不要混淆），对象用于指定服务的路由目标和名称，对象对应真实部署的服务。 类型的对象（和 和 类型，先忽略）可以路由到同一环境中的真实服务， 类型的对象可以作为当前路由代理中的外部服务。这些资源对象的管理可以使用 YAML 格式的文件来描述。大致了解这些之后，就可以开始动手了。

搭建基础设施和集群的过程就不说了，我们直接进入正题。首先我们需要准备一个公共基础环境，并以路由作为备份。这是一个全测试环境，包括被测系统中的所有服务和其他基础设施。暂时不考虑对外的访问，公共基础环境中所有服务对应的对象都可以使用类型，假设它们对应的名称为pub-base-env。这样，这个环境中的每个服务都会自动分配一个可用域名“服务名.svc.”和一个集群全局域名“服务名.pub-base-env.svc.”。有了备份的保障，就可以开始创建特性环境了。最简单的特性环境可以只包含一个真实服务（比如trade-），其他服务都以类型为对象代理到公共基础环境上。假设它使用名称-env-1，它的描述YAML如下（省略非关键字段信息）：

kind: Namespace

metadata:

  name: feature-env-1

---

kind: Service

metadata:

  name: trade-service

  namespace: feature-env-1

spec:

  type: ClusterIP

  ...

---

kind: Deployment

metadata:

  name: trade-service

  namespace: feature-env-1

spec:

  ...

---

kind: Service

metadata:

  name: order-service

  namespace: feature-env-1

spec:

  type: ExternalName

  externalName: order-service.pub-base-env.svc.cluster

  ...

---

kind: Service

...

注意 order- 服务，在当前特性环境中，可以使用本地域名 order-.svc. 来访问。请求会被路由到为其配置的全局域名 order-.pub-base-env.svc.，即公共基础环境中的同名服务。环境中的其他服务无法感知到这个差异，但会认为所有相关服务都部署在这个环境中。

如果开发人员在功能开发过程中修改了 order-，则需要将修改后的服务版本添加到环境中，只需修改 order- 的对象属性（使用 patch 操作），将其改为 type，并在当前环境中创建一个对象与之关联即可。

由于修改的对象只对对应（即对应的特性环境）中的服务有效，无法影响来自公共基础环境的回调请求，因此路由是单向的。此时特性环境必须包含待测试调用链路的入口服务和包含回调操作的服务。例如待测试特性由界面操作发起，则提供用户界面的服务即为入口服务。即使服务没有修改，也应该在特性环境中部署其主线版本。

这种机制可以很方便的用本地服务替换集群服务进行调试开发。如果集群和本地主机都在内网，可以将对象类型指向本地的 IP 地址和服务端口。否则，需要为本地服务添加公网路由，可以通过动态域名解析来实现。

与此同时，云效也在逐步完善基于的特色环境解决方案，并将提供更加完善的路由隔离支持。值得一提的是，由于公有云的特殊性，在联调时将本地主机加入到云集群中是一个必须要攻克的难题。为此，云效通过隧道网络+kube-proxy自身的路由能力，实现了将本地局域网主机（无需公网IP地址）加入到不在同一内网的集群中进行联调的方法。技术细节也将在近期的云效公众号中为大家揭晓，敬请期待。

概括

当很多人还在等待虚拟机、容器之后的下一波虚拟化技术浪潮时，阿里巴巴已经给出了答案。创业心态教会了阿里巴巴人要尽可能的节约。其实，限制创新的往往不是技术，而是想象力。服务级虚拟化的概念突破了人们对环境副本的传统认知，以独特的视角化解了测试环境成本与稳定性之间的矛盾。

特性环境作为一个特色化的技术载体，其价值不仅在于轻量级的测试环境管理体验，更在于给每一位开发者带来顺畅的工作方式，实则“简约而不简单”。

活动推荐

基于机器学习的时序数据智能诊断预测、超大规模日志实时智能聚类、二次开发。作为阿里巴巴集团底层日志平台，阿里云10PB+/天的日志系统是如何运转的？

2019深圳全球架构师峰会特别邀请了阿里巴巴高级技术专家孙廷涛，与大家分享阿里巴巴如何实现百万级客户端的管理、监控和自助问题定位，以及秒级流控、自动负载均衡、动态资源分配等难题的解决方案。