服務治理都要治理些什麽？讀了這篇文章，結合spring cloud的各種技術，感覺有所收獲，有些明白了。以下是原文（ 轉自：https://www.jianshu.com/p/104b27d1e943）：

一、服務治理-思路

2014年我們自我感覺技術挺好了，當我們梳理全平臺依賴狀況的時候出現了這樣一個狀況：我們的平臺存在各種各樣的依賴關系，沒有人能理清楚這樣繁雜的依賴關系，我們面臨著一個新的挑戰：服務治理。

我們現在的服務數量達到200+，服務實例數量600+，接口數超過3000，鏈路數400+，日調度數超過25億，機房5個，各種抖動、服務之間的調度會導致我們每天出現超過10萬次的調度失敗。這種情況下出現了很多問題：

1、服務資源配置困難。一個業務依賴很多其他服務，運維要花很多的資源來服務配置。

2、授權密鑰配置更困難，業務上線依賴著哪個系統就要去運維那邊申請，運維分配一個密鑰，服務訪問者需要配置該密鑰進行簽名，服務提供方也需要新增該caller的密鑰，所以密鑰配置是一個非常痛苦的經歷。

3、強依賴F5/或者DNS。F5做一些結點切換的時候沒辦法做到實時修改，比如域名，涉及DNS的過期問題；內部DNS更明顯，遇到DNS過期的問題，不能實時處理一些由於鏈路導致的具體問題，而且很多抖動問題都是瞬間發生，但很快又恢復，根本沒有時間讓運維去識別故障並做節點移除。

4、級聯故障，故障識別成本高。我們的那些鏈條過於復雜，有些四級、五級的鏈條，一旦哪個環節的一「點」出了問題，會出現一「片」的癥狀，這是比較痛苦的。

5、接口溝通成本高。HTTP協議+JSON的協議和簽名方式，接口溝通成本高。

我們的解決方式是搭建服務中心，服務中心就是服務治理的總體解決思路，由服務中心解決服務發現、服務調度、服務資源、服務質量、服務監控。

二、服務治理-設計

我們的設計非常簡單：

1、厘清三個節點：服務的消費者、生產者、服務中心。服務消費者和生產者之間沒有任何生產節點，我們的調用還是通過原生調用，服務中心只負責後面的一些資源管理和服務的配置推送，這期間運維是相對清閑的，因為所有的接入實例都會自動註冊到服務中心，無論是消費者，還是生產者都會實時接收到相關的配置變動。另外，服務消費者和服務生產者之間是沒有中間節點的，自動接入的服務都是以內網IP的方式進行通信。

2、服務調度框架HTTPSF，包括權重負載均衡、自動降權、自動恢復，調度鏈染色，後續我們基於HTTPSF實現了RPC框架。

3、內部/外部服務，內部服務是無需資源管理的，服務實例啟動時就會自動接入服務中心，同時，我們有很多的外部服務依賴，要訪問各種外部渠道平臺的接口，一個重點是把外部服務納入到我們的服務框架，在外部出現問題的時候，我們能夠自動做一個降權跟恢復處理，外部服務的服務信息沒辦法自動註冊，由運維做人工錄入到服務中心。

三、服務治理-協議

為什麽用HTTP協議？在著手進行服務治理時，整個平臺實際在線上已經有100+的服務，而且是用HTTP協議JSON的序列化方式，這造成我們沒辦法對現有的服務做一個徹底的改造，所以我們沒辦法使用現成的服務框架，例如淘寶的HSF服務框架來做服務化的改造，同時我們是個完全業務驅動的平臺，我們也沒法投入這樣的成本停下業務進行服務化改造，因此我們的框架是完全兼容現有的服務在上面做的HTTPSF，基於HTTP協議做的一個調度框架，我們幾乎沒有投入任何的接入成本就完成了服務化，後面我們做了一個HTTPSF-RPC框架，JWS框架中也集成了RPC的服務容器，新業務組件為了更高的開發效率會優先使用RPC框架。

四、服務治理-去中心依賴

因為加入了服務中心，平臺變成了一套非常復雜的分布式系統，服務中心變得非常重要，同時去中心化也就非常必要了。在服務中心出問題的時候，怎麽去處理，這邊會有兩級容災：第一級很簡單，就是服務中心集群部署，它保證內部不出問題，目前一直保證著5個9的可用性；另外一個層面就是萬一服務中心出問題了怎麽辦？每個服務接入都會有一個Backup文件，所有跟服務中心的交互、配置都會在本地同步一個Backup文件，一旦服務器出問題，沒法做接入的時候，會讀取最近一次的Backup文件，按照之前的配置結點啟動程序，這是去中心依賴的設計。

五、服務治理-負載均衡

