怎么制作网站教程视频,网站收录不好,环保网站建设公司排名,长沙软件公司排行榜简介#xff1a; 受阿里云邀请#xff0c;我有幸在《云原生架构白皮书》发布前试读了该书#xff0c;本文结合白皮书内容#xff0c;谈谈开放应用模型#xff08;OAM#xff09; 前言
7月21日阿里云发布了《云原生架构白皮书》#xff0c;该书由阿里云众多技术专家共同…简介 受阿里云邀请我有幸在《云原生架构白皮书》发布前试读了该书本文结合白皮书内容谈谈开放应用模型OAM 前言
7月21日阿里云发布了《云原生架构白皮书》该书由阿里云众多技术专家共同编撰而成从云原生定义、技术、架构、产品、实践和发展趋势几个方面详细介绍了云原生这一近些年来大火的技术概念。受阿里云邀请我有幸在该书发布前试读了该书但是由于最近比较忙现在才有空和大家分享我的试读感受。
熟悉我的朋友肯定知道去年开放应用模型OAM概念一经提出我就十分关注这一技术模型最近更是参与到了该模型的实现项目 Crossplane 中同社区中的同学共同实现云原生技术“以应用为中心”这一终极愿景。但是苦于社区中的资料都是英文同时自己的理解又比较片面在向身边同事和其他不了解该项技术的同学科普 OAM 时往往很难准确表达我的观点。
OAM 是什么OAM 能做什么我们为什么需要 OAM每每被同事进行灵魂拷问时总是不能拿出完整、条理、有说服力的东西只能根据自己的理解以及一些零零散散的技术文章来说明我的观点很是不爽。但是当我读到《云原生架构白皮书》第三章中的开放应用模型OAM章节时我知道我的问题解决了。该章系统的介绍了 OAM 这项技术的背景、定义、概念、实现和未来读者只要对云原生稍有理解就能轻松从这章中找到前面那些问题的答案。
那么 OAM 到底是什么
从《云原生架构白皮书》的内容出发结合我的理解大致将 OAM 的特点分为以下三点
以应用为中心
今年是 Kubernetes 项目诞生的第六年在这六年中以 Kubernetes 为首的云原生技术快速的改变着我们的技术架构一个又一个的应用被拆分成微服务打包成容器运行在 Kubernetes 上。然而随着微服务越拆越多管理微服务的难度也呈指数型增长Kubernetes 中并没有”应用“这一概念提供给我们的只有 deployment、StatefulSet 这样工作负载粒度的资源而一个应用可能由多个 Deployment、Service、以及各种相关配套资源组成如HPA 用于弹性伸缩、Ingress 用于外部访问等。Kubernetes 并没有提供给我们一个统一的资源或者说是方法来管理这些相关资源各个公司只能开发自己的 PASS 平台或设立规范约束自己的应用。
OAM 的出现补充了“应用”这一概念建立对应用和它所需的运维能力定义与描述的标准规范。换言之OAM 既是标准“应用定义”同时也是帮助封装、组织和管理 Kubernetes 中各种“运维能力”的工具。通过 OAM 中应用的可交付对象 - Application Configuration我们可以轻松的掌握我们的应用到底有那些 Kubernetes 工作负载组成这些工作负载都使用了哪些运维特性这些内容都会以 Kubernetes API 对象的形式展示查看起来和查看 Deployment 与 Service 资源一样方便。 关注点分离
在实践中如果基础架构和应用是由不同团队维护的由于各个团队的关注点不同、对 Kubernetes 了解的程度不同、使用习惯不同很容易产生混乱。实际上对于业务研发人员和运维人员而言他们并不想配置这些如此底层的资源信息而希望有更高维度的抽象。这就要求一个真正面向最终用户侧的应用定义一个能够为业务研发和应用运维人员提供各自所需的应用定义原语。 通过组件Component和运维特征Trait将业务研发人员与运维人员关注的不同特征进行分离再将不同的运维特征Trait与业务组件Component进行绑定最终再由OAM 可交付物 – Application Configuration 将所有组件组装为一个统一的应用。研发与运维对资源的控制进行细粒度的划分可以有效的解决实际情况中存在的类似”我比你更懂 Kubernetes要听我的“的现象避免了研发与运维之间的甩锅与扯皮的情况。
面向最终用户的应用管理平台
这部分白皮书中并未详细提及但这也是我们现阶段的主要工作和努力方向经过不到一年的时间OAM 的概念、思想已经基本成熟而基于 OAM 的实现也已经出现 - Crossplane 项目该项目目前为 CNCF 的 Sandbox 项目。
Crossplane 的出现解决了平台维护者也就是负责维护 Kubernetes 的基础设施工程师的难题。但是对于应用研发和运维人员也就是 OAM 的最终用户操作起来并不是十分的友好。基础设施工程师为他们提供了一堆 CRD他们必须逐个去挑选、测试和甄别尤其是一些运维特征Trait可能存在功能冲突不能同时与一个业务组件Component绑定这都都要应用研发和运维人员自己去学习和测试虽然可以通过文档来规范但显然这样做并不优雅这时 OAM App Engine暂定名 RdurX就出现了。 OAM App Engine 的目标用户群体是应用开发者是希望终端开发者用户可以感受到 OAM 提倡的各类应用管理理念带来的价值。相比于其他基于 K8s 的应用管理平台如 rio OAM App Engine 将至少具备如下三大核心价值。
插件系统App Engine 可以通过 OAM 具备快速纳管 operator 的能力轻松扩展各种能力。用户体验贴近开发者一切设计以最终开发者使用体验至上复杂的概念做抽象用户熟悉的概念不隐藏。最佳实践App Engine 将成为 OAM 实现的最佳实践。OAM App Engine 由 CLI 命令行工具、 Dashboard UI 管理页面和一系列编排文件/DSL 组成目前还处于功能设计与开发当中预计在8月底会和用户见面。OAM App Engine 的开发者均来自 OAM 中国社区来自不同的公司和组织是真正的从社区中来服务社区用户。
原文链接https://developer.aliyun.com/article/768884?utm_contentg_1000162429
本文为阿里云原创内容未经允许不得转载。
