开放应用模型（OAM）

在2019年上海QCon大会上，阿里云和微软联合推出了开放应用模型 Open Application Model （OAM）开源项目，OAM的愿景是在应用的维护生命周期内，提供一种标准化的沟通方式。将应用开发者、应用运维人员和基础设施运维人员，以一种标准化的方式连接起来。让云原生应用的开发、交付和运维变得更加简洁、高效并且可控。项目地址：https://openappmodel.io/

开放应用模型

00 前言

在软件行业中，日新月异的技术、标准、设计风格等不断的冒出来，代表着技术的不断进步和更迭，也说明这个行业存在着一群极其不安分的人，不断搞事情。究其原因，其实是当前行业中存在的问题，引发的创新，甚至是革命。

作为软件开发行业中的一员，我们必须深入了解这些新的技术和理念，因为很有可能你当前所面临的一个难题，就可以使用这个新技术或者理念很好地解决。因此我们本文介绍一下新鲜出炉的开放应用模型，文章内容包含官方文档中的介绍和自己一些理解。

01 云原生

开放应用模型针对云原生应用定义了一些规范和标准，这里就先简单介绍一下什么是云原生。云原生（cloud native）包含两部分：云和原生。云就是应用运行在云环境中，具有弹性和分布式的特点；原生就是土生土长的意思，也就是说应用在设计之初就考虑到了云的运行环境（IaaS、PaaS、SaaS）。

究竟云原生应用是如何实现的呢？

云原生 = 微服务 + DevOps + 持续交付 + 容器化

微服务

1. 应用间采用Restful API通信；
2. 可以独立部署、升级、扩缩容、重启；
3. 低耦合高内聚；

DevOps

1. 开发和运维高度协同工作；
2. 自动化发布管道和CI工具；
3. 快速部署到生产环境；

持续交付

1. 频繁发布、快速交付、快速反馈、降低发布风险；

容器化

1. Docker等容器技术；
2. 微服务的最佳载体；

02 开放应用模型介绍

开放应用模型，是构建云原生应用时，一个以团队为核心的标准。

其中明确描述了构建云原生应用的三个重度参与方：应用开发者、应用运维、基础设施运维。他们分别的职责：

1. 应用开发者 负责定义应用组件；
2. 应用运维 负责创建这些应用组件的实例，并且为它们分配相应的应用配置；
3. 基础设施运维 负责申请、安装、维护平台上的底层基础服务，并且能为上层应用组件提供稳定的服务；

云原生开发和OAM开发方式

序号	云原生开发	OAM开发方式
0	微服务非常复杂	一种新的应用模型
1	开发者必须在基础设施工具（镜像、仓库、版本控制等）上花费越来越多的时间	利用角色和作用域来管理应用，就像管理你的团队一样，不用关心基础设施
2	应用的开发过程中纠缠着应用的安全、性能和配置问题	有一个固定的工作流，它将开发者和运维所关注的事情分离开，并且提供了灵活性和明确分工
3	微服务的运行环境会影响到你的应用的开发和配置	可以运行在任何地方，可以跨云平台和边界设备部署

一个开放应用模型的Kubernetes实现：Rudr

Rudr 采用的是增量的方法解决问题，它的架构设计，提供了一组Kubernetes的插件，它允许任何对OAM规范的实现（使用原生的API或者kubectl）部署在该集群中。

应用开发者专注于构建OAM组件，应用运维人员专注于利用OAM应用配置的应用运维能力，基础设施运维人员专注于Kubernetes集群的运维。利用开放应用模型，现在用户可以按照这个框架在Kubernetes集群上定义他们的应用。

目前，Rudr 利用已经定义好的 trait 来完成任务，这样用户有选择任何底层工具的自由，并且提供了专注于功能而不是技术的 trait 。未来，Rudr 可能会提供一组默认的技术来支持一个trait所需要的功能。

03 对开放应用模型的理解

伴随着各种容器云技术的出现，微服务的应用开发也出现了很多可以选择的架构模式，可谓灵活性很高，想必使用过（或者调研过）的同学都是知道的。现在开放应用模型的出现，从行业上规范了云原生应用架构的方式，并且强化了应用生命周期中各个角色的职责。