云上业务测试环境治理一种方式

最近分配到新的业务工作，熟悉业务研发流程后，发现这边业务的一种测试环境治理方式挺好的，这里简单记录一下，阅读可能需要对kubernetes有一定的了解。

一、背景

目前维护一些前端的项目，业务部署在kubernetes上的Deployment workload，经常会有一些小bug需要处理，或者进行一些小迭代。业务的用户量比较大，希望测试和发布的时候，不要影响到外网功能的使用，而且尽可能方便。

二、测试环境

日常对业务进行改动，可以通过CI生成新的docker镜像。然后自动部署到测试的kubernetes workload上，然后得到一个测试环境的ip地址。CI生成的js, css, 图片等静态资源我们都加上MD5路径后直接发外网，只需要把测试的页面html地址，代理到测试ip就可以正常访问到测试环境。

在本地网络环境和测试ip连通的情况下，可以简单通过whistle配置代理，把请求直接转发到测试ip上面去，然后进行开发和测试，这其实已经可以满足开发人员的开发和调试需求。

但是现实中测试其实还是存在不少问题，例如:

1. 现在有很多公司测试都是外包的，外包测试人员的工作环境网络，不一定和测试环境ip是连通的。

2. 很多测试人员不太熟悉代理配置，容易出错和加大沟通成本。

三、业务网络链路改造

通常业务的网络链路大概是这样的

通常业务网络流量拓扑

如上图，用户请求到达接入层网关后，网关通过服务发现，获取业务集群的服务地址，然后把请求转发到业务集群。这样的架构比较简单稳定，但是有流量转发需求的时候，不太好操作。现在对网络链路进行一定的修改。

改进后的网络拓扑

这里做了如下的一些修改

1. 新增一个nginx集群前置在业务服务集群前面

2. 新增一个nohost服务，用于承接nginx集群转发的需要测试的请求

3. nginx集群通过读取kubernets的configMap配置，匹配请求用户的id，决定是否要把用户的请求转发到nohost集群

4. nohost集群可以支持把不同用户的请求配置到不同的测试环境地址。(关于nohost可以看看这里,是whistle的作品)

这里需要对nginx做一些扩展，让nginx定时的去读取configMap的配置，可以通过lua脚本可以比较简单的实现。关于性能相关问题，添加一层nginx, 实际造成的耗时损耗比较可控，大部分可能耗时增加不超过30ms。

四、便利优化

通过上面的链路修改，我们已经可以通过改configMap配置，让处于各种网络环境下的测试和产品人员访问到新特性测试环境了。但是还是不够便利，存在以下问题

1. 配置了测试环境不清除，可能会导致别人误以为是bug

2. 每次都得打开网页去改配置，不够便利

这里提供一些思路，我们可以利用一些CI的定时任务，每天零点的时候清空configMap配置。可以通过配置一些企业微信或者钉钉的机器人，通过机器人指令触发CI修改configMap