共计 2574 个字符，预计需要花费 7 分钟才能阅读完成。
近日，【CNBPA 实际沙龙】第二期在线上顺利举办，灵雀云资深产品经理进行了“云原生利用交付与治理——OAM 模型实际”的主题分享，和来自金融、工业、能源等不同行业的近百位 IT 从业者，独特探讨如何通过 OAM 让利用的构建越来越简略，实现基础设施主动匹配架构需要，在云原生时代真正享受到平台化的红利。以下为分享内容回顾。
存在现实的 PaaS 平台吗？
近年来，随着 Kubernetes 的一直成熟，基于 Kubernetes 的容器 PaaS 平台也更为宽泛地被客户所承受，然而这也衍生出了一些新的问题。
利用运维执行者须要在 Kubernetes 概念层工作，门槛和老本都比拟高。Kubernetes 的技术定位是面向基础设施的，而不是面向开发者的一体化利用平台，须要在 Kubernetes 上构建合乎本身业务需要的 PaaS 平台来晋升开发运维效率。这就导致不同利用平台的差异性很大，不足规范对立的利用交付和治理形式。
这时候就须要应用标准化利用模型来构建对立交付立体，实现混合环境下运维资产的对立治理，给云原生开发者提供自助式的交付和治理体验，也赋予平台自身更弱小的扩大能力。这个趋势的典型代表就是 OAM 规范。
OAM 的指标，就是为 PaaS 层找到相似的概念，让利用人员能不便地与本人相熟的概念对接，从而更快承受、更轻松地应用，助力打造绝对现实的云原生 PaaS 平台。
如何利用 OAM 实现云原生利用的对立交付与治理？
【某工业互联网平台企业】
背景及痛点：
该工业互联网平台企业，通过引入灵雀云的容器平台，建设工业互联网 PaaS 平台，再在工业互联网平台之下来建设工业利用。而这时平台层和应用层之间的”矛盾“就显现出来了，团队之间各自定义本人所在层面的利用，彼此之间绝对独立，解决跨平台的运维工作难度大，往往须要跨平台、跨团队的重复沟通，开发和运维团队之间在利用运维方面沟通老本绝对较高，运维工作自动化水平低。
解决方案：
首先，能够根据 OAM 模型，整顿出利用开发和运维标准，让开发人员更易于了解。
组件和运维特色都是 OAM 的基本概念，而须要封装的组件数量、组件类型和波及到什么样的运维特色，是用户能够依据本人的利用特点总结演绎进去的。比方整个利用模型，能够聚类整顿成以下内容。
在组件方面，能够总结出以下三个罕用组件：
- Microservice，即无状态、可随便扩大、向外提供服务的利用模块；
- Statefulset，即有状态、用于保留长久化数据的利用模块；
- Microtask，即利用中须要偶然执行的一次性工作。
在运维方面，能够总结出以下几个罕用的运维特色：
- Expose，即通过端口向外提供服务；
- Health probe，即确认利用模块的健康状况；
- Ingress，即通过域名提供内部拜访门路；
- Lifecycle，即生命周期，设置利用模块启动后和进行前的动作；
- Resource assign，即为利用模块调配计算资源；
- Node affinity，即对于亲和性的测试。
其次，须要让开发和运维团队有更简略明确的工作流程。
总结出上述这样的模型之后，两个团队之间的运维就更加标准了。
开发团队在做利用交付的时候，不必再去思考 Kubernetes 层面的概念，在开发时只须要以组件为单位来进行开发，给这些组件设置相应的运维特色，在进行测试后，就能够进行交付，生成一个基于这个利用模型的利用形容文件，后续就能够基于这个利用形容文件，进一步在生产环境中实现利用的主动部署或降级。
开发团队能够就在组件和运维特色层面进行开发，同时能够就在这个层面进行利用的运维；而当有新能力须要扩大时，运维团队就能够间接封装新的组件或运维特色，而后让开发团队应用。这样两个团队工作的切面就比拟清晰，整体的工作流程也会更简略，节俭了很多无谓的跨团队沟通工作。
【某商业银行】
背景及痛点：
该商业银行同时存在容器及微服务两个平台，这两个平台都提供利用治理，那么这时候就呈现了一个问题，利用开发和运维方面存在割裂的危险。他们的诉求是心愿可能把所有的利用管理工作都集中到容器平台上，而不被微服务平台所限度，整体平台的架构怎么去搭建和买通 是亟待解决的。
解决方案：
利用 OAM 弱小扩大能力，在容器平台的利用模块中定义微服务组件，先将利用部署集中到容器平台。这样从利用部署层面来看，微服务类的组件和其余类型的组件都能够在容器平台中进行对立的创立和治理。从利用运维层面来看，后续能够思考依据理论须要，将服务治理、伸缩等运维操作，通过自定义 Trait 的形式集中到容器平台。
灵雀云 ACP 的 OAM 能力
灵雀云在上述 OAM 模型的胜利落地实际中，积攒了丰盛的胜利落地教训，接下来为大家分享一下灵雀云云原生全栈公有云平台 ACP 中弱小的利用交付与治理能力。
灵雀云 ACP 具备 凋谢、灵便、可扩大 的产品特点，反对灵便对接企业基础设施、周边零碎、开发运维工具，平台可扩大、可定制。咱们在 ACP 产品中也通过集成 OAM 实现了利用的对立交付与治理。
首先，ACP 界面具备治理 OAM 利用的能力。在 OAM 列表页面里，OAM 利用的名称、状态、标签、组件数量等都能够同步展现进去；在创立 OAM 组件时，依照先抉择组件类型、依据不同类型去设置不同属性、再依据组件抉择不同的运维特色的程序，通过这 3 个步骤之后，就能够创立一个 OAM 组件。从操作过程和工作量上来看，比间接在 Kubernetes 上部署利用会容易很多；
此外，灵雀云在数百个 PaaS 平台实践经验中，形象出了一组罕用组件和运维特色，便于用户间接进行抉择；
同时，反对用户进行自定义设置，可不便导入用户自定义组件和运维特色。
综上，OAM 模型弱小的扩大能力可能让各种支流的利用架构，都有绝对固定对立的组件来对应，并且能随时包容新的模式的利用。
咱们置信，在 OAM 模型加持下，云原生时代的利用交付与治理肯定会向更便捷、更智能的方向倒退，咱们也期待着可能以更先进的技术、更凋谢的平台，帮忙更多行业、更多畛域的客户实现云原生时代的转型降级。
发送关键词【OAM】至灵雀云微信公众号，与灵雀云工程师独特探讨云原生时代的 OAM 实际，收费获取残缺演讲材料（含 PPT 下载）。
对于【CNBPA 实际沙龙】
【CNBPA 实际沙龙】由云原生技术实际联盟 CNBPA 主办，汇集云原生畛域技术大咖、意见首领、云原生技术落地的典型用户和生态搭档，探讨新技术的翻新利用趋势，展现技术推动业务翻新降级的优良实际。
