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

閱讀目錄

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

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

名稱所屬公司

是否開源

資料文件

備註dubbo

阿里巴巴是多

hsf阿里巴巴否中

目前已作為阿里雲產品edas其中的套件開放使用

tars是中

jsf京東否少

linkerd

cncf是少

原型是twitter所構建的乙個基於scala的可擴充套件rpc系統finagle

motan是中

istio

谷歌、ibm、lyft是少

1.阿里 - dubbo

2.阿里 - hsf

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

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

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

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

客戶端的自動發現：當我們在config檔案中指定具體的ip和埠來定義遠端服務的位址，或者直接在程式裡硬編碼遠端服務位址時，本身就是乙個端到端的訪問方式。無法靈活的在程式執行過程中去增加或減少後端的服務節點。

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

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

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

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

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

如果使用zookeeper的話，首先我們需要分別給每乙個服務的提供方定義乙個統一的目錄，作為各個服務的根節點。然後讓該服務的每個獨立的程序在這個根節點下create乙個臨時節點。這樣，我們的呼叫方只需要watch根節點下的子節點變化，即可實現了後端各個服務提供節點的移除和新增。但是需要注意的是zookeeper在連線斷了之後，不會馬上移除臨時資料，只有當sessionexpired之後，才會把這個會話建立的臨時資料移除。因此，我們需要謹慎的設定session_timeout。

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

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

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

出處：的***~。

定期發表原創內容：架構設計丨分布式系統丨產品丨運營丨一些思考。

」，回覆「運營」，送你乙份我長期收集和整理的思維導圖。

分布式系統中的必備良藥 全域性唯一單據號生成

閱讀目錄 我們作為乙個軟體系統，肯定到處充滿著各種單據，也必然需要有各種單據號與之對應。比如 電商行業的訂單號 支付流水號 退款單號等等。scm的採購單號 進貨單號 出貨單號 盤點單號等。在乙個企業內部或者乙個2c的平台，無法避免的需要通過某個單據號來進行溝通。所以乙個好的單據號必然是便於溝通的，簡...

分布式系統中的分布式事務

分布式事務中可以借助mq訊息系統來進行事務控制，這一點與可靠訊息最終一致方案一樣。看來mq中介軟體確實在乙個分布式系統架構中，扮演者重要的角色。最大努力通知方案是比較簡單的分布式事務方案，它本質上就是通過定期校對，實現資料一致性。中介軟體如何保證訊息的一致性 問題的問法多種多樣，怎麼保證兩個伺服器的...

初識分布式服務治理技術Dubbo（一）

一，達博應用的場景 1 當服務越來越多時，服務url配置管理變得非常困難，此時需要乙個服務註冊中心，動態的註冊和發現服務，使服務的位置透明。並通過在消費方獲取服務提供方位址列表，實現軟負載均衡和故障轉移，降低對f5硬體負載均衡器的依賴，也能減少部分成本。2 當進一步發展，服務間依賴關係變得錯蹤複雜，...