像智能手機同樣管理雲端應用：阿里雲聯合微軟全球首發開放應用模型（OAM）

2019 年 10 月 17 日上午 9 點 15 分，阿里巴巴合夥人、阿里雲智能基礎產品事業部總經理蔣江偉在 QCon 上海《基於雲架構的研發模式演進》主題演講中，正式宣佈：

「今天，咱們同微軟聯合發佈了一個全新的項目，叫作開放應用模型 Open Application Model（OAM）。」

項目主頁：openappmodel.io

蔣江偉在發佈中講道：「OAM 這個項目是業界第一個雲原生應用標準定義與架構模型。咱們但願經過這樣的架構模型，以高效、標準的方式鏈接應用開發者、運維人員和應用的最終用戶，讓這些雲端應用的參與者可以享受到像智能手機上同樣簡單、輕鬆、暢快的應用管理體驗。」

與此同一時間，微軟傑出工程師（Distinguished Engineer） 、Kubernetes 項目創始人 Brendan Burns 也在微軟的官方網站上，宣佈了同阿里雲的此次重量級聯合發佈。

圖片來源：cloudblogs.microsoft.com/opensource/…

你可能會好奇，到底什麼是 OAM 呢？又是什麼緣由，讓兩家全球頂級技術公司走在一塊兒，但願聯合整個雲原生技術社區共同推動這樣一個應用定義與架構模型項目呢？

這個事情自己，可能要從世界上最先的一次雲端應用交付的故事講起。

一個雲端應用交付的故事

2006 年 3 月 14 日，美國某在線電商公司發佈了一個叫作 Simple Storage Service（簡稱 S3）的存儲服務。在這個服務發佈不久，一名來自微軟的技術人員帶着嚐鮮的想法，編寫了一個使用該服務做爲底層存儲的應用。據這位開發者講述，從決定編寫應用到將該應用交付運行「總共花掉了幾天的時間」。對此，他感到很是興奮，後來他在本身的博客裏這麼寫到：

「這個服務的發佈，完全改變了技術行業的遊戲規則」。

這位開發者的名字，叫作 James Hamilton 。他是 IBM DB2 早期的架構師，也是當時 Microsoft SQLServer 的負責人之一。就在編寫完這個神奇的應用兩年後，他選擇加入了這家電商公司。現在，James Hamilton 已經成爲了 AWS 的副總裁（VP）和標誌性人物。

從 2006 年到如今，雲計算經歷了一波又一波變革和浪潮。現在的雲，早已再也不是 13 年前那個大衆眼裏須要「嚐鮮」的陌生事物。現在的雲服務，也早已在一次次的變革之中脫胎換骨，在成本和資源效率的極致優化中，將「摩爾定律」的失效推上了頂峯。2019 年 8 月，阿里雲驕傲的向全世界宣佈，雲計算「拐點已至」。上雲，正迅速成爲企業進行應用架構和基礎設施規劃的默認選項。
 
在 2019 年，若是一位開發者要像 James 當年同樣，把一個 Java Web 網站在雲平臺上線，到底體驗如何呢？

雲端應用管理的兩大難題

在回答上面的問題以前，咱們不妨先思考一下：現現在在智能手機上安裝一個應用，是什麼樣的體驗？升級應用呢？

在以 iPhone 爲表明的智能手機上，應用管理的體驗其實是一個「如絲般順滑」的感覺。

如今，咱們再回過頭來看雲。

一個雲上的應用，確定不僅是簡單的可執行文件。就拿 Java Web 網站爲例，這個應用要想在雲平臺上被最終用戶使用到，就須要有大量的外部依賴須要處理。這就是雲端應用開發者實際上關心的事情，其實一點也不簡單：

這種狀況下，在雲上交付一個應用的過程，實際上很是坎坷。

舉幾個例子：做爲雲上的開發者，咱們首先須要花費大量的時間來進行應用總體部署架構的設計，才能大體搞清楚這個應用到底須要開通哪些雲服務。但這依然避免不了一些讓人頭疼狀況的發生，例如：

