云原生时代的应用PAAS模型OAM指的是什么

云原生时代的应用PAAS模型OAM指的是什么，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。

随着kubernetes的兴起，很多公司都有了Paas平台建设的能力，但是应用Paas平台建设上基本上都是形态各异，百花齐放，而OAM在笔者看来就是应用Paas平台建设的kubernetes，未来的事实标准，今天让我们一起来聊下OAM吧。

1. 第1001个Paas平台

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

1.1 起步阶段

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

1.2 平台化阶段

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

1.3 服务化阶段

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

这里我们要想明白服务化能力与系统功能的区别，比如说发布系统提供几十个参数，让用户提供随意的定义，我理解这可能仅仅是功能，因为如果用户自由度越高，证明平台流程规范越不统一， 而且如果让一个用户用系统的时候，得先屡清楚你的几十个功能参数，上帝，祝你好运！而服务化的能力我理解上应该给用户提供的是比如发布策略，尽可能少的控制参数，标准化的流程，具体的复杂编排能力完全内聚到平台内部，对用户无感知。就称之为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来实现平台的快速交付。

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注亿速云行业资讯频道，感谢您对亿速云的支持。