如何在多云环境下做好高效应用交付？｜滴滴国际化建站提效系列收官

滴滴技术

于 2024-09-26 20:45:48 发布

阅读量496

点赞数 14

文章标签：人工智能 java 大数据数据库运维

本文链接：https://blog.csdn.net/DiDi_Tech/article/details/142581093

版权

背景

在《首次分享！滴滴国际化出行的建站实践经验》中详细介绍了机房建设提效的解决思路：

1. 梳理提效：建设应用模型，标准化描述各业务模块与依赖资源、运维设施、平台配置的关联关系，并实现应用信息的全生命周期管理；

2. 交付提效：基于标准化的应用描述，建设自动化的交付框架，实现一站式应用交付；

3. 改造提效：收敛业务模块中与环境关联的配置与逻辑，并进行标准化管理，与交付能力打通后实现交付过程代码 0 改造；

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

在《深度拆解滴滴国际化建站提效利器：环境差异配置管理》中详细介绍了改造提效中应用环境差异托管的方案，将环境信息与业务逻辑进行了拆分管理，并对环境信息进行了标准化，为环境信息自动化生成打下了坚实的基础。

下面我们深入剖析下，应用建模、交付框架的建设过程，并通过适配CAC配置管理方案生成环境配置信息，实现应用自动化交付的。

目标分析

应用交付的整体目标为建立一个描述应用所有工作负载的标准化的管理模型，进而实现在混合云环境中标准化和高效率的应用交付。

应用模型

1. 关注点分离

在国际化业务实践中，基础设施、应用日常迭代以及应用的日常运维是由不同团队维护的，由于各个团队的关注点不同，应用模型需要区分这些不同的角色。基础设施团队，主要由基础平台工程师完成，他们具备丰富的基础设施经验，负责维护稳定可靠的、可被复用的基础设施功能。开发团队，业务应用的开发者，日常根据业务需求对业务逻辑进行开发迭代，并选择合适的基础平台提供的功能与代码集成，不需要关注基础设施细节，快速、轻松构建可信赖的应用。运维人员，关注应用部署环境中的运维能力，保障服务的稳定性。

2. 平台无关、高可扩展

在国际化业务中，一个应用要整体运转起来，需要关注它的工作负载（弹性云计算资源）、存储资源（MySQL、Redis等）、中间件（Apollo、MQ等）以及运维特征（日志、报警）等，应用之间的的依赖是多种多样，存在较大差异的，例如有的应用依赖MySQL，有的应用依赖Redis，应用建模需要高可扩展的支持依赖的自由组合。另外，国际化业务全球拓展，在自建机房、AWS、GCP等混合云环境进行部署，应用建模需要与基础设施供应商实现解耦，应用描述支持跨平台。

3. 支持应用快速接入

通过应用模型描述一个完整的应用，需要梳理应用关联的所有依赖，目前国际化应用依赖的弹性云计算资源和运维特征通过服务树进行了关联，存储资源和中间件与应用无直接的关联关系，例如应用依赖存储资源信息在业务代码中，需要通过人工梳理进行管理。我们需要对资源的申请、下线等关系变更进行管控，长期维护他们的关联关系，为应用与关联的依赖提供统一的观测视角。另外需要为存量应用提供高效的自动化工具，探测发现应用关联的依赖信息。

交付框架

1. 交付流程自动化

在之前历史建站过程中，每个应用交付涉及的依赖多，依赖交付还存在一定的先后顺序，甚至是部署数据依赖。比如，差异配置托管依赖存储资源的创建，并需要收集存储资源的链接信息，生成新机房配置文件。交付框架需要覆盖所有依赖类型的自动化交付流程，并对它们的控制逻辑进行统一的编排，并提供数据向下传递的通道，保证它们交付的顺序和结果符合预期。

2. 交付能力高可扩展集成

国际化业务依赖的计算资源、存储资源、中间件、运维特征等有几十种，每一个均由不同的团队维护，并通过白屏化管控平台提供了丰富的运维能力。交付框架需要提供对基础平台技术架构影响最小，对业务使用体验基本无损，迁移过程基本透明的低成本、高扩展接入方式。其次，国际化业务需要在多云环境中进行部署，需要屏蔽底层基础设施的差异，保证对应用是无感知的。

解决思路&挑战

