Open Application Model 是什么？

Open Application Model 是一個用來構建云原生應用的規范。它描述了一個模型，開發人員可以在其中定義應用程序組件。應用程序操作員負責創建這些組件的實例并為它們分配應用程序配置。基礎架構運營商負責定義、安裝和維護平臺上可用的基礎服務。

OAM 是一個專注于描述應用的標準規范。有了這個規范，應用描述就可以徹底與基礎設施部署和管理應用的細節分開。這種關注點分離（Seperation of Conerns）的設計好處是非常明顯的。 舉個例子，在實際生產環境中，無論是 Ingress、CNI 還是 Service Mesh，這些表面看起來一致的運維概念，在不同的 Kubernetes 集群中可謂千差萬別。 通過將應用定義與集群的運維能力分離，我們就可以讓應用開發者更專注應用本身的價值點，而不是”應用部署在哪“這樣的運維細節。

此外，關注點分離讓平臺架構師可以輕松地把平臺運維能力封裝成可被復用的組件，從而讓應用開發者專注于將這些運維組件與代碼進行集成，從而快速、輕松地構建可信賴的應用。Open Application Model 的目標是讓簡單的應用管理變得更加輕松，讓復雜的應用交付變得更加可控。

OAM 為什么值得關注？

• 關注點分離：開發者關注應用本身，運維人員關注模塊化運維能力，讓應用管理變得更輕松、應用交付變得更可控。
• 平臺無關與高可擴展：應用定義與平臺層實現解耦，應用描述支持任意擴展和跨環境實現
• 模塊化應用運維特征：可以自由組合和支持模塊化實現的運維特征描述

Kubernetes 項目作為容器編排領域的事實標準， 成功推動了諸如阿里云 Kubernetes （ACK）等云原生服務的迅速增長。但同時我們也關注到，Kubernetes 的核心 API 資源比如 Service、Deployment 等，實際上只是應用中的不同組成部分，并不能代表一個應用的全部。也許，我們可以通過像 Helm charts 這樣的方式嘗試表達一個可部署的應用，可一旦部署起來，實際運行的應用中卻依舊缺乏以應用為中心的約束模型。這些問題都反映出，Kubernetes 以及云原生技術棧需要一種以應用為中心的 API 資源來提供一個專注于應用管理的、標準的、高度一致的模型，這個 API 資源可以代表完整運行的應用本身，而不僅僅是應用模板或者一個應用的幾個組成部分，這就是今天阿里云與微軟聯合宣布推出開放應用模型 Open Application Model （OAM）的原因。

一、應用組件（Components）

在 OAM 中，“應用”是由多個概念共同組合而成。第一個概念是：應用組件（Components），它是整個應用的重要組成部分。所以說，應用組件既可以包括應用運行所依賴的服務：比如 MySQL 數據庫，也包括應用服務本身：比如擁有多個副本的 PHP 服務器。開發者可以把他們寫的代碼”打包“成一個應用組件，然后編寫配置文件來描述該組件與其他服務之間的關系。應用組件的概念讓平臺架構師等能夠將應用分解成成一個個可被復用的模塊，這種模塊化封裝應用組成部分的思想，代表了一種構建安全、高可擴展性應用的最佳實踐：通過一個完全分布式的架構模型，實現了應用組件描述和實現的解耦。

二、應用部署配置文件（Application Configuration）

為了將這些應用組件描述變成一個真正運行起來的應用，應用運維人員會通過一個專門的、包含了所有應用組件信息的部署配置文件來實例化這個待運行的應用。這個配置文件本身也是 OAM 規范中的一個聲明式 API，用來讓應用運維人員能夠根據開發者或者平臺提交的應用描述，實例化出對應的、真正運行起來的應用。

三、應用運維特征（Traits）

最后一個概念是一組應用運維特征（Traits），它們描述了應用在具體部署環境中的運維特征，比如應用的水平擴展的策略和 Ingress 規則，這些特征對于應用的運維來說非常重要，但它們在不同的部署環境里卻往往有著截然不同的實現方式。 舉一個簡單的例子，同樣是 Ingress，它在公有云上和本地數據中心的實現可能完全不同：前者一般是 SLB 這樣的云服務，而后者則可能是一個專門的硬件。這也就意味著針對這兩個環境的 Ingress 運維工作，將會有天壤之別。 但與此同時，無論是在哪個環境里，這個 Ingress 規則對于應用開發人員來說，可能是完全相同的。應用特征的設計，讓這種關注點分離成為可能：只要這兩個環境在 OAM 模型下提供了對 Ingress 這個應用運維特征的實現，那么應用就可以使用統一的 Ingress 規則描述，無差別地在這兩個地方運行起來。與此同時，這兩個環境的基礎設施供應商可以繼續通過配置這些應用特征的實現，來滿足它們各自的運維要求（例如：不同環境里 Ingress 實現在滿足合規性和安全性上的差異）。

OAM：平臺無關、高可擴展的應用描述能力

與 PaaS 應用模型相比，OAM 有很多獨有的特點，其中最重要一點是：平臺無關性。雖然我們目前發布的 OAM 實現（rudr）是基于 Kubernetes 的，但?Open Application Model?與 Kubernetes 并沒有強耦合。實際上 ，OAM 可以實現到任意平臺或運行環境之上，這當然也包括邊緣計算與物聯網的場景。我們也認同 Kubernetes 在很多運行環境中可能并不是最好的選擇，或者是像 Serverless 這類用戶并不需要關心基礎設施復雜性的運行環境。在這些場景下，OAM 都可以提供完全一致的應用管理體驗。

第二個重要的特點是，OAM 的?specification （OAM 規范） 在設計上天然是可擴展的。OAM 不像 PaaS 那樣自成封閉體系，也不會通過某種獨有的應用管理環境屏蔽掉底層平臺的特點（比如：在 Kubernetes 之上”蓋一個大帽子“）。 相反，OAM 使平臺層可以通過應用特征系統 （Trait system）來體現平臺的特性和差異性。也就是說，只要不同的平臺都能夠提供應用所需要的某些應用特征 (Trait)，開發人員就能輕松地研發跨平臺的應用。類似地，哪怕最底層的硬件提供商，也可以通過應用特征系統來體現其平臺特性。OAM 的整體設計，就是為了避免在平臺可移植性中經常發生的“最小公分母”鎖定問題。相反，OAM 不但提供了可移植性的能力，還確保了每個平臺有能力去透出獨有的特性和用途。OAM 讓開發人員可以自由地針對不同平臺以標準方式在可移植性和差異化功能之間取得平衡。

開放的社區與未來

如今，開放應用模型以及相應的 Kubernetes 實現有了初步成果，我們感到非常興奮。 OAM 規范是基于 Open Web Foundation 協議進行開發的。我們的目標，從一開始就是讓開放應用模型 Open Application Model 成為中立基金會的項目，以便實現開放治理與廣泛合作。如果開發者希望了解更多信息，請前往開放應用模型項目的 GitHub 倉庫：?OAM specification?，以及基于 Kubernetes 的 OAM 標準實現?Rudr?。

介紹內容來自 InfoQ