一人一套测试**

本篇开始讲第16次架构经历：一人一套测试**。同样，先介绍业务场景。

业务场景：测试**何时能释放出来使用

当时，**的基础设施使用的是虚拟机，而且还未迁移到容器。

**一共搭建了3套测试**。之所以是3套而不是只有1套，主要是考虑到多个项目同时进行时需要分开测试和分开上线，而3套测试**在一定程度上可以避免这些并行项目因为排队而导致延期的情况。

一般来说，研发流程是这样的：需求宣讲——>接口/方案设计——>功能开发——>联调——>测试——>预生产——>上线。

在这3套测试**中，一套专门用于联调，另外两套专门用于测试。

那么，一套联调测试**够用吗？答案是不太够，因为经常需要排期使用。那么两套测试**够用吗？也不够。这里讲一个具体的例子。

之前有一个项目已经进入测试环节，功能测试反馈没问题后等待第三方验收，可是第三方的验收拖了很久，以至于不得不继续占用测试**。

之后又有一个小的迭代项目要求一周后上线，并且还有一个上百人做的超大项目刚进入测试阶段，所以又需要两套测试**。此时测试**就不够用了，而且联调**都被征用了。

然后，业务方还提了一个加急需求要求当周上线，于是出现了下面这段对话。

甲：“我们有个紧急需求这周四要求上线，你们能不能把测试1让一

下？”

乙：“不行，我们这个功能需要测试一周，下周四就要上线了。如果让

给你们一天，我们就要延期一天上线了。”

甲：“其实是两天……”乙：“那更不行了。要不你问问XX，他们在做的项目周期长，应该能让

给你们两天。”

甲：“不行吧，那个项目号称**第一优先级，我开不了口啊！”

乙：“不然你们就用测试3？”

甲：“我哪敢啊，那个验收项目是领导亲自跟的。”

乙：“可是我们也不能延期啊，业务方都确认过很多次了，我们也跟合

作伙伴谈好了。”

“……”

最终就是因为抢测试**的问题，导致紧急需求上不了线，有苦也没地方说。

在实际工作中，一个组同时开展好几个项目的情况经常发生，尤其是业务对接方比较多的小组。为此，**决定着手解决这个问题。

解决思路

**希望达成的目标是可以快速搭建一套新的测试**，用完马上销毁。针对这个目标，解决思路如下。

1）利用容器的特性，在几秒内快速启动服务实例。

2）将测试**需要搭建的服务通过容器实例部署起来。

3）将这些容器通过Kubernetes管理（编排）起来。

那么，这一整套测试**都需要包含哪些服务器？

如图17-1所示，每套测试**中需要部署的组件有MQ、ZooKeeper、Redis、配置中心、数据库、API服务、后台服务、**等。

• 图17-1 测试**服务范围

决定使用容器灵活创建测试**后，项目组针对每一套容器**是包含全部组件还是部分特定组件调研了很久。

用过容器的开发人员都知道，在容器中部署MQ、ZooKeeper、Redis或配置中心是一件很简单的事情。比如使用容器部署Redis，只需要输入以下两行命令即可。

使用容器部署ZooKeeper、MQ的方法与之类似。不过这里有点不一样的是，**所有的中间件基本都不是纯净的开源版本。比如配置中心，**并没有使用Spring Cloud Config，也没有使用Nacos，而是使用了一个完全自研的产品（MQ和**都是自研的），它既不支持容器，也不支持单机版。而ZooKeeper、Redis是基于开源版本的，并在服务端加了一些封装。

此时，客户端强制使用一个自定义的客户端SDK，且使用的中间件必须强绑定配置中心。

之前评估过，如果把这些中间件部署到容器中，将会出现以下3种情况。

1）中间件服务端改造成本大。

2）客户端的SDK需要进行大量的改造。

3）最重要的一点是，会导致容器**与其他普通**存在很大的代码差异。因此，即使在容器中测试没问题，也需要在其他**中进行大量测试，此时容器测试**就没有什么意义了。为此，最终决定在容器测试**中只部署独立的API服务或后端服务，其他组件直接重用测试**的中间件，如图17-2所示。

