开放模型OAM

开放应用模型（OAM）：全球首个云原生应用标准定义与架构模型-阿里云开发者社区 (aliyun.com)

OAM · Kubernetes 中文指南——云原生应用架构实战手册 (jimmysong.io)

kubernetes作为容器编排领域的事实标准，成功推动了诸如阿里云kubernetes（ACK）等云原生服务的迅速增长。但同时我们也关注到，Kubernetes的核心API资源比如Service、Deployment等，实际上只是应用的不同组成部分，并不能代表一个应用的全部。也许我们可以通过像Helm charts这样的方式来表达一个可部署的应用，可一旦部署起来，实际运行的应用中依旧缺乏以应用为中心的约束模型。这些问题都反应出，Kubernetes以及云原生技术栈需要一种以应用为中心的API资源来提供一个专注于应用管理的、标准的、高度一致的模型，这个API资源可以代表完整运行的应用本身，而不仅仅是应用模板或者一个应用的几个组成部分，这就是今天阿里云与微软宣布联合推出开放应用模型Open Application Model （OAM）的原因。

项目地址：https://oam.dev/

什么是Open Application Model

OAM是一个专注于描述应用的标准规范。有了这个规范，应用描述就可以彻底与基础设施和管理应用的细节分开。这种关注点分离（Seperation of Conerns）的设计好处是十分明显的。举个例子，在实际生产环境中，无论是Ingress，CNI，还是Service Mesh，这些表面看起来一致的运维概念，在不同的Kubernetes集群中可谓千差万别。通过定义域集群的运维能力分离，我们就可以让应用开发者更专注于应用本身的价值点，而不是“应用部署在哪”这样的运维细节。此外，关注点的分离让平台架构师可以秦松地把运维能力封装成可被复用的组件，从而让应用开发者能够专注于将这些运维与代码进行集成，从而快速、轻松地构建可信赖应用。Open Application Model的目标简单的应用管理变得更加轻松，让复杂的应用交付变得更加可控。

应用组件（Components）

在OAM中，“应用是”由多个概念共同组合而成的。第一个概念是：应用组件（Components），它是整个应用的重要组成部分。所以说，应用组件既可以包括应用运行所依赖的服务：比如MySQL数据库，也包括应用服务本身：比如拥有多个副本的PHP服务器。开发者可以把他们写的代码打包成一个组件，然后编写配置文件来描述该组件与其他服务之间的关系。应用组件的概念，让平台架构师能够将应用分解成一个个可以被复用的模块，这种模块化封装应用组成部分的思想，代表了一种构建安全高可扩展性应用的最佳实践：它通过一个完全分布式的架构模型，实现了应用组件描述和实现的解耦。

应用部署配置文件（Application Configuration）

为了让这些应用组件描述变成一个真正运行起来的应用，应用运维人员会通过一个专门的、包含了虽有应用组件信息的部署配置文件来实例化这个待运行的应用。这个配置文件本身也是OAM规范中的一个生命式API，用来让运维人员能够根据开发者平台提交的应用描述，实例化出对应的、真正运行起来的应用。

应用运维特征（Traits）

最后一个概念是一组应用运维特征（Traits），它描述了应用在具体部署环境中的运维特征，比如应用的水平扩展策略和Ingress特征，这些特征对于运营的运维来说非常重要，但它们在不同的部署环境里却往往有着截然不同的实现方式。举一个简单的例子，同样是Ingress，它在公有云上和本地数据中心的视线可能是完全不同的：前者一般是SLB这样的云服务，而后者可能是一个专门的硬件。这也就意味着针对俩个环境的Ingress运维工作，将会有着天壤之别。但与此同时，这个Ingress规则对于应用开发人员来说，可能是完全相同的。应用特征的设计，让这种关注点分离成为可能：只要这俩个环境在OAM模型下提供了对Ingress这个应用运维特征的视线，那么你的应用里就可以实现统一的Ingress规则描述无差别的在这俩个地方运行起来。与此同时，这俩个环境的基础设施供应商可以继续通过配置这些应用特征的视线，来满足它们各自的运维需求（例如：不同环境里Ingress实现在满足合规性上和安全性上的差异）

OAM：平台无关、高可扩展的应用能力描述

