分佈式調用框架RSF-註冊中心設計

時間 2019-11-26

標籤分佈式調用框架 rsf 註冊中心設計欄目系統架構简体版

原文原文鏈接

RSF 一直以來都是源碼形式存在並未發佈任何一版，其主要緣由仍是對於註冊中心這一塊一直以來都沒有想清楚。如今想的也差很少了拿出來跟你們曬曬也歡迎各位大牛前來拍磚。 git

首先要介紹一下什麼是 RSF 以及這貨是怎麼來的。安全

RSF全名是 Remote Service Framework，翻譯過來就是分佈式服務調用框架。也就是一個分佈式RPC。這裏是RSF的源碼地址：http://git.oschina.net/zycgit/rsf。服務器

這貨是我在學習淘寶HSF框架時學習總結而來的，在編寫它的時候一方面是學習總結，另外一方面是爲 Hasor 框架豐富更多的插件。可是RSF的註冊中心則更多的融入了我我的的一些思考。 session

Hasor框架源碼：http://git.oschina.net/zycgit/hasor（介紹：http://www.oschina.net/p/hasor）架構

交代完出身那麼就來講說這個註冊中心是個什麼東西。框架

首先拋開分佈式不講，但提一提RPC調用。RPC 本質上就是在 A 機器上去調用 B 機器上的一個服務方法。可是在分佈式下，A機器去調用遠程方法的時候會發現不光有一臺 B 機器。它會發現有 B、C、D、E...好多臺機器均可以去調用。分佈式

那麼如今問題來了，誰來告訴A，有 B、C、D、E 這麼多臺機器能夠去用呢？要麼 A 本身知道有這麼多臺機器，要麼有一箇中間人告訴 A 有 B、C、D、E 這些可選的機器。而「註冊中心」就是這麼個角色。工具

1、RSF註冊中心的目標

1.爲RSF提供服務發佈和訂閱 性能

這個目標指的是註冊中心要負責維護一個列表，這個列表上要列出全部在線的RSF應用。而且列出這些應用上的RSF服務。經過這個列表能夠爲RSF客戶端提供查詢從而完成中間人的角色。學習

2.提供鏈接終端的管理

該功能是用來管理哪些應用能夠鏈接到註冊中心那些應用不能夠鏈接到註冊中心。在應用級別的角度保障整個RSF集羣的安全可靠。同時也負責維護一些應用信息方便開發者查閱和追中數據。

2、考慮的緯度和模塊劃分

爲了達到這些目標註冊中心須要經過三個緯度共計四個模塊去實現。三個緯度（應用緯度、服務緯度、終端），四個模塊（應用管理、服務發現、監控中心、終端管理）先說緯度。

----緯度----

任何一個RSF客戶端都具備如下幾個特色。

RSF服務由某一個應用程序提供。
RSF調用是經過暴露服務接口來提供。
遠端兩個程序在進行RSF數據交換時必須經過TCP/IP。

根據這三個特色總結出的三個緯度。RSF註冊中心在這三個緯度上分別提供不一樣的功能支持。

應用緯度：應用這個緯度表示的比較籠統。它能夠是業務的也能夠是project的。從業務緯度上去講應用的話，一個應用會包含多個項目。可是不管是幾個項目，服務接口的定義應該是惟一的。這也就是RSF註冊中心在界定應用的重要依據。

RSF能夠把不一樣的接口組織到一塊兒稱之爲一個應用。例如在電商架構中搜索、庫存、商品展現、訂單等等都被拆成獨立的應用，可是都提供了不一樣的接口。若是公司想發展一些其它特殊業務則能夠新起一個應用。如何使用應用則全看您如何定義它。

應用的另外一項，重要功能是用於標記owner和接口人，當公司逐漸變大，業務逐漸複雜須要更多的人蔘與以後，應用的人員標記會很方便找到你的依賴方。從而達到節約溝通成本的做用。

服務緯度：在服務緯度下，註冊中心要提供基於服務（分組、名稱、版本）三個緯度的查詢支持。此外服務緯度中還要負責維護客戶端在線狀態列表，並實時的把不在線的機器從列表中踢出。爲此註冊中心還要設計一個心跳機制來保證機器的存活。

終端緯度：終端指的是一個實際物理鏈接，每一個終端都表明了一個實際的RSF客戶端應用程序。終端的管理更可能是安全方面的，例如是否容許某個終端的加入，同時終端管理也能夠用來作註冊中心上的流控規則。比方說在服務不中止的狀況下將其下線，若是單靠規則推送風險會比較大。由於規則的推送每每會影響更多的機器，而終端下線則只是模擬發送一條消息告訴集羣「某臺Server掛了，你們先不要去調用它了」而已。

