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