针对以上业务目标，以及国际化业务架构的现状，我们得出如下解决思路：

建设符合滴滴业务现状的应用描述规范，并在国际化业务中落地实践。

1. 应用描述规范化：对国际化应用依赖的所有计算资源、存储资源、运维特征进行抽象，并建设标准配置文件描述应用与依赖之间的关系，提供应用所有工作负载的观测视角。

2. 应用依赖关联：对国际化应用依赖所有资源的生命周期进行管理，保证应用与依赖关联关系的有效性。其次，提供导入工具，支持对存量服务依赖的所有资源信息进行探测发现。

3. 应用描述管理：定期对应用所有依赖的信息进行同步，保证应用自描述配置的时效性。并对应用描述信息的发布版本进行管理，方便溯源和回滚。

核心技术挑战

1. 应用描述模板，除了需要兼容可变参数的依赖资源，还需要考虑在交付时可被解析识别。

2. 对于新增资源依赖可以方便的进行管控，重点需要考虑存量服务资源依赖的关联，尤其是不在业务代码中的游离资源。

3. 应用描述要感知各个资源依赖的运维配置的变化，保证高度的时效性和参考价值。

与基础平台协作共建应用依赖自动化交付能力，并通过工作流引擎编排应用的交付流程。

1. 交付工作流编排：国际化应用交付，是一个比较复杂的过程。交付流程，因为场景、环境等因素的不同而千差万别。通过自定义配置化工作流，灵活适配所有应用交付场景。

2. 交付能力接入：与基础平台协作共建，将所有应用依赖的自动化交付能力以可插拔的方式集成到平台中，应用灵活选择使用。

3. 交付流程管理：为应用交付提供标准化的操作流程，并对交付状态及结果进行管理

核心技术挑战

1. 业务对资源的使用方式是千差万别的，交付工作流引擎需支持交付子任务可以自由组合，编排交付顺序。

2. 要对应用与资源依赖的关系进行管理，需要重点考虑与基础平台职责怎样划分，需要集成哪些能力。

3. 交付流程除了建站场景，还需要考虑业务日常的迭代需求，降低接入和使用成本，尽可能减少对开发效率的影响。

技术方案

业务抽象

应用描述模板

Kubernetes 带来的云原生技术革命，在于实现了基础设施层的标准化和抽象，但这一层抽象距离业务研发与运维还是太过遥远，Kubernetes 里面没有 “应用” 这个概念，它提供的是更细粒度的 “工作负载” 原语，比如 Deployment 或者 DaemonSet。所以，几乎每个公司在落地云原生时，都会围绕各自业务特点，对Kubernetes进行不同程度的抽象，自定义丰富多样的能力以独立的 PaaS 形式对外提供服务，这就导致了所有围绕着这些 “应用” 构建出来的系统，就成为了一个又一个的大烟囱。在滴滴内部，也是通过这样的方式抽象了odin一站式运维平台、base平台等独立PaaS平台，计算资源、存储资源、运维配置在各个平台进行操作，应用信息分散、冗余，难以统一关联和管理。

我们调研了业内应用描述的方案，选择了可以满足国际化出行需求的OAM应用模型，它标准化了应用定义的规范。我们按照OAM的标准，将计算资源、存储资源等RD关注的资源抽象为component，将监控报警等SRE关注的运维特征抽象为Trait，他们之间可以自由组合构成一个完整的应用，并且声明式的描述方式可以支持在混合云环境进行交付。在此基础上，我们可以抽象出应用依赖拓扑，进而将应用、资源等元信息维护整合到应用维度，从而具备应用整体运转起来的完整依赖的统一视角。

OAM原生应用描述模板，要求对每个组件的参数进行预定义，对其参数类型、取值范围、含义等进行明确的描述和界定。这些参数会由所有业务方进行解析，前端需要这些参数渲染组件表单UI并按照组件参数定义生成应用描述模板，交付框架需要解析应用模板并识别每个组件的参数用于与基础平台等资源负责方进行交互，资源负责方需要通过组件参数执行组件业务逻辑。精确的参数定义确保了各业务方对组件有一致和准确的理解，但是组件精确定义需要花费较多的时间和精力来制定，难以灵活迭代和扩展，对线上的稳定性和组件日常研发效率都带来了较大的挑战。我们对OAM应用模板进行了个性化改造，抽象了组件通用描述模板，对组件个性化参数进行标准方式序列化和透传，将个性化参数的业务逻辑闭环在每个组件内部，实现各个业务方的解耦。

