摘要：近几年，云原生平台已发展得比较成熟，而云原生应用的概念也在许多公司得到实践。其中，以阿里巴巴和微软提出的 OAM(Open Application Model) 概念得到了最广泛的认可，也在 CNCF（云原生计算基金会）社区孵化出项目 KubeVela，为云原

背景

近几年，云原生平台已发展得比较成熟，而云原生应用的概念也在许多公司得到实践。其中，以阿里巴巴和微软提出的 OAM(Open Application Model) 概念得到了最广泛的认可，也在 CNCF（云原生计算基金会）社区孵化出项目 KubeVela，为云原生应用的开发与交付提供了新的思路和框架。

基于KubeVela的理念，我们公司启动了应用中心平台的开发工作，经过多轮迭代与优化，应用中心平台在公司内部全面落地，并在混合云交付、多活治理及下下线三个关键场景中发挥了重要作用，极大地提升了应用管理的效率与灵活性。

在平台的建设发展过程中，我们面临了大量产品设计、工程实践与平台推广的挑战，凭借团队的协作与创新，我们逐一攻克难题，达成了诸多里程碑式的目标。本文将围绕应用中心平台发展的四个阶段，详细阐述我们在混合云交付到多活治理这一云原生架构蜕变之旅中的实践经验和心得体会。

概念入门 - OAM与KubeVela

OAM 的官方示意图如下，是对Application在抽象层面的描述：

Application 由 Components 和 Trait 构成，即 部署视角的组件+运维视角的特征；

以 Application 的维度，统一部署到各平台上。

而 KubeVela 的官方示意图更偏向于流程式的，实践了CICD、GitOps、Paas等多种理念（参考下图）。

官方文档对KubeVela的核心定义为：KubeVela is a modern software delivery and management control plane. The goal is to make deploying and operating applications across today's hybrid, multi-cloud environments easier, faster and more reliable.

这里强调了三个关键词：

功能：交付与管理；

定位：控制平面；

面向场景：混合云、多云。

第一阶段 - 打通KubeVela为核心的交付链路

在项目成立之初，我们要解决的核心问题与KubeVela的设计目标高度一致 - 支持混合云场景下的快速交付，所以选择了以 KubeVela 为核心，搭建了整条交付链路，我们称此阶段为 应用中心V1。

V1架构分析

平台主要分为四层：

应用管理- 用户交互的数据展示层，包括两部分功能：

应用定义：定义应用的相关依赖资源，如计算资源、存储资源、相关配置等；

应用交付：将应用交付到混合云的某个环境；

资源交付编排- 根据应用所依赖的资源与云环境的特点，编排整个交付过程

KubeVela- 完全复用开源社区的KubeVela：根据编排结果，对资源Operator调度

各资源Operator（也叫AddOn）- 实现资源交付的最小颗粒度，KubeVela官方给出了大量现成插件

V1交付示例

为了方便大家理解，这里以一个用户的交付过程为例，串联整个交付过程：

用户在 应用管理定义自己的应用，包括了 一个Git库、一个弹性云集群、两个MySQL数据库、一个Redis缓存、配套监控

用户在交付前，填写必要参数，指定将这个应用交付到某个新机房

交付编排根据平台能力，将整个交付过程定义成一个有向无环图（如下图）；

KubeVela收到上游的编排结果，根据顺序对 各资源Operator 进行调用，直到全部完成；

用户在 应用管理得知交付完成。

V1局限性分析

本阶段的应用概念实践了社区中 先定义，再交付的理念，完成了整套产品的落地。但是，V1版本的平台所应用的场景非常有限：

应用的范围少：只面向新增的服务，大量的存量服务无法自动接入平台；

应用的覆盖生命周期短：接入的应用在初次交付后，下游依赖因各种原因发生变更，平台无法自动感知到变化。

为了进一步提高平台的使用场景，我们明确了下一阶段的目标：接入公司的存量数据。

第二阶段 - 适配存量数据的应用同步体系

我们阅读了原KubeVela相关资料，也咨询了开源社区的部分团队，并未找到一个接入存量数据的最佳实践。

我们项目内部也反复讨论，依旧决定走通存量数据这条路，也是为了让产品有更广阔的空间：

提高用户的使用体验：自动打通存量应用数据，让用户能尽可能平滑地迁移到云原生应用的理念；

