随着kubernetes的兴起，不少公司都有了Paas平台建设的能力，可是应用Paas平台建设上基本上都是形态万千，百花齐放，而OAM在笔者看来就是应用Paas平台建设的kubernetes，将来的事实标准，今天让咱们一块儿来聊下OAM吧。java

1. 第1001个Paas平台

在聊OAM以前咱们先聊下传统的运维开发，从运维系统到运维平台的演进的过程，以及可能会遇到的问题mysql

1.1 起步阶段

在传统的运维开发中，基础组件CMDB、自动化、监控、发布、日志、流程几个系统基本上已是标配，经过CMDB存储元数据，自动化提供原子操做，而后经过发布搞定持续交付, 一般能够将这个阶段称为1.0阶段，该阶段运维能够提供必定的支持能力，该阶段运维主要目标是搞定内部需求，对外输出持续交付能力(仅仅是交付，大多数公司CI流程由测试把控，夸团队的事情就自行体会吧)git

1.2 平台化阶段

平台化阶段主要目标就是经过运维系统的集成，尽量的实现研发的自助操做，比较典型的就是基于ITSM实现上述流程平台的联动，研发填写固定的工单，而后经过流程编排，整合当前的运维子系统，实现某个场景的自助化操做，减小运维的参与度，提供研发效能，在这个过程当中，可能会打通公司的一些别的团队，好比数据库、测试、中间件团队，姑且称之为2.0阶段redis

1.3 服务化阶段

服务化Paas主要是经过底层基础设施、运维系统的服务化能力，而且公司内部具备高度统一的目标，开始向云化转变阶段转变，每一个团队都提供高度内聚的服务化能力，同时对外提供该平台全生命周期的管理能力。sql

这里咱们要想明白服务化能力与系统功能的区别，好比说发布系统提供几十个参数，让用户提供随意的定义，我理解这可能仅仅是功能，由于若是用户自由度越高，证实平台流程规范越不统一，并且若是让一个用户用系统的时候，得先屡清楚你的几十个功能参数，上帝，祝你好运！而服务化的能力我理解上应该给用户提供的是好比发布策略，尽量少的控制参数，标准化的流程，具体的复杂编排能力彻底内聚到平台内部，对用户无感知。就称之为3.0阶段好了数据库

1.4 1001种选择

在这个阶段一般平台的建设者就会考虑平台下一步大的方向是什么，从当前的运维产品类中，咱们能够分为三个方向：效能devops方向、Paas方向、运维门户，但你们有一个很一致的目标就是提升研发效能，实现应用全生命周期管理安全

1.4.1 运维门户

运维门户方向其目标主要是覆盖测试->发布->运维这三个阶段,经过整合运维侧的能力，好比cmdb、监控、发布、日志等系统实现应用的统一操做，一般会结合公司的CMDB来实现业务树来进行统一管理，其优势是符合运维操做需求，我的理解其相对于devops和cloud属于建设过程当中的一个阶段，主要强调的是整合。微信

1.4.2 devops效能

效能devops方向典型的表明就是阿里的云效，从需求->开发->测试->发布->运维->运营实现全链路的覆盖，在大多数工一般都是打通测试->发布->运维->运营这个链路就很不错了，可是一般公司大几率不会作这个事情，只要稍微碰过的就知道这里面需求->开发->测试这几个阶段是多难打通了。网络

1.4.3 Paas

Paas方向除了测试->发布->运维->运营这个链路的覆盖，很重要的一点是要提供云的基础能力，其中很关键的能力：弹性、多租户、自服务、按需付费，固然这有不少前提，好比你要弹性得公司有资源才行，按需付费也得公司想搞计费才行，但若是要作系统必定要想好，咱们后续万一要搞混合云呢？架构

1.4.4 运营

关于运营的理解，运营在运维这侧我目前理解就是维稳、降本、提效，稳定性应该是运维根本，运营的主要目标应该是后两个。

降本是指的平台能够经过一些机制去肯定下降运行成本，其中典型的体现就是业务使用资源是否合理，不管是在k8s仍是传统的vm，都有个问题就是研发申请了了4h8g的机器，真的合理嘛？若是咱们能够创建一套运营标准，好比咱们能够根据业务在过去周、月、季度、甚至年的资源使用，经过统一的标准去衡量其资源使用率，那有没有可能下降一些成本呢？

提效多是很难衡量的一个指标，由于没办法作一个平台以后，就说本身比以前提高了多少，更多的是多是从用户使用平台到底须要多长时间，好比上线应用，从应用建立、资源申请、线上交付一共花了多长时间？好比若是公司提供统一的脚手架，脚手架关联标准化建设，打通CI、CD、监控、日志、安全等等功能，那研发是否是只须要从git上拉下项目，而后进行代码开发，最终上线的时候，申请下资源便可？

固然这只是笔者的想法，也没有实践，感兴趣的能够一块儿聊聊想法，毕竟这个可能比AIops这些可能更容易落地一些。

1.5 选择的困惑

其实不管是在效能仍是Paas中，咱们都有在作同一件事情，就是应用的全生命周期管理，可是咱们会发现不一样方向、不一样公司的应用定义绝对是千差万别，并且针对应用全生命周期托管没有统一的规范，并且大多数公司的运维研发团队规模都并不大，如何设计出高内聚、低耦合、可扩展、分布式的应用Paas平台，发际线估计又要高很多。

