testing是什么意思啊,testing是什么平台

2022-07-26 15:37:30 热点扫描

　　作者简介：林凡(花名金鸡)，阿里巴巴研发中心技术专家；效率部。　　

　　相关：在阿里我们如何管理代码分支？　　

前言

　　阿里的很多做法看似简单，背后却有很多思考，比如测试环境的管理。　　

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

　　除此之外，还有很多不对外开放的运行环境，用于产品团队的日常开发和验证，统称为测试环境。正式环境的稳定性，除了软件本身的质量因素外，主要与运行的主机、网络等基础设施有关，而测试环境的稳定性更多的是受到人为因素的影响。由于频繁的版本变更和未验证代码的部署，测试环境失败并不罕见。　　

　　良好的代码提交习惯和适当的变更前检查有助于减少故障的发生，但不能完全消除后患。添加多套测试环境副本可以有效控制故障范围。但是企业的资源是有限的，所以降低测试环境的成本和提高测试环境的稳定性就成了矛盾的两面。　　

　　在这一领域，别出心裁的阿里研发；D efficiency团队设计了一种服务级复用的虚拟化技术，叫做“特色环境”，其巧妙的思路令人惊叹。本文将围绕测试环境管理这个话题，谈谈这种具有Ali特色的工作方式。　　

测试环境管理的困局

　　测试环境应用广泛。常见的测试环境，如系统集成测试环境、用户验收测试环境、预发布测试环境、灰度测试环境等。反映产品交付生命周期，间接反映整个团队的组织结构。　　

　　小作坊产品团队的测试环境管理起来非常简单。每个工程师都可以启动一套完整的软件组件进行本地调试。如果你不放心，一个公共的集成测试环境就足够了。　　

　　随着产品规模的扩大，在本地启动所有服务组件既费时又费力。工程师只能在本地运行一些要调试的组件，然后在公共测试环境中使用其余的组件，形成一个完整的系统。　　

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

　　就交付过程而言，一个显著的变化是测试环境的多样性。为了不同的目的，工程师们设计了各种特殊的测试环境。这些测试环境的组合形成了每个企业独特的交付过程。下图显示了大型项目的复杂交付过程。　　

　　从单个服务的角度来看，环境与环境之间是通过流水线连接的，自动测试或人工审批操作形成一个检查点，实现环境之间的传递。一般环境等级越高，部署频率越低，所以相对稳定性越高。相反，在较低级别的环境中，随时可能有新的部署，这会干扰正在使用该环境的其他人。有时候，为了重现一些特殊的问题场景，一些开发人员不得不直接登录服务器“办事”，进一步影响了环境的稳定性和可用性。　　

　　面对随时可能崩溃的测试环境，小企业会想办法“封杀”它：限制服务变更时间，设置严格的变更规范，而大企业则善于“疏”它：增加测试环境的副本，隔离故障的范围。显然，负担过重的测试环境必须被更多地“堵塞”和“泄漏”。一千年前大禹治水的故事已经揭示了真相，刻意的控制拯救不了脆弱的试验环境。　　

　　近年来DevOps文化的兴起，端到端的解放了开发者的双手，对于测试环境的管理是一把双刃剑。一方面，DevOps鼓励开发者参与运维，了解产品的完整生命周期，帮助减少不必要的低级运维事故；另一方面，DevOps让更多的手伸向测试环境，更多的改动和热修复出现。这些做法都是利大于弊的，但都无法缓解测试环境的动荡。简单的工艺疏通也拯救不了脆弱的试验环境。　　

　　那么该投资的就得投资。不同团队使用的底层测试环境是相互独立的。此时，每个团队看到的是一条线性装配线。整体上呈现河流汇聚的形态。　　

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

　　由于客观的规模和体量，阿里的产品团队也无法幸免于这些测试环境管理的烦恼。　　

　　首先是测试环境种类的管理。 　　

　　在阿里内部，也有丰富的测试环境区分。各种测试环境及其工作的命名　　

用息息相关，虽然业界有些常用的名称，但都未形成权威的标准。实际上，环境的名称只是一种形式，关键还在于各种测试环境应当分别适配于特定应用场景，且场景之间应当或多或少存在一些差异。

这种差异有些在于运行的服务种类，譬如性能测试环境很可能只需要运行与压力测试相关的那部分访问量最大的关键业务服务，其他服务运行了也是浪费资源。有些差异在于接入数据的来源，譬如开发自测的环境的数据源与正式环境肯定不一样，这样测试使用的假数据就不会污染线上用户的请求；预发布环境（或用户验收测试环境）会用与正式环境一致的数据源（或正式数据源的拷贝），以便反映新功能在真实数据上运行的情况；自动化测试相关的环境会有单独的一套测试数据库，以避测试运行过程中受到其他人为操作的干扰。

