本文整理自司徒放(姬風(fēng))題目為《開源的黃金時代,阿里巴巴云原生開源的探索與實踐》的演講。
阿里巴巴的應(yīng)用架構(gòu)演進(jìn) 大家好,我是司徒放,目前在阿里巴巴負(fù)責(zé)阿里云的應(yīng)用平臺和微服務(wù)產(chǎn)品線。在和大家分享我們在云原生應(yīng)用方面的探索之前,先和大家介紹一下阿里巴巴在整個應(yīng)用架構(gòu)方面的演進(jìn)歷程。 今年是阿里巴巴成立的二十周年,二十年前,阿里巴巴使用的這個應(yīng)用的架構(gòu),還是單體應(yīng)用模式,它有很多的業(yè)務(wù)模塊都在一個應(yīng)用里面,各個業(yè)務(wù)都在一個應(yīng)用里面開發(fā),這個架構(gòu)的一個好處是簡單,也非常容易部署,對小的創(chuàng)業(yè)公司來說是很方便的。它的缺點(diǎn)在于團(tuán)隊變大變多之后,不能滿足快速迭代要求,因為每一個業(yè)務(wù)它需要去發(fā)布的時候,都需要在同一個應(yīng)用上做修改、發(fā)布,當(dāng)這個業(yè)務(wù)迭代非??斓臅r候,它同時的一個并發(fā)修改就非常多。 所以在 2008 年的時候,阿里巴巴就引進(jìn)到了微服務(wù)架構(gòu),只是當(dāng)時并不叫微服務(wù),而是叫服務(wù)化架構(gòu)。各個業(yè)務(wù)模式就按照服務(wù)的邊界來拆分,這是比較松耦合的一種方式,一個微服務(wù)應(yīng)用是無狀態(tài)的,可以快速擴(kuò)展實例。而且某個實例有異常比如宕機(jī)時會可以自動下線,不會影響整個服務(wù)架構(gòu)的穩(wěn)定性。微服務(wù)架構(gòu)也比較容易推動整個互聯(lián)網(wǎng)公司的快速迭代需求。 大概三年前,阿里巴巴就走向了云原生的架構(gòu)。這是一個天然適合云的、能夠充分利用云的彈性能力和標(biāo)準(zhǔn)云服務(wù),給整個阿里巴巴的電商降低機(jī)器的準(zhǔn)備成本,特別是類似于在大促雙十一需要很多機(jī)器去支撐,但是大促結(jié)束之后,這些機(jī)器有一半以上就可以歸還到云上。 這個時候,阿里巴巴就在往云原生的方向去邁進(jìn),而且通過整個云服務(wù)能夠更快地加快整個阿里巴巴的技術(shù)構(gòu)建。而且云原生架構(gòu),是一個比較開放、標(biāo)準(zhǔn)、沒有侵入性的技術(shù)架構(gòu)。 阿里巴巴在云原生的開源進(jìn)程 在阿里巴巴進(jìn)入到了云原生之后,我們看一下阿里巴巴在開源方面做了一些什么樣的事情呢? 運(yùn)維領(lǐng)域 首先,整個云原生架構(gòu)里面最重要、最關(guān)鍵的一個基石就是 Kubernetes。 開發(fā)領(lǐng)域 在開發(fā)領(lǐng)域,阿里巴巴很早就已經(jīng)使用了微服務(wù)架構(gòu),也對外進(jìn)行了開源,比如說 Apache Dubbo,這個是比較知名的 RPC 框架;還有去年開源的 Nacos ,作為阿里巴巴集團(tuán)支撐大規(guī)模的服務(wù)注冊發(fā)現(xiàn)、配置推送一個組件;另外,還有 Spring Cloud Alibaba,基于阿里開源的組件提供了一整套 Spring Cloud 最佳實現(xiàn);還有像支撐整個阿里巴巴高可用的 Sentinel、以及 Apache RocketMQ 消息隊列,都是我們在開發(fā)領(lǐng)域做的開源。 這些組件其實隨著阿里巴巴進(jìn)入云原生時代之后,也在逐步結(jié)合云原生做一些改進(jìn),比如說 Apache Dubbo,會更好地去適配我們未來的微服務(wù) Service Mesh 架構(gòu),它會理解 Istio 的 xDS 協(xié)議,成為一種數(shù)據(jù)面;比如 Nacos,它為 Service Mesh 的 Istio 提供 MCP 協(xié)議的對接,成為云原生微服務(wù)和傳統(tǒng)微服務(wù)互通的橋梁。 應(yīng)用 在開發(fā)領(lǐng)域和運(yùn)維領(lǐng)域之間,其實我認(rèn)為還有一個很大的空缺,就是專門用來連接整個開發(fā)和運(yùn)維的應(yīng)用這一塊。 對于開發(fā)階段,寫完代碼之后交付的是一個應(yīng)用包,而這個應(yīng)用包也是整個運(yùn)維系統(tǒng)上運(yùn)行的一個基礎(chǔ)顆粒。我們認(rèn)為現(xiàn)在在云原生階段,缺少了一個很好的應(yīng)用交付和運(yùn)維標(biāo)準(zhǔn),大家在不同的公司會看到每個公司都有不一樣的運(yùn)維平臺,應(yīng)用的部署和交付都沒有辦法被標(biāo)準(zhǔn)化。我們現(xiàn)在進(jìn)入云原生時代,推崇的是標(biāo)準(zhǔn)、開放,所以我們認(rèn)為在這一塊上面還有很大的機(jī)會去做進(jìn)一步的應(yīng)用標(biāo)準(zhǔn)建設(shè),這是我接下來想要和大家重點(diǎn)分享的一個話題。 云上應(yīng)用交付和運(yùn)維的痛點(diǎn) 先看一下云原生在交付和運(yùn)維方面有哪些痛點(diǎn)呢? 剛剛也講到了,在進(jìn)入到了微服務(wù)之后,我們面臨的一個問題就是應(yīng)用的實例數(shù)會越來越多,會到成百上千的規(guī)模不斷往上增長;另外還有我們部署的環(huán)境也變得越來越多,比如說現(xiàn)在有不同的云廠商,以及我們有很多專有云的自建機(jī)房的輸出;另外還有很多自建的環(huán)境,這些環(huán)境多樣化以及我們應(yīng)用在運(yùn)行時它會以容器的方式去運(yùn)行,可能還是以傳統(tǒng)的虛擬機(jī)的方式去運(yùn)行,或者它會以函數(shù)的方式去運(yùn)行,但是運(yùn)行時也會有很多不一致,比如不同的環(huán)境、或運(yùn)行時的不一致,會導(dǎo)致整個分布式運(yùn)維體系變得越來越復(fù)雜,它的監(jiān)控、日志采集也是一個很大的挑戰(zhàn)。 當(dāng)這些應(yīng)用已經(jīng)放到云上去運(yùn)行的時候,由于很多的云服務(wù)并沒有被標(biāo)準(zhǔn)化,很多這種云的能力需要集成到應(yīng)用上的時候,也會有很大集成的困難。而這些云上應(yīng)用運(yùn)維的痛點(diǎn)以前也有類似的,我們可以跟過往的解決方案做一個對比。 過往解決方案 首先,是類似 Ansible、Puppet 這些基礎(chǔ)設(shè)施運(yùn)維自動化的工具。這些工具對整個運(yùn)維效率起到了很大的提升作用,減輕了運(yùn)維同學(xué)的工作量,但是它使用的是一些自應(yīng)用的模塊,而且它的概念是偏向于腳本運(yùn)維的方式,非常的底層。 隨后出現(xiàn)了類似 Cloud Foundry 、Heroku 這種比較經(jīng)典的應(yīng)用平臺,這些應(yīng)用平臺是以應(yīng)用為中心去做運(yùn)維和交付,往上把運(yùn)維的工作進(jìn)行了一個抽象,按照 buildpack 的方式去做運(yùn)維和交付,通過 buildpack 的方式,可以簡化整個應(yīng)用運(yùn)維的工作,但是 buildpack 本身覆蓋的范圍比較窄,在運(yùn)維和交付方面,缺乏一些運(yùn)維交付的標(biāo)準(zhǔn),所以它的可擴(kuò)展性是比較差的。 隨著 Docker 容器的橫空出世,打破了傳統(tǒng)基于 buildpack 的應(yīng)用交付模式,所以就出現(xiàn)了新一代的容器管理平臺,而 Kubernetes 成為了云原生時代一個新的容器平臺事實標(biāo)準(zhǔn)。Kubernetes 本身提供了很多基礎(chǔ)服務(wù)抽象,比如說 Deployment、Service。在社區(qū)里面它有一句很著名的定位:“Kubernetes is the platform for platforms.”也就是說,Kubernetes 定位是構(gòu)建平臺的平臺,能夠簡化構(gòu)建應(yīng)用平臺的復(fù)雜度,它不會再去做上層基于應(yīng)用的抽象。大家可以發(fā)現(xiàn)歷史總是那么相似,從過去的運(yùn)維工具到后來基于應(yīng)用的抽象,到現(xiàn)在容器出現(xiàn)打破運(yùn)維格局,重新對這個領(lǐng)域進(jìn)行洗牌,自然,在云原生時代需要一個對應(yīng)交付和運(yùn)維應(yīng)用的平臺。 從過往解決方案引發(fā)的思考 關(guān)于云原生時代的應(yīng)用抽象,我們要做一個思考:我們需要什么樣的應(yīng)用抽象呢? 首先,它需要解決我們運(yùn)維交付的一個復(fù)雜度,以及屏蔽底層細(xì)節(jié)差異。無論什么時候,都是應(yīng)用平臺需要解決的問題。另外,參考我們過去比較傳統(tǒng)的應(yīng)用平臺的問題,比如說 buildpack 這種方式,它存在不通用/不易于擴(kuò)展的問題,我們認(rèn)為接下來的應(yīng)用抽象,它應(yīng)該要具備在應(yīng)用運(yùn)維方面更加通用、可擴(kuò)展的描述能力。 除此之外,我們在推廣應(yīng)用抽象的時候,還是要采用開源和社區(qū)的方式去推進(jìn),因為未來一定是更加標(biāo)準(zhǔn)和開放的,我們推廣這個應(yīng)用抽象,就是希望有更多開發(fā)和運(yùn)維工作者,能夠給這個標(biāo)準(zhǔn)提供更多的建議,能夠通過整個社區(qū)進(jìn)一步推動整個應(yīng)用交付和運(yùn)維標(biāo)準(zhǔn)的發(fā)展。 Open Application Model - 開放應(yīng)用模型 在上個月中旬,阿里云和微軟聯(lián)合發(fā)布了“Open Application Model(開放應(yīng)用模型)”這一個開源項目。我們希望通過這個開放應(yīng)用模型,解決“在云原生時代缺乏一種應(yīng)用交付標(biāo)準(zhǔn)”的問題。(“Open Application Model -開放應(yīng)用模型”后面簡稱為“OAM”) OAM 的三種角色 OAM 里面有三種不同的角色。
OAM 核心概念解讀 下面為大家解讀以上的三個角色對應(yīng)的三個核心概念。
用 OAM 描述的應(yīng)用配置示意 接下來是一個具體的用 OAM 描述的應(yīng)用配置文件(上圖文件做了一定內(nèi)容簡化,具體以下面的 yaml 文本為準(zhǔn))。 apiVersion: core.oam.dev/v1alpha1 由運(yùn)維人員編寫的 ApplicationConfiquration 文件,它將 Component 和 Trait 兩個概念綁定在一起。首先里面描述運(yùn)維要部署一個叫 wordpress-app的應(yīng)用,它引用了一個叫 wordpress 的 Component。這是開發(fā)人員在另一個配置文件 Component 定義的,他除了定義 wordpress 應(yīng)如何運(yùn)行(比如配置鏡像位置)以外,還允許運(yùn)維配置運(yùn)行實例的副本數(shù)以及運(yùn)行時環(huán)境變量 test-key 的值。在 ApplicationConfiquration 里同時引用了兩個運(yùn)維特征,運(yùn)維人員會填寫這個應(yīng)用需要一個負(fù)載均衡,要做外網(wǎng)的端口映射,部署時需要采用金絲雀發(fā)布策略。這個文件對應(yīng)到實際上的部署階段會變成如上圖右側(cè)所示,上面會有一個負(fù)載均衡,比如在云上運(yùn)行時,就會使用 SLB 去做負(fù)載均衡的自動分發(fā),會給它配置外網(wǎng) IP 和內(nèi)外端口映射。 通過這個簡單的 yaml 文件,大家就可以了解到這個應(yīng)用怎么做快速部署,并且描述運(yùn)維要具備什么能力。 OAM 的設(shè)計理念 給大家總結(jié)一下,我所認(rèn)為的 OAM 的重要的設(shè)計理念。
EDAS & OAM 上面我們說了這么多其實都是比較一些概念性的東西,接下來我們看一下,在阿里巴巴的云產(chǎn)品 EDAS 對 OAM 所做一些落地方面的嘗試,這也是第一個在實際生產(chǎn)上面基于 OAM 對外可開放使用的云產(chǎn)品。 下面會用 EDAS 為例,給大家做一個介紹,講解一下 OAM 具體怎么運(yùn)作。 EDAS 是什么? 首先介紹一下 EDAS 是阿里云上面的一個云產(chǎn)品,它扮演著我剛才講到的類似于一個應(yīng)用平臺的一個角色:
這些是 EDAS 作為應(yīng)用平臺在阿里云上的產(chǎn)品定位。 EDAS 支持 OAM 的運(yùn)行示意圖 那么它在支持 OAM 在運(yùn)行的時候又是什么樣的呢? 如圖所示,一個開發(fā)人員,他首先需要去編寫一個按照 OAM 標(biāo)準(zhǔn)為參考去定義一個 Component。這個 Component 里面會定義如開發(fā)應(yīng)用類型是什么樣子,比如它的鏡像路徑、它需要多大的存儲空間,以及它的環(huán)境變量是什么樣子,這些都是開發(fā)人員在開發(fā)的時候需要去描述的內(nèi)容。 對于阿里云來說,它是一個基礎(chǔ)設(shè)施平臺的身份。它在上面其實有很多運(yùn)維的能力,比如說像監(jiān)控報警、塊存儲、需要發(fā)布策略和彈性伸縮的策略。EDAS 會把這些平臺能力抽象成一個一個獨(dú)立的 Trait,開放給運(yùn)維人員使用。 在需要部署應(yīng)用的時候,運(yùn)維人員會選擇 EDAS 上提供的 Trait 并填寫相關(guān)參數(shù),同時也設(shè)置好開發(fā)人員的 Component 的參數(shù),這作為一次應(yīng)用部署,生成了 ApplicationConfiguration 提交給 EDAS。 EDAS 作為 OAM 的運(yùn)行時,在讀取到這份部署配置后,它會去實現(xiàn) Trait 提供相應(yīng)的運(yùn)維特征動作,比如說運(yùn)維描述需要一個塊存儲,那么 EDAS 會在阿里云上面去申請一個具體的塊存儲對象,并綁定到這個應(yīng)用上面。同時 EDAS 會提供一個容器環(huán)境(如 Kubernetes)去運(yùn)行開發(fā)者定義的 Component 的工作負(fù)載,比如購買 ECS,配置好容器環(huán)境,把環(huán)境變量傳給容器,使 Component 能夠正常運(yùn)行。 以上就是整個 EDAS 支持 OAM 的一個運(yùn)行示意圖。 EDAS 支持 OAM 的對比 那么 EDAS 在支持 OAM 之后,它的使用情況又會發(fā)生怎樣的變化呢? 在沒有使用 OAM 的時候,客戶需要和系統(tǒng)解釋我要做些什么事情、我要怎么做這個事情。比如說,他需要申請 5G NAS 存儲,并且要把它掛載到某個機(jī)器的某個目錄上面;或者他還有一個監(jiān)控的需求,他需要告訴系統(tǒng)現(xiàn)在有一個業(yè)務(wù)指標(biāo)文件,需要被監(jiān)控采集,他要去設(shè)置這個文件的指標(biāo)處理規(guī)則,最后把這個指標(biāo)存儲成時間序列數(shù)據(jù),并且設(shè)置報警閾值。在使用 OAM 之后,它就變成了描述式,他只要描述我需要什么東西就夠了。比如開發(fā)者可以說這個目錄上面需要有 5G 的外置可讀寫存儲就夠了,具體這 5G 存儲怎么申請是由 OAM 運(yùn)行時去幫助解決的。另外,在監(jiān)控的時候,他只需要描述自己的這個應(yīng)用需要被監(jiān)控、哪個指標(biāo)需要被監(jiān)控并報警就夠了,他不需要了解對接到具體是哪一個監(jiān)控系統(tǒng),他不需要去關(guān)心這些事情。 原來很多云產(chǎn)品或者原來很多自定義運(yùn)維平臺都是需要依賴特定的 API 或者 CLI 這種模式去做運(yùn)維的,這個時候應(yīng)用要遷移到另外一個運(yùn)維平臺,它的代碼、鏡像、二進(jìn)制包可以帶走,但是它的很多運(yùn)維的設(shè)施、運(yùn)維的配置包括監(jiān)控的配置,這些東西都是只能留在這個平臺上的,沒有辦法很容易地遷移到另外一個平臺上面。而通過 OAM,可以將平臺所有的運(yùn)維配置以 yaml 導(dǎo)出,并且能夠很快地導(dǎo)入到另外一個環(huán)境、甚至是另一個應(yīng)用平臺上,整個系統(tǒng)會變得更加標(biāo)準(zhǔn)。 在使用 OAM 以前,運(yùn)維人員需要去學(xué)習(xí)很多知識,比如使用的是 Kubernetes,他需要去了解整個容器和 Kubernetes 的使用方式,他要做定制和拓展就需要去學(xué)習(xí) Kubernetes。如果他是從虛擬機(jī)的模式切換到容器的運(yùn)維模式,這個時候他就需要很多時間去理解容器和虛擬機(jī)運(yùn)維之間的差異。遷移到 OAM 之后,相當(dāng)于 OAM 屏蔽了整個平臺底層的細(xì)節(jié),所以使得整個運(yùn)維平臺的 OAM 配置沒有多大差別。 最后一點(diǎn)就是定制的難度上面。剛剛也講到過,這個是 OAM 的一個重要的目標(biāo),讓整個運(yùn)維的擴(kuò)展能夠更容易的被發(fā)現(xiàn)、被組合、被替換。在使用 OAM 之前,運(yùn)維的邏輯都散落在腳本里面,或者說都在運(yùn)維平臺內(nèi)部,這個時候很難去統(tǒng)一管理。而一套 OAM 的運(yùn)行環(huán)境是可以自描述的,可以非常容易把平臺提供的 Trait、Component 工作負(fù)載羅列出來,使用者可以替換或增加新的 Traits,在運(yùn)行應(yīng)用時可以自由選擇和組合這些 Traits。 OAM 后續(xù)規(guī)劃,歡迎社區(qū)貢獻(xiàn) 以上講了 OAM 相關(guān)的一些基本內(nèi)容,實際上 OAM 剛剛開源還有很多需要補(bǔ)充和完善的地方,這里也列出了 OAM 上最近這半年的計劃,希望大家能夠參與社區(qū),在上面貢獻(xiàn)更多的想法。 主要有幾個規(guī)劃:
最后,我的演講就到這里,謝謝大家!喜歡 OAM 的朋友可以掃描下方二維碼,謝謝! 更多詳細(xì)信息請關(guān)注“阿里巴巴云原生”。
作者:司徒放(姬風(fēng)) 阿里巴巴技術(shù)專家 本文為云棲社區(qū)內(nèi)容,未經(jīng)允許不得轉(zhuǎn)載。 |