分散式系統中的必備良藥 —— 服務治理
閱讀目錄
一、前言
首先本文僅作為筆者在做一些調研之後的總結，僅提供思路，不提供原始碼，所以如果是想直接衝著原始碼來的，可以跳過此文。如果後續有機會將專案開源出來，會第一時間寫新文章講解實線細節。
在分散式系統的構建之中，服務治理是類似血液一樣的存在，一個好的服務治理平臺可以大大降低協作開發的成本和整體的版本迭代效率。在服務治理之前，簡單粗暴的RPC呼叫使用的點對點方式，完全通過人為進行配置操作決定，運維成本高（每次佈置1套新的環境需要改一堆配置檔案的IP），還容易出錯，且整個系統執行期間的服務穩定性也無法很好的感知。
關於服務治理網上相關的資訊也是非常多，但是如何基於每個公司的當下情況去選擇最合適的方案落地，是我們每個架構師或者Leader需要考慮的問題。所謂工欲善其事必先利其器，做好了服務治理，那麼SOA化的推進會事半功倍，已經從技術層面天然支援了程式的水平擴充套件。.Neter社群下成熟的服務治理平臺缺乏，我想這也是每個基於.Net技術棧公司面臨的問題。2016年微軟正式推出了Service Fabric，並於17年開源（
二、成熟的解決方案
查閱的一些資料，目前的業界一些比較成熟的解決方案如下：
| 名稱 | 所屬公司 | 是否開源 | 資料文件 | 備註 |
| Dubbo | 阿里巴巴 | 是 | 多 | |
| HSF | 阿里巴巴 | 否 | 中 | 目前已作為阿里雲產品EDAS其中的套件開放使用 |
| Tars | 騰訊 | 是 | 中 | 已作為騰訊雲應用框架對外提供使用 |
| JSF | 京東 | 否 | 少 | |
| Linkerd | CNCF | 是 | 少 | 原型是Twitter所構建的一個基於scala的可擴充套件RPC系統Finagle |
| Motan | 新浪微博 | 是 | 中 | |
| istio | 谷歌、IBM、Lyft | 是 | 少 |
相關資料文件較為豐富的只有一個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.內建的熔斷機制，避免整個分散式系統產生雪崩效應。
如果你想及時得到個人自寫文章的訊息推送，歡迎掃描下面的二維碼~。
