簡介：?受阿里云邀請，我有幸在《云原生架構白皮書》發布前試讀了該書，本文結合白皮書內容，談談開放應用模型（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_content=g_1000162429

本文為阿里云原創內容，未經允許不得轉載。

?

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的读完《云原生架构白皮书》，我们来谈谈开放应用模型（OAM）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。