开放应用模型（OAM）
在2019年上海QCon大会上，阿里云和微软联合推出了开放应用模型 Open Application Model （OAM）开源项目，OAM的愿景是在应用的维护生命周期内，提供一种标准化的沟通方式。将应用开发者、应用运维人员和基础设施运维人员，以一种标准化的方式连接起来。让云原生应用的开发、交付和运维变得更加简洁、高效并且可控。项目地址：https://openappmodel.io/
开放应用模型
00 前言
在软件行业中，日新月异的技术、标准、设计风格等不断的冒出来，代表着技术的不断进步和更迭，也说明这个行业存在着一群极其不安分的人，不断搞事情。究其原因，其实是当前行业中存在的问题，引发的创新，甚至是革命。
作为软件开发行业中的一员，我们必须深入了解这些新的技术和理念，因为很有可能你当前所面临的一个难题，就可以使用这个新技术或者理念很好地解决。因此我们本文介绍一下新鲜出炉的开放应用模型，文章内容包含官方文档中的介绍和自己一些理解。
01 云原生
开放应用模型针对云原生应用定义了一些规范和标准，这里就先简单介绍一下什么是云原生。云原生（cloud native）包含两部分：云和原生。云就是应用运行在云环境中，具有弹性和分布式的特点；原生就是土生土长的意思，也就是说应用在设计之初就考虑到了云的运行环境（IaaS、PaaS、SaaS）。
究竟云原生应用是如何实现的呢？
云原生 = 微服务 + DevOps + 持续交付 + 容器化
微服务
- 应用间采用Restful API通信；
- 可以独立部署、升级、扩缩容、重启；
- 低耦合高内聚；
DevOps
- 开发和运维高度协同工作；
- 自动化发布管道和CI工具；
- 快速部署到生产环境；
持续交付
- 频繁发布、快速交付、快速反馈、降低发布风险；
容器化
- Docker等容器技术；
- 微服务的最佳载体；
02 开放应用模型介绍
开放应用模型，是构建云原生应用时，一个以团队为核心的标准。
其中明确描述了构建云原生应用的三个重度参与方：应用开发者、应用运维、基础设施运维。他们分别的职责：
- 应用开发者 负责定义应用组件；
- 应用运维 负责创建这些应用组件的实例，并且为它们分配相应的应用配置；
- 基础设施运维 负责申请、安装、维护平台上的底层基础服务，并且能为上层应用组件提供稳定的服务；
云原生开发和OAM开发方式
| 序号 | 云原生开发 | OAM开发方式 |
|---|---|---|
| 0 | 微服务非常复杂 | 一种新的应用模型 |
| 1 | 开发者必须在基础设施工具（镜像、仓库、版本控制等）上花费越来越多的时间 | 利用角色和作用域来管理应用，就像管理你的团队一样，不用关心基础设施 |
| 2 | 应用的开发过程中纠缠着应用的安全、性能和配置问题 | 有一个固定的工作流，它将开发者和运维所关注的事情分离开，并且提供了灵活性和明确分工 |
| 3 | 微服务的运行环境会影响到你的应用的开发和配置 | 可以运行在任何地方，可以跨云平台和边界设备部署 |
一个开放应用模型的Kubernetes实现：Rudr
Rudr 采用的是增量的方法解决问题，它的架构设计，提供了一组Kubernetes的插件，它允许任何对OAM规范的实现（使用原生的API或者kubectl）部署在该集群中。
应用开发者专注于构建OAM组件，应用运维人员专注于利用OAM应用配置的应用运维能力，基础设施运维人员专注于Kubernetes集群的运维。利用开放应用模型，现在用户可以按照这个框架在Kubernetes集群上定义他们的应用。
目前，Rudr 利用已经定义好的 trait 来完成任务，这样用户有选择任何底层工具的自由，并且提供了专注于功能而不是技术的 trait 。未来，Rudr 可能会提供一组默认的技术来支持一个trait所需要的功能。
03 对开放应用模型的理解
伴随着各种容器云技术的出现，微服务的应用开发也出现了很多可以选择的架构模式，可谓灵活性很高，想必使用过（或者调研过）的同学都是知道的。现在开放应用模型的出现，从行业上规范了云原生应用架构的方式，并且强化了应用生命周期中各个角色的职责。