还有些差异在于使用者的不同，譬如灰度和预发布环境都使用正式的数据源，但灰度环境的使用者是一小撮真实的外部用户，而预发布环境的使用者都是内部人员。总之，没必要为一个不存在业务特殊性的测试场景专门发明一种测试环境。

在集团层面，阿里对流水线形式的约束相对宽松。客观的讲，只有在一线的开发团队知道最适合团队的交付流程应该是什么样子。阿里的开发平台只是规范了一些推荐的流水线模板，开发者可在此基础上进行发挥。列举几个典型的模板例子：

这里出现了几种外界不太常见的环境类型名称，稍后会详细介绍。

其次是测试环境成本的管理。

成本管理的问题十分棘手且十分值得深究。与测试环境相关的成本主要包括管理环境所需的“人工成本”和购买基础设施所需的“资产成本”。通过自动化以及自服务化的工具可以有效降低人工相关的成本，自动化又是个很大的话题，宜另起一篇文章讨论，此处暂且收住。

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

最早的虚拟化技术是虚拟机，早在20世纪50年代，IBM就开始利用这种硬件级的虚拟化方法获得成倍的资源利用率提升。虚拟机上的不同隔离环境之间各自运行完整操作系统，具有很好的隔离性，通用性强，但对于运行业务服务的场景，显得略为笨重。2000年后，KVM、XEN等开源项目使得硬件级虚拟化广泛普及。

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

之后诞生的Docker以其镜像封装和单进程容器的理念，将这种内核级虚拟化技术推上百万人追捧的高度。阿里紧随技术前进的步伐，早早的就用上了虚拟机和容器，在2017年双十一时，在线业务服务的容器化比例已经达到100%。然而，接下来的挑战是，基础设施资源利用率还能做得更高吗？

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

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

具体来说，在阿里的交付流程上，包含两种特殊类型的测试环境：“公共基础环境”和“特性环境”，它们形成了具有阿里特色的测试环境使用方法。公共基础环境是一个全套的服务运行环境，它通常运行一个相对稳定的服务版本，也有些团队将始终部署各服务的最新版本的低级别环境（称为“日常环境”）作为公共基础环境。

特性环境是这套方法中最有意思的地方，它是虚拟的环境。从表面上看，每个特性环境都是一套独立完整的测试环境，由一系列服务组成集群，而实际上，除了个别当前使用者想要测试的服务，其余服务都是通过路由系统和消息中间件虚拟出来的，指向公共基础环境的相应服务。由于在阿里通常的开发流程中，开发任务需要经过特性分支、发布分支和诸多相关环节最后发布上线，大多数环境都从发布分支部署，唯独这种开发者自用的虚拟环境部署来自代码特性分支的版本，故可称为“特性环境”（阿里内部叫“项目环境”）。

举个具体例子，某交易系统的完整部署需要由鉴权服务、交易服务、订单服务、结算服务等十几种小系统以及相应的数据库、缓存池、消息中间件等组成，那么它的公共基础环境就是这样一套具备所有服务和周边组件的完整环境。假设此时有两套特性环境在运行，一套只启动了交易服务，另一套启动了交易服务、订单服务和结算服务。对于第一套特性环境的使用者而言，虽然除交易服务外的所有服务实际上都由公共基础环境代理，但在使用时就像是自己独占一整套完整环境：可以随意部署和更新环境中交易服务的版本，并对它进行调试，不用担心会影响其他用户。对于第二套特性环境的使用者，则可以对部署在该环境中的三个服务进行联调和验证，倘若在场景中使用到了鉴权服务，则由公共基础环境的鉴权服务来响应。

咋看起来，这不就是动态修改域名对应的路由地址、或者消息主题对应的投递地址么？实事并没那么简单，因为不能为了某个特性环境而修改公共基础环境的路由，所以单靠正统路由机制只能实现单向目标控制，即特性环境里的服务主动发起调用能够正确路由，若请求的发起方在公共基础环境上，就无法知道该将请求发给哪个特性环境了。对于HTTP类型的请求甚至很难处理回调的情况，当处于公共基础环境的服务进行回调时，域名解析会将目标指向公共基础环境上的同名服务。