• 由於一個操做流程失誤，一些須要預先申請的雲資源不到位，就得返工重來；
• 一旦某個雲服務的配置不合理，就得從新配置，甚至刪掉重來；
• 整個上線應用的過程，咱們須要不停地在各類雲產品控制檯之間來回跳轉；
• 還有不少時候，咱們不得不一個一個手工處理應用刪除遺留下來的各類雲資源。

上述狀況的出現，總的來講是由於雲上應用管理的過程，其實是一個離散的狀態，致使整個流程雜亂無序，也很難把控，出錯返工就在所不免了。

再舉個例子。除了過程上的繁雜以外，雲端應用管理的另外一個現狀就是：開發者老是須要不停的去開通和配置各類各樣的雲服務，同時也要花大量的時間去開發各類雲產品的開通和接入代碼。尤爲讓人頭疼的是，這些全部對雲服務的開通、配置和接入工做，幾乎都是「一次性工做」。我給一個應用組件作的事情，再上線另外一個應用組件的時候，又得所有從新作一遍。甚至有時候爲了接入一個新的雲服務，必須從新開發整個應用。上述狀況的出現，歸根究竟是由於對於應用所依賴的雲服務來講，它們的開通與配置工做，並非一個可複用的能力，這就致使了大量的重複勞動和對接工做須要一而再、再而三的在應用管理的過程當中不斷重複進行。

這些狀況，都是現今制約和困擾着雲端應用開發和運維人員的幾個典型「症狀」，也點明瞭當前雲應用管理過程「耗時」、「耗力」背後，兩個顯著的癥結所在：

1. 應用自己：不能以統1、自描述的方式定義應用與雲資源的關係；
2. 雲基礎設施自己：沒有一種統1、標準、高效的方式交付給應用使用。

智能手機 VS 雲

在體驗到了手機上 App 管理的流暢和簡單以後，如今再來看雲端應用管理的卡頓和繁雜，咱們不由會想到這樣一個問題：雲計算技術突飛猛進的今天，咱們是否有機會在雲上也感覺到像智能手機同樣的應用管理體驗呢？

事實上，若是咱們深刻分析一下智能手機上的應用管理體系和現在的雲端應用管理架構，就會發現，這二者本質上是徹底一致的**。

首先，在標準的硬件，或者說手機的「標準化基礎設施」之上，智能手機已經爲使用者鋪上了一個「標準化的接入層」。**在 iPhone 上，這個標準化接入層，就是 iOS 操做系統，它對上暴露出 UNIX 風格的操做系統接口來屏蔽掉底層資源的細節。在雲上，這一層實際上就是 Kubernetes 和雲服務自己的 OpenAPI。 但，這顯然還不是所有。 不管是應用開發者仍是 APP 最終用戶，咱們仍是不會直接跟 UNIX 操做系統接口打交道。這是由於，**在「標準化的接入層」之上，iPhone 還爲使用者提供了一整套的「標準化應用架構與管理體系」。**這套體系，既包括了對操做系統接口的 Library 化封裝（即：模塊化的 SDK），也包括應用如何組織和打包的交付規範，還以此爲基礎，提供了 IDE 等一系列開發工具甚至編程語言。這才使得基於 iOS 之上的應用管理，呈現出了「如絲般順滑」的用戶體驗。 這時候，咱們再回過頭來看雲計算。**就會發現：在對應「標準化的應用架構與管理體系」這一層，雲的能力目前是缺失的。雲上的應用，並無一種統一和標準的方式來描述本身與雲資源的關係，也沒有一種統一和標準的方式來對接雲計算的基礎設施服務。 這也是爲何在 2006 年，一位開發者上線世界上最先的 S3 應用，只須要花費幾天的時間，然而 13 年後，當雲計算提供的能力已經強大到天壤之別的今天，咱們在雲上交付和升級一個 Java Web 網站，卻恐怕仍是要花費數小時之久，甚至更長。

什麼是 OAM？

開放雲應用模型 Open Application Model（OAM），它正是一個雲原生時代的應用標準定義與架構模型。Open Application Model 的主要內容，就是爲雲端應用管理者提供了一套描述應用的規範。應用管理者只要遵照這個規範，就能夠編寫出一個自包含、自描述的「應用定義文件」。具體的說，這個應用定義文件實際上由兩部分組成：

