書的第一章裏面提到一個核心觀念：以應用作為運維體系建設的核心

下面我從what，why，how 的角度，嘗試理解下作者的推崇的思想：

一、"應用"是什麽？

微服務架構都是從單體工程拆分而來，每個產品設計初期都只有部分核心功能，隨著時間推移與產品的不斷叠代，產品本身會越來越臃腫，從初期一個解決某種特定場景，服務於特定人群的一個"工具"，最終演變成為一個龐大的體系，甚至是一個生態。而一個產品一旦變得臃腫，後續的維護工作會變得越來越復雜，我能想到的最麻煩的一個問題可能就是發版本。假如所有服務都放在一個工程下面，某天A 團隊為了緊急修復a 模塊的bug，緊急發布，導致B團隊的b模塊也跟著重啟，而實際上我們知道b模塊跟這個bug本身無關，但放在一個單體工程下面，就會面臨這種問題，牽一發動全身。所以文章裏面提到的第一個觀點就是"拆"，將一個臃腫的應用拆解成為一個個的服務，每個服務又對外暴露API供其他服務調用，這樣的架構就是我們常說的微服務架構。書裏面給了一個範例圖：

舉一個具體一點的例子，以電商網站為例，我們知道電商網站包含很多功能，如用戶登錄註冊、產品概覽、產品詳情、支付/充值、售後等等一系列服務，在應用的設計初期，就可以將一個龐大的工程拆解成一個個功能模塊。

拆分後的模塊數量與業務體量和復雜度相關，所以為了統一概念，我們將這些模塊稱之為"應用"。為了確保每個應用的唯一性，我們會給每個應用確定一個唯一的標示符，例如上圖中的DetailServices，SKUService，TagService,TemplateService 等等，後續將通過這裏定義的"應用名"貫徹整個產品的生命周期，將該產品設計到的方方面面都關聯起來。

二、為什麽要以"應用"為核心？

文中舉了2個場景：

場景一：研發團隊出於業務上線需要，在運維平臺申請了一些資源，比如說緩存或者消息隊列（數據庫、VIP、存儲等等），一開始這些資源都是自己使用，所以很清楚這些資源的用途。隨著業務發展，時間一長，申請的資源一多，慢慢的記不住了。後面業務交接給其他團隊維護，或者原先申請資源的負責人離職，慢慢的這些資源就變得七零八碎，沒有人清楚它的用途，沒有人知道這個資源有沒有用到，沒有人能看清楚整個應用的全貌。

前段時間，我們內部在做成本優化的時候，這個問題就特別的棘手。成本優化中有一部分工作就是梳理服務器，合理利用機櫃，要知道每臺服務器的成本不僅僅是服務器本身的價格，還有後續每年機櫃的費用（托管機房都是這樣）。所以有一段時間，我們都在推動業務方搬遷機器，說實話這是一個臟累活，不管是開發團隊還是運維團隊都不想做。為什麽不想做，原因很簡單，就是上面提到的問題，有些年代久遠的服務器上面部署的服務，負責人已經轉了幾次手，甚至已經離職，現階段的業務負責人根本不知道這個應用的用途，不知道機器上面跑的memcache、redis 有沒有用，什麽服務在用，甚至於有些負責人都不知道機器上面還跑了個memcache、redis。後果可想而知，我們在搬遷過程中遇到了各種阻力，畢竟出故障是大家都不想看到的結果。

文中舉的第二個場景是：同一個應用沒有一個統一的應用名，沒有以應用名貫穿整個應用的什麽周期，通過應用名將所有與該應用相關的資源關聯起來。開發團隊認為自己只要按時按量完成產品的開發/上線即可，為了快速上線，草草的為產品或者應用起了隨意起了一個名字，例如用戶中心（User）。運維團隊則從產品上線後的維護工作考慮，為了資源和應用配置管理方便，通常又會獨立定義一套應用名體系，給產品取了另外一個名字，用戶中心（UserCenter）,如果後面還有配置管理、發布、監控系統，可能又各自維護了獨立一套應用名體系，而實際上我們知道無論是開發團隊定義的User 還是 運維團隊定義的UserCenter 本質上都是對應著同一個應用下面的不同資源。最終的結果就是，通過應用下面的各自資源都成為一個個的孤島，無法將彼此關聯起來，如下圖範例圖所示：

