隨着kubernetes的興起，不少公司都有了Paas平臺建設的能力，可是應用Paas平臺建設上基本上都是形態萬千，百花齊放，而OAM在筆者看來就是應用Paas平臺建設的kubernetes，將來的事實標準，今天讓咱們一塊兒來聊下OAM吧。java

1. 第1001個Paas平臺

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

1.1 起步階段

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

1.2 平臺化階段

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

1.3 服務化階段

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

這裏咱們要想明白服務化能力與系統功能的區別，好比說發佈系統提供幾十個參數，讓用戶提供隨意的定義，我理解這可能僅僅是功能，由於若是用戶自由度越高，證實平臺流程規範越不統一，並且若是讓一個用戶用系統的時候，得先屢清楚你的幾十個功能參數，上帝，祝你好運！而服務化的能力我理解上應該給用戶提供的是好比發佈策略，儘量少的控制參數，標準化的流程，具體的複雜編排能力徹底內聚到平臺內部，對用戶無感知。就稱之爲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來實現平臺的快速交付

3. 小結

OAM雖然並無標準化，可是相信將來必定很美好，筆者如今也在進行這方面的工做，不過目前僅僅是設計調研階段，歡迎你們一塊兒交流公司平臺建設上面的問題以及各類場景的解決方案，文中的理解僅僅是我的的一些理解，阿里大佬們在推進OAM方面作了不少的努力，在接下來幾篇我會介紹下OAM的更多的東西，感興趣的能夠持續關注下，附錄裏面都是阿里大佬的分享，你們多多關注，今天先到這，下期再見