微服務架構時代，運維體系建設要以「應用」為核心

科技 01-21

程序員的 8 點技術早餐

本文節選自趙成教授在極客時間 App 開設的「趙成的運維體系管理課」，已獲授權。更多相關文章，請下載極客時間 App，訂閱專欄獲取。

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

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

應用的起源

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

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

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

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

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

應用模型及關係模型的建立

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

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

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

應用業務模型

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

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

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

應用管理模型

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

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

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

資源層面：應用運行所必需的資源載體有物理機、虛擬機或容器等，如果對外提供 HTTP 服務，就需要虛 IP 和 DNS 域名服務；

基礎組件：這一部分其實就是我們所說的中間件體系，比如應用運行過程中必然要存儲和訪問數據，這就需要有資料庫和資料庫中間件；想要更快地訪問數據，同時減輕 DB 的訪問壓力，就需要緩存；應用之間如果需要數據交互或同步，就需要消息隊列；如果進行文件存儲和訪問，就需要存儲系統等等。

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

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

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

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

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

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

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

真實的情況是怎麼樣的？

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

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

場景一

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

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

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

場景二

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

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

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

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

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

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