云原生時代的應用PAAS模型OAM指的是什么

云原生時代的應用PAAS模型OAM指的是什么，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

隨著kubernetes的興起，很多公司都有了Paas平臺建設的能力，但是應用Paas平臺建設上基本上都是形態各異，百花齊放，而OAM在筆者看來就是應用Paas平臺建設的kubernetes，未來的事實標準，今天讓我們一起來聊下OAM吧。

1. 第1001個Paas平臺

在聊OAM之前我們先聊下傳統的運維開發，從運維系統到運維平臺的演進的過程，以及可能會遇到的問題

1.1 起步階段

在傳統的運維開發中，基礎組件CMDB、自動化、監控、發布、日志、流程幾個系統基本上已經是標配，通過CMDB存儲元數據，自動化提供原子操作，然后通過發布搞定持續交付, 通常可以將這個階段稱為1.0階段，該階段運維可以提供一定的支持能力，該階段運維主要目標是搞定內部需求，對外輸出持續交付能力(僅僅是交付，大多數公司CI流程由測試把控，夸團隊的事情就自行體會吧)

1.2 平臺化階段

平臺化階段主要目標就是通過運維系統的集成，盡可能的實現研發的自助操作，比較典型的就是基于ITSM實現上述流程平臺的聯動，研發填寫固定的工單，然后通過流程編排，整合當前的運維子系統，實現某個場景的自助化操作，減少運維的參與度，提供研發效能，在這個過程中，可能會打通公司的一些別的團隊，比如數據庫、測試、中間件團隊，姑且稱之為2.0階段

1.3 服務化階段

服務化Paas主要是通過底層基礎設施、運維系統的服務化能力，并且公司內部具有高度統一的目標，開始向云化轉變階段轉變，每個團隊都提供高度內聚的服務化能力，同時對外提供該平臺全生命周期的管理能力。

這里我們要想明白服務化能力與系統功能的區別，比如說發布系統提供幾十個參數，讓用戶提供隨意的定義，我理解這可能僅僅是功能，因為如果用戶自由度越高，證明平臺流程規范越不統一， 而且如果讓一個用戶用系統的時候，得先屢清楚你的幾十個功能參數，上帝，祝你好運！而服務化的能力我理解上應該給用戶提供的是比如發布策略，盡可能少的控制參數，標準化的流程，具體的復雜編排能力完全內聚到平臺內部，對用戶無感知。就稱之為3.0階段好了

1.4 1001種選擇

在這個階段通常平臺的建設者就會考慮平臺下一步大的方向是什么，從當前的運維產品類中，我們可以分為三個方向：效能devops方向、Paas方向、運維門戶，但大家有一個很一致的目標就是提高研發效能，實現應用全生命周期管理

1.4.1 運維門戶

運維門戶方向其目標主要是覆蓋測試->發布->運維這三個階段,通過整合運維側的能力，比如cmdb、監控、發布、日志等系統實現應用的統一操作，通常會結合公司的CMDB來實現業務樹來進行統一管理，其優點是符合運維操作需求，個人理解其相對于devops和cloud屬于建設過程中的一個階段，主要強調的是整合。

1.4.2 devops效能

效能devops方向典型的代表就是阿里的云效，從需求->開發->測試->發布->運維->運營實現全鏈路的覆蓋，在大多數工通常都是打通測試->發布->運維->運營這個鏈路就很不錯了，但是通常公司大概率不會做這個事情，只要稍微碰過的就知道這里面需求->開發->測試這幾個階段是多難打通了。

1.4.3 Paas

Paas方向除了測試->發布->運維->運營這個鏈路的覆蓋，很重要的一點是要提供云的基礎能力，其中很關鍵的能力：彈性、多租戶、自服務、按需付費，當然這有很多前提，比如你要彈性得公司有資源才行，按需付費也得公司想搞計費才行，但如果要做系統一定要想好，我們后續萬一要搞混合云呢？

1.4.4 運營

關于運營的理解，運營在運維這側我目前理解就是維穩、降本、提效，穩定性應該是運維根本，運營的主要目標應該是后兩個。

降本是指的平臺可以通過一些機制去確定降低運行成本，其中典型的體現就是業務使用資源是否合理，無論是在k8s還是傳統的vm，都有個問題就是研發申請了了4h8g的機器，真的合理嘛？如果我們可以建立一套運營標準，比如我們可以根據業務在過去周、月、季度、甚至年的資源使用，通過統一的標準去衡量其資源使用率，那有沒有可能降低一些成本呢？

提效可能是很難衡量的一個指標，因為沒辦法做一個平臺之后，就說自己比之前提升了多少，更多的是可能是從用戶使用平臺到底需要多長時間，比如上線應用，從應用創建、資源申請、線上交付一共花了多長時間？比如如果公司提供統一的腳手架，腳手架關聯標準化建設，打通CI、CD、監控、日志、安全等等功能，那研發是不是只需要從git上拉下項目，然后進行代碼開發，最終上線的時候，申請下資源即可？

當然這只是筆者的想法，也沒有實踐，感興趣的可以一起聊聊想法，畢竟這個可能比AIops這些可能更容易落地一些。

1.5 選擇的困惑

其實不論是在效能還是Paas中，我們都有在做同一件事情，就是應用的全生命周期管理，但是我們會發現不同方向、不同公司的應用定義絕對是千差萬別，而且針對應用全生命周期托管沒有統一的規范，而且大多數公司的運維研發團隊規模都并不大，如何設計出高內聚、低耦合、可擴展、分布式的應用Paas平臺，發際線估計又要高不少。

