分散式系統中的必備良藥 —— 服務治理

閱讀目錄

• 前言
• 成熟的解決方案
• 剖析
• 實戰
• 服務治理的擴展

一、前言

　　首先本文僅作為筆者在做一些調研之後的總結，僅提供思路，不提供源碼，所以如果是想直接衝著源碼來的，可以跳過此文。如果後續有機會將項目開源出來，會第一時間寫新文章講解實線細節。

　　在分散式系統的構建之中，服務治理是類似血液一樣的存在，一個好的服務治理平臺可以大大降低協作開發的成本和整體的版本迭代效率。在服務治理之前，簡單粗暴的RPC調用使用的點對點方式，完全通過人為進行配置操作決定，運維成本高（每次佈置1套新的環境需要改一堆配置文件的IP），還容易出錯，且整個系統運行期間的服務穩定性也無法很好的感知。

　　關於服務治理網上相關的信息也是非常多，但是如何基於每個公司的當下情況去選擇最合適的方案落地，是我們每個架構師或者Leader需要考慮的問題。所謂工欲善其事必先利其器，做好了服務治理，那麼SOA化的推進會事半功倍，已經從技術層面天然支持了程式的水平擴展。.Neter社區下成熟的服務治理平臺缺乏，我想這也是每個基於.Net技術棧公司面臨的問題。2016年微軟正式推出了Service Fabric，並於17年開源（https://github.com/Azure/service-fabric），但是相對Java社區常見的解決方案，這個還未得到大規模驗證，所以還需謹慎對待。所以本文就通過對不同的成熟解決方案來分析，提煉出一些核心的通用準則，來分析自建一個服務治理框架需要做些什麼。歡迎大家拍磚。

二、成熟的解決方案

　　查閱的一些資料，目前的業界一些比較成熟的解決方案如下：

　　相關資料文檔較為豐富的只有一個Dubbo。下麵先羅列一下這些解決方案的架構設計（點擊圖片可跳轉到圖片出處）。

　　1.阿裡 - Dubbo

　　2.阿裡 - HSF

 　　3.騰訊 - Tars

　　4.JSF

　　5.CNCF - Linkerd

　　6.新浪 - Motan

　　7.istio

 　　大家可以看到，大部分（Linkerd除外、MSEC沒找到架構圖）方案的設計風格非常相似，都是通過庫的方式在調用客戶端做的服務發現。那麼除了實際的RPC調用之外，主要多了這3個動作：註冊、訂閱、變更下發。除了這3個核心動作之外，其它的輔助操作還有統計上報、鑒權等等，這也是我們搭建一個服務治理框架需要實現的功能。從MVP的角度來說，註冊、訂閱、變更下發是最基礎的核心功能。

三、剖析

 　　首先前文里也說了，引入服務治理是為了對整體的RPC調用進行集中化管理。對我們來說其核心價值在於，減少重覆勞動、避免手動配置物理文件產生的問題、降低開發人員的技術運用成本。下麵針對其中的功能點進行分別講解。

服務的自動註冊：

　　這是一個服務治理框架的基礎功能。大家運用WCF的時候應該感受更加明顯，我們要配置一個WCF服務端的時候需要在config文件中做很多配置，甚至大部分公司其實配置都是一模一樣的到處複製黏貼，整個這個過程其實是價值較低的重覆性勞動。

　　解決這個問題需要通過動態的感知到服務端的地址信息，然後針對該地址信息進行自動化配置或者模板化配置，讓其快速可用。那麼這些額外的信息保存在哪，就需要引入一個註冊中心的概念來進行集中化管理。

客戶端的自動發現：

　　當我們在config文件中指定具體的IP和埠來定義遠程服務的地址，或者直接在程式里硬編碼遠程服務地址時，本身就是一個端到端的訪問方式。無法靈活的在程式運行過程中去增加或減少後端的服務節點。

　　解決這個問題需要和服務註冊的實現方式配套。還可以針對於不同類型的應用制定一些負載均衡的策略進行切換。

變更下發：

　　客戶端的自動發現就依賴於此下發的數據，需要及時把提供服務的節點信息變化下發到各個客戶端。它面向的場景如：當我們進行一個發佈的時候，先將需要發佈的節點從負載均衡列表中移除，然後再進行更新，最後再添加到負載均衡列表中。這個時候避免了訪問到正在發佈中的程式。

　　當然這點也可以基於狀態檢測模塊去做，這樣可以對服務節點的健康狀態感知能力得到更好的加強。

四、實戰

下麵我們剖析一下這2個核心功能的實現。

1.註冊、訂閱

　　通過上面可以看到，主流的註冊、訂閱的實現需要引入一個數據集中化的節點。如果我們想要自己建立這個節點程式，那麼需要考慮高可用問題。如果圖省事，可以引入一個分散式協調器（也可以理解為一個配置中心）來實現，如：ZooKeeper、Consul等。

2.變更下發

　　如果上面的第一點選擇自研，那麼需要考慮通知下發的問題，一般可以通過tcp建立長連接來進行主動推送。

　　如果使用Zookeeper的話，首先我們需要分別給每一個服務的提供方定義一個統一的目錄，作為各個服務的根節點。然後讓該服務的每個獨立的進程在這個根節點下Create一個臨時節點。這樣，我們的調用方只需要watch根節點下的子節點變化，即可實現了後端各個服務提供節點的移除和新增。但是需要註意的是Zookeeper在連接斷了之後，不會馬上移除臨時數據，只有當SESSIONEXPIRED之後，才會把這個會話建立的臨時數據移除。因此，我們需要謹慎的設置Session_TimeOut。

五、服務治理的擴展

 　　在企業中，我們可以針對服務治理做更多的擴展。比如：

　　1.基於版本號的服務管理，可以用於灰度發佈。

　　2.請求的複製回放，用於模擬真實的流量進行壓測。

　　3.給請求打標簽用於實時的線上壓測。

　　4.更靈活的負載均衡和路由策略。

　　5.內置的熔斷機制，避免整個分散式系統產生雪崩效應。

作者：Zachary_Fan
出處：http://www.cnblogs.com/Zachary-Fan/p/service_manage_discovery.html

如果你想及時得到個人自寫文章的消息推送，歡迎掃描下麵的二維碼~。