如何才能实现数据双向的正确路由和投递呢？不妨先回到这个问题的本质上来：请求应该进入哪个特性环境，是与请求的发起人相关的。因此实现双向绑定的关键在于，识别请求发起人所处的特性环境和进行端到端的路由控制。这个过程与“灰度发布”很有几分相似，可采用类似的思路解决。

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

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

还有一个问题是服务集群调试。

配合AoneFlow的特性分支工作方式，倘若将几个服务的不同特性分支部署到同一个特性环境，就可以进行多特性的即时联调，从而将特性环境用于集成测试。不过，即使特性环境的创建成本很低，毕竟服务是部署在测试集群上的。这意味着每次修改代码都需要等待流水线的构建和部署，节约了空间开销，却没有缩短时间开销。

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

DIY体验特性环境

觉得服务级虚拟化太小众，离普通开发者很远？实事并非如此，我们现在就可以动手DIY个体验版的特性环境来玩。

阿里的特性环境实现了包括HTTP调用、RPC调用、消息队列、消息通知等各类常用服务通信方式的双向路由服务级虚拟化。要完成这样的功能齐全的测试环境有点费劲，从通用性角度考虑，咱不妨从最符合大众口味的HTTP协议开始，做个支持单向路由的简易款。

为了便于管理环境，最好得有一个能跑容器的集群，在开源社区里，功能齐全的Kubernetes是个不错的选择。在Kubernetes中有些与路由控制有关的概念，它们都以资源对象的形式展现给用户。

简单介绍一下，Namespace对象能隔离服务的路由域（与容器隔离使用的内核Namespace不是一个东西，勿混淆），Service对象用来指定服务的路由目标和名称，Deployment对象对应真实部署的服务。类型是ClusterIP（以及NodePort和LoadBalancer类型，暂且忽略它们）的Service对象可路由相同Namespace内的一个真实服务，类型是ExternalName的Service对象则可作为外部服务在当前Namespace的路由代理。这些资源对象的管理都可以使用YAML格式的文件来描述，大致了解完这些，就可以开始动工了。

基础设施和Kubernetes集群搭建的过程略过，下面直接进正题。先得准备路由兜底的公共基础环境，这是一个全量测试环境，包括被测系统里的所有服务和其他基础设施。暂不考虑对外访问，公共基础环境中的所有服务相应的Service对象都可以使用ClusterIP类型，假设它们对应的Namespace名称为pub-base-env。这样一来，Kubernetes会为此环境中的每个服务自动赋予Namespace内可用的域名“服务名.svc.cluster”和集群全局域名“服务名.pub-base-env.svc.cluster”。有了兜底的保障后，就可以开始创建特性环境了，最简单的特性环境可以只包含一个真实服务（例如trade-service），其余服务全部用ExternalName类型的Service对象代理到公共基础环境上。假设它使用名称为feature-env-1的Namespace，其描述的YAML如下（省略了非关键字段的信息）：

kind: Namespace

metadata:

kind: Service

metadata:

namespace: feature-env-1

spec:

type: ClusterIP

...

kind: Deployment

metadata:

namespace: feature-env-1

spec:

...

kind: Service

metadata:

namespace: feature-env-1

spec:

type: ExternalName

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

...

kind: Service

...

注意其中的order-service服务，它在当前特性环境Namespace中可以使用局部域名order-service.svc.cluster访问，请求会路由到它配置的全局域名order-service.pub-base-env.svc.cluster，即公共基础环境的同名服务上处理。处于该Namespace中的其它服务感知不到这个差异，而是会觉得这个Namespace中部署了所有相关的服务。

若在特性的开发过程中，开发者对order-service服务也进行了修改，此时应该将修改过的服务版本添加到环境里来。只需修改order-service的Service对象属性（使用Kubernetes的patch操作），将其改为ClusterIP类型，同时在当前Namespace中创建一个Deployment对象与之关联即可。

由于修改Service对象只对相应Namespace（即相应的特性环境）内的服务有效，无法影响从公共基础环境回调的请求，因此路由是单向的。在这种情况下，特性环境中必须包含待测调用链路的入口服务和包含回调操作的服务。例如待测的特性是由界面操作发起的，提供用户界面的服务就是入口服务。即使该服务没有修改，也应该在特性环境中部署它的主线版本。

通过这种机制也不难实现把集群服务局部替换成本地服务进行调试开发的功能，倘若集群和本地主机都在内网，将ExternalName类型的Service对象指向本地的IP地址和服务端口就可以了。否则需要为本地服务增加公网路由，通过动态域名解析来实现。

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