首次分享！滴滴国际化出行的建站实战经验

从2018年开始，滴滴国际化出行业务陆续进入巴西、墨西哥等多个海外国家市场，而伴随着业务的扩张，出于稳定性、成本、合规等要求，业务系统需要频繁在不同地区、不同基础设施环境的机房内进行大规模建站交付，例如自建 IDC、AWS、GCP 等公有云环境。

经过几次新机房交付后，我们发现，出行业务包括业务系统在内，有上千个模块与存储实例以及数万张表，业务架构复杂、链路长、依赖多，导致当前建站效率非常低，从建设开始到正式提供服务，需要全链路业务 RD、SRE、QA ，大量团队的数百位同学参与支持，前后耗时 3 个月以上，严重影响了正常业务功能的迭代，同时由于整个交付过程极高的复杂度，异常问题及风险频发，对线上业务造成预期外的影响。在低效的建站交付也会对业务的决策造成严重影响，错失关键的市场窗口。

因此我们在 2021 年 Q4 正式开始立项解决上述的建站提效问题。在进行问题分析及解法设计之前，我们先展望一下理想中的建站交付应该是什么样的：

带着这些目标，在接下来的系列内容中给大家介绍一下国际化出行在建站提效方向的一些核心思路、关键技术方案以及经验总结，整个系列包括三篇文章：整体方案及实战经验、环境差异配置管理，以及应用交付。

本文为第一篇综述，重点介绍建站提效的整体架构以及在国际化出行业务的落地路径与效果。

我们先拆解一下国际化出行建站的全过程，分析当前建站低效的根因。

整体建站流程大致可拆分为上图所示五个阶段：

为了便于理解，这里看一个基础设施搭建的实际模块交付 CASE：

在上述各阶段中，基础设施搭建阶段相对业务不敏感且流程固定，可以收敛在基础平台内部完成，当然目前也存在效率提升的空间，可应用 IAC(Infrastructure As Code) 的思路优化，本系列不展开讨论。相比之下，后面几个环节的效率问题更为严重，核心原因在于这几个环节目前都需要业务 RD 的直接参与，这样导致了交付效率与业务复杂度正相关，需要全链路上的各服务负责人介入，而由于各自服务间的复杂依赖，这个过程中产生的沟通成本也与之骤增。目前需要业务 RD 参与的主要有以下几部分内容：

因此当前在每次建站交付过程中都需要通过一个非常复杂的文档来收集上述信息，这些过程都非常依赖 RD 的经验，有的需要梳理全量代码才能完成，一方面非常低效，另一方面也容易出错，往往在联调过程中会发现各种资源漏建、代码漏改或改错的情况，导致交付进展缓慢，有的问题甚至还会流入生产环境，例如将欧洲机房某个服务的 redis 连接信息配置成美东集群导致的线上故障。除此之外，SRE 的交付动作目前也缺少统一的能力支持，基本是通过各类临时脚本实现，可维护性也存在一定风险。

因此，当前在每次建站交付过程中都需要通过一个非常复杂的文档来收集上述信息，该过程非常依赖 RD 的经验，有的需要梳理全量代码才能完成，一方面非常低效，另一方面也容易出错，同时，在联调过程中往往会发现各种资源漏建、代码漏改或改错的情况，从而导致交付进展缓慢；有的问题甚至还会流入生产环境，例如将欧洲机房某个服务的 redis 连接信息配置成美东集群导致的线上故障。

进一步剖析上述问题，我们可以发现它们源自以下几个根因：

针对上述三个核心问题根因，结合长期的建站交付目标我们得出如下解决思路：

一言以蔽之：建设以应用为中心的自动化交付框架。

参照上述的整体解决思路，我们依次介绍三个核心问题的技术解决方案。

在上面的现状分析中说到，我们目前缺少围绕一个应用或者一个服务的整体描述，因此无法直接在一个全新环境中将其交付出来，为了解决这个问题，主要从两个方向入手：1. 制定应用描述的模板；2. 围绕应用汇总本身及相关依赖的信息，组织成符合上述模板的应用描述。

首先是应用描述模板的制定，我们采用了目前业内比较规范的云原生开放应用模型——OAM(Open Application Model)。一方面是因为 OAM 对应用的模型定义比较清晰，另一方面也是为了契合滴滴云原生技术路线。

在 OAM 中，应用是由以下几个核心概念组合构成：

以某真实线上服务为例，其应用模型可以由如下组件描述：

应用描述文件 ApplicationConfiguration 示例如下：

使用上述应用描述模板，我们可以将一个应用的所有信息描述出来，同时这样的描述是关注点分离的，开发者只需要明确服务的架构，定义依赖的 Component 及相关描述，而其他的运维属性信息 Traits 则由 SRE 负责填充，这样在交付过程中职责边界是清晰的。

