今天就跟大家聊聊有關(guān)OAM存在的意義是什么，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

創(chuàng)新互聯(lián)建站堅持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都網(wǎng)站設(shè)計、成都網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時代的營口網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

OAM Kubernetes Runtime 將會成為 OAM 社區(qū)官方維護的基礎(chǔ)組件，目標是在 Kubernetes 上提供穩(wěn)定且統(tǒng)一的 OAM 核心插件。 

為進一步了解，本次探討了 OAM 項目存在的意義。

OAM 因何而生

我們知道，應(yīng)用容器技術(shù)自誕生開始，就以 “徹底改變了軟件打包與分發(fā)方式” 的魅力迅速征服了幾乎所有的云廠商與數(shù)據(jù)中心。 不過，軟件打包與分發(fā)方式的革新，并沒有能夠讓軟件本身的定義與描述發(fā)生本質(zhì)的變化，基于 K8s 的應(yīng)用管理體驗，也沒有讓業(yè)務(wù)研發(fā)與運維的工作變得更簡單。 

實際上，Kubernetes 帶來的云原生技術(shù)革命，在于實現(xiàn)了基礎(chǔ)設(shè)施層的標準化和抽象，但這一層抽象距離業(yè)務(wù)研發(fā)與運維還是太過遙遠了。一個最典型的例子，直到今天，Kubernetes 里面始終都沒有 “應(yīng)用” 這個概念，它提供的是更細粒度的 “工作負載” 原語，比如 Deployment 或者 DaemonSet。

而在實際環(huán)境中，一個應(yīng)用往往是由一系列獨立組件的組合，比如一個 “ PHP 應(yīng)用容器” 和一個 “數(shù)據(jù)庫實例” 組成的電商網(wǎng)站；一個 “參數(shù)服務(wù)節(jié)點” 和一個 “工作節(jié)點” 組成的機器學習訓練任務(wù)；一個由 “Deployment + StatefulSet + HPA + Service + Ingress” 組成的微服務(wù)應(yīng)用。

“應(yīng)用” 這個概念在 Kubernetes 項目中的缺失，既是一個有意而為之的設(shè)計，卻也造成了今天云原生應(yīng)用管理生態(tài)的極度碎片化和極高的學習門檻。如何通過標準化的方式去解決這個 “ Kubernetes 里到底什么是應(yīng)用” 的問題，正是 OAM 項目發(fā)布的最初始動機。 

有什么意義？

在 OAM 發(fā)布之前，云原生生態(tài)里其實并沒有一個叫做 “應(yīng)用” 的概念。哪怕在今天，全世界幾乎每一個在落地云原生的團隊，都有一個自己定義的 “應(yīng)用” 的概念，它們的抽象程度層次不齊，定義方式也豐富多樣，這就導(dǎo)致了所有圍繞著這些 “應(yīng)用” 構(gòu)建出來的系統(tǒng)，就成為了一個又一個的大煙囪。 

對于整個云原生生態(tài)來說，這種應(yīng)用層的碎片化和煙囪化，其實對于整個生態(tài)演進是非常不利的。而今天的現(xiàn)狀也已經(jīng)證明了這一點，在 Kubernetes 逐漸標準化了基礎(chǔ)設(shè)施能力的接入方式之后，原本更加接近用戶、更加重要的應(yīng)用管理層，卻幾乎停滯了演進，在最近幾年里沒有提出任何一個創(chuàng)新性的思想出來。 

應(yīng)用管理層停滯不前的結(jié)果，就是全世界的業(yè)務(wù)研發(fā)和運維一夜之間都被迫變成了 “容器專家”，一邊學習著根本不應(yīng)該是他們關(guān)心的各種 “基礎(chǔ)設(shè)施即數(shù)據(jù)（Infrastructure as Data）” 領(lǐng)域的概念（比如：聲明式 API，控制器等），一邊吐槽 Kubernetes 實在是太復(fù)雜了、設(shè)計太奇葩了。 

簡而言之，Kubernetes 作為一個面向基礎(chǔ)設(shè)施工程師的系統(tǒng)級項目，主要負責提供松耦合的基礎(chǔ)設(shè)施語義，這就使得用戶學習和操作 Kubernetes YAML 文件的時候，往往會感覺這些文件里的關(guān)注點非常底層，學習門檻很高。 

實際上，對于Kubernetes 真正的最終用戶比如業(yè)務(wù)研發(fā)人員和運維人員來說，他們并不想配置這些如此底層的資源信息，而是希望有更高維度的抽象。這就要求一個真正面向最終用戶側(cè)的應(yīng)用定義，需要能夠為業(yè)務(wù)研發(fā)和應(yīng)用運維人員提供各自視角的應(yīng)用定義原語。所以說，OAM 帶來的第一個改變，就是提供了一種大家都可以遵循的、標準化的方式來定義更高層級的應(yīng)用層抽象，并且把“關(guān)注點分離”作為這個定義模型的核心思想。

而 OAM 帶來的第二個變化，則是為 Kubernetes 項目帶來了應(yīng)用定義，更確切地說，是對應(yīng)用本身和它所需運維能力進行定義與描述的標準開源規(guī)范。站在 Kubernetes 項目的角度來講，OAM 是一個 Kubernetes 原生的標準的“應(yīng)用定義”項目，同時也是一個專注于封裝、組織和管理 Kubernetes 中各種“運維能力”、以及連接“運維能力”與“應(yīng)用”的平臺層框架。 

