开放应用模型OAM

应用容器技术，彻底改变了软件打包与分发方式，但是并没有让软件本身的定义与描述发生本质的变化，基于Kubernetes的应用管理体验，也没有让业务研发与运维的工作变得更简单。Kubernetes云原生技术仅仅实现了基础设施层的标准化和抽象。Kubernetes里面始终都没有 “应用”的概念，它提供的是更细粒度的“工作负载”原语。在实际的部署环境中，一个应用往往是由一系列独立组件的组合而成的。Kubernetes中缺少“应用”这个概念，造成了云原生应用管理生态的极度碎片化和极高的学习门槛。为了解决以上问题，阿里云联合微软共同发布了Open Application Model(OAM)开源项目，解决了从Kubernetes项目到“以应用为中心”的平台之间最关键环节——标准化应用定义。

Open Application Model(OAM)是一个“以应用为中心“的Kubernetes标准规范和框架，旨在为云端应用开发者、运维人员、云基础设施管理人员和云平台构建一套标准化应用架构和管理体系。提升云端应用交付和运维的效率以及体验。它的目标是：让简单的应用程序变得更简单，让复杂的应用程序更易于管理。

OAM主要有三个特点：

开发和运维关注点分离：开发者关注业务逻辑，运维人员关注运维能力，不同角色专注于不同的领域知识和能力；

平台无关与高可扩展：应用定义与平台解耦，应用描述支持跨平台实现和可扩展性；

模块化应用部署和运维特征：应用部署和运维能力可以描述成高层抽象模块，开发和运维可以自由组合，支持模块化实现。

应用组件是是整个应用的重要组成部分，开发者可以把他们写的代码”打包“成一个应用组件，然后编写配置文件来描述该组件与其他服务之间的关系。运维人员定义这些属性之后就能按照组件声明得到运行的组件实例，组件声明包含以下信息：工作负载类型（Workload type），元数据（Metadata），资源需求（Resource requirements），参数，工作负载定义（Workload definition）。

运维特征描述了应用在具体的部署环境中的特征，比如应用的水平扩展的策略和Ingress规则，对应用的运维来说非常重要，但它们在不同的部署环境里得实现方式缺大不不同。OAM中应用特征的设计分离了这种关注点：只要不同的环境在OAM模型下提供了对Ingress应用运维特征的实现，那么应用就可以使用统一的Ingress 规则描述，无差异地在不同的部署环境中运行起来。同时，不同环境的基础设施供应商可以继续通过配置这些应用特征的实现，来满足各自的运维要求。特征声明包含以下信息：元数据（Metadata），适用工作负载列表（Applies-to list），属性（Properties）。

OAM在应用部署配置中通过Scope来给应用进行逻辑分组，并且定义了服务运维的行为边界，一个应用可以划分到一个或者多个分组中，运维通过Scope来聚合服务,官方提供了两种Scope，NetworkScope和HealthScope)，应用边界声明包含以下信息：名称等元信息， Scope应用的参数，Scope类型。

应用部署配置将应用组件描述变成一个真正运行起来的应用。应用运维人员通过专门的、包含了所有应用组件信息的部署配置文件来实例化待运行的应用。应用部署配置文件本身也是OAM规范中的一个声明式的API，使应用运维人员能够根据开发者提交的应用描述，实例化出对应的应用。应用部署配置将组件、特征和应用边界组合在一起实例化部署，应用配置声明包含以下信息：元数据（Metadata），参数覆盖（Parameter overrides），组件设置（Component），绑定组件的运维特征配置（Trait Configuration）。

综上所述，一个Application由一组 Components构成，每个Component的运行时由Workload描述，每个Component可以施加 Traits来获取运维的能力，使用Application scopes将Components划分到一个或者多个应用边界中，以便于统一配置、限制、和管理。OAM整体的运行模式如下所示：

图片来源于网络

组件、运维特征、应用边界通过应用配置实例化，然后再通过OAM的实现层翻译为真实的资源。

使用OAM规范来管理云原生应用主要是从“四个概念和一个动作”入手。如下图所示：

图片来源于网络

四个概念包括上面提到的应用组件，工作负载，运维特征，应用边界。一个动作是指运维人员通过应用部署配置实例化四个概念得到实际的运行应用。“运维特征，应用边界”供运维人员使用，“工作负载”供开发者使用，同时开发者准备“组件”供运维人员使用。这样角色划分就就变得非常明显了：开发者提供组件，使用平台的工作负载；运维人员关注一个动作实例化四个概念；平台方需要提供工作负载，运维特征，应用边界，并且托管用户的应用组件。

在OAM规范基础上，OAM提供了开源、标准的 OAM Kubernetes实现-KubeVela项目。KubeVela是OAM的实现之一。

对于开发人员和运维人员来说，KubeVela就是一个开箱即用的PaaS或Serverless平台。用户通过简单的命令行工具和图形化界面，以及内置的一组简洁的工作负载和运维能力，可以方便地在Kubernetes上部署和管理自己的云原生应用，对接CI/CD和DevOps工具链。KubeVela的出现主要解决如下几类问题。

可插拔式的能力模块

KubeVela支持将任何现有的Kubernetes API资源声明为工作负载或运维能力，而无须任何改动。这种可插拔式的设计方式，使得现有Kubernetes集群里的所有能力在OAM化时变得非常容易。

工作负载与运维能力标准化交互机制

工作负载与运维能力之间的交互标准化、统一化，使得KubeVela保证了OAM模块式接入、部署和管理任何Kubernetes工作负载和运维能力。在OAM 中，应用配置里引用的工作负载和运维能力也必须通过协作的方式来操作具体的Kubernetes资源。KubeVela通过DuckTyping（鸭子类型）机制，在运维能力对象上自动记录与之绑定的工作负载关系，从而实现工作负载和运维能力之间的双向记录关系。

KubeVela提供了其他几个非常重要的基础功能，以供平台工程师构建自己的PaaS或 Serverless平台：

（1）组件版本控制：KubeVela会为交付记录保留历史记录。以便运维人员通过运维能力进行回滚、蓝绿发布等运维操作。

（2）组件间依赖关系与参数传递：主要解决部署的组件间依赖问题，包括组件之间的依赖和参数传递，以及运维能力与组件之间的依赖和参数传递。

（3）组件运维策略：允许开发人员在组件的声明中，提出对对运维能力的要求，运维人员可以通过组件运维策略为组件绑定和配置合理的运维能力。

综上所述，基于OAM构建的Kubernetes应用管理平台架构如下：

图片来源于网络

OAM规范是云原生架构设计中的重要组成部分。企业应用遵循开放应用模型的设计理念和实践方法，可以更加灵活、高效地构建和管理自己的云原生应用，实现应用的可移植性、可扩展性和互操作性，从而更好地适应不断变化的业务需求和技术环境实现竞争优势。

【1】4个概念，1个动作，让应用管理变得更简单

【2】云原生架构设计：开放应用模型（OAM）的重要性与实践