解密蚂蚁研发效能

本文整理自 GOPS 2019 全球运维大会蚂蚁研发效能技术专家仲光明（花名：元衡）的分享。通过对分布式链路下蚂蚁金服快速构建低成本、高可用联调环境的解析，带大家了解蚂蚁金服在研发效能领域上的深度实践。

🚀我们招聘了！招聘详情见文末！！！

仲光明（元衡）

蚂蚁金服 技术专家

蚂蚁金服技术专家，目前主要负责研发侧配置管理和联调环境产品的架构和研发工作，关注持续交付相关领域；2011年加入蚂蚁金服，先后参与核心中间件的测试自动化，蚂蚁金融云以及蚂蚁持续交付产品的建设工作。

随着蚂蚁金服业务的快速增长，业务场景的不断丰富，研发规模也对应不断扩大。到目前为止，蚂蚁全站已有几千个应用服务，每周并行上千个研发活动。

同时，为了支撑业务的飞速发展，分布式系统架构不断演进，业务链路日趋复杂，单涉及资金交易的单条核心链路就有近百个上下游依赖的应用服务，服务间相互调用近千次。如下图所示：某条付款业务上下游链路的一小部分可视化示意图，从中也可窥见到业务链路上下游调用的复杂性。

• 联调涉及应用服务多，导致环境构建和维护的成本都非常高，手工搭建一套可用联调环境，少则1-2天，部分情况下甚至可能花费1到2周。因此，如何降低联调环境构建成本，让研发同学专注于业务联调本身？

• 联调链路上下游依赖应用服务多，为每一个联调链路都全量搭建一套独立环境，资源消耗太大，需要对没有变更的应用服务进行复用。但是复用又带来了新的问题，每周上千个的并行研发活动，同一个应用服务可能为了支持不同需求在研发阶段存在多个并行研发，如何在资源复用的基础上，解决并行研发带来的干扰？

• 联调过程中出现了问题，排查的链路往往比较长，一般研发同学对自己负责的应用服务比较了解，如果问题出在依赖的下游，往往需要联系对应负责的同学排查，过程中有很多的沟通成本，排查效率比较低。如何协助研发同学快速定位联调问题，提升业务联调的效率?

基于上述的挑战，我们在蚂蚁建设了联调环境产品，给出了我们自己的解法：

• 通过自动化构建和管理的方式，解决环境搭建成本的问题

• 通过环境复用基础上基于研发分组的隔离，解决业务链路长消耗资源以及并行研发干扰的问题

• 通过链路自动化监控和诊断，解决业务联调排查成本的问题

下面，我们也将就上述的三个挑战及对应的解法，详细分享下我们在蚂蚁的一些实践。

自动化构建

解决构建成本的直接方式就是将整个环境构建自动化起来，让研发同学只需要提供相关的环境描述信息（比如应用服务启动所需要的代码信息，服务器数量等），通过联调环境产品自动化的完成包括资源申请，代码构建，服务部署，服务可用检测以及研发分组绑定等一系列操作，最终完成环境自动交付。研发分组绑定目前大家可以理解，为每一个联调环境都分配了一个唯一标识，称之为研发分组，这个概念在后面环境隔离的部分会重点提到，这里先留一个伏笔。

如下图所示，整个自动化的过程在10min内完成，相比原先手动搭建的耗时，大大提高了整个联调环境构建的效率。

可用性验证

环境中每个应用服务部署都没有问题，并不代表整个环境是可联调，可用的。我们之前也遇到过，当我们协助开发拉起整个环境后，在做真正业务联调时，往往因为一些系统或业务配置的问题（这些配置并不影响服务启动，但是影响业务逻辑行为），导致联调结果不符合预期。

所以在环境部署好后，我们需要有验证整个链路是否可用的手段，最好是自动化的。这里，我们引入了链路用例（也叫端到端用例）。链路用例相比传统的单元和集成测试用例，更专注于对整个联调链路每个节点的输入输出进行验证。

因此，在环境搭建好后，可以在新环境中自动运行预设的链路用例，并将这些用例执行的结果同步给研发同学，方便他们评估整个联调环境的可用性。

生命周期管理

