深度拆解滴滴国际化建站提效利器：环境差异配置管理

背景介绍

随着滴滴国际化业务的发展和扩张，当前已在全球多个国家提供面向当地的出行服务，为了给用户提供更好的体验和更低的响应延迟，异地多机房灵活部署及云上弹性部署的需求日益强烈。出于体验、成本、合规和稳定性的考量，2020至今，国际化业务进行了多次不同规模的机房部署。早期部署过程非常低效，除去SRE的参与，需要部署全量模块的业务RD参与资源梳理、资源申请、适配新机房代码改动、上线部署、联调测试一系列工作。部署范围通常几百个模块，部署周期在2-3个月，几百个人2个多月的协作，期间难免发生错误，沟通协调成本可想而知非常巨大。

随着云原生技术的发展和运用，微服务数量越来越多是不可逆转的趋势，为了减少部署过程中参与的业务RD人数，首先要找到问题根因是什么？

根因分析

批量服务交付时，业务RD的工作主要集中在3点：

1.资源梳理和申请 

2.代码改造适配新环境 

3.部署联调

其中第一点的效率问题由应用中心解决（见结尾延伸阅读），后两点——适配新环境时大量服务的代码改动效率和部署效率低下，是本文要解决的重点问题。RD主要的改造部署工作步骤和分析如下：

步骤1：梳理出零散的环境差异内容

业务现状：根据差异内容存在的位置不同，可分为以下四种类型：按照环境区分的配置文件中的机房差异、代码中硬编码的机房差异、用环境标识判断的业务逻辑差异

问题分析：单个服务中环境差异内容的位置分散，部署周期远远大于开发上线周期的特点，决定了RD的梳理只能是一次性工作，下次交付又要重新进行复杂的梳理，因此从单服务角度，不同环境使用同一套基准代码，将环境差异全部集中在一起配置，能够有效框定梳理范围。现实中大家也多是这么倡导的，但是环境差异配置与代码存储在同一个git仓库中，无法强制保证每个开发者遵守该倡议，难免腐化。

步骤2：针对各种类型繁多的差异内容适配新环境

业务现状：各个服务的下游依赖种类繁多，环境差异五花八门，每个负责RD都要独自处理所有下游依赖的适配工作；对下游来讲，因为被多个上游同时依赖着，机房交付时，多个上游都会分别找过来沟通，以寻求支持适配方案，不得不重复沟通。早期的多次机房部署均是依靠堆人的方式解决，几乎是八仙过海各显神通。

问题分析：微服务架构是滴滴主流开发架构，各个微服务遵循单一职责原则，高内聚低耦合，基于接口契约进行服务间通信，独立进行开发、测试和部署。微服务架构下的职责划分，促进了系统的可维护性、可扩展性和灵活性，日常开发好处多多。与此同时，这样的职责划分意味着机房部署时服务间单点沟通，各个服务RD日常对各自服务环境差异内容自定义命名。

步骤3：内容适配改造完成后，各自进行线上部署

业务现状：每个RD完成各自负责服务的新环境适配改造后，进行上线部署。当组织者和所有相关服务全部确认上线完成后，测试团队介入，构造测试数据进行回归测试。

问题分析：前2步所需时间都由服务本身的复杂度和RD的个人节奏决定，所有人都改造部署完毕再进行联调，注定存在漫长的等待。组织者要与所有人拉齐部署进度，服务复杂度低的RD往往要等待几周甚至一个多月才能开始联调，如若代码修改出现纰漏，又要重新拉齐部署进度。而现实中，由于新机房部署联调时没有线上流量不承担风险，基础数据缺乏导致测试数据构造存在一定成本，部署RD往往不会对部署的新环境服务进行完备的测试，发现纰漏进行返工，屡见不鲜。

总结一下，当前业务RD适配新机房的部署工作低效，主要存在以下三个问题：

1.服务中环境差异内容位置分散，且耦合在代码逻辑中，梳理工作复杂且每次部署需要重复进行；

2.服务环境差异种类繁多，集团缺乏相应标准与支撑工具，各个服务中环境差异内容进行自定义命名，形成信息孤岛，每个RD独自负责适配工作，导致上下游重复沟通；

3.各个RD人工部署，人员数量庞大导致信息拉齐困难；新交付集群无线上流量不承担风险，改造内容自测不充分，导致频繁返工，拖慢整体联调测试回归进度。

解决思路

想要根本解决问题一，必须将配置与代码彻底分离，不再存储于同一个git仓库，同时禁止代码感知当前环境标识，所有环境一套代码，从而杜绝增量的环境差异内容被添加到代码中。这在描述云原生应用最佳实践的十二要素配置管理原则中有所提及，云原生领域Heroku创始人AdamWiggins提出的"TheTwelve-Factor App"是业界广泛认可的云原生微服务开发原则，其中提到的配置管理的方法论：a.微服务应该只有一套基准代码，但可以存在多份部署，不同环境的差异应该在部署时动态确定； b.发布可回溯，配置和代码共同组成一份release，每个release可管理可复用； c.配置可分离，任何配置变更不需要改动代码。基于此，更加清晰明确了代码与环境配置之间的关系。

图片来源：《The Twelve-Factor A