近日，【CNBPA实践沙龙】第二期在线上顺利举行，灵雀云资深产品经理进行了 “云原生应用交付与管理——OAM模型实践”的主题分享，和来自金融、工业、能源等不同行业的近百位IT从业者，共同探讨如何通过OAM让应用的构建越来越简单，实现基础设施自动匹配架构需求，在云原生时代真正享受到平台化的红利。以下为分享内容回顾。

存在理想的PaaS平台吗？

近年来，随着Kubernetes的不断成熟，基于Kubernetes的容器PaaS平台也更为广泛地被客户所接受，然而这也衍生出了一些新的问题。

应用运维执行者需要在Kubernetes概念层工作，门槛和成本都比较高。Kubernetes的技术定位是面向基础设施的，而不是面向开发者的一体化应用平台，需要在Kubernetes上构建符合自身业务需求的PaaS平台来提升开发运维效率。这就导致不同应用平台的差异性很大，缺乏标准统一的应用交付和管理方式。

这时候就需要使用标准化应用模型来构建统一交付平面，实现混合环境下运维资产的统一管理，给云原生开发者提供自助式的交付和管理体验，也赋予平台本身更强大的扩展能力。这个趋势的典型代表就是 OAM 标准。

OAM的目标，就是为PaaS层找到类似的概念，让应用人员能方便地与自己熟悉的概念对接，从而更快接受、更轻松地使用，助力打造相对理想的云原生PaaS平台。

如何利用OAM实现云原生应用的统一交付与管理？

【某工业互联网平台企业】

背景及痛点：

该工业互联网平台企业，通过引入灵雀云的容器平台，建设工业互联网PaaS平台，再在工业互联网平台之上去建设工业应用。而这时平台层和应用层之间的”矛盾“就显现出来了，团队之间各自定义自己所在层面的应用，彼此之间相对独立，处理跨平台的运维任务难度大，往往需要跨平台、跨团队的反复沟通，开发和运维团队之间在应用运维方面沟通成本相对较高，运维工作自动化程度低。

解决方案：

首先，可以依据OAM模型，整理出应用开发和运维规范，让开发人员更易于理解。

组件和运维特征都是OAM的基本概念，而需要封装的组件数量、组件类型和涉及到什么样的运维特征，是用户可以根据自己的应用特点总结归纳出来的。比如整个应用模型，可以聚类整理成以下内容。

在组件方面，可以总结出以下三个常用组件：

l  Microservice，即无状态、可随意扩展、向外提供服务的应用模块；

l  Statefulset，即有状态、用于保存持久化数据的应用模块；

l  Microtask，即应用中需要偶尔执行的一次性任务。

在运维方面，可以总结出以下几个常用的运维特征：

l  Expose，即通过端口向外提供服务；

l  Health probe，即确认应用模块的健康状况；

l  Ingress，即通过域名提供外部访问路径；

l  Lifecycle，即生命周期，设置应用模块启动后和停止前的动作；

l  Resource assign，即为应用模块分配计算资源；

l  Node affinity，即关于亲和性的测试。

其次，需要让开发和运维团队有更简单明确的工作流程。

总结出上述这样的模型之后，两个团队之间的运维就更加规范了。

开发团队在做应用交付的时候，不用再去考虑Kubernetes层面的概念，在开发时只需要以组件为单位来进行开发，给这些组件设置相应的运维特征，在进行测试后，就可以进行交付，生成一个基于这个应用模型的应用描述文件，后续就可以基于这个应用描述文件，进一步在生产环境中实现应用的自动部署或升级。

开发团队可以就在组件和运维特征层面进行开发，同时可以就在这个层面进行应用的运维；而当有新能力需要扩展时，运维团队就可以直接封装新的组件或运维特征，然后让开发团队使用。这样两个团队工作的切面就比较清晰，整体的工作流程也会更简单，节省了很多无谓的跨团队沟通工作。

【某商业银行】

背景及痛点：

该商业银行同时存在容器及微服务两个平台，这两个平台都提供应用管理，那么这时候就出现了一个问题，应用开发和运维方面存在割裂的风险。他们的诉求是希望能够把所有的应用管理工作都集中到容器平台上，而不被微服务平台所限制，整体平台的架构怎么去搭建和打通是亟待解决的。

解决方案：

利用OAM强大扩展能力，在容器平台的应用模块中定义微服务组件，先将应用部署集中到容器平台。这样从应用部署层面来看，微服务类的组件和其他类型的组件都可以在容器平台中进行统一的创建和管理。从应用运维层面来看，后续可以考虑根据实际需要，将服务治理、伸缩等运维操作，通过自定义Trait的方式集中到容器平台。

灵雀云ACP的OAM能力

灵雀云在上述OAM模型的成功落地实践中，积累了丰富的成功落地经验，接下来为大家分享一下灵雀云云原生全栈私有云平台ACP中强大的应用交付与管理能力。

灵雀云ACP具备开放、灵活、可扩展的产品特点，支持灵活对接企业基础设施、周边系统、开发运维工具，平台可扩展、可定制。我们在ACP产品中也通过集成OAM实现了应用的统一交付与管理。

首先，ACP界面具备管理OAM应用的能力。在OAM列表页面里，OAM应用的名称、状态、标签、组件数量等都可以同步展示出来；在创建OAM组件时，按照先选择组件类型、根据不同类型去设置不同属性、再根据组件选择不同的运维特征的顺序，经过这3个步骤之后，就可以创建一个OAM组件。从操作过程和工作量上来看，比直接在Kubernetes上部署应用会容易很多；

此外，灵雀云在数百个PaaS平台实践经验中，抽象出了一组常用组件和运维特征，便于用户直接进行选择；

同时，支持用户进行自定义设置，可方便导入用户自定义组件和运维特征。

综上，OAM模型强大的扩展能力能够让各种主流的应用架构，都有相对固定统一的组件来对应，并且能随时容纳新的形式的应用。

我们相信，在OAM模型加持下，云原生时代的应用交付与管理一定会向更便捷、更智能的方向发展，我们也期待着能够以更先进的技术、更开放的平台，帮助更多行业、更多领域的客户实现云原生时代的转型升级。

点击此处，与灵雀云工程师共同探讨云原生时代的OAM实践，免费获取完整演讲资料（含PPT下载）。

关于【CNBPA实践沙龙】

【CNBPA实践沙龙】由云原生技术实践联盟CNBPA主办，聚集云原生领域技术大咖、意见领袖、云原生技术落地的典型用户和生态伙伴，探讨新技术的创新应用趋势，展示技术推动业务创新升级的优秀实践。

讲师招募：如果您有云原生技术实践相关话题，欢迎加入CNBPA讲师队伍，请添加下方二维码联系社区助手 。

上一篇：汽车行业云原生最佳实践分享

下一篇：演讲实录 | 云原生网络的企业级实践之路