詳細的說，OAM 基于 Kubernetes API 資源模型（Kubernetes Resource Model）來標準化應(yīng)用定義的規(guī)范，它強調(diào)一個現(xiàn)代應(yīng)用是多個組件的集合，而非一個簡單的工作負載或者 K8s Operator。所以在 OAM 的語境中，一個 PHP 容器和它所依賴的數(shù)據(jù)庫，以及它所需要使用的各種云服務(wù)，都是一個“電商網(wǎng)站”應(yīng)用的組成部分。更進一步的，OAM 把這個應(yīng)用所需的“運維策略”也認為是一個應(yīng)用的一部分，比如這個 PHP 容器所需的 HPA（水平自動擴展策略）：

以 Crossplane 項目為例，它在本次合作中通過 OAM 升級之后得到了怎樣的變化呢？

“ 作為混合云管理領(lǐng)域中的佼佼者，Crossplane 的 OAM 化保證了今天任何一個符合 OAM 規(guī)范的待運行程序、運維能力和它所依賴的云服務(wù)，可以組成一個整體在混合云環(huán)境中無縫漂移?！?nbsp;

這種平臺無關(guān)的應(yīng)用定義范式，使得應(yīng)用研發(fā)人員只需要通過 OAM 規(guī)范來描述他們的應(yīng)用程序，那么該應(yīng)用程序就可以在任何 Kubernetes 群集或者 Serverless 應(yīng)用平臺甚至邊緣環(huán)境上運行，而無需對應(yīng)用描述做任何修改。本次合作中 Crossplane OAM 版的發(fā)布，則意味著 OAM 社區(qū)正在將標準應(yīng)用定義和標準化的云服務(wù)管理能力統(tǒng)一起來，從而實現(xiàn)真正的 “云端應(yīng)用交付” 。 

OAM 如何發(fā)揮作用

那么 OAM 在一個項目中是如何運作的呢？

據(jù)介紹，OAM 以原生插件的方式運行在 Kubernetes 當中。OAM 強調(diào)整個模型是關(guān)注點分離的。即業(yè)務(wù)研發(fā)人員負責定義和維護組件 (Component) 來描述服務(wù)單元，而運維人員定義運維特征 (Trait)，并將其附加到前面的組件上，最后構(gòu)成 OAM 可交付物 ——ApplicationConfiguration。

這種設(shè)計是 OAM 在能夠無限接入 Kubernetes 各種能力的同時，保證給業(yè)務(wù)研發(fā)與運維人員提供最佳的使用體驗和最低的心智負擔的重要基礎(chǔ)。與此同時，基礎(chǔ)設(shè)施工程師可以隨時在 Kubernetes 中添加更多工作負載（例如 FaaS）以運行無服務(wù)器功能，或者添加運維特性（例如 CronHPA）來定義 CronJob 類型的 HPA 策略。OAM 以標準的聲明方式在整個平臺中管理應(yīng)用交付能力和流程，并且提供面向各個角色的 API 原語來表達各自的訴求，最后通過 Kubernetes 把這些訴求落實。

什么樣的項目需要 OAM

實際上，幾乎所有基于 Kubernetes 的應(yīng)用管理平臺都對通過 OAM 來以標準化的方式去構(gòu)建自己的應(yīng)用模型有明確的訴求。另一方面，由于 OAM 是原生的 Kubernetes API 資源模型，這里的遷移過程難度很低，可以通過 API 對象灰度納管的方式逐步完成遷移操作（通過 OAM 對象逐步接管現(xiàn)有 Kubernetes 對象）。

而相比于傳統(tǒng) PaaS 封閉的、不能同 “以 Operator 為基礎(chǔ)的云原生生態(tài)” 銜接的現(xiàn)狀，基于 OAM 和 Kubernetes 構(gòu)建的現(xiàn)代云原生應(yīng)用管理平臺，本質(zhì)上是一個 “以應(yīng)用為中心” 的  Kubernetes ，保證了這個應(yīng)用平臺在能夠無縫接入整個云原生生態(tài)。同時，OAM 可以進一步屏蔽掉容器基礎(chǔ)設(shè)施的復(fù)雜性和差異性，為平臺的使用者帶來低心智負擔的、標準化的、一致的應(yīng)用管理與交付體驗。這就使得一個基于OAM 構(gòu)建的 Kubernetes 應(yīng)用平臺，首先能夠隱藏底層基礎(chǔ)設(shè)施的細節(jié)（例如，是云還是物聯(lián)網(wǎng)），專注于應(yīng)用層抽象，提供以應(yīng)用為中心的資源模型。

其次，OAM 劃分了應(yīng)用交付路徑上的開發(fā)、運維、基礎(chǔ)架構(gòu)三種角色，分離了關(guān)注點，讓流程更加清晰和易于管理。

第三，OAM 站在 K8s  API 資源模型的肩膀之上，提供了可移植的應(yīng)用與基礎(chǔ)設(shè)施抽象，讓一個應(yīng)用描述可以完全不加修改的云、邊、端等任何環(huán)境下直接交付運行起來。

除此之外，OAM 還定義了一組核心工作負載/運維特征/應(yīng)用范疇，作為應(yīng)用程序交付平臺的基石。而平臺開發(fā)者也可以添加更多工作負載（例如 FaaS 或者任意云服務(wù)），或者添加運維特性（例如 CronHPA）來定義 CronJob 類型的 HPA 策略。OAM 以標準的聲明方式在整個平臺中管理應(yīng)用交付能力和流程。當模塊化的 Workload 和 Trait 越來越多，就會形成組件市場。而 OAM 就像是這個組件市場的管理者，處理組件之間的關(guān)系，把許多組件集成起來變成一個產(chǎn)品交付給用戶。OAM 加持下的 Kubernetes 應(yīng)用管理平臺，可以像樂高積木一樣靈活組裝底層能力、運維特征、以及開發(fā)組件。使得應(yīng)用管理變得統(tǒng)一，功能卻更加強大。

看完上述內(nèi)容，你們對OAM存在的意義是什么有進一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。