在当下云原生时代，你们能够基于k8s的Paas(Saas)云原生的能力快速构建公司的容器云平台，咱们可能会本身搞个App而后结合Service、DEployment等资源去描述一个应用，而后针对日志/监控等进行改造适配，其实你们潜移默化的就在遵循共同的一种标准，其实就是k8s提供给你的，可是针对应用依赖，好比mysql、redis这种信息怎么描述呢？针对中间件这种又该怎么描述呢？这就是今天的主角OAM

2. OAM初识

OAM 全称是 Open Application Model，从名称上来看它所定义的就是一种模型，同时也实现了基于 OAM 的我认为这种模型旨在定义了云原生应用的标准。

开放（Open）：支持异构的平台、容器运行时、调度系统、云供应商、硬件配置等，总之与底层无关
应用（Application）：云原生应用
模型（Model）：定义标准，以使其与底层平台无关

该段描述引用自宋老师的文章，参考附录1

这里我说说个人理解，咱们作平台的都会有个痛点就是千奇百怪的设计，几年没动的停机可能起不来应用，谁特么都不敢动，而基于Model，我理解就是，翻滚吧牛宝宝，固然更大的目标确定是你们有同一个标准，同一个梦想，并且拥有统一的视角。Open开放有两层含义，1）支持异构：咱们经过标准的模型声明，接纳云、虚拟机、物理机、容器不一样的基础设施，这意味着咱们能够无限的扩容咱们的平台 2）云原生时代，咱们能够复用各类基础设施，让小做坊，也能够体验下五星级酒店的感受，经过复用云厂商、开源社区可让咱们平台无缝享受开源社区的能力，接下来让咱们一块儿看看OAM是怎么实现这边目标

2.1 Component

Component是应用组成的一部分，一般由开发进行描述，以下部分均可以描述为一个Component: 1.研发将本身的程序打包成一个镜像，经过Deployment部署 2.研发声明须要使用一个4核8G的mysql5.7的数据库

这两个描述都是component,简而言之研发能够描述的均可以称为Component，由于他们都是组成Application的一部分，这个部分的Model体现主要是体如今咱们经过Component的标准化，可让研发只须要关注极少数的须要知道的东西，就能够完成一个应用在研发角度的定义

在这一层我理解基础设施团队提供给研发定义应用的能力，研发只须要根据应用须要声明对应的component组件，而并不关注底层的基础设施具体的实现

2.2 Trait

Trait则是运维和基础架构服务化的能力提供手段，运维能够根据应用的描述，来给应用加对应的Trait，那什么能够称之为一个Trait呢？好比弹性扩缩容多是一种Trait，日志多是一种Trait、监控可能也是一种Trait，几个实际Trait: 1.研发上线一个java应用，运维这边根据标准化和服务化能力，就会自动加入对应的监控，这其实就是监控的服务化能力 2.应用灰度发布，发现问题，主动进行回滚，这实际上是发布系统服务化能力的体现

经过运维能力的输出，研发就不须要关注底层的各类运维细节，只须要声明应用想拥有的能力，就能够经过实现底层应用运维的自动化托管，不须要关注底层的任何细节，并且各类运维能力能够自由组合，实现应用稳定高效的运行

2.3 Policy

Policy其实是Component中的概念，体现的实际上是研发诉求，好比研发提出个人应用须要响应延迟在100ms之内，那运维就能够根据这个Policy结合本身的服务化能力，提供对应的Trait, 研发其实并不须要知道运维是如何保障SLA的，只须要提供研发诉求Policy，其实就能够完成诉求传递，一切可描述，可度量

研发经过声明Policy传递诉求，运维根据诉求结合运维能力，提供对应的保障，一切都是数据化的，既是运维服务化能力的体现，也是研发和运维彼此信任的良好桥梁，同时研发也并不须要关注各类底层的细节

2.4 Application Scope

应用边界中咱们首先要理解边界，边界主要是定义具备某些意义的一类应用的边界，好比在公有云环境中，一般会根据VPC网络划分边界，经过统一的网络配置，能够划分出多个网络区，这些都属于Application Scope。更复杂的场景则是多数据中心，快速止损，当前大多数公司为了灾备都会有多个数据中心，那其实每一个数据中心都会划分为一个边界，若是发现某个中心忽然挂掉了，即对应的Application Scope下面的

并且ApplicationScope能够任意组合，咱们能够经过这种玩法，将要进行某一类的应用进行统一的管理，关注其对应的状态，进而结合咱们的Trait来实现各类场景的建设

2.5 Application Configuration

上面咱们声明了组成应用的component, 同时附加了运维的Trait，还经过AapplicationScope,划分了对应的网络或者应用层的边界，这些组件都是独立声明，能够独立进行演进，实现了应用接入配置的标准化、模型化、松耦合、自由装配，剩下的一步就是经过Application Configuration去将Conponent、Trait、ApplicationScope等组合起来，即就是咱们最终的应用声明，基于这份声明结合面向终态的设计，OAM会按照规则分别进行各个组件的托管，同时咱们也能够复用社区优秀的Component和Trait来实现平台的快速交付

3. 小结

OAM虽然并无标准化，可是相信将来必定很美好，笔者如今也在进行这方面的工做，不过目前仅仅是设计调研阶段，欢迎你们一块儿交流公司平台建设上面的问题以及各类场景的解决方案，文中的理解仅仅是我的的一些理解，阿里大佬们在推进OAM方面作了不少的努力，在接下来几篇我会介绍下OAM的更多的东西，感兴趣的能够持续关注下，附录里面都是阿里大佬的分享，你们多多关注，今天先到这，下期再见