应用依赖关联

应用依赖全生命周期管理能力建设

目前国际化业务，应用与依赖的关联基本分为2种，一种为计算资源、运维特征，这部分依赖是通过应用NS组织的，天然与应用存在关联关系。第二种是存储资源，这些资源目前与应用无任何关联关系，需要通过将存储资源申请入口统一收敛来解决。

每一个资源的运维平台都提供了非常全面的运维能力，例如 MySQL 除了集群申请的能力，还有数据恢复、数据查询、权限管理等运维能力，要实现资源的全生命周期管理有2种思路：

由各个基础平台支持在创建资源时上报应用信息，并由基础平台维护应用与资源的关联关系。

将基础平台资源部分管理能力统一收敛到一个中间平台，所有申请、流转、下线在统一的入口操作，长期维护应用与资源的关联关系。

方案一不仅需要各个基础平台进行适配，而且需要对资源共享等业务需求进行适配；该方案与业务产生耦合，对现有基础平台架构影响大。方案二不是建设一个大而全的平台一刀切的将所有能力统一收敛，而是只关注对应用与资源关联关系会产生影响的能力，例如集群申请、集群下线，其他运维能力保持不变，通过原有的方式继续提供服务，中间层适配的方案，不管是对业务还是基础平台，影响都很小，所以我们在可信云原生技术委员会下通过FT的形式，与基础平台协作共建了应用中心，将资源生命周期管理的能力进行了统一的入口收敛，详情如下：

1. 应用依赖资源申请入口收敛

要进行资源申请入口收敛，需要先确认国际化出行服务都依赖了哪些资源，这些资源使用的频率是怎样的。在国际化出行多次机房建设过程中，已经通过人工梳理的方式沉淀了一些应用依赖资源的数据，根据这些数据，我们确定了依赖存储资源的范围：MySQL、Redis、MQ、ETCD 等，并按照优先级与基础平台协作，将申请入口迁移集成到统一的应用中心。例如MySQL资源，申请入口统一由基础平台通过弹窗引导到应用中心统一入口进行申请，建立应用与新增资源的关联关系。

2. 应用依赖资源关系流转

目前在国际化业务中，存在多个应用共享资源的场景，比如乘客特征数据，在进行发单、反作弊、交易撮合时都存在依赖。在进行资源关联时，我们抽象为了 2 种类型，一种为从属关系，代表该资源的 owner 以及成本为该应用；一种为绑定关系，代表该资源为共享使用的资源，该应用只有使用权限。

针对共享资源，应用中心提供了解绑、转交流程，支持应用依赖资源的关联关系流转。

应用依赖资源下线

我们在应用中心，将资源的下线入口也进行了收敛，保证在资源下线时，将应用与资源的关联关系解除。资源下线为业务成本治理提供了抓手，避免了孤岛资源的产生，将资源的生命周期管理进行了闭环。

应用依赖探测

进行应用与资源依赖关联关系的建立，更大头的工作集中在存量资源的治理。除了人工梳理代码的方式，我们来看看有哪些其他抓手可以自动化进行关联：

1. 代码扫描：通过对业务的代码库进行扫描分析，尤其是配置文件，识别应用代码库中配置的资源的信息。目前国际化业务技术栈不统一，有 php、java、golang、C++等，另外配置方式也多种多样，存在 yaml、toml、json 等多种形式，开发迭代难度大，准确度也难以保障。

2. CAC：在《深度拆解滴滴国际化建站提效利器：环境差异配置管理》中介绍了集群差异配置托管的 CAC 方案，该方案由 RD 进行人工一次性改造，结果经过了 RD 人工确认，而且配置进行了规范化，可以依赖这部分数据创建应用与资源的关联关系。但是 CAC 方案推广进度难以保障，无法完全依赖。

3. Metric：通过资源平台上报 metric 的方式，将与资源产生链接的来源 ip 信息上报，然后对 metric 数据进行统一清洗与分析，创建应用与资源的关联关系。目前由于各个资源方上报 metric 格式不统一，数据清洗需要个性化支持，存在一定的开发成本。