对于大项目，联调是个持续的过程，环境构建好交付研发联调只是一个开始。在联调过程中发现的问题，需要及时修复并重新部署，整个联调过程是不断发现问题并修复的过程，直到全部联调完成到准备发布上线为止。因此，联调环境需要有自己的生命周期管理，在联调过程中支持资源或者服务的变更，并在联调结束时完成环境的回收。

下图是目前联调环境产品生命周期管理的简单示意图：

生命周期管理也需要对整个环境的可用性负责，我们称之为健康巡检。即联调环境会对每一个创建的环境进行异常巡检，检测是否存在不可用的应用服务，并尝试进行服务自愈（服务宕机重启/物理机宕机进行迁移后重启...）。

当然，有时候服务启动是没有问题的，但是因为引入了BUG导致联调异常，这时候也提供基线恢复的能力，可以快速将异常的应用服务恢复到之前稳定联调的版本。整个过程既可以自动化完成并通知研发同学，也允许研发同学通过人工介入的方式进行手动排查恢复。

研发环境复用

在背景部分提到过，业务链路复杂，单条核心链路涉及上下游应用服务非常多。当链路进行改造或者新增业务链路需要联调时，不可能为每一个联调场景把整个链路的上下游应用服务都独立申请一套，一方面耗费资源巨大，另一方面后期维护的成本也非常高。因此，我们需要对链路上不变的应用服务和相关的基础设施进行复用。

蚂蚁有一套稳定环境里面，部署了几乎全量应用服务的线上稳定版本。同时，对于一些基础设施，比如DB，中间件等，也是研发环境内复用的。研发同学只需要为变更的应用服务申请独立的部署资源即可，如果链路上涉及不变的应用服务，统一复用稳定环境。

环境复用，解决了复杂链路联调资源消耗成本的问题，但是，也引入了新的问题，即复用必然带来的相互干扰。如上图所示，假设系统调用链路为A->B->C，在研发环境中，刚好A和C系统存在两个并行研发，分别为A1，C1和A2，C2，他们都复用稳定环境的B进行联调。那么问题来了，从A1发起服务请求到B后，B是如何判断最终能将流量重新返回到C1，而不是错误的调用到同一个环境下的另一个研发分组C2，抑或是稳定环境的C。

因此，在环境复用的基础上，需要具备基于研发分组（可以理解为一个个独立的联调环境）的相对隔离能力。下面就隔离涉及的方面进行具体介绍。

服务路由隔离

我们接着上面描述的问题，服务路由基于研发分组的隔离能力，是通过中间件提供的SOFARouter产品提供的，其原理图如下：

继续结合上面的例子来说明，首先在搭建环境时，我们将A1和C1在SOFARouetr的服务端绑定到研发分组1，当A1发起调用到B时，同时也携带了自身所属的研发分组信息。B通过服务发现知道可调用的下游服务包括[C1,C2,C],同时B拿到研发分组信息去SOFARouter服务端获取到分组信息包含[A1,C1]，两者取交集为[C1]，即是这次调用应该去到的正确地址。从而完成了服务调用基于研发分组隔离的能力，保证流量的有去有回。

我们将分组绑定集成到环境构建的过程中，就有了下面这张示意图:

中间件隔离

除了服务路由外，复用的中间件也需要具备基于研发分组的隔离能力。这里以动态配置推送为例子：

在生产环境运维时，动态配置推送往往使用集群推送功能，将动态配置快速的在整个集群变更生效。但是在线下研发环境中，为了测试，经常需要推送一些异常值，这时候往往不能使用集群推送，因为会影响到这个环境下其他在并行研发的相同应用服务，甚至是稳定环境的应用服务。因此，需要支持按照研发分组进行配置推送，从而保证推送值只会影响到当前需要验证的应用服务，而不对其他业务造成干扰。

DB隔离

DB作为应用依赖的基础设施，也有隔离诉求。比如一些配置表数据，在一些联调场景下可能需要改成不同的值进行验证，并行研发的时候就会造成冲突。如果沟通不当，往往会排查半天才发现是DB里的数据被别人修改导致的。因此，如果能够在联调时，对这些配置库表进行隔离，就能避免上述问题。