应用数据可持续化管理：在应用交付后的维护期间，自动地更新数据，减轻用户的梳理成本，也规避稳定性上的问题。

V2架构分析

从架构来看，变动主要是新增了一条同步链路：

整个平台的数据链路分成了两个部分：

自顶向下的交付链路

自底向上的同步链路

这两条链路的定位、功能特性上有不少差异：

交付链路：交付用户所声明的相关内容，主要是创建类指令性的传递、编排

同步链路：客观地描述整个软件环境的运行现状，反映长期的、真实的应用状态

应用概念升级

在改造过程中，产品形态基本保证了前后兼容，但底层的应用概念有了很大的调整。下面从3个用户使用的体验来描述：

应用定义更简单

V1：很重，需要完整地描述一个标准化的应用，包括相关依赖、配置等；

V2：轻量级，应用更多的是一种虚拟的、规范性的定义，更详细地定义放在集群维度。

集群交付更灵活

V1：以应用定义的为标准，交付出一个集群，支持少量调整项；

V2：在应用下新增或以一个存量集群为标准进行克隆，非常灵活。

集群信息准确，提高持续交付的质量

V1：交付完成后不再更新集群信息，下次交付时，用的仍是上一个交付记录的数据，经常存在数据过期的问题；

V2：交付完成后，周期性自动更新集群信息，交付失败概率大幅下降，稳定性也得到提高。

V2交付示例

对应上述功能，此时应用中心对用户侧的体验如下：

新建交付：将定义依赖资源调整到了集群交付时的动作，不再作为前置规范；

集群克隆：将全量定义的过程，调整为按需调整少量参数的过程，至少减少了90%的梳理与配置的工作，包括交付的资源范围：根据源集群所使用的资源，按需增减；交付的资源配置：根据业务需求，调整名称、规格等参数。

推广的两大利器

为了接入存量数据，应用中心的核心框架已逐渐脱离KubeVela，而只把KubeVela作为交付过程中的关键组件。此时，为了支撑V2版本的使用与体验，我们也建设了两项关键性的能力：集群克隆与资源探测。

资源探测 - 自动绘制集群使用资源的关系

一个集群使用了哪些MySQL、Redis、MQ等产品，对于熟悉相关代码的开发同学来说，做一次梳理还是比较容易的，但长期维护时会遇到各类问题：

代码变更，导致新增或删减某个依赖

服务交接，接手的同学不了解相关实现

未直接体现在代码配置里的依赖

因此，我们联动了各存储与可观测平台，搭建了一套资源探测的链路，通过数据清洗和状态机等技术，自动地绘制出每个集群使用资源的情况，综合准确性超过了95%，核心存储更是超过了98%。

通过资源探测绘制的关系，我们能自动梳理出集群依赖的资源，相当于生成了一种集群层、数据真实可靠的OAM模型，既减少了人工梳理的工作量，又能根据真实的环境自动更新数据。

集群克隆 - 应用下的集群间差异化管理

KubeVela虽然有对集群间差异化配置的设计，但篇幅很少，也没有找到相关的Best Practice。

而对于存量的线上服务，如果我们希望推广整个应用中心产品，肯定不能走 先做改造到标准化应用，再进行交付这种思路，而是必须让产品能自动兼容存量数据。我们观察了线上多集群间的差异，虽然有部分是不规范的配置所导致的，但还有相当一部分差异是合理的：

集群间的功能定位有差异

不同机房的业务系统定位有差异

不同机房的基础设施有差异

在明确集群差异是长期存在的前提下， 同一个应用下的多集群数据天然就是有差别的，过多地强调应用层的标准化反而不利于平台功能。于是，我们将许多应用层的标准下降到集群层面。

此时，集群的交付主要就包括2种场景：

全新集群交付：根据业务需求完整填写必要信息，再发起交付；

集群克隆交付：默认根据源集群的数据1:1交付，可人工根据业务特点调整差异性项。

集群克隆功能上线后，超过80%的存量应用都使用这种模式交付，既减少了对源集群的梳理这项工作、又能根据需求灵活调整。

V2的局限性分析

V2阶段的应用中心很好地解决了存量数据的问题，也大幅拓宽了使用面。但是，V2层面的模型有个比较大的局限性：

为了反映真实的服务运行情况，将模型概念落在了集群层、而不是应用层。当一个应用包含多个集群时，集群间的差异化过多，导致从架构规范视角来看，无法识别哪些差异是合理的、哪些差异是需要治理的。

