本篇文章選自極客時(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)題。

我們知道，微服務(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)管理的核心概念。

上面我們定義出來(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(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è)施和組件

從這里我們可以挖掘出一條規(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)景。

這個(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)有任何的生命周期管理措施。

這個(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)你分享給身邊的朋友。

歡迎你留言與我一起討論。

趙成，美麗聯(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)。