当前位置: 首页 > 科技观察

转转测试环境治理的高效实践

时间:2023-03-20 22:29:28 科技观察

转转测试环境治理经历了三轮迭代,大大降低了环境建设的耗时和资源占用,积累了丰富的实践经验过程。本文将从测试环境的需求和背景出发,介绍转转各版本测试环境治理的原理、技术、优缺点,并毫无保留地与读者分享转转的实战经验。1背景及需求1.1系统架构的发展很久以前,在并发度不高的时候,系统多采用单体架构。单个web服务直接连接数据库,nginx在多个web服务节点之间做负载均衡。单体架构随着系统并发量的增加,单体架构无法满足性能需求,需要对单体服务进行拆分,于是我们来到了微服务架构。微服务架构与单体架构的显着区别在于链路更长、更复杂。微服务架构1.2测试环境要求测试环境与线上环境的典型区别在于,线上环境中各个节点的代码一般是一致的,各个节点是平等的,任何一个节点的业务逻辑在运行时都是一致的。请求到达;测试环境一般是多分支并行开发,各个节点逻辑不一致。由于本次开发的功能是要测试的,所以要求请求能够准确到达部署的节点。在单体架构下,这个需求很容易实现。通过修改nginx的配置,在上游只包含目标测试节点,很容易实现目标节点的精准测试,或者不使用nginx直接通过IP+端口的形式调用也可以实现精准到达对目标节点的请求。如下图A'和A''属于两种不同的需求,通过分别固定nginxupstream和IP+port来实现对请求的精准控制。单体架构测试在微服务架构下,这个需求的实现就没那么简单了。如下图所示,该链路包括服务A、B、C,图中A'、B'、C'属于同一个需求,而A''、B''、C''属于另一个需求。单体架构下采用的方案只能控制请求准确到达A'或A'',无法实现请求准确到达B'、C'和B''、C''。微服务架构测试2.传统测试环境方案——物理隔离为了实现请求精准到达被测服务节点,传统的做法是提供多套相互完全隔离的测试环境,每套测试环境包括全方位的服务和注册中心、MQbroker等,每个需求都分配一个测试环境,只需要将被测服务部署在这个环境中,即可实现请求到节点的精准到达正在测试中。这种方法也称为物理隔离。物理隔离物理隔离在公司服务数量不多(20个以下)的情况下是一个完美的解决方案,非常简单可靠。但是,随着服务数量的增长,物理隔离的弊端逐渐显现——资源浪费太严重。假设整个系统有100个服务,每个需求只修改其中的1-3个,资源浪费率高达97%-99%。而且,服务数量的增加往往意味着公司的业务在增长,持续需求的数量也在增加。需要提供更多的测试环境,消耗大量资源。3、转转测试环境V1-改进的物理隔离转转传统的测试环境方案属于改进的物理隔离。3.1稳定的环境赞转拥有稳定的环境,包括全方位的服务,与线上代码一致。在测试环境中,没有使用注册中心,而是为每个服务分配一个唯一的域名,通过修改机器主机映射手动控制服务发现。默认情况下,如果稳定环境下服务A部署在192.168.1.1,所有测试环境机器的host文件中都有一个配置192.168.1.1A.zhuaninc.com。3.2动态环境每次请求申请的环境称为动态环境,是一个kvm虚拟机。假设一个动态环境的IP是192.168.2.1,在这个动态环境下部署服务A时,同时在机器的host文件中添加192.168.1.1A.zhuaninc.com(假设环境稳定服务A的IP为192.68.1.1)映射,修改为127.0.0.1A.zhuaninc.com。下图所示的动态环境192.168.4.1,其中A'和E'是这个需求修改的服务。初始化过程如下:申请一个动态环境192.168.4.1,申请完成后,本机host文件包含全量服务域名映射,被映射默认为对应稳定环境的IP。本例中,只有F服务的域名映射为192.168.5.1F.zhuaninc.com(假设服务F在稳定环境下的IP为192.168.5.1)。部署服务E',同时将127.0.0.1写入主机文件。部署服务D,同时将127.0.0.1写入host文件。部署服务C,同时将127.0.0.1写入host文件。部署服务B,同时将127.0.0.1写入host文件。部署服务A',同时将127.0.0.1写入主机文件。部署条目。部署nginx,修改服务A的上游只包含127.0.0.1。这样,就像焊接管道一样,从服务E到nginx,按照倒序焊接一条没有分叉的管道。测试时,只需要将被测域名通过主机映射映射到IP,即可使请求准确到达A'和E',E'之后的链接(F开头的链接)使用稳定的环境。对于MQ来说,与稳定环境的物理隔离是通过给动态环境中的topic加上IP前缀来实现的。如下图所示,不同的topic在broker上有不同的queue,稳定环境的消息不能和动态环境的消息互通。MQ消息的物理隔离。如果在测试过程中发现需要修改更多的服务,比如需要修改服务F,那么在动态环境部署服务F的同时需要重启服务E',因为E'已经兼容了稳定的环境。F已经建立了tcp连接,修改F的服务的域名映射不会导致E'和F重新建立tcp连接,所以需要重启E'。如果F服务的调用者不只是E',则需要重启。3.3优缺点该方案与物理隔离类似,但相比物理隔离有所改进。改进是动态环境不包含全量服务。动态环境只包括从nginx开始到最后一个测试的服务,而使用稳定环境作为被测链接的尾部。3.3.1优点隔离性强,类似于物理隔离。链接简单,流量在同一台机器上关闭。3.3.2缺点需要把服务从nginx部署到最后一个要测试的。存在将未修改的服务部署在动态环境中,导致资源浪费的情况。由于部署过程依赖于服务的调用关系,部署效率低。在极端情况下,调试测试环境需要几天时间。主机管理复杂。给topic加IP前缀容易出错,而且代码跟环境有关。单机内存有限,链接太长无法满足。4、转转测试环境V2-基于自动IP标签的流量路由随着转转业务的快速发展,服务数量迅速增加,每个动态环境部署的服务数量增加到30-60个。搭建测试环境的成本越来越高。为了解决这个问题,转转架构部、运维部、工程效率部推出了流量路由解决方案。该方案在之前的公众号文章赞转测试环境服务治理实践中已有详细讲解,本文仅做简单介绍。这种流量路由技术称为基于自动IP标签的流量路由。之所以选择IP作为标签,是因为根据现有的使用习惯,发现所有测试的服务都部署在同一个虚拟机上,IP地址相同,IP容易获取,用户无感知;“自动”是指不需要用户标记服务和流量,标记是完全自动化的。基于自动IP标签的流量路由,将测试环境搭建时间从小时-天缩短到30分钟-1小时,每个环境部署的服务数量从30-60个服务下降到个位数,完全兼容无流量路由使用习惯。但是仍然存在申请虚拟机耗时较长,无法扩展kvm内存等问题。5.转转测试环境V3-trafficroutingbasedonmanuallabels基于自动IP标签的流量路由解决了转转测试环境中的大部分问题,将测试环境搭建时间从几小时到几天缩短到30分钟-1小时,但是还存在应用环境耗时长,kvm内存无法扩展等问题。本着精益求精、用户至上的原则,我们开发了基于人工标签的流量路由。