有了这样的描述模板，我们进一步对准入系统进行升级，在新应用进行创建的过程中以此为入口由负责人进行相关信息的描述，同时对旧应用也可以进行准入重入，将相关信息汇总至此，并且会伴随应用的全生命周期存在，这样在后续的新环境交付的时候直接拉取应用的完整描述然后交由下面的交付框架进行批量交付即可。

在具备了应用完整描述信息之后，接下来便是基于这个标准化描述文件进行自动化交付的框架设计。

基于上述的长期建站目标，我们最终采用了基于阿里云开源的 基于 OAM 模型的云原生应用交付平台——KubeVela 进行定制化的建设方案，核心原因如下：

KubeVela 整体架构如下：

我们主要使用了 KubeVela 的核心引擎，上层的应用层与滴滴现有的 DevOps 平台结合，下层基础设施接入滴滴的基础架构栈，深度定制了滴滴内部的交付平台。对滴滴内各类核心资源组件与运维设施进行了交付能力适配接入，同时支持了基于 Terraform 对接公有云的资源组件交付能力，实现了从应用组件描述到应用声明式交付的完整流程，同时将该能力落地成了应用中心平台，实现了应用编排、资源交付、环境管理、应用克隆等能力，供建站交付过程使用。

同时在适配过程中我们发现，资源组件和运维设施的接入维护以及对外交付能力的露出都需要相关方不少的支持投入，同时在后续变更过程中的管理成本也很高，为此我们基于 KubeVela 的 x-Def 能力实现了组件市场解决该问题，如下图所示，组件市场支持接入方自定义交付模板，该模板会将相关参数透出至交付环节供用户输入，同时在 KubeVela 交付引擎中将用户输入的内容传递至相关组件的交付接口，实现组件方交付能力的自助接入。

在应用建模与交付框架完成后，建站交付的过程如下图所示：日常 RD & SRE 在应用准入、日常变更、运维过程中依赖应用中心维护应用的环境无关编排信息，该编排信息通过交付框架支持在任意新的多云环境中进行声明式交付。解决了上述建站过程中依赖人工进行应用依赖信息梳理以及人工交付的低效问题。

关于应用建模及交付框架的详细技术细节将在系列第三篇文章展开进行更深入的介绍。

环境信息管理重点解决各业务模块代码中与集群耦合的配置与逻辑管理问题，如 Mysql 连接串、超时重试配置等。历史上由于缺少统一规范，而业务模块运行时环境有非常多，包括离线自测环境、线上联调环境、预发环境、小流量环境、多区域生产环境等，导致大家广泛将集群间差异的配置与逻辑硬编码在配置文件或代码中，甚至有的业务逻辑的实现也存在通过集群进行分支控制的，导致建站期间很难遍历需要变更的范围，出现上述低效以及高风险问题。

我们从本质出发思考该问题便容易发现：首先业务模块的逻辑中带有环境信息是完全不必要也不合理的，因为业务功能的实现与实际部署的环境不应有耦合，理论上一套逻辑集成后可被交付至任意环境，包括自建设施或公有云、离线测试或线上生产环境等；其次环境信息是和环境一一对应的，可以认为是环境的元信息而不是业务代码的运行时配置，业务代码应该做到能从环境元信息中获取相应字段后统一执行后续逻辑。上述两点也都在描述云原生应用最佳实践的十二要素配置管理原则中提及，详情可参考文末资料内容。

基于上述思考，我们形成了理想的环境信息管理方案：1. 标准化定义环境相关配置模板；2. 解耦业务代码与环境配置实现集中式管理；3. 打通应用交付框架实现新环境配置自动生成。

配置模板定义

配置模板定义的目的是将服务代码依赖的环境相关差异信息进行标准化定义，方便后续的集中式管理与自动化生成。

环境相关差异信息大致可分为三类：环境元信息（region、可用区、类型等）、组件信息（连接串、超时重试信息等）、其他自定义字段，针对环境元信息与组件信息，我们与相关设施提供方定义标准化模板，支持业务代码获取，针对这部分模板字段，支持与上述交付框架打通，关联交付规则，实现配置自动化交付能力；对于其他自定义字段，主要用于非标模板的管理，如需新增，需要用户定义标准交付规则，适配配置自动交付能力。模板详情如下图所示：

配置集中管理

在配置模板标准化定义完成后，需要将配置仓库从代码仓库中解耦出来进行集中管理以实现后续的自动化交付，配置集中管理是环境信息管理中最核心也是最复杂的部分。

要实现与配置与代码解耦集中管理的重点需要回答三个问题：1. 增删改查如何交互？2. 环境配置如何下发？3. 环境配置如何被业务代码获取？下面来依次探讨：

1. 增删改查入口