4. EBPF：ebpf 技术具有很大的灵活性，本身支持多种 hook 点，可以在业务不进行代码变更的前提下，实现对服务调用关系的采集。借助 ebpf 对 uprobe 的 hook，能够获取服务在响应请求后的调用逻辑，进而获取 [caller, caller_func, callee, callee_func] 的服务响应-调用四元组，进而创建应用与资源的关联关系。ebpf 方案也存在一些问题，对一些低频调用难以发现，并且受限于 ebpf 方案在业务中的推广进度。

经过对以上方案评估，最终选择了 metric+ebpf 协作的方案进行应用与资源的关联关系探测。Metric 数据准确，但是覆盖资源类型有限（MySQL、KV），以ebpf 数据作为补充。

在国际化业务落地过程中，我们在核心主流程所有应用模块推广接入了《深度拆解滴滴国际化建站提效利器：环境差异配置管理》方案，在进行应用与依赖关联关系创建时，我们优先使用人工梳理确认的CAC数据，对于未接入 CAC的服务模块，使用 metric+ebpf 的资源探测方案。

应用描述管理

应用模板以及应用依赖信息就可以完整的描述一个应用了，但是由于滴滴资源管理平台现状，我们无法每个资源组件日常运维的入口都进行收敛，所以经过一段时间的运维之后，应用描述信息与线上资源实际的信息会存在一定的GAP，我们需要定期对每个组件的信息进行同步，保证应用描述的实时性。由于组件日常运维以及应用交付的频率是比较低的，所以我们同步的频率是以天为粒度的，并将组件信息存储与MySQL，可以加速应用中心管理平台的使用体验。生成的应用描述信息则保存在了gitlab中，gitlab可以轻松存储、跟踪代码和更改配置文件，并进行版本管理；可以帮助我们提高发布质量，可以快速比较不同版本的配置文件的差异，如果出现了Bug也可以跟踪发现问题的根源。

交付框架

OAM的工作原理如下图所示，OAM Spec 定义了云原生应用的规范，OAM规范解析器将应用定义解析为Kubernetes或其他云服务（例如 Istio）中的资源对象。可以将下图分为三个层次：

汇编层：即人工或者使用工具来根据 OAM 规范定义汇编出一个云原生应用的定义，其中包含了该应用的工作负载和运维能力配置。
转义层：汇编好的文件将打包为 YAML 文件，由OAM 的实现将其转义为 Kubernetes 或其他云服务（例如 Istio）上可运行的资源对象。
执行层：执行经过转义好的云平台上的资源对象并执行资源配置。

经过业务抽象过程，已经完成了应用交付描述文件的生成，交付框架核心要解决交付描述文件的解析，以及资源对象的执行。

交付引擎

交付引擎基于OAM规范驱动了应用描述解析为资源对象或者自定义资源对象，以及这些资源的交付。我们首先考虑的是将应用交付流程集成在滴滴内部现有的CI/CD工作流中，对应用的准入、日常迭代发布、下线等流程进行全生命周期管理。下面我们看下现有的CI/CD工作流能够支持哪些业务场景。

流水线由「阶段」和「任务」构成，多个「阶段」串联组成一条流水线，每一个阶段可以由多个「任务」组成，同一个阶段的任务可以「串行」也可以「并行」如下图。流水线除了提供任务编排和基本的任务执行能力，还提供外部插件的集成能力。

但是通过对国际化服务依赖的所有资源及使用现状分析后我们发现，现有的CI/CD流水线和应用交付框架的目标存在较大的差异。首先CI/CD流水线是一个针对应用架构以及业务日常变更需求的相对固定的工具集合，无法适配业务日常迭代过程资源灵活变化高度可扩展的需求。其次，CI/CD流水线的交付模型，是按照阶段维度串行执行，阶段内部任务串行或者并行的执行流程，与应用交付顺序任意编排组合的需求也不太匹配。最后，外部自定义插件，支持的UI组件比较单一，无法适配现有的各类资源组件的展示需求，影响后续的平台迁移成本。

然后我们调研对比了业内的一些OAM规范的落地产品，例如Argo CD、Crossplane、Kubevela等，根据它们的功能特性、集成能力、社区和生态、学习成本等因素，最终采用了基于阿里云开源的基于 OAM 模型的云原生应用交付平台——KubeVela 进行定制化的建设方案，核心原因如下：

