Kubernetes资源编排之五：OAM篇
作者：雪尧（郭耀星）、炯思（钟炯恩）
前文我们提到了Helm/Kustomize/CRD+Operator这些方式，都可以在各自的领域很好的承载一个组件（Component）的概念。但是都没有解决一个完整的面向业务场景的应用（Application）的问题。
OAM（Open Application Model）是2019年阿里云与微软联合推出的开放应用模型。下面我们来看这个模型是什么。
一、 OAM是什么？
在应用部署上，大家或多或少有过一些这样的经历：面对复杂的K8S YAML手足无措，有些字段能理解含义，有些字段光在字面上无法确认影响，有些字段提交修改就报错，提示这个字段不可被修改。如果说k8s内置资源的字段基本都还有迹可循的话，通过CRD+Operator创建的自定义资源的字段都会放飞自我，连文档都找不到。那么这些YAML能不能做得像乐高积木一样呢？既能自由地插拔创造发挥，又有一些限制约束，使得创意不会太剑走偏锋，让使用者也能快速理解其中的作用和价值。
于是OAM应运而生。OAM（Open Application Model）是一个标准的、基础设施无关的跨云应用部署模型。有以下几个特性：
• 应用为先。一个应用的交付与部署应该是自包含的，其中的各类操作行为应该作为应用定义的一部分，这些内容与实际基础设施无关。
• 清晰和可扩展性。定义一套开放标准，可以模块化整个应用交付流程，根据个人需要将这些模块自由组装，达成自己想要的结果。
• 云服务供应商无关。定义的开放标准应该是一套更高级别的抽象，可以跨本地集群、跨云服务供应商，不会被锁定到任何一个厂商的底座。
其实上面这些点写几个Operator也都能解决，但OAM的亮点在于他并不是一个程序的实现，他是一个文字定义的标准，大家只要依照这个标准去落地，就能把已有的东西整合起来发挥作用。下面来看一下OAM模型抽象：
如上图所示，OAM将一个模型分成了Application（应用）、Component（组件）、Trait（运维特征）这样几层，于是相关角色的关注点也都被巧妙地分解开来，各角色只要聚焦于自己的内容就能一起协作完成一个复杂的应用工程，如下图所示：
• 应用开发人员：负责组件Component的定义及研发。
• 应用运维人员：
｡ 定义适用于不同Workload的运维属性Trait和管Component的ApplicationScope（or Policy）。
｡ 将应用开发人员定义好的Component与运维属性Trait绑定在一起，辅以Policy+Workflow，生成Application，提交到Runtime实现，维护应用程序的生命周期。
• 基础设施运维人员：提供不同的Workload类型映射到实际的基础设施。
OAM通过一系列概念的定义，完成了对一个应用的抽象，实现了角色职责的分离，将应用交付这件事情与底座解耦，使得跨云快速交付应用成为可能。开发同学也不再关心底座实现细节，只关心自己的应用模型即可。OAM的诞生，旨在定义云原生应用标准。
OAM只是一纸协议，并没有应用/组件管理的能力，但它却定义了一个良好的管理应用/组件的系统应该是什么样子，通过一套统一的概念收拢社区中分散在各处的垂直能力工具。下面我们就来讲讲SREWorks如何基于这个协议构建完整的云原生运维生态。