這是我們的後臺頁面，實際上是運維同學用的最多的頁面，但其實要做的事情並不多，只要知道我們服務都接入了哪些實例，權重如何，是否開啟等等，內部服務接入之後會有一個已接入狀態，內網IP就會自動發布，上面account_server是我們九遊的帳號服務，就可以通過內網IP來做訪問。uop是UC的帳號系統，就是UC的賬戶開放平臺提供了整個UC的帳號體系，uop相對我們平臺而言就是一個外部服務。這裏運維啟用了4條鏈路，都是在做多級容災。正常情況下絕大部分訪問量都會到我們運維希望最快的鏈路上面去了，一旦出現了問題，他會自動切換到移動或者電信或者汕頭機房的集群。這就實現了多鏈路容災處理。

六、服務治理-調度依賴管理

我們在服務的依賴管理方面可以拿到很多數據，所有對外依賴的系統和接口，各個負責人都可以看到自己系統的依賴情況，我們還可以看到實時訪問量的曲線波動情況，可以對系統做一些依賴管理。

我們每周會發布依賴質量情況：比如這個系統對外依賴的情況，它依賴了這麽多對外系統，其實都是我們內部的系統；它的訪問量占比代表依賴情況；接著就是性能情況，以及可用性情況，每周可用性是增加還是降低的，都是可以看到的；訪問量有沒有增大，都可以做分析。負責人可以根據這個情況來判斷對外依賴的情況是否需要改善或者做一些系統優化。

七、服務治理-故障拓撲

現在我們有整個的故障拓撲，這張圖是我們線上的真實情況，服務量不是很多，因為我們做了一個服務的分級處理，運維只關心核心服務，核心服務涉及到的調度都在這裏。運維只關心不同級別的服務的可用性，這是比較關鍵的，像上圖中核心服務實際上是要求可用性能夠確保達到4個9，這是最真實的可用性，因為不是通過采樣得到的數據，而是所有的調度數據都會進行實時的統計。

我們九遊服務管理人的角色，你進去之後可以看到所有依賴你的服務跟你對外依賴的服務組成的網狀故障拓撲，基於這個拓撲，我們可以做一些報警或者一些質量分析。

八、服務治理-流程審批

在服務治理方面有流程審批，為了使整個運維工作更加便捷。我們所有的上線會變得非常簡單，只需要在後臺就可以完成，因為用戶註冊、申請權限、然後上線申請、服務調度授權申請，都是由各個業務負責人去提交流程。這也是在打造我們的運維生態，讓運維工作可以更簡單，變得規範化、降低成本，畢竟維護200多個獨立系統，沒有規範的流程，一定會出現疏漏的問題。

我們盡量把所有涉及到的服務管理、服務治理的問題處理好，盡量讓運維不需要人工操作，包括看到的各種系統展示，運維沒有任何的操作概念在裏面，他只要管控、處理好監控、處理好報警閥值，這是他的一些具體工作。同時，服務中心系統讓運維人員更關註一些應用上的數據，包括服務的依賴，容量，和質量，運維不再局限於只是做部署，從而把運維上升到一個應用運維層面，做的這些事情都是在幫助運維打造這樣一個生態。

打造運維生態

要做好服務治理，尤其是有運維產品的服務治理，要做的事情挺多、也挺專業的。可以看到我們有這麽多內容，包括服務發現、服務調度、服務資源、服務質量，包括後面我們一直在打造的運維生態。我可能實現了一個協議，我們做了一個調度，實現了服務的交互，這些就是服務治理嗎？不是的，我們要做很多事情來維護所有服務，比如確保服務註冊、服務發現、接口發布都是實時感知的。

服務調度，一旦出現波動問題都是做自動降權或者自動恢復，以應對運維來不及處理異常的情況。之前很多級別的問題都是數據突然間抖動或者網絡突然間抖動，但抖動的時間不長，可能是幾十秒，造成依賴方阻塞，這種情況下通過服務調度做自動降權，確保不會被你依賴，保證自身的穩定；當然服務方的服務容器這塊我們有統一請求隊列關聯和過載保護機制，共同確保我們整個平臺的可用性。

服務資源包括服務、實例、接口、接口黑白名單、RPC元數據、RPC容器、調度授權、調度策略、集群管理。

還有服務質量，包括調度監控、調度鏈監控、依賴監控、故障拓撲、故障時間分布、質量報告、服務分級、集群監控、報警系統。我們各種調度的監控，剛才列出來的只是很少一部分，我們還有各種各樣的依賴、調度鏈，包括故障分布時間，服務分級的一些監控、質量報告、集群監控等等。

我們做了很多工作來確保整個平臺的穩定性，所做的工作基於打造運維生態，確保我們的運維能夠盡量減少人工操作，盡量可以讓系統自動識別、自動處理，運維從全局把控住整個依賴關系的具體情況，保證系統全局處於穩定的情況。

服務治理的技術點