一、前言

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

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

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

二、成熟的解決方案

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

　　相關(guān)資料文檔較為豐富的只有一個Dubbo。下面先羅列一下這些解決方案的架構(gòu)設計（點擊圖片可跳轉(zhuǎn)到圖片出處）。

　　1.阿里 - Dubbo

　　2.阿里 - HSF

 　　3.騰訊 - Tars

　　4.JSF

　　5.CNCF - Linkerd

　　6.新浪 - Motan

　　7.istio

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

三、剖析

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

服務的自動注冊：

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

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

客戶端的自動發(fā)現(xiàn)：

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

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

變更下發(fā)：

　　客戶端的自動發(fā)現(xiàn)就依賴于此下發(fā)的數(shù)據(jù)，需要及時把提供服務的節(jié)點信息變化下發(fā)到各個客戶端。它面向的場景如：當我們進行一個發(fā)布的時候，先將需要發(fā)布的節(jié)點從負載均衡列表中移除，然后再進行更新，最后再添加到負載均衡列表中。這個時候避免了訪問到正在發(fā)布中的程序。

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

四、實戰(zhàn)

下面我們剖析一下這2個核心功能的實現(xiàn)。

1.注冊、訂閱

　　通過上面可以看到，主流的注冊、訂閱的實現(xiàn)需要引入一個數(shù)據(jù)集中化的節(jié)點。如果我們想要自己建立這個節(jié)點程序，那么需要考慮高可用問題。如果圖省事，可以引入一個分布式協(xié)調(diào)器（也可以理解為一個配置中心）來實現(xiàn)，如：ZooKeeper、Consul等。

2.變更下發(fā)

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

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

五、服務治理的擴展

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

　　1.基于版本號的服務管理，可以用于灰度發(fā)布。

　　2.請求的復制回放，用于模擬真實的流量進行壓測。

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

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

　　5.內(nèi)置的熔斷機制，避免整個分布式系統(tǒng)產(chǎn)生雪崩效應。

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

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

http://www.cnblogs.com/Zachary-Fan/p/service_manage_discovery.html

延伸閱讀

• 分布式系統(tǒng)中的必備良藥 —— 全局唯一單據(jù)號生成 2017-07-21
• 基于Nginx dyups模塊的站點動態(tài)上下線并實現(xiàn)簡單服務治理 2017-02-16

分布式系統(tǒng)中的必備良藥 —— 全局唯一單據(jù)號生成