本篇文章選自極客時間“趙成運維體系管理課” 付費專欄中的其中一篇，專欄內容主要聚焦在分布式軟件架構下的應用運維這個領域，更多的是作者對運維的一些架構思考，主要分成四部分:應用運維體系建設、效率和穩定性等方面的最佳實踐、云計算方面的思考和實踐以及個人成長與趨勢熱點分析。專欄詳情請。

今天我來講一下微服務架構模式下的一個核心概念：應用。

我會從這幾個方面來講：應用的起源、應用模型和應用關系模型建模以及為什么要這樣做。最終希望，在微服務的架構模式下，我們的運維視角一定轉到應用這個核心概念上來，一切要從應用的角度來分析和看待問題。

我們知道，微服務架構一般都是從單體架構或分層架構演進過來的。軟件架構服務化的過程，就是我們根據業務模型進行細化的過程，在這個過程中切分出一個個具備不同職責的業務邏輯模塊，然后每個微服務模塊都會提供相對應業務邏輯的服務化接口。

如果解釋得簡單點，就一個字，拆！如下圖，從一個單體工程，拆分出 N 個獨立模塊。

這些模塊可以獨立部署和運行，并提供對應的業務能力。拆分后的模塊數量與業務體量和復雜度相關，少則幾個、十幾個，多則幾十、幾百個，所以為了統一概念，我們通常稱這些模塊為應用。

為了確保每個應用的唯一性，我們給每個應用定義一個唯一的標識符，如上圖的 APP-1、APP-2 等，這個唯一標識符我們稱之為應用名。

接下來，這個定義為應用的概念，將成為我們后續一系列微服務架構管理的核心概念。

上面我們定義出來的一個個應用，都是從業務角度入手進行拆分細化出來的業務邏輯單元。它雖然可以獨立部署和運行，但是每一個應用都只具備相對單一的業務職能。如果要完成整體的業務流程和目標，就需要和周邊其它的服務化應用交互。同時，這個過程中還需要依賴各種與業務無直接關系、相對獨立的基礎設施和組件，比如機器資源、域名、DB、緩存、消息隊列等等。

所以，除了應用這個實體之外，還會存在其他各類基礎組件實體。同時，在應用運行過程中，還需要不斷地與它們產生和建立各種各樣復雜的關聯關系，這也為我們后續的運維帶來很多困難。

那接下來，我們要做的就是應用模型以及各種關系模型的梳理和建立，因為只有模型和關系梳理清楚了，才能為我們后面一系列的運維自動化、持續交付以及穩定性保障打下一個良好的基礎。

1. 應用業務模型

應用業務模型，也就是每個應用對外提供的業務服務能力，并以 API 的方式暴露給外部，如下圖商品的應用業務模型示例：

這個業務模型通常都是業務架構師在進行業務需求分析和拆解時進行設計，更多的是聚焦在業務邏輯上，所以從運維的角度，我們一般不會關注太多。

而接下來的幾部分，將是運維要重點關注的內容。

2. 應用管理模型

應用管理模型，也就是應用自身的各種屬性，如應用名、應用功能信息、責任人、Git 地址、部署結構（代碼路徑、日志路徑以及各類配置文件路徑等）、啟停方式、健康檢測方式等等。這其中，應用名是應用的唯一標識，我們用 AppName 來表示。

這里我們可以把應用想象成一個人，通常一個人會具備身份證號碼、姓名、性別、家庭住址、聯系方式等等屬性，這里身份證號碼，就是一個人的唯一標識。

3. 應用運行時所依賴的基礎設施和組件

從這里我們可以挖掘出一條規律，那就是這些基礎設施和組件都是為上層的一個個業務應用所服務的。也正是因為業務和應用上的需求，才開啟了它們各自的生命周期。如果脫離了這些業務應用，它們自己并沒有單純存在的意義。所以，從始至終基礎設施和組件都跟應用這個概念保持著緊密的聯系。

理清了這個思路，我們再去梳理它們之間的關系就會順暢很多，分為兩步。

第一步，建立各個基礎設施和組件的數據模型，同時識別出它們的唯一標識。這個套路跟應用管理模型的梳理類似，以典型的緩存為例，每當我們申請一個緩存空間時，通常會以 NameSpace 來標識唯一命名，同時這個緩存空間會有空間容量和 Partition 分區等信息。