應用描述 = 應用組件 + 應用特徵

**應用組件：應用開發者經過一個聲明式的描述，來定義他要部署和管理的是什麼樣的應用。**好比，是 Java Web 網站？是容器？仍是 Function？這個應用怎麼運行，是經過 Kubernetes ？仍是 ECS？須要注意的是，這個應用描述，是對應用自己開發和運行方式的、一個開發人員視角的敘述，它不會包括任何應用運維和基礎設施相關的細節。

**應用特徵：應用運維人員則經過另外一個聲明式的描述，來定義這個應用的「運維特徵」。**好比，安全組策略怎麼設置？路由訪問策略是什麼規則？水平擴展策略如何？能夠看到，這些應用特徵，其實是對應用運維細節和基礎設施能力的敘述。

**因此說，在 OAM 規範下，在雲上管理一個應用，其實是經過這樣兩個聲明式的描述配合來完成的。**在實際操做中，應用開發人員只須要提交他所編寫的應用描述，運維人員則負責定義和管理各類各樣的應用特徵。雲平臺或者應用架構師，則負責按照應用描述中的需求，爲它綁定合適的應用特徵。

而 OAM 這套規範的特殊性在於，它並非一套「應用配置 + 外部依賴 」的簡單組合，而是在應用定義的規範中，「植入」了對雲端應用管理相當重要的兩個「解耦」：

• **第一，應用管理過程當中的角色解耦。 **經過這個解耦，OAM 應用管理流程中開發和運維角色就能夠各司其職，只關注本身關心的部分，這是 OAM 提高開發者生產力的重要途徑。而與此同時，雲平臺或應用架構師，則能夠靈活的組合應用特徵和應用描述，從而在徹底不影響開發人員體驗的狀況下，爲雲上的應用搭配合適的應用特徵。這種關注點分離（Seperate Conerns）的設計，使得 OAM 模型下的應用的定義，不只職責明確，同時也能清晰的自描述出一個應用所依賴的全部雲基礎設施能力（即：特徵），併爲對它們的關係進行系統化管理提供了基礎。

• **第二，應用定義與實現層解耦。**經過這個解耦，用戶的應用定義和雲的基礎設施能力是徹底分開的。因此一個應用，不會再被侷限於只能運行某種具體的平臺或者雲服務上：對於這些應用運行時的選擇，只是應用描述中的一個可配置參數而已。而應用的運維特徵，在實現層實際上就是每個雲基礎設施能力的模塊化實現。因此一旦一個應用描述與某個應用特徵綁定，雲平臺就能夠自動將對應的雲服務接入到應用運行時當中，從而避免了用戶陷入到「永無止境」的雲服務開通和配置工做中。

不過，OAM 對於雲端應用管理的價值，還遠遠不止更好的用戶體驗這麼簡單。

應用特徵系統：平衡可移植性和差別性

在 Open Application Model 的模型中，應用管理人員能夠靈活搭配應用描述與應用特徵，從而對接不一樣的雲基礎設施能力到應用中。這種基礎設施能力經過 OAM 對用戶透出以後，實際上就可以差別化的表達不一樣運行環境可以爲應用提供的不一樣基礎設施能力。

舉個例子，一位開發者定義了一個叫作「車」的應用描述，並作出了以下敘述：

• 要有安全性
• 要能有操控能力
• 要有行使動力

而後，他把這樣的應用描述交給了雲平臺，雲平臺根據這個描述，爲它綁定了一組比較基礎的「應用特徵」：

• 安全：安全帶、氣囊、普通剎車
• 操控：手動 5 檔、普通方向盤
• 動力：普通發動機

這樣，這個應用在它的最終用戶看來，實際上就是一個「家用汽車」。

可是，過了一陣子，開發者決定對這個「車」進行一次升級。這時候，他該怎麼作呢？

實際上，他什麼也不用作。他只要告訴應用運維，爲以前的「車」應用描述，綁定一組更加「強大」的應用特徵便可，好比：

• 安全：高強度車架、懸掛減震、全身防禦、賽車式剎車
• 操控：手動 8 檔、賽車方向盤
• 動力：賽車引擎