在环境配置集中管理后，需要有增删改查入口来取代原研发过程中直接操作代码的流程，这个问题相对简单，唯一需要思考的是为了保证环境配置仓库的标准化，是不允许用户直接进行通过 git 进行任意修改与提交的，因此需要封装一层配置仓库的操作入口。为了实现简单，我们在前期直接使用滴滴成熟的 WebIDE 能力，在其上添加了较为完整的配置校验插件之后交由用户进行编辑修改；在后期这种方式的配置校验偏后置，且无法支持更为复杂的校验能力，用户易用性也比较差的问题越发凸显，因此我们在此基础上提供了更友好的白屏化交互能力。

2. 环境配置下发通道

这里有多种选择，最直接的是考虑使用滴滴现成的配置热更新组件 Apollo，但是通过对国际化全量服务进行扫描和分析后我们发现，这里的环境配置和 Apollo 管理的配置存在较大差异，Apollo 中更适合管理动态配置，即在运行时调整的配置，无须进行服务重建，而这里的环境配置更多的是静态配置，例如 Mysql 连接串、下游依赖的 Token 等，这些配置基本只在服务启动时加载一次，同时，大部分配置场景还是会随着代码变更，整体的配置变更频率较低，对质量保障的要求更高，而 Apollo 目前配置变更的流程相对线上代码的变更质量保障要弱很多。

另一种选择是将配置下发放置在 CD 阶段，类似目前弹性云的环境变量管理，这样可以在每次服务变更时进行环境配置的 double check，但是这种方式依然存在着风险，例如配置变更在开发测试期间和变更时的环境变量配置不一致导致的异常。

因此最后权衡后我们决定把配置下发的流程前置到 CI 阶段，在代码仓库之外新增一个配置仓库，在代码变更流水线中的构建阶段进行配置仓库内容的拉取，这样可以保证配置的变更可以完整走过 CR、测试、自动化 case 等质量保障环节。当然放置在 CI 环节还有一系列相关问题需要解决，例如配置的拉取脚本，配置的协同开发流程，和代码流水线的合并等。下图为配置仓库与业务代码仓库的协同 CI 流程。

3. 环境配置获取机制

解决了配置下发通道问题之后，接着需要解决服务代码如何获取这部分解耦的配置，这里的设计需要考虑的关键问题是服务接入的成本，因为这里的改造基本涉及所有的服务，如果成本过高，推进难度会很大。最直接想到的方案是提供简单易用的 SDK，同时与公司的各种研发框架结合，我们在项目初期尝试了这种方案，但是在部分试点服务接入过程中我们发现，SDK 的接入成本还是很难接受，原服务配置中有环境差异配置也有很多环境无关配置，为了接入这部分配置管理，还需要对其进行拆分，导致很多额外成本。另一方面，SDK 的维护成本也很高，我们需要为不同语言开发不同的 SDK，后续的版本更新也需要所有服务配合。 

因此我们采用了另一种模板替换的方案：配置在仓库中通过固定格式管理，然后服务在原配置中将需要从配置仓库中获取差异配置的部分改造为占位符，例如：^cac{{.mysql.user}}，我们在配置下发过程中自动识别这些占位符进行字符替换。这样业务代码的配置获取方式可以保持不变，只需对配置进行少量改造即可，改造量非常低，同时这种方案是语言无关的，维护成本也非常低。具体的细节也放在本系列第二篇文章中介绍。

配置自动交付

在配置模板标准化以及集中管理完成之后，我们便掌握了所有模块所依赖的环境差异信息，且是格式化的数据，因此交付框架可以获取并理解这些差异信息内容，自然可以实现在新环境下资源组件交付后进行模块依赖的差异信息注入，进一步实现建站交付的提效；为此，我们在交付框架中额外实现了 BizConfig 组件，负责收敛交付出的资源描述信息，然后按照集中管理的配置模板进行自动化注入，并自动完成镜像构建及部署交付。

解决上述三个配置管理的核心问题之后，还有两个需要重点考虑的问题，包括：稳定性保障及配置防腐。

在环境配置管理能力建设完成后，实现了建站交付无须代码改造，解决了上述建站过程中资源交付后需要大量人工改造与部署联调的低效问题。

关于环境信息管理的详细技术细节将在系列第二篇文章展开进行更深入的介绍。

将上述三个核心方向的技术方案结合起来便可得到建站提效的整体技术架构：

如上图所示，整体架构由以下几部分组成：

在完成上述建站提效的整体技术解决方案的设计之后，接下来进入到该方案的具体实施落地的阶段，而该项目的落地难度无疑是巨大的。

从方案的整体拆解过程中容易发现，我们的解决方案定位是建设较为通用的建站交付平台，该交付能力是对原有 DevOps 体系的完善，因此需要内部各基础架构与中间件团队的适配支持，同时环境配置管理的接入还需要全流程业务模块负责人的改造支持，涉及团队范围非常广，需要设计比较合理的实施路径并把控落地节奏。

