應用的起源
軟件架構服務化就是根據業務模型進行細化的過程，在這個過程當中切分出一個個具有不一樣職責的業務邏輯模塊，而後每一個微服務模塊都會提供相對應業務邏輯的服務化接口。數據庫
簡單來講就是把一個單體工程，拆分出 N 個獨立模塊。緩存
拆分後的模塊，咱們稱爲應用，而且爲每個應用定義一個惟一標識符，如上圖中的APP-一、APP-2,也就叫應用。架構
應用模型及關係模型的創建
上面定義出來的應用須要和周邊的其餘應用交互，完成總體的業務流程，還須要依賴各類與業務無關的組件，好比機器、緩存、消息隊列等等。運維
下來就是具體的梳理過程，梳理清楚，才能爲咱們後面一系列的運維自動化、持續交付以及穩定性保障打下一個良好的基礎。微服務
1. 應用業務模型spa
應用業務模型，也就是每一個應用對外提供的業務服務能力，並以 API 的方式暴露給外部，以下圖商品的應用業務模型示例：設計
業務模型一般都是業務架構師在進行業務需求分析和拆解時進行設計，更多的是聚焦在業務邏輯上，因此從運維的角度，咱們通常不會關注太多。日誌
接下來是運維關注的重點中間件
2. 應用管理模型blog
應用管理模型，也就是應用自身的各類屬性，如應用名、應用功能信息、責任人、Git 地址、部署結構（代碼路徑、日誌路徑以及各種配置文件路徑等）、啓停方式、健康檢測方式等等。這其中，應用名是應用的惟一標識，咱們用 AppName 來表示。
這裏咱們能夠把應用想象成一我的，一般一我的會具有身份證號碼、姓名、性別、家庭住址、聯繫方式等等屬性，這裏身份證號碼，就是一我的的惟一標識。
3. 應用運行時所依賴的基礎設施和組件
- 資源層面：物理機、虛擬機或容器，對我提供http服務，公網IP 和 DNS 域名服務；
- 基礎組件：這一部分其實就是咱們所說的中間件體系，好比應用運行過程當中必然要存儲和訪問數據，這就須要有數據庫和數據庫中間件；想要更快地訪問數據，同時減輕 DB 的訪問壓力，就須要緩存；應用之間若是須要數據交互或同步，就須要消息隊列；若是進行文件存儲和訪問，就須要存儲系統等等。
這些基礎設施和組件都是爲上層的一個個業務應用所服務的，因此纔開啓它們各自的生命週期。反之它們就沒有存在的必要。
具體操做
第一步，創建各個基礎設施和組件的數據模型（資源和組件的關係）以典型的緩存爲例，每申請一個緩衝空間，一般會以 NameSpace 來標識惟一命名，同時這個緩存空間會有空間容量和 Partition 分區等信息。
第二部，也是最關鍵的一步，就是識別出基礎設施及組件能夠與應用名 AppName 創建關聯關係的屬性，或者在基礎組件的數據模型中增長所屬應用這樣的字段。
以上面的緩存爲例，既然是應用申請的緩存空間，而且是一對一的關聯關係，既能夠直接將 NameSpace 字段取值設置爲 AppName，也能夠再增長一個所屬應用這樣的字段，經過外鍵關聯模式創建起應用與緩存空間的關聯關係。
相應地，對於消息隊列、DB、存儲空間等，均可以參考上面這個思路去作。
通過梳理，能夠創建以應用爲核心的應用模型和關聯關係模型，應用將成爲整個運維信息管理及流轉的紐帶。
真實的狀況是怎麼樣的？
大部分公司在這塊的統籌規劃是不夠的，或者說是不成熟的。也就是軟件架構上引入了微服務，可是後續的一系列運維措施和管理手段沒跟上，主要仍是思路沒有轉變過來。雖說要作 DevOps，但實際的執行仍是把開發和運維分裂了去對待。
- 場景一
是關於線上的緩存和消息隊列的。
開發使用的時候就去申請一下，一開始還能記住本身使用了哪些，可是時間一長，或者申請得多了，就記不住了。長此以往，線上就存在一堆無用的 NameSpace 和 Topic，可是集羣的維護者又不敢隨意清理，由於早就搞不清楚是誰用的，甚至申請人已經離職，之後會不會再用也已經沒人講得清楚了，越日後就越難維護。
根本緣由，就是前面咱們講到的，太片面地對待基礎組件，沒有與應用的訪問創建起關聯關係，沒有任何的生命週期管理措施。
- 場景二
場景就體現了應用名不統一的問題。
按說應用名應該在架構拆分出一個個獨立應用的時候就明確下來，並貫穿整個應用生命週期纔對。
大多數狀況下，咱們的業務架構師或開發在早期只考慮應用開發，不注重應用名的統一
運維這裏，也只從軟件維護的角度，爲了便於資源和應用配置的管理，會獨立定義一套應用名體系出來，方便本身的管理。
會出現不統一。
微服務架構模式下的運維思路必定要轉變，必定要將視角轉換到應用這個維度，從一開始就要統一規劃，從一開始就要將架構、開發和運維的工做拉通了去看，這一點是與傳統運維的思路徹底不一樣的。
固然，這裏面也有一個經驗的問題。雖然微服務在國內被大量應用，可是咱們絕大多數技術團隊的經驗還集中在開發設計層面。微服務架構下的運維經驗，確實還須要一個總結積累的過程。我本身也是痛苦地經歷了上面這些反模式，才總結積累下這些經驗教訓。
總結
微服務架構下，運維管理體系必需要以應用爲核心。
以應用爲核心，把相關的基礎實施及組件都關係梳理和創建起來，才能爲後面一系列的運維自動化、持續交付以及穩定性保障打下一個良好的基礎。
技術團隊不只僅關注開發設計，還要關注微服務運維。