因此，一旦上述「更強大」的應用特徵，同「車」應用描述綁定，咱們就能夠將一個「家用車」馬上升級成一部強大的「賽車」。而在這個過程當中，應用開發和應用運維惟一要作的事情，就是像「樂高積木」那樣，靈活搭配和組裝不一樣的應用特徵而已。
 
而更重要的是，OAM 的設計初衷之一，是要提供標準化雲端應用管理體驗，這就須要「抹平」不一樣運行環境之間的不一樣，以便讓應用「 一次定義，多處運行」。但與此同時，OAM 提供的應用特徵系統，則使得雲平臺標準化的暴露出本身的能力以後，用戶依然能夠經過對比不一樣運行環境的應用特徵的差別，從而更準確的選擇本身的應用要部署到哪一個運行環境當中，真正意義上實現「Define Once, Run Where I Choose」 的交付體驗。因此說，應用特徵系統，正是 OAM 在設計中平衡可移植性和差別性的一個重要的創新之舉。

OAM 項目的現狀與將來

OAM 開源項目，主要包括了兩部份內容：

1. Open Application Model Specification （OAM Spec）：這個項目是 OAM 模型的官方規範與標準庫。在這個代碼庫中，詳細的闡述和定義了 OAM 模型中的全部核心理念和詳細到具體字段的 API 規範。與此同時，這些全部的 Spec 也都原生提供了進一步的擴展規範，使得這個模型自己具有了接入任意運行時、模塊化任意雲基礎設施能力、標準化描述任意應用運維特徵的、高靈活度的模型約束力。能夠看到，這個庫堪稱 OAM 的使用者和實現者的官方「聖經」。

OAM Spec 項目 GitHub 地址：github.com/oam-dev/spe…

2. Rudr 項目: 這個項目，是 Open Application Model 在 Kubernetes 上的標準實現。Rudr 項目自己是 Kubernetes 的一個標準插件，只要安裝上去便可爲用戶提供標準的 OAM 風格的的應用管理能力，經過模塊化應用特徵同 SMI，Knative，Istio 等應用基礎設施能力無縫對接。值得一提的是，Rudr 項目是由 Rust 編寫完成的，它的實現簡潔、高效，性能優異，也是全世界第一個 Rust 實現的 Kubernetes 生態開源組件。

Rudr 項目 GitHub 地址：github.com/oam-dev/rud…

雖然 OAM Spec 和 Rudr 項目目前是由阿里雲和微軟雲的工程師共同發起和維護的，但這兩個項目自己，均從一開始就採用中立基金會的方式進行運做，使用徹底中立和開放的開源貢獻者協議，同任何一家公司或者組織都沒有綁定關係。這麼作的緣由也很是明朗：做爲將來雲計算應用管理生態的基礎性模型，Open Application Model 從一開始就採用徹底中立和開放的方式同整個社區協做，並計劃在項目穩定後便移交給中立基金會進行託管。

目前，OAM 已經在阿里雲多個項目中進行了數月的內部落地的嘗試。經過一套統1、標準的應用定義體系，承載了多個雲應用管理項目和產品的應用與外部資源關係的高效管理，並將雲原生應用管理體驗統一的帶給了基於 Function、ECS、Kubernetes 等不一樣運行時的應用管理流程；經過應用特徵系統，將多個阿里雲獨有的能力進行了模塊化，大大提升了阿里雲基礎設施能力的交付效率。 與此同時，做爲 OAM 的初創參與方，微軟 Service Fabric 團隊已經開始經過 OAM 模型將 Service Fabric 強大的應用基礎設施能力進行了「樂高積木化」，從而無縫接入到雲原生技術體系當中，並進一步在此基礎上開始了「Mesh 化編程模型」的構建。

在將來的發展過程當中，OAM 將會始終致力爲雲應用管理的參與者帶來智能手機通常的使用體驗，在保證可移植性和可擴展性的前提下，以標準化的方式幫助「應用」高效和高質量地交付到世界上任何一個位置。咱們期待全世界每一位開發者和每個雲計算生態的參與者，都能加入到這個全新的應用架構模型的發展過程當中來，共同打造一個繁榮的雲端應用生態背後的標準模型和基礎依賴。

「 阿里巴巴雲原生微信公衆號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術公衆號。」