我们判断其中有几个核心关键点需要把控：1. 阶段性里程碑：需要合理拆解项目技术话题，结合实际使用场景取得阶段性成果，激发参与成员的价值感；2. 平台产品化：需要有成熟稳定的落地产品，并与当前大家熟悉的 DevOps 流程深度融合，提升易用性的同时减少大家对体验迁移的不适；3. 长期防腐投入：避免低频率的交付场景对建站能力的腐蚀，将基础能力应用至更多高频场景为佳。

基于以上考虑，我们的实施路径大致分为三个阶段：

1. MVP快速建设+小型场景适应性验证（持续时间约 6 个月）

该阶段的主要目标是整体方案的可行性验证，因此我们精简了整体方案，在 KubeVela 框架基础上适配了滴滴内部较为常用的 1-2 个组件及 1-2 个运维设施交付能力，同时自行实现了简易的配置仓库管理流程，并在国际化出行的小型机房建设过程中应用，验证了交付流程的有效性。

2. 能力拓展覆盖+平台产品化（持续时间约 1 年）

该阶段的主要目标是对 MVP 版本支持能力的全面拓展，逐个适配接入各类常用资源组件与运维设施；同时与平台同学合作，将 MVP 版本中自行实现的交付能力与环境配置管理能力集成至已有的 DevOps 流程中，形成标准化平台产品。

3. 全链路推广接入+真实场景大规模应用（持续时间约 6 个月）

在平台能力相对成熟之后，我们启动了国际化出行业务全链路的推广接入，包括应用模型描述、交付能力收敛以及环境差异配置管理能力的推广，并在国际化出行真实的建站场景中进行了大规模的应用，验证了交付能力对建站效率的大幅提升。

在上述三个阶段完成后，建站能力在国际化出行业务得到验证并取得了不错的成果，我们接着将注意力转移至平台能力的进一步拓展，以及长期防腐能力的建设上：

最终整体建站提效能力落地为应用中心及环境信息管理两个平台，分别负责应用信息管理&交付以及环境差异信息管理。具体效果如下：

1. 应用中心

2. 应用模型：负责应用依赖的资源组件信息的增删改查。

3. 环境管理：负责管理应用模型在不同环境下的交付，支持环境间克隆。

4. 环境信息管理：负责环境差异信息的增删改查以 及编译部署环节的注入获取能力

在上述平台产品落地成熟之后，再回过头来看上文中提到的某模块交付的CASE，交付流程从原来复杂的资源梳理+资源交付+代码改造过程，优化至只需要从交付平台中选择该模块任意环境进行应用描述的克隆，进行相关交付规格的配置调整后便可由交付平台实现自动化的交付过程，整个交付无须人工参与便可将模块依赖的弹性云集群、资源组件以及代码中依赖的新环境配置一并交付，开箱即用，直接进入联调测试环节。

同时，我们也在 2023 年国际化出行新机房真实建站过程中全面应用了上述建站交付能力，实现了一次完整建站过程的人力投入大幅减少80%，初步解决了困扰已久的建站低效问题。

首先，需要对当前建站能力进行进一步的拓展以更全面地解决建站过程中的效率问题，包括支持的基础设施环境（自建 IDC、公有云等）、支持的资源组件范围（如大数据链路、内部中间件等）、支持的组件交付能力范围（如数据同步、配置同步等）、交付平台的交互优化等，同时可以进一步将建站能力推广至滴滴其他业务线以支持更多的建站需求。

其次，当前完成建站提效能力建设之后，在滴滴的 DevOps 流程中补充了两项核心能力：

具备这两项能力后，可以衍生至除建站交付外的其他场景，主要包括以下两点：

1. 架构治理：利用应用描述信息，发现未被使用的资源组件，同时在应用中心中收敛资源组件的全生命周期变更，实现应用依赖关系的准确维护，针对历史中未使用的资源组件进行下线处理，同时保证架构迭代过程中不出现无人管理的资源组件；

针对应用描述信息，扫描分析应用架构中的异常，并围绕应用进行架构问题的跟进处置；

2. GitOps：将交付框架的声明式交付能力逐步引入日常 DevOps 流程，实现更稳定的线上环境管理、自动化程度更高的部署能力；

需要注意的是，以上衍生能力的推进都会对现存的 DevOps 流程有所冲击，需要谨慎平衡收益以及带来的负向影响。

参考资料

你们公司的建站效率如何？有哪些经验可以分享？欢迎评论区留言互动，作者将在留言中选取5位送出【中秋节月饼礼盒】一份。如需与我们进一步交流探讨，也可直接私信后台。