第三阶段 - 打造标准化的应用管理

通过V2阶段的打磨，应用中心的数据已经能客观地反映了线上服务真实的运行情况。

随着平台的演进，我们将目标不仅仅定义为交付，而是规范交付，这里面最大的挑战就是要去识别和落地 规范 这个概念。

V3架构分析

为了支持更复杂场景的应用管理，整个架构重点在三块做了升级：

新增模型管理模块，重点是对规范的定义、识别与应用

引入自研的流程引擎，支持更复杂的流程调度能力

数据同步新增离线同步链路，让应用的数据更完整

为什么逐渐弃用KubeVela

在这个版本，我们纠结许久，最终决定将Vela从核心链路中逐渐移除。

由于平台自身的定位限制，在迭代的过程中，应用中心与KubeVela的发展方向有诸多分歧：

无法全生命周期管理：KubeVela期望以声明式API来管理应用的全生命周期，打通CICD；但是，应用中心平台短期内无法替代原来各平台的入口，为保证稳定性，需要进行兼容；

Vela大量的Addon都无法复用：KubeVela最大的提效点在于复用Addon（Operator），尤其是支持了丰富的开源产品与公有云产品，但公司内有诸多安全、权限、成本等限制，无法使用；

自研的Operator/Addon维护成本很高：在对接各类公司内的平台时，为了保证交付到用户手上的是一个正确的、可用的产品，不仅仅是需要对接创建接口，还需要对接包括 认证、权限、审计、配额、成本 等特性，也需要适配下游平台的变更，成了整个项目中维护成本最高的模块；

于是，从长期来看，KubeVela在平台中的地位越来越弱：

当前用到的KubeVela功能很有限：整个KubeVela框架在平台中的核心能力就剩下了工作流，而这个工作流的实现机制也不复杂；

长期发展不适配KubeVela框架：平台计划支撑更为复杂的多活场景的交付，例如多活的MySQL与Redis，现有框架很难支撑；

于是，我们计划将工作流部分也逐渐迁移到自研模块上，脱离了原生的KubeVela服务。尽管我们弃用了KubeVela，但整个框架依然遵循KubeVela的设计思路，也非常关注社区内的相关进展。

应用模型与OAM有什么差异？

在V3版本，我们推出了一个全新的功能 - 应用模型（参考下图）。

从产品效果来看，应用模型与社区里OAM的许多理念都是重合的，但在实践路径上有很大差异：

OAM强调的是自上而下的规范化交付

应用模型强调地是自下而上的收集数据，展示多集群的实际使用情况

为了推广应用模型这个产品，我们重点建设了两个配套功能：

降低接入门槛：自动化地分析并生成模型数据；

保障数据准确性：通过多平台协作，长期维护整个模型数据准确。

V3交付示例

在V3阶段，新建交付与集群克隆的场景与前面基本一致，我们重点引入了模型交付的功能。

在模型交付的场景下，我们引入了应用层面的模型规范概念，加强了对多集群管理。

在定义应用时，明确模型规范的保障范围：往往是业务线上的多个核心集群

在交付时，保障多集群的架构一致性

为什么我们要推广V3

应用中心V3所推出的 模型功能，标志着应用中心从 单集群的一维视角，迭代到 多集群的二维视角。

随着维度的提升，产品所包含的信息量也大幅增加。从应用的管理角度来说，我们希望多集群之间是 同构的。这里的同构主要体现在模型中的每一行。以下图中红框标记的Redis为例：

名称定义为order - 说明这个Redis的大致功能是作为订单的缓存；

三个集群使用的redis产品。

a.机房A预发使用Redis order_pre - 独立，与线上环境隔离；

b.机房A线上和机房B线上使用Redis order - 共用一套缓存（存储底层是否双活并未表示）。

通过自动生成与人工辅助梳理的方式，我们不断提升模型数据的准确性。而当数据基本一致后，自然就形成了一个OAM视图。

兜兜转转一圈，我们最终走回了OAM预期的线路，为后续应用的多活规范完成了能力的铺垫。

V3的局限性分析

在调研时， 应用模型功能的反响呈两极化：

对习惯于单集群视角的开发，模型功能显得冗余

对参与多活建设的开发，则是提供了清晰的、多视角的产品，把控规范

于是，应用模型当前仅在多活场景下推广。