• 图17-2 容器测试**示意图

基于以上设计方案，如果想快速部署一套独立的测试**，一般需要解决哪些问题？因为容器测试**复用了测试**的一些组件，所以需要解决以下5个问题。

API服务间的隔离

如何确保容器**的客户端请求能到达容器的API服务，而非仍然到达测试**的API服务？

当 时 的 系 统 是 这 么 设 计 的 ： 每 一 个 API 服 务 中 都 会 带 一 个 配 置 项channelID，然后客户端每次访问API时都需要加上一个channelID参数；**层接收到这个请求后，会根据channelID将请求匹配到对应channelID的API服务中（当然URL也需要匹配），此时整个隔离过程就比较简单了。

先介绍一下具体的研发流程：每个项目都有一个JIRA Issue，而XXX123就是一个JIRA Issue ID，项目组会为每个项目单独创建一套容器测试**，于是这个Issue ID自然而然地被当作了**标识。

再回到API的隔离。一般来说，客户端会把上面的channelID放在配置文件中，等到容器测试时再打一个包，此包中channelID的配置值为JIRA IssueID，也就是容器测试**的标识。最后，会在容器**打包API服务时，自动将channelID的配置值改为JIRA Issue ID。

具体的调用请求处理过程如图17-3所示。

• 图17-3 利用channelID导向不同容器**

在图17-3中，**层接收到所有请求后，会根据不同的channelID将请求分发到不同的API服务中。这样，API服务的隔离问题就解决了。

后台服务间的隔离

如何确保容器**部署的服务只调用容器服务，而测试**虚拟机的服务只调用虚拟机服务？

当时的系统是这样设计的：在打包RPC服务时，将一个**变量env的值设置为容器测试**的标识，也就是JIRA Issue ID，比如XXX123；然后每个RPC服务注册ZooKeeper时，将在Service的metadata中加一个tag参数，并设置tag的值为XXX123。之后，RPC服务只会调用同样tag的服务。这是什么意思？

比如测试**中有3个UserService，其中，一个是测试**的虚拟机，两个 是 容 器 测 试 环 境 部 署 的 UserService 。 前 者 的 tag 为 空 ， 后 两 个 容 器UserService 注 册 ZooKeeper 后 ， 它 们 的 tag 值 分 别 为 XXX123 和 XXX245 。

OrderService调用UserService时，如果OrderService也是XXX123这个容器**的服务，则它只会调用带XXX123这个tag值的UserService；如果它是正常虚拟机的服务，则只会调用不带tag值的UserService。

这样，后台RPC服务间的隔离问题就解决了。

以上要点中并没有提及ZooKeeper，因为API和RPC服务的隔离问题解决后，ZooKeeper的数据隔离问题基本也解决了。其实，ZooKeeper在每套测试**中起到的作用只是API服务和RPC服务的注册发现。

MQ和Redis隔离

如何确保容器**和虚拟机之间的MQ消息不互串、Redis数据不互相影响？

项目组本来想使用类似tag的概念来解决这个问题，通过封装MQ与Redis的客户端代码让它们只消费同样env值的服务生产的内容。

但是，还需要遵循以下原则：尽量**容器测试**与正式**的代码差异。针对这个问题，项目组讨论了很久，最终认为没必要专门定制，只需保证走测试流程时使用不同的测试数据就可以了（不同的项目一般都会使用不同的测试数据，包括不同的用户、不同的订单等），这样基本不会再出现不同容器测试**流转相同MQ消息、缓存数据的情况了。

当然，Redis中的一些通用数据还是会被共同使用，比如城市的基础数据。不过这些数据即使在不同容器测试**之间互相串联也没关系。

配置中心数据的隔离

对于配置中心是这样设计的：如果容器测试**的值与虚拟机测试**的值不一样，不会修改配置中心的值，而是在容器**的启动脚本中动态加上针对各自容器测试**的**变量，然后在业务代码中启动**变量优先级高于配置中心的参数，这样就确保了容器测试**的特殊配置，从而不影响配置中心的值。