第二步，也是最關鍵的一步，就是識別出基礎設施及組件可以與應用名 AppName 建立關聯關系的屬性，或者在基礎組件的數據模型中增加所屬應用這樣的字段。

還是以上面的緩存為例，既然是應用申請的緩存空間，并且是一對一的關聯關系，既可以直接將 NameSpace 字段取值設置為 AppName，也可以再增加一個所屬應用這樣的字段，通過外鍵關聯模式建立起應用與緩存空間的關聯關系。

相應地，對于消息隊列、DB、存儲空間等，都可以參考上面這個思路去做。

通過上面的梳理，我們就可以建立出類似下圖這樣的以應用為核心的應用模型和關聯關系模型了，基于這個統一的應用概念，系統中原本分散雜亂的信息，最終都被串聯了起來，應用也將成為整個運維信息管理及流轉的紐帶。

真實的情況是怎么樣的？

上面講了這么多理論和道理，但是我們業界真實的現狀是怎樣的呢？

從我個人實際觀察和經歷的場景來看，大部分公司在這塊的統籌規劃是不夠的，或者說是不成熟的。也就是軟件架構上引入了微服務，但是后續的一系列運維措施和管理手段沒跟上，主要還是思路沒有轉變過來。雖然說要做 DevOps，但實際的執行還是把開發和運維分裂了去對待，不信你看下面兩個常見的場景。

這個場景是關于線上的緩存和消息隊列的。

開發使用的時候就去申請一下，一開始還能記住自己使用了哪些，但是時間一長，或者申請得多了，就記不住了。久而久之，線上就存在一堆無用的 NameSpace 和 Topic，但是集群的維護者又不敢隨意清理，因為早就搞不清楚是誰用的，甚至申請人已經離職，以后會不會再用也已經沒人講得清楚了，越往后就越難維護。

根本原因，就是前面我們講到的，太片面地對待基礎組件，沒有與應用的訪問建立起關聯關系，沒有任何的生命周期管理措施。

這個典型場景就體現了應用名不統一的問題。

按照我們前面講的，按說應用名應該在架構拆分出一個個獨立應用的時候就明確下來，并貫穿整個應用生命周期才對。

但是大多數情況下，我們的業務架構師或開發在早期只考慮應用開發，并不會過多地考慮整個應用的生命周期問題，會下意識地默認后面的事情是運維負責的，所以開發期間，只要將應用開發完和將服務注冊到服務配置中心上就 OK 了。

而到了運維這里，也只從軟件維護的角度，為了便于資源和應用配置的管理，會獨立定義一套應用名體系出來，方便自己的管理。

這時不統一的問題就出現了，如果持續交付和監控系統這些運維平臺也是獨立去開發的，脫節問題就會更嚴重。

如下圖所示，一個個的孤島，無法成為體系，當這些系統需要對接時，就會發現需要做大量的應用名轉化適配工作，帶來非常多無謂的工作量，所謂的效率提升就是一句空話。

所以，今天一開頭我就提到，微服務架構模式下的運維思路一定要轉變，一定要將視角轉換到應用這個維度，從一開始就要統一規劃，從一開始就要將架構、開發和運維的工作拉通了去看，這一點是與傳統運維的思路完全不同的。

當然，這里面也有一個經驗的問題。雖然微服務在國內被大量應用，但是我們絕大多數技術團隊的經驗還集中在開發設計層面。微服務架構下的運維經驗，確實還需要一個總結積累的過程。我自己也是痛苦地經歷了上面這些反模式，才總結積累下這些經驗教訓。

這也是為什么我今天分享了這樣一個思路，我們要轉換視角，規劃以應用為核心的運維管理體系。

不知道你目前是否也遇到了類似的問題，如果今天的內容對你有幫助，也請你分享給身邊的朋友。

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

趙成，美麗聯合集團技術服務經理，公眾號“Forrest 隨想錄”的作者，多屆 ArchSummit 運維專題明星講師和優秀出品人，EGO 杭州分會會員。目前專注于云計算和人工智能時代的運維轉型和提升。2018年1月在極客時間上開設“趙成運維體系管理課”。專欄詳情請。