从软件架构视角来说，我们希望尽可能减少集群间差异带来的复杂度，最终呈现到研发面前的效果为：像维护单个集群一样地维护多活集群。而在当前阶段，我们做到了让研发看清多活集群的架构现状，而并未解决降低维护复杂度的难题。

第四阶段 - 多活场景的交付与治理

随着应用模型推广和实践，我们也进入了最为复杂的阶段 - 深度介入多活场景的交付与治理。

这一阶段，要解决的难题有许多，较为突出的是：

如何实现各种资源（MySQL/Redis等）的多活交付，并呈现给用户

如何定义和发现多活架构中的可能存在的风险项，并推动治理

如何控制不合理的变更，保证多活架构的稳定性、可持续性

V4架构分析

当前，应用中心正处于V4阶段的前期。我们将功能迭代聚焦到了模型侧的规范，主要分为两类：

交付链路 - 阻塞类规范，必须满足规范要求，侧重于高风险的规范

治理链路 - 提醒类规范，根据应用当前数据进行判断，是否需要治理交由用户决定

资源的多活交付

多活场景下的交付，计算类资源的交付通常较为简单，往往独立出一个新的容器集群即可，较为复杂的往往是依赖资源的多活交付 - 例如存储类的MySQL、Redis。

以Redis多活为例，由于业务方案、研发代码等差异，Redis所呈现出来的双活效果会分为多种，如数据同步方式、存储容量、读写方式等。每个维度都提供了多种选项，重重组合后，交付的方案呈几何倍数扩增。在推广的过程中，我们主要关注两块能力的建设：

资源多活的产品化：对于很多研发同学来说，会更聚焦于自己的服务怎么使用存储，而并不希望过多地了解依赖资源的底层实现细节。于是，我们和资源平台打造了更为通俗易懂的产品形态，降低研发的使用门槛。

易扩展的软件架构：多活资源的交付不再以的一个Operator/Addon角度进行维护，而是和流程引擎的编排功能进行组合。例如，可以将一个主从Redis的申请，改造成两步：两个机房各申请一个Redis，然后建立数据同步链路。

模型规范的复杂度

当我们在多活项目中推进模型规范时，遇到了一个很大的挑战 - 规范无法一概而全，需要不断适配。例如：

成本限制- 因成本限制，在备份机房中的计算资源与存储资源往往会出现裁剪

非核心依赖- 对非核心依赖的一些依赖项，经过梳理与评估，在部分机房会进行降级

基础设施变更- 如因云厂商、网络等底层差异，导致部分技术选型上存在差异

业务目标差异- 如不同机房承载的流量有差异，导致容量上的差异；

所以，相对于如何判断规范，根据场景，制定合理的规范更加复杂：不仅仅要求开发人员掌握各基础产品，更是需要熟悉不同业务系统的特点。在这个方向，我们和多个业务架构组深度合作，仍在不断探索最合适的方案。

其余相关方向

在应用中心整个迭代过程中，我们也和公司多个平台与项目组合作，将平台的影响力进一步扩大。

平台能力扩展

下线流程（稳定性方向）- 下线SOP流程化，支持日常的服务下线（包括资源下线、配置清理）

建站中心（大规模交付方向）- 支持大规模新机房交付时的依赖梳理、交付过程编排与集群状态验证

应用负责人（元信息方向）- 将应用作为软件资产，在公司人员流动场景下保证归属准确

跨平台合作

成本归属（FinOps方向）- 将资源的申请/销毁与负责成本管理的平台打通，保证各类资源的成本归属到正确的业务方

配置托管（交付方向）- 将集群依赖的资源配置详情提供给业务方，自动生成配置文件，实现新集群交付时无需人工修改

各架构团队（交付、治理等方向）- 对于业务特性较强的需求，通过与业务架构团队的数据互通，助力达成目标

小结

应用中心在滴滴历经了两年多的打磨，经历了新机房交付、成本治理、老旧服务下线等项目契机实现了快速发展，已在服务的交付、治理和下线三个领域落地。尤其是在新机房交付的场景中，围绕着应用中心 资源探测和集群克隆这两个核心能力，交付效率提升超过了60%。

我们理解，云原生应用强调的是一种理念与趋势，在公司内的实践时必须结合现状进行评估 - 应用中心并非滴滴云原生应用的最终产物，但一定是里程碑式的一个产品。

来源：纵览全局