我们的做法是，让研发同学在联调环境选择需要隔离的数据源，产品通过所选数据源的库表信息进行隔离DB的创建，在复制表时，也会根据联调需要进行适当的缩库缩表，以降低隔离DB的资源成本。最后通过部署在应用服务上的agent将数据源映射到新创建的隔离库上。

业务场景隔离

除了基础设施，一些公用的业务系统也需要支持隔离以满足联调需求。这里以蚂蚁无线网关为例子，从手机端发起的请求，需要首先经过无线网关，再路由到其背后对应的应用服务上。在联调场景下，相同的应用服务可能在同时有几个版本在并行研发，无线网关如何能将对应手机端发起的请求正确路由到与之对应正确的应用服务上呢？（显然这里也是采用了复用无线网关的策略，而不是为每一个场景都独立申请搭建一套网关服务）

如上图所示，通过客户端改造，支持将研发分组信息通过手机扫码的方式进行绑定，从而保证通过该手机发起的请求，都会携带对应扫码绑定的研发分组信息，从而流转到网关时，网关可以通过对应的分组信息，来决定应该如何路由。

链路信息诊断

在做链路信息诊断之前，我们依赖了两个基础产品：

• Tracer：由中间件团队提供，用于分布式系统链路调用跟踪的组件。通过统一的ID串联整个调用链路，并以日志的形式进行记录

• 云图：由研发效能团队提供，基于Tracer，将链路日志可视化并具备根据配置的规则进行日志分析和链路诊断的能力

联调环境拥有相关的环境信息（这个环境有哪些应用服务，IP等），结合云图的链路分析能力，就可以做到联调问题的自动化诊断。用户只需要提供对应调用上游的trace信息，就可以通过诊断能力快速定位到整条链路到底是哪里发生了异常（业务异常），或者哪里调用到错误的服务上（路由异常）。如下图所示:

业务信息诊断

链路信息的诊断依赖用户提供trace信息，但是由于trace信息是无业务含义的，其获取方式往往需要登录到服务器去查看业务日志才能获取到。这就给联调诊断设置了门槛，因为在有些场景下，研发或者测试人员是很难获取到其信息，比如在手机端发起的联调。

如果有一种方式，可以将研发同学熟悉的业务信息，自动转换为对应的trace信息，就会大大降低整个联调诊断的门槛。比如还是通过手机端发起的业务，我们往往比较清楚所测试的用户信息或者是返回的错误码，通过提供时间区间和对应上述信息，诊断系统自动从对应业务系统日志反查回对应的trace信息，如果匹配了多条，则让研发人员二次确认，通过这样的方式，将业务信息转换为链路信息再触发诊断，就可以达到降低联调诊断门槛的目的。

主动监控

上述的诊断方式从产品侧来看仍然是被动的，需要用户来使用诊断功能才能触发。是否有更好的方式作为补充，比如对整个环境的调用情况进行主动监控，主动发现联调过程中的问题，并聚合反馈给研发同学，而不是等到他们发现问题上来排查。

通过自动监控是可以做到这一点的，通过对联调环境中应用服务调用日志的主动分析，过滤掉环境无关的信息后进行问题诊断，如果问题反复出现，在一定时间内对相同问题进行汇总聚合后，以异常事件的形式通知到研发人员。

联调环境最初是为了解决联调环境搭建难的问题，因此我们最先建设了整个环境构建的能力。之后，出于对环境的持续维护需求，建设了生命周期管理和联调链路验证的功能。发展至今，也在环境隔离能力和问题诊断监控方面不断建设。未来，我们将会围绕着三个核心能力继续深化演进产品构建、隔离、诊断等能力。

长按识别二维码关注我们

P.S.

蚂蚁金服研发效能团队招募进行中，解决方案架构师、技术运营、数据研发专家、技术专家、技术支持专家、产品专家、测试平台高级开发工程师、代码分析技术专家等众多岗位持续开放，让我们共同开赴DevMind/DevOps/DevServices三大战场，助力内部及外部伙伴研发效能的持续提升🚀🚀🚀

如果你对任何岗位感兴趣，请留下联系方式，或者发简历到：AntLinkE@antfin.com

技术同学请附上你的GitHub/GitLab个人地址哦~

▼ 点击“阅读原文”获取更多职位详情