转转测试环境的服务治理实践

Posted 2021-04-25 转转技术

点击蓝字

转

转

你还在为测试环境申请不到资源而发愁吗？

你还在为测试环境部署服务过多、时间过长而忧伤吗？？

你还在为测试环境的调用链路排查问题而焦虑吗？？？

他来了，他来了，他骑着小摩托迎风来了！

测试环境由于存在着并行开发，业务会同时部署测试多个分支的版本，而线上环境只有一套纯净的master版本，因此测试环境的服务治理难度要远远高于线上环境。传统的做法是为每套测试环境搭建一个封闭的生态，整个链路的调用都在这个闭环内，这种方式模型简单，排查问题也相对方便。但随着微服务规模的增大，这种方式会存在着部署效率低下、资源浪费严重等硬伤，如何能够既快好省的部署测试环境成为转转及止业内一个绕不开的痛点问题。

转转架构部为测试环境服务治理存在的这些问题提供了一整套的解决方案，它通过IP标签的流量路由，业务只须在动态测试环境（即个人申请的动态测试机）部署修改的服务集X，其他服务统一都走公共稳定环境。在整个请求链路中，所有涉及X的服务都会由框架自动路由到动态环境，而其他服务都走稳定环境。这样就实现了测试环境服务的最小化部署，并充分利用稳定环境的公共服务，简化了部署流程，极大节省了测试资源，同时节约了部署时间。

另外，为解决调用链路在动态环境、稳定环境来回穿插所带来的链路排查问题，我们又引进Zipkin并进行深度定制，开发出一套对业务透明的分布式调用链路跟踪系统--天网。天网对测试环境100%全量采样，这样我们就可以看到所有请求的完整调用链路，以便快速定位。

一

背景

在进行测试时，我们期望调用链路可以经过本次需求所修改的所有服务。转转早期的做法是，在测试时将测试链路上所有的服务都部署在同一台服务器上，形成单机闭环。其RPC和MQ路由原理为：

·RPC路由：通过hosts配置将各服务的dns解析到申请的动态测试机，从而保证这些服务调用都跳不出本机。当然也可以将一些服务的host指向稳定环境，但调用一旦跳出该单机闭环就收不回来了；

·MQ路由：通过为生产者和消费者的topic添加ip前缀，相当于不同的动态环境拥有自己独立的topic，从而保证生产者和消费者在动态测试机中形成闭环。

其调用流程如下：

动态环境A的hosts如下：

该图中一次调用涉及7个模块，entry、A、B、C、D、E、F。本次需求修改了B、E模块，但需要将entry、A、B’、C、D、E’部署在动态环境A上，通过hosts配置将A、B’、C、D的调用限定在本机，通过给MQ topic加IP前缀将D和E’的生产消费限定在本机，而F走稳定环境。如果F再有下游调用就出环收不回来了。

这种方式模型简单，排查问题也比较方便，适用于公司早期较小规模快速迭代。但随着转转的发展业务形态日趋复杂，多数情况下会部署数十个服务，这就存在着部署效率低下、资源浪费严重、hosts管理复杂、topic前缀替换易错等硬伤。如何能够既快好省的部署测试环境成为转转的痛点问题，对我们架构部也提出了新的挑战。

二

解决方案

通过IP标签的流量路由，我们只需在动态环境部署entry+X（entry表示涉及请求的接入层，由它作为调用链起始点；X表示我们修改的服务集）。整个请求链路中，所有涉及X的服务都会由框架自动路由到动态环境，而其他服务都走稳定环境。其调用流程示意图如下所示：

其调用流程为：

1. 动态环境自动部署nginx，upstream挂上Entry'，生成测试环境域名；

2. 用户通过域名设置将APP请求打到动态环境的Entry'；

3. Entry'收到请求后，将自身的IP（SRC_IP）设置到thread local里。在进行下游调用（SCF&MQ）时，如果发现下游模块有同机部署，则优先走同机部署的，否则走稳定环境。并将SRC_IP透传至下游模块；

4. 下游模块收到请求后，首先将SRC_IP设置到当前thread local里，在进行下游调用时，也优先走同机部署的下游模块；

5. 以此类推。

这样，我们只需在动态环境部署entry+B’+E’，调用链路中所有途经B’和E’的服务都走动态环境，其他走稳定环境，从而实现修改模块的最小化部署，既提高了部署效率，又节省了机器资源。

下面就流量路由中涉及的核心要点进行详细阐述。

2.1 如何区分动态环境和稳定环境？

我们将测试环境分为两种：动态环境（testserver）和稳定环境(teststable)，会在/opt/system.env中标记。动态环境表示业务测试时申请的测试机器，在上面部署业务修改的、要测试的服务集；稳定环境表示提供公共稳定服务的环境，其代码跟线上的保持一致，每次上线后部署平台会自动在稳定环境同步部署，有专门的部门在维护，业务线无权限操作。

2.2 SRC_IP如何透传？

·RPC：加入到RpcContext中；

· MQ：加入到Msg的Header中；

· 跨线程（池）：通过使用阿里开源的transmittable-thread-local组件。

2.3 RPC的流量路由

我们弃用了hosts模式，启用服务管理平台用于全体服务发现，服务上下线时会自动加入默认分组。在下游调用时，RPC框架的负载均衡器会优先调用跟SRC_IP同机部署的服务，如果没有就调用稳定环境的。