近期我們在搞告警、監控梳理，也面臨到這個問題。我們原先的告警非常零散，比如機器本身健康狀況的告警（比如CPU、內存、IO等等），會由服務器告警出來；機房間網絡有網絡中斷，網絡丟包告警；各個基礎組件也有各自的告警，比如進程存活告警等；如果是個web服務，還有URL探測的告警，服務異常的告警等等等等。我們初期想法是將這些告警匯總到一塊，並嘗試從這些告警中找出共性，縮小問題定位的範圍，從而輔佐我們更快的定位問題根因以及後續的告警抑制，服務自愈等等。

但是我們剛剛開展這項工作的時候，遇到的一個問題就是各種資源沒有一個統一的"應用名"可以將彼此關聯起來，舉個例子，一臺機器CPU告警了，告警出來只有一個IP還有一個業務模塊的信息，如果告警的是個web的服務，那麽在web管理系統裏面我們有業務模塊、域名的信息機器的信息，我們可以勉強的通過業務模塊或者域名作為一個key展開，將告警關聯起來。但來到發布系統裏面，每個應用的應用名又變成了業務名、項目名，並沒有所謂的域名（這個字段其實是有的，但這裏的域名又不同於前面提到的域名，沒辦法關聯起來），更沒有關聯的IP信息，內部自成一套應用名體系，這種時候想關聯起來就相當麻煩。所以，如果要順利的將監控/告警梳理這項工作順利開展下去，第一步我們就是要將前面的坑填好，引導研發團隊自行將應用名、域名、IP等等信息關聯起來。

三、以"應用"為核心應該怎麽做？

每個應用都有自己的職能，並依賴於各種與業務無直接關系的，相對獨立的基礎設施和組件，比如服務器資源，IP，域名，數據庫，網絡等等。所以，在產品的生命周期裏面，除了應用本身這個實體以外，還有著各種基礎組件實體，並且在應用上線後，還可能會不斷的有新的組件產生，而新的組件不斷產生，又會給後續的維護造成更大的困難。因此，以"應用"為核心就變得極其重要，通過應用模型和關系模型的梳理和建立，為後續持續交付、運維自動化奠定基礎。

應用模型的梳理，其實就是上面範例中提到的電商網站，將一個產品拆分成多個模塊，不同功能模塊暴露自己的API供其他模塊調用。拆分的工作更多是由產品架構師來把控，我們不展開討論，重點看看運維層面關心的 應用管理模型的梳理。

應用管理模型：我們知道每個人都會有自己的各種屬性，比如姓名，性別，職業，聯系方式，家庭住址，×××號碼等等，我們都知道每個人的名字並非唯一，同名同姓隨處可見，而×××號碼則是這個人唯一的標識。每個應用也有著自身的各種屬性，比如應用名，功能，負責人，SVN地址，域名，部署架構，配置等等，而其中應用名就是該應用的唯一標識。

每個應用依賴的組件和基礎設施大概可以分為兩類：

資源層面：應用本身運行的載體，如物理服務器、容器、虛擬機，網絡，以及對外提供服務的域名、IP等等。

基礎組件：應用依賴的中間件，如nginx、tomcat、java等基礎組件，以及數據庫、消息隊列、緩存、存儲等等。

我們可以看到，這些基礎設施/組件 本質上都是為上層的應用提供服務，拋開應用，這些基礎設施/組件本身並沒有單獨存在的意義。

文中建議我們可以按這個思路去梳理應用 與 基礎設施/組件之間的關聯關系。例如，在用戶中心（User）在申請數據庫資源的時候，在數據庫平臺肯定也會要求業務方提供一個數據庫平臺範疇內全局唯一的一個標識，這裏我假定這個字段叫做服務名。那麽業務方在申請數據庫資源的時候，就可以將數據庫裏面的服務名賦值為應用名User，又或者添加一個應用名的字段，通過外鏈的方式將數據庫與應用關聯起來。

同理，對於其他基礎設施、基礎組件也可以以類似的方法梳理。完成這一步之後，我們就會得到類似下面的一個以應用為核心的完整架構圖，將應用、基礎設施、服務、配置、運行載體等關聯起來。

以上是我剛讀完《進化：運維技術變革與實踐探索》第一章的一些總結，並結合自身實際工作中遇到的一些問題，展開的一些思考，篇幅比較長難免會有錯漏，歡迎大家幫忙指正，也歡迎大家提出各自的觀點，共同探討這個話題，謝謝

《進化：運維技術變革與實踐探索》讀書筆記1 —— 以應用為核心