vlambda博客
学习文章列表

在进行测试时，我们期望调用链路可以经过本次需求所修改的所有服务。转转早期的做法是，在测试时将测试链路上所有的服务都部署在同一台服务器上，形成单机闭环。其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等等。不管道路怎么弯曲坎坷，在我们的共同努力下，在大家热情的配合与支持下，相信我们一定可以提供一个比较满意的解决方案！