与Paas（平台即服务）应用模型相比，OAM有很多独有的特点，其中最重要一点是：平台无关性。虽然我们目前发布的OAM实现（rudr）是基于Kubernetes的，但Open Apllication Model与Kubernetes并没有强耦合。实际上，OAM可以实现到任意平台或运行环境上，这当然也包括边缘计算与物联网的场景。我们也认同Kubernetes在很多运行环境中可能并不是最好的选择，或者像是Server less这类不需要关心基础设施复杂性的运行环境。在这些场景下，OAM都可以提供完全一致的应用管理体验。

第二个重要的特点是，OAM 的 specification （OAM 规范） 在设计上天然是可扩展的。OAM 不像 PaaS 那样自成封闭体系，也不会通过某种独有的应用管理环境来屏蔽掉底层平台的特点（比如：在 Kubernetes 之上”盖一个大帽子“）。 相反，OAM 使平台层可以通过应用特征系统 （Trait system）来体现平台的特性和差异性。也就是说，只要不同的平台都能够提供应用所需要的某些应用特征 (Trait)，开发人员就能轻松地研发跨平台的应用。类似地，哪怕最底层的硬件提供商，也可以通过应用特征系统来体现其平台特性。 OAM 的整体设计，就是为了避免在平台可移植性中经常发生的“最小公分母”锁定问题。相反，OAM 不但提供了可移植性的能力，它还确保了每个平台有能力去透出独有的特性和用途。 OAM 让开发人员可以自由地针对不同平台以标准方式在可移植性和差异化功能之间取得平衡。

原则

• OAM 的本质是根据软件设计的“兴趣点分离”原则对负责的 DevOps 流程的高度抽象和封装，这背后还是“康威定律”在起作用。
• OAM 仅定义云原生应用的规范，OAM 开源之初推出的 Rudr 可以看做是 OAM 规范的 Kubernetes 解释器（已停止维护），将云原生应用定义翻译成 Kubernetes 的资源对象。
• OAM 与 Crossplane 将展开合作，就 Kubernetes 式以 API 为中心的应用定义发扬光大，并深度参与 CNCF SIG App Delivery，以共同定义云原生应用标准。

马尔文·康威（Melvin Conway）1967年提出的： "设计系统的架构受制于产生这些设计的组织的沟通结构。"

OAM规范设计遵循了以下原则

• 关注点分离：根据功能和行为来定义模型，以此划分不同的角色职责
• 平台中立：OAM的视线不绑定到特定平台
• 优雅：尽量减少设计复杂性
• 复用性：可移植性好，同一个应用程序可以再不同的平台上不加改动的执行
• 不作为具体的编程模型：OAM 提供的是应用程序模型，描述了应用程序的组成和组件的拓扑结构，而不关注应用程序的具体实现。

OAM模型中包含以下基本对象，以本文发稿时最新的API版本 core.oam.dev/v1alpha2 为准：

• Component：OAM 中最基础的对象，该配置与基础设施无关，定义负载实例的运维特性。例如一个微服务 workload 的定义。
• TraitDefinition：一个组件所需的运维策略与配置，例如环境变量、Ingress、AutoScaler、Volume 等。（注意：该对象在 apiVersion: core.oam.dev/v1alpha1 中的名称为 Trait）。
• ScopeDefinition：多个 Component 的共同边界。可以根据组件的特性或者作用域来划分 Scope，一个 Component 可能同时属于多个 Scope。
• ApplicationConfiguration：将 Component（必须）、Trait（必须）、Scope（非必须）等组合到一起形成一个完整的应用配置。

因为 OAM 还处在发展早起，API 变化较快，以上四个对象在不同的 API 版本中的 kind 名称不同，请大家使用时注意区别。

总的来说，OAM 模型对象的定义格式与 Kubernetes 对象的类型字段相似。关于 OAM 的基本概念模型的更多信息请访问 Overview and Terminology。

OAM 工作原理

OAM Spec 定义了云原生应用的规范（使用一些 CRD 定义）， KubeVela 可以看做是 OAM 规范的解析器，将应用定义翻译为 Kubernetes 中的资源对象。可以将上图分为三个层次：

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

从以上描述中可以看出 OAM 对于定义云原生应用标准的野望，其目标不仅限于 Kubernetes 之上的又一上层抽象，而是对于一切云服务，在基于资源对象的基础上，Trait 来控制 Kubernetes 中的一众高层次非可调度的资源对象，如 AutoScaler、Volume、Ingress，Istio 中的流量配置对象 VirtualService、DestinationRule 等，还可容纳更多的云服务，对于 Serverless 时代的去基础设施化的思想不谋而合，未来可期。