說完緯度再說功能模塊就會清晰不少，RSF註冊中心的四個模塊中有三個都是針對緯度。只有監控被特殊單獨列爲一個模塊。下面開始介紹模塊的功能和做用。

----模塊----

應用註冊

提供一個頁面讓開發者能夠建立一個RSF應用分組，而且能夠設置應用（Code、應用名稱、owner、接口人、應用分組）等信息以備未來查閱，同時還要提供相關的更新、刪除操做功能。其中Code是應用的惟一識別碼，爲了安全起見只容許使用（數字、字母和下劃線），應用分組數據是一個樹形結構。

在應用下面還包含了服務列表的管理，服務列表包含了（新增、刪除、修改）三個功能，經過服務管理能夠預先定義服務而且能夠給服務配置路由策略。服務至少要包含（分組、名稱、版本、owner、接口人）信息。

應用預受權

應用受權是安全方面的考慮，當RSF客戶端嘗試在註冊中心上登記時。若是配置的受權碼不正確註冊中心會拒絕這個客戶端的鏈接，被拒絕的客戶端不會獲得註冊中心任何信息反饋。這個功能能夠防止一些惡意程序的連入和掃描，也能夠在公司內部用以安全防範。

也就是說RSF客戶端在向中心註冊的時候，至少須要提供應用的（Code碼、受權碼）兩個數據。若是啓用了匿名應用則能夠什麼都不傳直接鏈接到中心，有關匿名應用詳見下面專門的介紹。

應用列表（包含：應用查詢、應用詳情）

這個是應用管理中一個比較重量級的模塊，它包含了 list 和 detail 兩個頁面，其中 list 頁中還要提供基於（應用名、應用Code、應用組名）查詢支持。點擊list頁上的信息能夠進入 detail 在 detail 頁 owner 能夠修改應用信息。信息的詳細程度能夠具體在實現中逐步完善。

匿名應用

匿名應用是一個預留的默認選項，若是強制要求全部鏈接到註冊中心 RSF客戶端都要求有應用與其對應的話，開發和部署會比較麻煩。所以匿名應用就產生了。啓用匿名應用以後，RSF客戶端能夠直接鏈接到RSF註冊中心查詢本身所須要的服務列表。

服務中心

服務中心是一組後臺服務，它是整個RSF註冊中心的核心，它負責接收來自RSF客戶端的請求。處理應用上線、下線、服務發佈、服務訂閱。同時也負責維護客戶端心跳，必要時候服務中心還會更新服務在線狀態。

所以咱們能夠看到服務的發佈、訂閱和心跳檢測功能都是在這裏。配置推送指的是服務路由策略的推送。

RSF中心和RSF客戶端，的通信採用長輪訓（Long-Polling）方式。客戶端發起一個長鏈接請求並同時攜帶上一次請求時標識ID，若是服務器端發如今這個標識ID以後曾經發生了數據變更那麼就把最新的數據返回給客戶端（全量數據），尚若服務器發現沒有數據變化，那麼持有這個鏈接 30 秒。在持有鏈接的過程當中若是有數據發生變化，註冊中心要及時的反饋數據給客戶端。

每當註冊中心把數據響應給客戶端以後都要把鏈接關閉，等待下一次客戶端發來請求。經過這種方式RSF客戶端和服務器之間能夠達到實時同步數據的目的。之因此這樣設計是由於考慮到實際生產環境中服務器的上下線不會很頻繁。並且這種設計很小巧切知足功能須要，同時也不須要引入 zookeeper 這樣的你們夥。

若是註冊中心和RSF客戶端之間採用 zookeeper 進行數據同步的話就不得不考慮，zookeeper 死掉和 zookeeper session 丟失的問題。可是若是使用長輪訓這種方式，咱們在設計整個 RSF 體系的時候就會思路很是清晰，把複雜的事情簡單化纔是目的所在。

查詢中心

查詢中心包含兩個頁面，一個是 list 頁另外一個是 detail頁。在 list 頁裏開發者能夠經過（應用名、服務分組名、服務名稱、客戶端IP）這些信息來查詢在線的RSF服務。全部符合條件的RSF服務都會被列出來，固然頁面是要有分頁的。點擊其中一條數據就能夠進入服務詳情頁（與應用註冊中的詳情頁共享）在這個頁面中會羅列出，這個服務的 owner，所屬應用，接口人，服務名字，服務分組，服務版本，提供者列表、消費者列表等信息。