数据库间的数据隔离

数据库互相影响的情况一般有两种。

1.测试数据互相影响

这一点其实和MQ、Redis的情况一样，只需要保证测试数据各自独立即可。

2.数据库结构兼容问题

比如同时进行两个项目，XXX123这个项目删除了user这张表的updateFlag字段，而XXX100这个项目还需要使用这个字段，此时如果两个项目共用一个数据库就会互相影响。

其实，这一点在第2章中介绍过：每次版本迭代时，都需要保证数据库可以兼容前一个版本的代码。比如刚刚那个例子，不能直接在XXX123中删掉updateFlag字段，而是等XXX100上线后再删掉。

关于数据库兼容前一个版本，再举一个例子。比如在XXX123这个项目中**了一个字段updateUserID，且该字段的值为必填，否则数据就会报错；而XXX100这个项目并不会更新updateUserID，这样如果XXX123读到了XXX100写入的数据就会报错。

这种情况该如何处理？此时可以在项目XXX123中**一些代码让它可以容错，即允许updateUserID为空。也可以将项目XXX123与项目XXX100部署到不同测试**的数据库中。

解决完上面这些问题后，基于现有测试**快速部署多套容器**的方案设计就基本完成了，接下来再简单介绍一下使用流程。

使用流程

使用流程是这样的，每次新建一个工程时（新的API或者后台服务）都会在Jenkins上配置一个Job，而这个Job需要接受以下3个参数。1）Branch，即需要部署的代码分支。

2）测试**test1/test2/test3（已经有3个测试**，它决定了部署需要使用哪个测试**的中间件）。

3）容器测试**标识，也就是JIRA Issue ID。

这 个 Job 启 动 时 ， 需 要 调 用 一 个 小 工 具 ， 而 这 个 小 工 具 需 要 连 接Kubernetes创建namespace（=JIRA Issue ID），然后在namespace中**一个pod（pod中运行的是专门为JIRA Issue ID打包的代码）。

在 做 某 个 项 目 时 ， 假 设 XXX123 需 要 使 用 UserAPI 、 UserService 、OrderService 、 ProductService ， 就 会 配 置 一 个 新 的 Jenkins Job 来 联 动UserAPI、UserService、OrderService、ProductService的Job，并且将各个服务对应的Branch、测试**和JIRA Issue ID传入Jenkins Job（这些值都通过硬编码配置在新的Jenkins Job中）。之后，每次点击这个项目的JenkinsJob时，就可以对其容器测试**进行部署了。

当然，如果项目成员想自己部署一套**，此时只需单独配置一个新的Jenkins Job，并找一个不一样的（比如开发任务的Issue ID）容器测试**标识即可。

通过这套方案可以实现图17-4所示的效果，项目基本不会再陷入因缺少测试**而延期的境地。

• 图17-4 每个需求独立的测试进程

一人一套测试**的方案成本其实非常小，因为代码改动很少，且一两周就可以把整个方案实施完成（时间主要用在申请服务器和部署Kubernetes上）。

此方案上线后，**了使用者的一致好评，尤其是测试人员，这里总结了3点原因。

1）再也不需要因为协调测试**花很多时间沟通了。

2）一键就可以将相关服务部署起来，不再需要一个服务一个服务地部署。

3）因为容器测试**的搭建很简单，开发人员每完成一个功能，测试人员即可介入测试，而不需要等整个项目提测后再介入，大大缩短了提测后的测试周期。

总体来说，这个项目的效果非常好，而且之后的容器测试**基本上**人均一套的使用状态。

小结

到这里，16次架构经历也就讲完了。接下来的结束语，不讲架构经历，将通过3次真实的经历向大家分享：如何成为不可或缺的人。

本文给大家讲解的内容是开发运维场景实战：一人一套测试**下篇文章给大家讲解的内容是开发运维场景实战：如何成为不可或缺的人？觉得文章不错的朋友可以转发此文关注小编；感谢大家的支持！！