目录：
1、什么是云原生
2、什么是OAM
3、OAM助力云原生
3.1、传统应用上云
3.2、基于OAM模型云原生
1、什么是云原生：
官网上将云原生的定义概况为：服务网格、声明式API、DevOps、持续交付、微服务、容器这六大特征，这也成了很多人对云原生的基础印象。
云原生计算基金会总经理Priyanka Sharma对云原生的解释为：云原生技术是指工程师和软件人员利用云计算构建更快、更有弹性的技术，这样做是为了快速满足客户的需求。
这里我对云原生的理解为：云原生继承于云计算，"原生"这两个字代表了从原生家庭(云计算)中遗传了绝大部分的云计算属性，但是在遗传的过程中发生了一些变化，就像人类遗传上基因的碱基对发生了改变。那么在"云原生"的遗传过程中核心发生变化的碱基对是其承载计算方式的改变，由虚拟机、物理机改变成了容器为核心的工作负载的计算方式。从而对不同云计算环境下有较强的亲和性。
简单的说云原生就是基于云计算利用容器技术快速构建应用的一种规范。
2、什么是OAM：
定义：OAM( Open Application Model )全称开放应用模型。是云原生应用标准定义与架构模型，一种标准规范，通过这个模型我们可以以统一的应用模型标准快速、高效的构建基于k8s基座上的应用，管理以及运维。
我们知道在k8s上面部署一个应用，承载这个应用的基础k8s资源有deployment、service、ingress、configmap等不同部分组成，我们需要创建和管理这些资源的yaml文件对象，虽然我们可使用helm charts来进行统一的打包管理，但是这个helm charts不能代表这个应用的全部内容，要是我们缺少一个应用相应的依赖资源，那么我们需要给这个helm charts包添加修改。
那么是否能为Kubernetes 以及云原生技术栈提供一种以应用为中心的 API 资源来提供一个专注于应用管理的、标准的、高度一致的模型，这个 API 资源可以代表完整运行的应用本身，而不仅仅是应用模板或者一个应用的几个组成部分，这就是开放应用模型 Open Application Model （OAM）通过这个模型来规范云原生技术栈下应用生命周期的统一标准管理。OAM简单的说就是一个规范，用这个规范将应用的定义与运维能力进行分离。应用管理者只要遵守这个规范，就可以编写出一个自包含、自描述的“应用部署配置文件”。具体的说，这个应用部署配置文件(应用描述文件)实际上由两部分组成：
应用描述 = 应用组件 + 应用特征
1)、应用组件：
在 OAM 中，“应用”是由多个概念共同组合而成的。 第一个概念是：应用组件（Components），它是整个应用的重要组成部分。 所以说，应用组件既可以包括应用运行所依赖的服务：比如 MySQL 数据库，也包括应用服务本身：比如拥有多个副本的 PHP 服务器。 开发者可以把他们写的代码“打包”成一个应用组件，然后编写配置文件来描述该组件与其他服务之间的关系，就像使用docker compose一样来描述应用之间的依赖。 应用组件的概念，让平台架构师能够将应用分解成一个个可被复用的模块，这种模块化封装应用组成部分的思想，代表了一种构建安全、高可扩展性应用的最佳实践：它通过一个完全分布式的架构模型，实现了应用组件描述和实现的解耦。
2)、应用特征：
最后一个概念是一组应用运维特征（Traits） ，它们描述了应用在具体部署环境中的运维特征，比如应用的水平扩展的策略和 Ingress 规则，这些特征对于应用的运维来说非常重要，但它们在不同的部署环境里却往往有着截然不同的实现方式。 举一个简单例子，同样是 Ingress，它在公有云上和本地数据中心的实现可能是完全不同的：前者一般是 SLB 这样的云服务或者使用nsx-t这样的网络提供的lb，而后者则可能是使用haproxy-ingress controller。这也就意味着针对这两个环境的 Ingress 运维工作，将会有天壤之别。 但与此同时，无论是在哪个环境里，这个 Ingress 规则对于应用开发人员来说，可能是完全相同的(提供负载功能)。 应用特征的设计，让这种关注点分离成为可能：只要这两个环境在 OAM 模型下提供了对 Ingress 这个应用运维特征的实现，那么你的应用就可以使用统一的 Ingress 规则描述无差别的在这两个地方运行起来。而与此同时，这两个环境的基础设施供应商可以继续通过配置这些应用特征的实现，来满足它们各自的运维要求（例如：不同环境里 Ingress 实现在满足合规性和安全性上的差异）。
总结：OAM是一个模型、是一个标准规范、是一个框架，其核心落地思想是以应用为中心API资源，其本质是应用本身和应用特征分离。
3、OAM助力云原生：
3.1、传统应用上云：
应用上云目前已经成为中小企业绕不开的发力点，而应用上云时候应用架构和基础设施规划已经成为了企业的默认选项。
一个云上的应用，肯定不只是简单的可执行文件。就拿 Java Web 网站为例，这个应用要想在云平台上被最终用户使用到，就需要有大量的外部依赖需要处理。这就是云端应用开发者实际上关心的事情，其实一点也不简单：
这种情况下，在云上交付一个应用的过程，实际上非常坎坷。
举几个例子：作为云上的开发者，我们首先需要花费大量的时间来进行应用整体部署架构的设计，才能大致搞清楚这个应用到底需要开通哪些云服务。但这依然避免不了一些让人头疼情况的发生，例如：
因为一个操作流程失误，一些需要预先申请的云资源不到位，就得返工重来；
一旦某个云服务的配置不合理，就得重新配置，甚至删掉重来；
整个上线应用的过程，我们需要不停地在各种云产品控制台之间来回跳转；
还有很多时候，我们不得不一个一个手工处理应用删除遗留下来的各种云资源；
上述情况的出现，总的来说是因为云上应用管理的过程，实际上是一个离散的状态，导致整个流程杂乱无序，也很难把控，出错返工就在所难免了。
再举个例子。除了过程上的繁杂之外，云端应用管理的另一个现状就是：开发者总是需要不停的去开通和配置各种各样的云服务，同时也要花大量的时间去开发各种云产品的开通和接入代码。尤其让人头疼的是，这些所有对云服务的开通、配置和接入工作，几乎都是“一次性工作”。我给一个应用组件做的事情，再上线另一个应用组件的时候，又得全部重新做一遍。甚至有时候为了接入一个新的云服务，必须重新开发整个应用。上述情况的出现，归根到底是因为对于应用所依赖的云服务来说，它们的开通与配置工作，并不是一个可复用的能力，这就导致了大量的重复劳动和对接工作需要一而再、再而三的在应用管理的过程中不断重复进行。
这些情况，都是现今制约和困扰着云端应用开发和运维人员的几个典型“症状”，也点明了当前云应用管理过程“耗时”、“耗力”背后，两个显著的症结所在：
应用本身：不能以统一、自描述的方式定义应用与云资源的关系；
云基础设施本身：没有一种统一、标准、高效的方式交付给应用使用。
总结：从上面可以看出云上环境通过开放的api已经实现简化对云基础设施层资源的调用，然而在上层应用和开放的api层缺少声明式的描述。
3.2、基于OAM模型云原生：
在 Open Application Model 的模型中，应用管理人员可以灵活搭配应用组件与应用特征，从而对接不同的云基础设施能力到应用中。这种基础设施能力通过添加一层垫片“OAM”来服务用户后，实际上就能够差异化的表达不同运行环境能够为应用提供的不同基础设施能力。
举个例子，一位开发者定义了一个叫做“车”的应用描述，并做出了如下叙述：
要有安全性
要能有操控能力
要有行使动力
然后，他把这样的应用描述交给了云平台，云平台根据这个描述，为它绑定了一组比较基础的“应用特征”：
安全：安全带、气囊、普通刹车
操控：手动 5 档、普通方向盘
动力：普通发动机
这样，这个应用在它的最终用户看来，实际上就是一个“家用汽车”。
但是，过了一阵子，开发者决定对这个“车”进行一次升级。这时候，他该怎么做呢？
实际上，他什么也不用做。他只要告诉应用运维，为之前的“车”应用描述，绑定一组更加“强大”的应用特征即可，比如：
安全：高强度车架、悬挂减震、全身防护、赛车式刹车
操控：手动 8 档、赛车方向盘
动力：赛车引擎
所以，一旦上述“更强大”的应用特征，同“车”应用描述绑定，我们就可以将一个“家用车”立刻升级成一部强大的“赛车”。而在这个过程中，应用开发和应用运维唯一要做的事情，就是像“乐高积木”那样，灵活搭配和组装不同的应用特征而已。
而更重要的是，OAM 的设计初衷之一，是要提供标准化云端应用管理体验，这就需要“抹平”不同运行环境之间的不同，以便让应用“ 一次定义，多处运行”。但与此同时，OAM 提供的应用特征系统，则使得云平台标准化的暴露出自己的能力之后，用户依然可以通过对比不同运行环境的应用特征的差异，从而更准确的选择自己的应用要部署到哪个运行环境当中，真正意义上实现“Define Once, Run Where I Choose” 的交付体验。所以说，应用特征系统，正是 OAM 在设计中平衡可移植性和差异性的一个重要的创新之举。
参考：
云原生:
https://builtin.com/cloud-computing/what-is-cloud-native
oam:
https://developer.aliyun.com/article/721106
https://mp.weixin.qq.com/s/lh4t9MNlfI5GqJeMFj7Mew