在當下云原生時代，大家可以基于k8s的Paas(Saas)云原生的能力快速構建公司的容器云平臺，我們可能會自己搞個App然后結合Service、DEployment等資源去描述一個應用，然后針對日志/監控等進行改造適配，其實大家潛移默化的就在遵循共同的一種標準，其實就是k8s提供給你的，但是針對應用依賴，比如mysql、redis這種信息怎么描述呢？針對中間件這種又該怎么描述呢？這就是今天的主角OAM

2. OAM初識

OAM 全稱是 Open Application Model，從名稱上來看它所定義的就是一種模型，同時也實現了基于 OAM 的我認為這種模型旨在定義了云原生應用的標準。

• 開放（Open）：支持異構的平臺、容器運行時、調度系統、云供應商、硬件配置等，總之與底層無關

• 應用（Application）：云原生應用

• 模型（Model）：定義標準，以使其與底層平臺無關

該段描述引用自宋老師的文章，參考附錄1

這里我說說我的理解，我們做平臺的都會有個痛點就是千奇百怪的設計，幾年沒動的停機可能起不來應用，誰特么都不敢動，而基于Model，我理解就是，翻滾吧牛寶寶，當然更大的目標肯定是大家有同一個標準，同一個夢想，而且擁有統一的視角。Open開放有兩層含義，1）支持異構：我們通過標準的模型聲明，接納云、虛擬機、物理機、容器不同的基礎設施，這意味著我們可以無限的擴容我們的平臺 2）云原生時代，我們可以復用各種基礎設施，讓小作坊，也可以體驗下五星級酒店的感覺，通過復用云廠商、開源社區可以讓我們平臺無縫享受開源社區的能力， 接下來讓我們一起看看OAM是怎么實現這邊目標

2.1 Component

Component是應用組成的一部分，通常由開發進行描述，如下部分都可以描述為一個Component: 1.研發將自己的程序打包成一個鏡像，通過Deployment部署 2.研發聲明需要使用一個4核8G的mysql5.7的數據庫

這兩個描述都是component,簡而言之研發可以描述的都可以稱為Component，因為他們都是組成Application的一部分，這個部分的Model體現主要是體現在我們通過Component的標準化，可以讓研發只需要關注極少數的需要知道的東西，就可以完成一個應用在研發角度的定義

在這一層我理解基礎設施團隊提供給研發定義應用的能力，研發只需要根據應用需要聲明對應的component組件， 而并不關注底層的基礎設施具體的實現

2.2 Trait

Trait則是運維和基礎架構服務化的能力提供手段，運維可以根據應用的描述，來給應用加對應的Trait，那什么可以稱之為一個Trait呢？比如彈性擴縮容可能是一種Trait，日志可能是一種Trait、監控可能也是一種Trait，幾個實際Trait: 1.研發上線一個java應用，運維這邊根據標準化和服務化能力，就會自動加入對應的監控，這其實就是監控的服務化能力 2.應用灰度發布，發現問題，主動進行回滾，這其實是發布系統服務化能力的體現

通過運維能力的輸出， 研發就不需要關注底層的各種運維細節，只需要聲明應用想擁有的能力，就可以通過實現底層應用運維的自動化托管，不需要關注底層的任何細節，而且各種運維能力可以自由組合，實現應用穩定高效的運行

2.3 Policy

Policy實際上是Component中的概念，體現的其實是研發訴求，比如研發提出我的應用需要響應延遲在100ms以內，那運維就可以根據這個Policy結合自己的服務化能力，提供對應的Trait, 研發其實并不需要知道運維是如何保障SLA的，只需要提供研發訴求Policy，其實就可以完成訴求傳遞，一切可描述，可度量

研發通過聲明Policy傳遞訴求，運維根據訴求結合運維能力，提供對應的保障，一切都是數據化的，既是運維服務化能力的體現，也是研發和運維彼此信任的良好橋梁，同時研發也并不需要關注各種底層的細節

2.4 Application Scope

應用邊界中我們首先要理解邊界，邊界主要是定義具有某些意義的一類應用的邊界，比如在公有云環境中，通常會根據VPC網絡劃分邊界，通過統一的網絡配置，可以劃分出多個網絡區，這些都屬于Application Scope。更復雜的場景則是多數據中心，快速止損，當前大多數公司為了災備都會有多個數據中心，那其實每個數據中心都會劃分為一個邊界，如果發現某個中心突然掛掉了，即對應的Application Scope下面的

而且ApplicationScope可以任意組合，我們可以通過這種玩法，將要進行某一類的應用進行統一的管理，關注其對應的狀態，進而結合我們的Trait來實現各種場景的建設

2.5 Application Configuration

上面我們聲明了組成應用的component, 同時附加了運維的Trait， 還通過AapplicationScope,劃分了對應的網絡或者應用層的邊界， 這些組件都是獨立聲明，可以獨立進行演進，實現了應用接入配置的標準化、模型化、松耦合、自由裝配，剩下的一步就是通過Application Configuration去將Conponent、Trait、ApplicationScope等組合起來，即就是我們最終的應用聲明，基于這份聲明結合面向終態的設計，OAM會按照規則分別進行各個組件的托管，同時我們也可以復用社區優秀的Component和Trait來實現平臺的快速交付。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。