10.3.4 OAM 与 KubeVela
2019 年 10 月，阿里云与微软在上海 QCon 大会上联合发布了全球首个开放应用模型（OAM，Open Application Model）。该项目有两个部分：OAM 规范以及 OAM 规范的 Kubernetes 实现。
在 OAM 的规范中，应用由一组具有运维特征（Trait）的组件（Component）组成，并且限定在一个或多个应用边界（Application Scope）内。上述并非是完全抽象的概念，而是可实际使用的自定义资源（CRD）。这些概念的具体含义如下：
- 组件（Component）：只要有编程经验的人，应该都知道组件的含义，组件是应用的基本构建块，具备可复用性，用于定义核心功能单元。在 OAM 中，每个组件代表一个独立的、可部署的微服务或资源（例如：数据库、缓存、API 网关等）。
- 运维特征（Trait）：既然应用功能可以复用，那某些运维逻辑自然也可以封装复用。运维特征是可以随时绑定给待部署组件的、模块化、可拔插的运维能力，比如：副本数调整（手动、自动）、数据持久化、 设置网关策略、自动设置 DNS 解析等。
- 应用边界（Application Scopes）:定义应用级别的部署特征，比如健康检查规则、安全组、防火墙、SLO、检验等模块。相对于运维特征而言，应用边界作用于一个应用的整体，而运维特征作用于应用中的某个组件。
- 应用（Application）：将 Component（必需）、Trait（必需）和 Scope（可选）组合并实例化，形成了一个完整的应用描述。
OAM 通过上述自定义资源将原本复杂的 Kubernetes All-in-one 配置进行了一定程度的解耦。应用研发人员负责管理 Component，运维人员将 Component 组合并绑定 Trait，形成 Application。平台或基础设施提供方则负责 OAM 的解释能力，将这些自定义资源映射到实际的基础设施上。各种角色的关注点恰当地分离，不同角色更聚焦更专业的做好本角色的工作。
整个过程如图 10-3 所示。
图 10-3 OAM 工作原理
KubeVela 是 OAM 规范在 Kubernetes 上的完整实现，它起源于 OAM 社区，由阿里巴巴、微软等技术专家共同维护。
对于平台工程师（Platform Builder）来说，KubeVela 是一个具备无限扩展性的 Kubernetes 原生应用构建引擎。他们负责准备应用部署环境、维护稳定可靠的基础设施，并将这些基础设施能力作为 KubeVela 模块注册到集群中。对于最终用户（End User，研发人员或运维人员）来说，只需选择部署环境、挑选能力模块并填写业务参数，就可以在不同运行环境上把应用随时运行起来！
KubeVela 工作流程如图 10-4。
图 10-4 KubeVela 工作原理
企业落地 Kubernetes 的难题
很多企业落地 Kubernetes 的时候采用了 “PaaS” 化的思路，即在 Kubernetes 之上，开发一个类 PaaS 平台。但这个平台设计理念、模型和使用方式往往都是自己的，这些设计会“盖住” Kubernetes 的能力，使其声明式 API、容器设计模式、控制器模式根本无法发挥原本的实力，也难以与广泛的生态系统对接。
上述问题的直接表现就是，这个 PaaS 系统不具备扩展性。假设我们要满足以下诉求：
- 能不能帮我运行一个定时任务
- 能不能帮我运运行一个 MySQL Operator
- 能不能根据自定义 metrics 定义水平扩容策略
- 能不能基于 Istio 来帮我做渐进式灰度发布
这里的关键点在于，上述能力在 Kubernetes 生态中都是常见且广泛支持的，有些甚至是 Kubernetes 内置功能。但是到了 PaaS 这里，要实现这些能力往往需要重新开发，而且由于先前的设计假设，可能还需要进行大规模的重构。
KubeVela 本质上是在 Kubernetes 上安装了一个 OAM 插件，使平台工程师能够依据 OAM 规范，将 Kubernetes 生态中的各种能力和插件整合成一个应用交付平台。所以说，KubeVela 为最终用户提供了类似 PaaS 的使用体验，同时也为平台工程师带来了 Kubernetes 原生的高可扩展性和平台构建规范。
不过，目前来看，KubeVela 背后的理论还是过于抽象，落地有一定的技术门槛！但 KubeVela 这种构建以”应用为中心“的上层平台的思想，毫无疑问代表着云原生技术未来的发展方向！