作者：鄧洪超 阿裡巴巴應用傳遞專家
前言
通過 K8s，使用者能夠自定義基礎設施，可以平行的替換或改造平台的已有功能，而非隻能局限在平台提供的能力之上建構。但正是這樣的“白盒化”體驗，正在為越來越多的研發和運維帶來“太複雜”的困擾。
從 Kubernetes 到“以應用為中心”的美好未來之間，全世界的 PaaS 工程師其實都在期待一項全新的技術能夠彌補這之間的鴻溝。阿裡雲原生應用平台團隊的做法是，通過為應用“模組化”的方式來解決這個問題，這也正是 Open Application Model (OAM) 開源項目得以建立的重要目的。
阿裡巴巴的容器化之旅
阿裡巴巴的容器化之旅始于 2013 年。在 Docker 誕生之前，阿裡巴巴基于 lxc 的容器引擎研發了容器技術 T4，用于在裸機上部署和管理應用程式。
2017 年, 阿裡巴巴内部孵化了類似于 K8s 的容器編排引擎 Sigma 作為資源統一層，用于管理内部機器池，平均使用率達到 40％。
2018 年，Sigma 重新設計并遷移成相容 K8s API，阿裡巴巴重新編寫了自定義控制器和排程算法，并向暴露聲明式 API 給使用者試用。
2019 年底，阿裡巴巴中的大多數應用都在 K8s 上運作，并且在 K8s 之上建構了數十個原生架構，構築 K8s 生态系統。而 2019 年的 雙11 活動不僅僅是商業上的成功，更是 K8s 基礎設施可以支援如此大規模的有力證明。
在解決了 K8s 中的規模化和穩定性問題之後，我們開始面臨一個新的挑戰：K8s API 過于複雜，開發人員很難學習。
導緻 K8s API 複雜的 3 個原因
K8s API 之是以複雜，主要有以下三個主要原因：
1. K8s 缺乏以“應用”為中心的資源模型
K8s 中沒有“應用”的概念，隻有松散耦合的基礎架構資源。部署應用需要編寫 Pod、設定網絡和存儲之類的基礎設施資源，非常底層。然而，對于開發人員來說，他們不想配置這些複雜的底層資源資訊，他們想從開發層面指定應用部署規範，例如具有自動擴容、監控、Ingress 等功能的無狀态服務元件。我們需要提供更高層級的應用層抽象和以應用程式為中心的資源模型，以彌合部署應用程式和配置之間的差距。
2. K8s API 中沒有分離開發和運維的關注點
其次，K8s API 中沒有分離開發和運維的關注點。從上圖可以看出，K8s 将所有屬于不同角色的字段封裝在一個 API 中。例如，開發人員僅需指定容器映像、端口和運作狀況檢查；運維人員則負責配置副本大小、滾動更新政策、存儲卷通路模式等。
對于 K8s API 來說這樣的聲明是沒有問題的。K8s 意在公開基礎架構功能，并用于建構其他平台。是以，它需要包含所有内容，并提供多合一的 API。但是，我們發現多合一 API 不适合寫應用程式的終端使用者。在 K8s API 之上，我們需要區分角色、将開發和運維的關注點分離開。
3. 在 K8s 上沒有可移植的應用抽象定義
K8s 定義了使用基礎資源的标準方法。但是如上所述，部署應用程式需要網絡接入、監控、日志等。我們需要對那些應用程式操作接口進行标準化，實作可移植的應用層抽象。
OAM 開啟下一代雲原生 DevOps 技術革命
針對上述 K8s API 過于複雜、開發人員難學習的問題，這裡來介紹一下由阿裡巴巴聯合微軟在社群推出的用于建構和傳遞雲原生應用的标準規範 -- 開放應用程式模型 OAM（Open Application Model）。
2019 年 10 月，阿裡巴巴宣布聯合微軟共同推出開放應用模型項目（Open Application Model - OAM）。
所謂“應用模型”，其實是一個專門用來對雲原生應用本身和它所需運維能力進行定義與描述的标準開源規範。是以對于 Kubernetes 來說，OAM 即是一個标準的“應用定義”項目（類比已經不再活躍的 Kubernetes Application CRD 項目），同時也是一個專注于封裝、組織和管理 Kubernetes 中各種“運維能力”、以及連接配接“運維能力”與“應用”的平台層項目。
在 OAM 中，一個應用程式包含三個核心理念：
第一個核心理念是組成應用程式的服務元件（Component），它包含微服務、資料庫、雲服務等；
第二個核心理念是描述應用程式運維特征（Trait）的集合，例如，彈性伸縮和 Ingress 等功能。它們對應用程式的運作至關重要，但在不同環境中其實作方式各不相同；
最後，為了将這些描述轉化為具體的應用執行個體，運維人員使用應用配置（Application Configuration）來組合元件和相應的特征，以建構可部署的應用傳遞執行個體。
如上圖所示，我們可以看到開發人員定義了元件 (Component) 來描述服務單元。然後運維人員定義運維特征 (Trait)，并将其附加到前面的元件上，最後構成 OAM 可傳遞物 -- ApplicationConfiguration。在圖中最下方，底層的基礎設施資源将通過 OAM 平台呈現。
那麼 OAM 如何解決上述三個 Kuberntes API 的問題？首先，OAM 隐藏了底層基礎架構細節（例如，是雲還是物聯網），專注于應用層抽象，提供以應用為中心的資源模型。其次，OAM 劃分了應用傳遞路徑上的開發、運維、基礎架構三種角色，分離了關注點，讓流程更加清晰和易于管理。第三，K8s 定義了基礎架構的可移植抽象，而 OAM 站在 K8s 的肩膀上，提供了可移植的應用層抽象，讓同一個應用可以跨平台運作。
OAM 還定義了一組核心工作負載/運維特征/應用範疇，作為應用程式傳遞平台的基石。并且，這些核心規範有一個開源實作 -- Crossplane。Crossplane 提供了讓使用者擴充其功能的機制。例如 Crossplane core 提供的 ContainerizedWorkload，在容器中運作應用程式并管理應用程式的生命周期。
此外，我們還可以添加更多工作負載（例如 FaaS）以運作無伺服器功能，或者添加運維特性（例如 CronHPA）來定義 CronJob 類型的 HPA 政策。OAM 以标準的聲明方式在單個平台中管理應用傳遞能力和流程。當子產品化的 Workload 和 Trait 越來越多，就會形成元件市場。而 OAM 就像是這個元件市場的管理者，處理元件之間的關系，把許多元件內建起來變成一個産品傳遞給使用者。OAM 加持下的 PaaS，可以像樂高積木一樣靈活組裝底層能力、運維特征、以及開發元件。使得應用管理變得統一，功能卻更加強大！
結語
以上我們讨論了 OAM 的背景、動機和架構細節。值得注意的是，OAM 項目是開源中立、由社群驅動的。該規範和實作得到包括 Alibaba、Microsoft、Upbound 在内的開放社群的支援。我們歡迎更多的人參與其中，共同定義雲原生應用傳遞的未來。
您可以在 github repos 上貢獻：https://github.com/oam-dev/spec
加入郵件清單: https://groups.google.com/forum/#!forum/oam-dev
加入社群周會: Bi-weekly, Tuesdays 10:30AM PST
加入釘釘讨論群:
“阿裡巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”