近日，【CNBPA實踐沙龍】第二期在線上順利舉行，靈雀雲資深產品經理進行了 “雲原生應用交付與管理——OAM模型實踐”的主題分享，和來自金融、工業、能源等不同行業的近百位IT從業者，共同探討如何通過OAM讓應用的構建越來越簡單，實現基礎設施自動匹配架構需求，在雲原生時代真正享受到平臺化的紅利。以下為分享內容回顧。

存在理想的PaaS平臺嗎？

近年來，隨著Kubernetes的不斷成熟，基於Kubernetes的容器PaaS平臺也更為廣泛地被客戶所接受，然而這也衍生出了一些新的問題。

應用運維執行者需要在Kubernetes概念層工作，門檻和成本都比較高。Kubernetes的技術定位是面向基礎設施的，而不是面向開發者的一體化應用平臺，需要在Kubernetes上構建符合自身業務需求的PaaS平臺來提升開發運維效率。這就導致不同應用平臺的差異性很大，缺乏標準統一的應用交付和管理方式。

這時候就需要使用標準化應用模型來構建統一交付平面，實現混合環境下運維資產的統一管理，給雲原生開發者提供自助式的交付和管理體驗，也賦予平臺本身更強大的擴充套件能力。這個趨勢的典型代表就是 OAM 標準。

OAM的目標，就是為PaaS層找到類似的概念，讓應用人員能方便地與自己熟悉的概念對接，從而更快接受、更輕鬆地使用，助力打造相對理想的雲原生PaaS平臺。

如何利用OAM實現雲原生應用的統一交付與管理？

【某工業網際網路平臺企業】

背景及痛點：

該工業網際網路平臺企業，通過引入靈雀雲的容器平臺，建設工業網際網路PaaS平臺，再在工業網際網路平臺之上去建設工業應用。而這時平臺層和應用層之間的”矛盾“就顯現出來了，團隊之間各自定義自己所在層面的應用，彼此之間相對獨立，處理跨平臺的運維任務難度大，往往需要跨平臺、跨團隊的反覆溝通，開發和運維團隊之間在應用運維方面溝通成本相對較高，運維工作自動化程度低

解決方案：

首先，可以依據OAM模型，整理出應用開發和運維規範，讓開發人員更易於理解。

元件和運維特徵都是OAM的基本概念，而需要封裝的元件數量、元件型別和涉及到什麼樣的運維特徵，是使用者可以根據自己的應用特點總結歸納出來的。比如整個應用模型，可以聚類整理成以下內容。

在元件方面，可以總結出以下三個常用元件：

• Microservice，即無狀態、可隨意擴充套件、向外提供服務的應用模組；
• Statefulset，即有狀態、用於儲存持久化資料的應用模組；
• Microtask，即應用中需要偶爾執行的一次性任務。

在運維方面，可以總結出以下幾個常用的運維特徵：

• Expose，即通過埠向外提供服務；
• Health probe，即確認應用模組的健康狀況；
• Ingress，即通過域名提供外部訪問路徑；
• Lifecycle，即生命週期，設定應用模組啟動後和停止前的動作；
• Resource assign，即為應用模組分配計算資源；
• Node affinity，即關於親和性的測試。

其次，需要讓開發和運維團隊有更簡單明確的工作流程。

總結出上述這樣的模型之後，兩個團隊之間的運維就更加規範了。

開發團隊在做應用交付的時候，不用再去考慮Kubernetes層面的概念，在開發時只需要以元件為單位來進行開發，給這些元件設定相應的運維特徵，在進行測試後，就可以進行交付，生成一個基於這個應用模型的應用描述檔案，後續就可以基於這個應用描述檔案，進一步在生產環境中實現應用的自動部署或升級。

開發團隊可以就在元件和運維特徵層面進行開發，同時可以就在這個層面進行應用的運維；而當有新能力需要擴充套件時，運維團隊就可以直接封裝新的元件或運維特徵，然後讓開發團隊使用。這樣兩個團隊工作的切面就比較清晰，整體的工作流程也會更簡單，節省了很多無謂的跨團隊溝通工作。

【某商業銀行】

背景及痛點：

該商業銀行同時存在容器及微服務兩個平臺，這兩個平臺都提供應用管理，那麼這時候就出現了一個問題，應用開發和運維方面存在割裂的風險。他們的訴求是希望能夠把所有的應用管理工作都集中到容器平臺上，而不被微服務平臺所限制，整體平臺的架構怎麼去搭建和打通是亟待解決的。

解決方案：

利用OAM強大擴充套件能力，在容器平臺的應用模組中定義微服務元件，先將應用部署集中到容器平臺。這樣從應用部署層面來看，微服務類的元件和其他型別的元件都可以在容器平臺中進行統一的建立和管理。從應用運維層面來看，後續可以考慮根據實際需要，將服務治理、伸縮等運維操作，通過自定義Trait的方式集中到容器平臺。

靈雀雲ACP的OAM能力

靈雀雲在上述OAM模型的成功落地實踐中，積累了豐富的成功落地經驗，接下來為大家分享一下靈雀云云原生全棧私有云平臺ACP中強大的應用交付與管理能力。

靈雀雲ACP具備開放、靈活、可擴充套件的產品特點，支援靈活對接企業基礎設施、周邊系統、開發運維工具，平臺可擴充套件、可定製。我們在ACP產品中也通過整合OAM實現了應用的統一交付與管理。

首先，ACP介面具備管理OAM應用的能力。在OAM列表頁面裡，OAM應用的名稱、狀態、標籤、元件數量等都可以同步展示出來；在建立OAM元件時，按照先選擇元件型別、根據不同型別去設定不同屬性、再根據元件選擇不同的運維特徵的順序，經過這3個步驟之後，就可以建立一個OAM元件。從操作過程和工作量上來看，比直接在Kubernetes上部署應用會容易很多；

此外，靈雀雲在數百個PaaS平臺實踐經驗中，抽象出了一組常用元件和運維特徵，便於使用者直接進行選擇；

同時，支援使用者進行自定義設定，可方便匯入使用者自定義元件和運維特徵。

綜上，OAM模型強大的擴充套件能力能夠讓各種主流的應用架構，都有相對固定統一的元件來對應，並且能隨時容納新的形式的應用。

我們相信，在OAM模型加持下，雲原生時代的應用交付與管理一定會向更便捷、更智慧的方向發展，我們也期待著能夠以更先進的技術、更開放的平臺，幫助更多行業、更多領域的客戶實現雲原生時代的轉型升級。

傳送關鍵詞【OAM】至靈雀雲微信公眾號，與靈雀雲工程師共同探討雲原生時代的OAM實踐，免費獲取完整演講資料（含PPT下載）。

關於【CNBPA實踐沙龍】

【CNBPA實踐沙龍】由雲原生技術實踐聯盟CNBPA主辦，聚集雲原生領域技術大咖、意見領袖、雲原生技術落地的典型使用者和生態夥伴，探討新技術的創新應用趨勢，展示技術推動業務創新升級的優秀實踐。