本篇文章選自極客時(shí)間“趙成運(yùn)維體系管理課” 付費(fèi)專(zhuān)欄中的其中一篇,專(zhuān)欄內(nèi)容主要聚焦在分布式軟件架構(gòu)下的應(yīng)用運(yùn)維這個(gè)領(lǐng)域,更多的是作者對(duì)運(yùn)維的一些架構(gòu)思考,主要分成四部分:應(yīng)用運(yùn)維體系建設(shè)、效率和穩(wěn)定性等方面的最佳實(shí)踐、云計(jì)算方面的思考和實(shí)踐以及個(gè)人成長(zhǎng)與趨勢(shì)熱點(diǎn)分析。專(zhuān)欄詳情請(qǐng)。
今天我來(lái)講一下微服務(wù)架構(gòu)模式下的一個(gè)核心概念:應(yīng)用。
我會(huì)從這幾個(gè)方面來(lái)講:應(yīng)用的起源、應(yīng)用模型和應(yīng)用關(guān)系模型建模以及為什么要這樣做。最終希望,在微服務(wù)的架構(gòu)模式下,我們的運(yùn)維視角一定轉(zhuǎn)到應(yīng)用這個(gè)核心概念上來(lái),一切要從應(yīng)用的角度來(lái)分析和看待問(wèn)題。
應(yīng)用的起源我們知道,微服務(wù)架構(gòu)一般都是從單體架構(gòu)或分層架構(gòu)演進(jìn)過(guò)來(lái)的。軟件架構(gòu)服務(wù)化的過(guò)程,就是我們根據(jù)業(yè)務(wù)模型進(jìn)行細(xì)化的過(guò)程,在這個(gè)過(guò)程中切分出一個(gè)個(gè)具備不同職責(zé)的業(yè)務(wù)邏輯模塊,然后每個(gè)微服務(wù)模塊都會(huì)提供相對(duì)應(yīng)業(yè)務(wù)邏輯的服務(wù)化接口。
如果解釋得簡(jiǎn)單點(diǎn),就一個(gè)字,拆!如下圖,從一個(gè)單體工程,拆分出 N 個(gè)獨(dú)立模塊。
這些模塊可以獨(dú)立部署和運(yùn)行,并提供對(duì)應(yīng)的業(yè)務(wù)能力。拆分后的模塊數(shù)量與業(yè)務(wù)體量和復(fù)雜度相關(guān),少則幾個(gè)、十幾個(gè),多則幾十、幾百個(gè),所以為了統(tǒng)一概念,我們通常稱(chēng)這些模塊為應(yīng)用。
為了確保每個(gè)應(yīng)用的唯一性,我們給每個(gè)應(yīng)用定義一個(gè)唯一的標(biāo)識(shí)符,如上圖的 APP-1、APP-2 等,這個(gè)唯一標(biāo)識(shí)符我們稱(chēng)之為應(yīng)用名。
接下來(lái),這個(gè)定義為應(yīng)用的概念,將成為我們后續(xù)一系列微服務(wù)架構(gòu)管理的核心概念。
應(yīng)用模型及關(guān)系模型的建立上面我們定義出來(lái)的一個(gè)個(gè)應(yīng)用,都是從業(yè)務(wù)角度入手進(jìn)行拆分細(xì)化出來(lái)的業(yè)務(wù)邏輯單元。它雖然可以獨(dú)立部署和運(yùn)行,但是每一個(gè)應(yīng)用都只具備相對(duì)單一的業(yè)務(wù)職能。如果要完成整體的業(yè)務(wù)流程和目標(biāo),就需要和周邊其它的服務(wù)化應(yīng)用交互。同時(shí),這個(gè)過(guò)程中還需要依賴(lài)各種與業(yè)務(wù)無(wú)直接關(guān)系、相對(duì)獨(dú)立的基礎(chǔ)設(shè)施和組件,比如機(jī)器資源、域名、DB、緩存、消息隊(duì)列等等。
所以,除了應(yīng)用這個(gè)實(shí)體之外,還會(huì)存在其他各類(lèi)基礎(chǔ)組件實(shí)體。同時(shí),在應(yīng)用運(yùn)行過(guò)程中,還需要不斷地與它們產(chǎn)生和建立各種各樣復(fù)雜的關(guān)聯(lián)關(guān)系,這也為我們后續(xù)的運(yùn)維帶來(lái)很多困難。
那接下來(lái),我們要做的就是應(yīng)用模型以及各種關(guān)系模型的梳理和建立,因?yàn)橹挥心P秃完P(guān)系梳理清楚了,才能為我們后面一系列的運(yùn)維自動(dòng)化、持續(xù)交付以及穩(wěn)定性保障打下一個(gè)良好的基礎(chǔ)。
1. 應(yīng)用業(yè)務(wù)模型
應(yīng)用業(yè)務(wù)模型,也就是每個(gè)應(yīng)用對(duì)外提供的業(yè)務(wù)服務(wù)能力,并以 API 的方式暴露給外部,如下圖商品的應(yīng)用業(yè)務(wù)模型示例:
這個(gè)業(yè)務(wù)模型通常都是業(yè)務(wù)架構(gòu)師在進(jìn)行業(yè)務(wù)需求分析和拆解時(shí)進(jìn)行設(shè)計(jì),更多的是聚焦在業(yè)務(wù)邏輯上,所以從運(yùn)維的角度,我們一般不會(huì)關(guān)注太多。
而接下來(lái)的幾部分,將是運(yùn)維要重點(diǎn)關(guān)注的內(nèi)容。
2. 應(yīng)用管理模型
應(yīng)用管理模型,也就是應(yīng)用自身的各種屬性,如應(yīng)用名、應(yīng)用功能信息、責(zé)任人、Git 地址、部署結(jié)構(gòu)(代碼路徑、日志路徑以及各類(lèi)配置文件路徑等)、啟停方式、健康檢測(cè)方式等等。這其中,應(yīng)用名是應(yīng)用的唯一標(biāo)識(shí),我們用 AppName 來(lái)表示。
這里我們可以把應(yīng)用想象成一個(gè)人,通常一個(gè)人會(huì)具備身份證號(hào)碼、姓名、性別、家庭住址、聯(lián)系方式等等屬性,這里身份證號(hào)碼,就是一個(gè)人的唯一標(biāo)識(shí)。
3. 應(yīng)用運(yùn)行時(shí)所依賴(lài)的基礎(chǔ)設(shè)施和組件
資源層面:應(yīng)用運(yùn)行所必需的資源載體有物理機(jī)、虛擬機(jī)或容器等,如果對(duì)外提供 HTTP 服務(wù),就需要虛 IP 和 DNS 域名服務(wù);基礎(chǔ)組件:這一部分其實(shí)就是我們所說(shuō)的中間件體系,比如應(yīng)用運(yùn)行過(guò)程中必然要存儲(chǔ)和訪(fǎng)問(wèn)數(shù)據(jù),這就需要有數(shù)據(jù)庫(kù)和數(shù)據(jù)庫(kù)中間件;想要更快地訪(fǎng)問(wèn)數(shù)據(jù),同時(shí)減輕 DB 的訪(fǎng)問(wèn)壓力,就需要緩存;應(yīng)用之間如果需要數(shù)據(jù)交互或同步,就需要消息隊(duì)列;如果進(jìn)行文件存儲(chǔ)和訪(fǎng)問(wèn),就需要存儲(chǔ)系統(tǒng)等等。從這里我們可以挖掘出一條規(guī)律,那就是這些基礎(chǔ)設(shè)施和組件都是為上層的一個(gè)個(gè)業(yè)務(wù)應(yīng)用所服務(wù)的。也正是因?yàn)闃I(yè)務(wù)和應(yīng)用上的需求,才開(kāi)啟了它們各自的生命周期。如果脫離了這些業(yè)務(wù)應(yīng)用,它們自己并沒(méi)有單純存在的意義。所以,從始至終基礎(chǔ)設(shè)施和組件都跟應(yīng)用這個(gè)概念保持著緊密的聯(lián)系。
理清了這個(gè)思路,我們?cè)偃ナ崂硭鼈冎g的關(guān)系就會(huì)順暢很多,分為兩步。
第一步,建立各個(gè)基礎(chǔ)設(shè)施和組件的數(shù)據(jù)模型,同時(shí)識(shí)別出它們的唯一標(biāo)識(shí)。這個(gè)套路跟應(yīng)用管理模型的梳理類(lèi)似,以典型的緩存為例,每當(dāng)我們申請(qǐng)一個(gè)緩存空間時(shí),通常會(huì)以 NameSpace 來(lái)標(biāo)識(shí)唯一命名,同時(shí)這個(gè)緩存空間會(huì)有空間容量和 Partition 分區(qū)等信息。
第二步,也是最關(guān)鍵的一步,就是識(shí)別出基礎(chǔ)設(shè)施及組件可以與應(yīng)用名 AppName 建立關(guān)聯(lián)關(guān)系的屬性,或者在基礎(chǔ)組件的數(shù)據(jù)模型中增加所屬應(yīng)用這樣的字段。
還是以上面的緩存為例,既然是應(yīng)用申請(qǐng)的緩存空間,并且是一對(duì)一的關(guān)聯(lián)關(guān)系,既可以直接將 NameSpace 字段取值設(shè)置為 AppName,也可以再增加一個(gè)所屬應(yīng)用這樣的字段,通過(guò)外鍵關(guān)聯(lián)模式建立起應(yīng)用與緩存空間的關(guān)聯(lián)關(guān)系。
相應(yīng)地,對(duì)于消息隊(duì)列、DB、存儲(chǔ)空間等,都可以參考上面這個(gè)思路去做。
通過(guò)上面的梳理,我們就可以建立出類(lèi)似下圖這樣的以應(yīng)用為核心的應(yīng)用模型和關(guān)聯(lián)關(guān)系模型了,基于這個(gè)統(tǒng)一的應(yīng)用概念,系統(tǒng)中原本分散雜亂的信息,最終都被串聯(lián)了起來(lái),應(yīng)用也將成為整個(gè)運(yùn)維信息管理及流轉(zhuǎn)的紐帶。
真實(shí)的情況是怎么樣的?
上面講了這么多理論和道理,但是我們業(yè)界真實(shí)的現(xiàn)狀是怎樣的呢?
從我個(gè)人實(shí)際觀(guān)察和經(jīng)歷的場(chǎng)景來(lái)看,大部分公司在這塊的統(tǒng)籌規(guī)劃是不夠的,或者說(shuō)是不成熟的。也就是軟件架構(gòu)上引入了微服務(wù),但是后續(xù)的一系列運(yùn)維措施和管理手段沒(méi)跟上,主要還是思路沒(méi)有轉(zhuǎn)變過(guò)來(lái)。雖然說(shuō)要做 DevOps,但實(shí)際的執(zhí)行還是把開(kāi)發(fā)和運(yùn)維分裂了去對(duì)待,不信你看下面兩個(gè)常見(jiàn)的場(chǎng)景。
場(chǎng)景一這個(gè)場(chǎng)景是關(guān)于線(xiàn)上的緩存和消息隊(duì)列的。
開(kāi)發(fā)使用的時(shí)候就去申請(qǐng)一下,一開(kāi)始還能記住自己使用了哪些,但是時(shí)間一長(zhǎng),或者申請(qǐng)得多了,就記不住了。久而久之,線(xiàn)上就存在一堆無(wú)用的 NameSpace 和 Topic,但是集群的維護(hù)者又不敢隨意清理,因?yàn)樵缇透悴磺宄钦l(shuí)用的,甚至申請(qǐng)人已經(jīng)離職,以后會(huì)不會(huì)再用也已經(jīng)沒(méi)人講得清楚了,越往后就越難維護(hù)。
根本原因,就是前面我們講到的,太片面地對(duì)待基礎(chǔ)組件,沒(méi)有與應(yīng)用的訪(fǎng)問(wèn)建立起關(guān)聯(lián)關(guān)系,沒(méi)有任何的生命周期管理措施。
場(chǎng)景二這個(gè)典型場(chǎng)景就體現(xiàn)了應(yīng)用名不統(tǒng)一的問(wèn)題。
按照我們前面講的,按說(shuō)應(yīng)用名應(yīng)該在架構(gòu)拆分出一個(gè)個(gè)獨(dú)立應(yīng)用的時(shí)候就明確下來(lái),并貫穿整個(gè)應(yīng)用生命周期才對(duì)。
但是大多數(shù)情況下,我們的業(yè)務(wù)架構(gòu)師或開(kāi)發(fā)在早期只考慮應(yīng)用開(kāi)發(fā),并不會(huì)過(guò)多地考慮整個(gè)應(yīng)用的生命周期問(wèn)題,會(huì)下意識(shí)地默認(rèn)后面的事情是運(yùn)維負(fù)責(zé)的,所以開(kāi)發(fā)期間,只要將應(yīng)用開(kāi)發(fā)完和將服務(wù)注冊(cè)到服務(wù)配置中心上就 OK 了。
而到了運(yùn)維這里,也只從軟件維護(hù)的角度,為了便于資源和應(yīng)用配置的管理,會(huì)獨(dú)立定義一套應(yīng)用名體系出來(lái),方便自己的管理。
這時(shí)不統(tǒng)一的問(wèn)題就出現(xiàn)了,如果持續(xù)交付和監(jiān)控系統(tǒng)這些運(yùn)維平臺(tái)也是獨(dú)立去開(kāi)發(fā)的,脫節(jié)問(wèn)題就會(huì)更嚴(yán)重。
如下圖所示,一個(gè)個(gè)的孤島,無(wú)法成為體系,當(dāng)這些系統(tǒng)需要對(duì)接時(shí),就會(huì)發(fā)現(xiàn)需要做大量的應(yīng)用名轉(zhuǎn)化適配工作,帶來(lái)非常多無(wú)謂的工作量,所謂的效率提升就是一句空話(huà)。
所以,今天一開(kāi)頭我就提到,微服務(wù)架構(gòu)模式下的運(yùn)維思路一定要轉(zhuǎn)變,一定要將視角轉(zhuǎn)換到應(yīng)用這個(gè)維度,從一開(kāi)始就要統(tǒng)一規(guī)劃,從一開(kāi)始就要將架構(gòu)、開(kāi)發(fā)和運(yùn)維的工作拉通了去看,這一點(diǎn)是與傳統(tǒng)運(yùn)維的思路完全不同的。
當(dāng)然,這里面也有一個(gè)經(jīng)驗(yàn)的問(wèn)題。雖然微服務(wù)在國(guó)內(nèi)被大量應(yīng)用,但是我們絕大多數(shù)技術(shù)團(tuán)隊(duì)的經(jīng)驗(yàn)還集中在開(kāi)發(fā)設(shè)計(jì)層面。微服務(wù)架構(gòu)下的運(yùn)維經(jīng)驗(yàn),確實(shí)還需要一個(gè)總結(jié)積累的過(guò)程。我自己也是痛苦地經(jīng)歷了上面這些反模式,才總結(jié)積累下這些經(jīng)驗(yàn)教訓(xùn)。
這也是為什么我今天分享了這樣一個(gè)思路,我們要轉(zhuǎn)換視角,規(guī)劃以應(yīng)用為核心的運(yùn)維管理體系。
不知道你目前是否也遇到了類(lèi)似的問(wèn)題,如果今天的內(nèi)容對(duì)你有幫助,也請(qǐng)你分享給身邊的朋友。
歡迎你留言與我一起討論。
作者簡(jiǎn)介趙成,美麗聯(lián)合集團(tuán)技術(shù)服務(wù)經(jīng)理,公眾號(hào)“Forrest 隨想錄”的作者,多屆 ArchSummit 運(yùn)維專(zhuān)題明星講師和優(yōu)秀出品人,EGO 杭州分會(huì)會(huì)員。目前專(zhuān)注于云計(jì)算和人工智能時(shí)代的運(yùn)維轉(zhuǎn)型和提升。2018年1月在極客時(shí)間上開(kāi)設(shè)“趙成運(yùn)維體系管理課”。專(zhuān)欄詳情請(qǐng)。