1. 声明式交付：KubeVela 是基于 K8S 实现的，因此在 KubeVela 中的应用交付是面向终态的，交付人员给出应用描述后，它可以保证交付至应用所需状态，这样可以降低用户的使用门槛以及底层 API 的复杂性。同时也方便后续与 GitOps 结合，以代码的方式对应用状态进行常态化管理。

2. 基础设施无关：虽然 KubeVela 是基于 K8S 实现的，但是它只使用了 K8S 的控制平面，具体的交付目标环境是不做限制的，因此适用于滴滴目前的自建机房架构，也同样适用于公有云的云原生技术体系，迁移过程对于用户也是透明的。

3. 高度可扩展：KubeVela 中各类依赖组件的交付支持都是通过 CUE 语言进行定义的，非常容易适配当前滴滴内的各个资源组件，且交付能力的拓展非常方便，同时也支持与 IAC 能力的结合，方便对多云环境的资源进行透明交付。

Kubevela是完整实现了OAM模型的云原生平台构建引擎，模块是Kubevela的基本扩展能力单元，它将底层的能力封装抽象为模块，使得这些能力可以被用户快速理解、使用并和其他能力组装、衔接，就像搭建乐高积木一样构成一个具有丰富功能的业务应用。我们可以基于业务最佳实践将滴滴内部各类资源组件抽象为Kubevela模块，为上层开发者屏蔽底层细节以及多云间差异，做到应用交付与基础设施无关，而又保留灵活的扩展性。KubeVela 是使用 CUE 配置语言来编写自定义模块的，一个模块定义包含输入、输出、操作以及这三者之间的衔接关系，底层通过kubernetes Operator设计实现。kubernetes Operator是一种特定应用的控制器，可以扩展kubernets API的功能，来创建、配置和管理复杂应用的实例。我们基于kubernetes Operator对kubevela的能力进行了深度定制化，将所有资源组件抽象和规范化为了通用组件，并将组件执行的业务逻辑抽象到了组件市场，由资源组件方自由开发和发布，打造应用交付研发生态。下面我们来详细看下交付能力是怎样集成到组件市场的。

交付能力接入

组件抽象

在进行交付能力集成时，通过 openapi 与基础平台进行协作，往往难以及时跟进基础平台的功能迭代，尤其是 openapi 协议变更，可能会导致交付能力失效。所以我们建设了组件市场，为公司内部各个基础服务提供产品定义及注册，比如MySQL、Redis等组件负责人在组件市场定义自身服务能力，并负责组件功能维护及底层多云适配等，并通过可插拔的方式提供能力给到应用中心，由业务研发人员根据自身服务需求在应用中心编排资源、组装功能，从而对外提供服务；

组件UI标准化：组件市场，针对所有类型组件的可扩展性，在满足各组件可变输入参数项的情况下，为了实现较为原生的UI体验，设计了的UI-Schema规范，并提供了组件参数白屏化自定义能力，支持自动化生成相应的UISchema，并在应用中心自动化渲染。例如如下灰度发布元素，通过自定义slider，可以自动化渲染“滑块”前端页面。

组件交付控制器标准化：定义了组件增删改查的标准协议，接入kebevela的组件只要实现了apply, query, delete 三个声明式接口，就可以以可插拔的形式集成到应用中心，由应用中心通过声明式的方式不断调谐，实现组件的自动化交付。例如，资源创建协议如下，将组件自定义可变参数序列化，并通过properties参数进行透传，资源交付逻辑收敛在组件交付控制器内部，与应用中心交付框架完全解耦，应用中心可以通过可插拔的方式任意扩展交付能力。

组件接入

我们在组件抽象中对组件集成到交付框架中进行了规范化，下面我们通过一个具体的例子，介绍下组件是怎样进行接入的。

在《深度拆解滴滴国际化建站提效利器：环境差异配置管理》中介绍了 CAC 方案，在新机房交付前，我们对国际化出行技术团队进行了 CAC 的推广，对所有存在机房差异配置的服务进行了托管和规范化，并将新机房配置生成的能力通过bizconf组件集成到了交付框架中，在资源完成自动化申请之后可以获取资源的链接信息，自动化按照标准的格式，生成新机房的配置。

组件UI设计