2.4 MQ的流量路由

我们弃用给topic加前缀的方式，改为框架给group自动加IP前缀。

·生产时，将SRC_IP放在Header中；

·消费时：

        · 动态环境：IP_group，且只消费IP匹配的

        · 稳定环境：test_group，消费动态环境不能匹配的

                  · 稳定环境发的

                  · 动态环境发的，但动态环境group不存在或服务被回收

三

分布式链路调用系统-天网

通过流量路由方式，我们只需在动态环境中部署Entry+X，极大简化了测试环境的部署，但仍存在一个问题，如果测试时E’没收到请求，该如何排查？

为解决调用链路在动态环境、稳定环境来回穿插所带来的链路排查问题，我们又引进Zipkin并进行深度定制，开发出一套对业务透明的分布式调用链路跟踪系统--天网。天网对测试环境100%全量采样，这样我们可以看到所有请求的整个调用链路，以便快速定位。

3.1 原理与构架

我们借鉴Google的Dapper系统，通过<TraceId, SpanId, ParentSpanId>三元组来串联一条完整的调用链路。在分布式系统中，相同的请求会落在后端的不同节点上，再加上微服务的水平拆分、垂直拆分，导致一次请求会经过后端的几十甚至上百个服务模块，而每个模块又有许多不同的节点。调用链的复杂化催生了分布式调用跟踪系统，其原理就是在包括但并不仅限于节点的边界处（如rpc、mq、db、cache）进行埋点并将埋点信息收集存储，以构建完整的调用链路。

天网架构如下：

天网系统中主要组件有Radar、ZipKin，其中Radar为架构部自研，ZipKin为开源软件。

Radar为天网系统的客户端，采用编码的方式接入。负责埋点的生成、格式化，并通过异步、批量的方式上报到Collector，对应用影响极小。Radar可集成在任何需要跟踪的模块中，目前我公司已集成到MQ、Servlet、Scf、TransactionMessage中。

Zipkin主要包含3个模块，为别为Collector、Storage、UI。其中Collector负责和Radar对接收集埋点数据并对数据进行格式化处理，Storage负责将Colletor处理过的数据存到DB中，而UI负责查询和展示调用链路。

3.2 效果

天网对测试环境100%抽样，从而可以查询全部请求的完整调用链路。

通过天网，我们可以看到调用方信息（名称、IP、端口），服务方信息（名称、IP、端口），接口、实参、序列化、耗时、数据大小等。

同时，我们也将<TraceId, SpanId, sampled>信息放入MDC中，以便日志打印。

四

效果

我们于2020.06上线流量路由模式，进入单机闭环和流量路由的双模式过渡期，直至2020.12才将测试环境完全切换至流量路由模式。回首2020年，转转的服务数增长超过50%，但通过流量路由模式，我们的测试环境资源使用量不但没有增加，反而显著降低。

4.1 每周平均环境部署的服务数

每个动态环境部署服务数是评估流量路由效果的一个重要指标。

可以看到，2020.12切换后，我们每个环境部署的服务数从30个降到了10个左右。

4.2 每周平均环境的大小

每个动态环境申请多大的机器资源（尤其是内存）是评估流量路由效果的另一个重要指标。

可以看到，我们申请的动态环境内存大小从年初的16GB降至不足12GB。

4.3 小结

从整体结果上来看，2020年转转的服务数增长超过50%，但通过流量路由模式，我们的测试环境资源使用量不但没有增加，反而显著降低，取得了较好效果。

但从业务发展上来看，正常需求一般修改集X为1~3个，对应的内存使用量也该在4GB内。我们现在的效果离这一目标还有较大差距，这主要是因为业务同学在部署动态环境时，仍习惯沿用单机闭环模式，在动态环境中部署了很多本次需求没有修改的服务，这需要我们从流程上继续优化。同时，也给流量路由模式更广阔的优化空间。

五

总结

基于IP标签的流量路由方案从2019.07开始正式立项，直至2020.12我们才将测试环境全部切换至流量路由模式，历时将近一年半。它涉及RPC、MQ、服务管理平台、部署平台、线上脚本等，横跨构架、工程效率、运维、业务等近乎所有转转后端技术部门，应该是我个人进入转转以来经历过的最为复杂的一个需求。

但其简约的设计理念，通过测试环境服务的最小化部署，并充分利用稳定环境的公共服务，简化了测试环境部署流程，极大节省了测试资源，同时节约了部署时间，已成为我们服务部署的一个利器，为转转业务迭代降本、提质、增效。

回首这将近一年半的开发历程，经历过懵懂、希望、彷徨、质疑、沮丧、惊喜，沮丧和希望并存，压力与挑战齐飞。每次解决一个问题，新的问题又会接踵而至，但在简化测试环境服务部署的美好愿景下、在无数转转人的鼓舞下，我们和工程效率、运维的同学攻城拔寨，时至今日终于提供了一个还算比较完整的解决方案。

道阻且长，今天我们只是正式发布了一个还算比较完整的1.0版解决方案，这只是一个里程碑，但并不是终点；行百里者半于九十，随着需求的迭代，我们陆续还会继续完善下去，推出2.0、3.0、4.0等等。不管道路怎么弯曲坎坷，在我们的共同努力下，在大家热情的配合与支持下，相信我们一定可以提供一个比较满意的解决方案！

作

者

道阻且长，拥抱变化；而困而知，且勉且行。