第五章第一節、大話微服務架構之服務治理和監控-為什麼需要服務治理平臺？（一）
不知道大家對服務治理中心有沒有了解或聽說過，通俗點將就是服務管理中心，也就是管理微服務的，那為什麼非要服務治理平臺來管理微服務呢？下面本文作者將和大家分享下如下幾點要使用服務治理中心的原因：
1、服務集中化可視化管理
當微服務被越來越多的人追捧並被廣泛使用後，大規模的微服務被上線到生產環境中，京東的微服務已經上線部署到上萬個Docker容器中，這麼多的容器和微服務，一旦哪個環節出了問題，運維成本可想而知。
所以，要想科學有效的管理這些微服務，就必須要藉助一些平臺或工具。可以以可視化操作界面的形式看到所有微服務的列表以及運行狀態、部署在哪個區域、哪個環境、哪臺機器上面。甚至可以看到哪個微服務壓力比較大，調用比較頻繁等等。如果沒有這個平臺的話，我們傳統的做法就是登錄到每臺機器去查看這些微服務的各項指標了。
2、提供服務發現與註冊入口
一個系統通常被分為若干個微服務，這些微服務通常又是彼此有關聯的，比如用戶微服務和訂單、庫存等微服務通常要交叉調用。但是在生產環境中，這些微服務被分佈式的部署在不同的機器和容器上面，如果去找到自己所需要服務的地址是一個大難題，當知道了這個服務地址後，這個服務是否是可用的也不是很確定。這時，如果有微服務治理平臺的話，只需要知道服務治理中心的地址，通過微服務唯一名稱去微服務治理中心查對應服務就可以得到想要的微服務地址，而且，如果服務治理中心如果本身集成了複雜均衡和健康檢查的話，你得到的地址將是一個負載均衡和健康檢查後的高可用地址。
服務能被治理中心發現，前提是，服務一旦上線後，自動註冊到服務治理中心，服務治理中心提供服務註冊的統一入口。
3、遠程批量操作微服務
當系統運行一段時間，修改了一個數據，需要重啟某個微服務時，由於這個微服務部署在不同的平臺和機器或容器上時，要手工去挨個操作，一是效率低，工作量大，而是不安全，因為人工難免有事物，個別機器忘記操作了也是常用的事。而如果有統一的服務治理中心後，就可以在可視化界面修改下配置、點幾下鼠標就可以分分鐘搞定，而且還會有操作日誌，詳細的記錄成功重啟了哪些機器、耗時多久，有多少臺機器重啟失敗，失敗的機器列表裡面，還有重試的按鈕，支持再次重啟。
4、灰度發佈
我們部署微服務的初衷是什麼？無非就是微服務體量小，可以快速的產品迭代、快速上線、灰度發佈。
大家也知道，互聯網系統一般都是7*24全天候不間斷運行的。具體到微服務這裡，也就是說每個微服務在7*24時間段內至少要有一個實例在運行。即使在產品發佈期間，也是如此。那要更新這個微服務怎麼辦呢？當然是灰度發佈，也就是，微服務要一個一個或是一批一批的更新，而不能一口氣把全部實例更新完，要保證，在更新期間，每個微服務至少有一個實例在運行，可以正常對外提供服務。這時如果每個微服務治理中心的話，人工是很難精確做到每個服務不停機進行灰度發佈的。
5、監控服務狀態
微服務上線後，那接下來就是監控了，如果沒有統一的服務監控中心，靠人工去一個個監控，那是不現實的。有了服務監控中心後，運維人員可以在可視化的控制面板裡看到或查到每個微服務的每個實例的運行狀況，資源消耗參數。以及當前有哪些服務發出了報警，需要處理的任務列表等等。
6、負載均衡
服務註冊到統一的治理中心後，我們可以根據一些負載均衡的算法比如輪詢、加權輪詢、隨機輪詢、最少錯誤、最小時延等等。提供給調用方的是一個經過負載均衡之後的地址，提供服務的高可用性。
7、服務編排
在灰度發佈部署和其它調度任務時，編排服務。
提供服務的統一鑑權中心。
當然，有些服務治理中心平臺做得比較複雜的，還有更多的功能，這裡就不一一列舉了，大家如果有好的想法可以在下方留言一起溝通交流！
閱讀更多 微服務DevOps 的文章