我们通过组件市场，提供了组件自定义参数的能力。但是bizocnf组件中定义的应用依赖的资源的链接信息等机房间差异配置，每个应用的配置是存在差异的，无法通过在组件市场提前进行预定义。我们为bizconf组件定制化提供了动态UI-Schema的能力，我们通过gitlab openapi可以获取托管在独立库中的集群差异配置，并以此作为该应用bizconf的需求参数，然后通过反射获取每个参数的类型，并匹配相应类型的UI元素，并且我们预定义了CAC标准配置的每个元素的提示信息、预填充等信息，如下：

固定值，不允许修改：例如进行服务发现的应用或者资源唯一标识，在多机房间是相同的，可以使用主机房的值克隆，并且不允许修改，从流程上保障一致性。
动态值，可修改：例如对下游资源依赖的超时配置等，在多机房间由于网络或者机房位置可能存在一定差异，默认使用主机房值克隆，并提供更新调整能力。
差异值，自动化生成：存储资源的链接信息，例如 MySQL 的 VIP 以及账号密码信息，在资源自动化创建完成后，可以自动化获取并按照标准格式填充。
差异值，不可生成：例如机房 inrouter、应用个性化配置等。这些配置没有标准的值，需要 RD 人工输入，提供人工填充的入口，并可以交付前进行收集映射，保证配置最终自动化生成。

基于以上，可以动态渲染bizconf组件的UI-Schema。

组件交付逻辑

bizconf组件交付的核心逻辑是收集所有新创建资源的链接信息，并按照标准化的方式生成新机房的配置文件。bizconf组件会通过交付流程编排的方式，保证在MySQL、Redis、MQ等存储资源类组件执行完成后再执行，并通过数据通道获取它们的交付结果，获取每个存储资源的链接信息。在新机房交付时，会将新生成的配置代码提交到配置库中，新增的机房配置虽然在后续业务迭代过程中会打包到镜像中，但是业务逻辑库无变更，并且没有对新机房配置文件的直接引用关系，我们认为在该状态下，直接将应用部署到新机房不会对其他机房业务产生任何影响。基于以上考虑，我们与 CI/CD 平台进行了协作，在新机房配置生成后可以自动化发起应用编译打包，将新提交的配置构建一个新机房的应用镜像，并自动化部署到新机房。考虑到国际化业务对 CI 流水线使用的多样性，在流水线中可能配置了个性化的环境变量，在自动化编译时，我们对主机房线上的业务镜像中的交付物进行了解析，获取了业务的流水线参数，并在新机房编译时进行了复用，保证了编译环境和线上的一致性。

交付流程管理

交付工作流定义了一个应用以及依赖资源组件的交付计划，可以帮助我们自定义交付计划中的步骤，粘合所有资源依赖的交付流程。简而言之，工作流提供了定制化的控制逻辑，在原有 Kubernetes 模式交付资源（Apply）的基础上，提供了面向过程的灵活性。比如说，使用工作流实现条件判断、暂停、状态等待、数据流传递、多环境灰度、A/B 测试等复杂操作。

我们按照国际化出行业务架构，将依赖的所有组件类型的交付顺序进行了编排。例如，集群差异配置管理bizconf组件，依赖于所有存储类组件的交付；弹性云计算资源组件，依赖于通过bizconf组件生成新机房配置。基于这些业务架构，我们定义了通用的应用交付工作流，并基于KubeVela 中的 Inputs 和 Outputs 在工作流步骤间进行数据传递，这样应用可以按照DAG的顺序自动化执行。

然后，我们也在交付流水线中，需要观测每个组件的交付状态。获取组件交付状态主要有两种方式，第一种是组件在交付完成后通过回调的方式上报组件最终交付状态，第二种是应用层通过轮训的方式不断刷新交付状态。对于第一种组件上报的方式，由于应用交付过程中涉及的链路比较长，可能未到组件交付过程就已经失败，该状态无法上报到应用中；其次为了保障交付状态上报的确定性，还需要引入消息队列等其他依赖；最后，该方案基础层组件交付对应用层交付状态的管理产生了耦合，增加了运维成本。基于以上这些因素考虑，我们最终选择了第二种方案，通过kubevela声明式的交付方式，不断调谐获取组件的交付状态，并在交付工作流中展示每个组件的交付细节。