HSF原理簡介

0. 前言

HSF是一個分佈式的遠程服務調用框架，其實我更喜歡把分佈式幾個字去掉，由於HSF自己並非一個單獨的服務（指一個進程），他是附屬在你的應用裏的一個組件，一個RPC組件(遠程過程調用——Remote Procedure Call，是一種經過網絡從遠程計算機程序上請求服務，而不須要了解底層網絡技術的協議。在OSI網絡通訊模型中，RPC跨越了傳輸層和應用層。RPC使得開發分佈式應用更加容易)，固然HSF徹底的內容確定不止這些。

​ HSF(High-speed Service Framework)，高速服務框架，是阿里系主要採用的服務框架，其目的是做爲橋樑聯通不一樣的業務系統，解耦系統之間的實現依賴。其高速體如今底層的非阻塞I/O以及優秀的序列化機制上，實現了同步和異步調用方式，而且有一套軟負載體系，實現分佈式應用。

1. RPC

咱們先來看一張圖：

不少同窗看了這張圖可能會以爲這跟http的過程有什麼區別？

有這麼一個場景（原本想舉一個便具體業務的例子，想一想仍是已技術實現相關的比較好），監控平臺：監控全部主機的狀態，這時候每臺主機上有一個agent，每一個幾秒向監控平臺上傳一次數據（主機內存使用率、硬盤情況、CPU、load、進程信息等等）。

可能在開發的時候最簡單的方式就是監控平臺有一個http接口，agent每隔幾秒請求一次，可以知足需求，可是若是主機數快速增加了不少、監控項愈來愈多、請求體愈來愈大，你會發現http的傳輸效率降低了，每一次調用的耗時增長了。

這時咱們會去研究http協議，想去優化這個過程，發現http的過程是：創建鏈接、發送請求信息、發送響應信息、關閉鏈接， 看到這個過程首先想優化的就是能不能不要每次都去創建鏈接關閉鏈接，由於數據上報是個持續的過程；緊接着去研究http頭，發現不少協議用不到，繁雜，白白增長了消息體； 後來又以爲http的協議解析還原過程很複雜，能夠本身開發一個提高性能……

RPC來了，他能知足這些需求，可是前提是須要開發，須要前期成本，因此想項目設計時就要去衡量，不過沒事，咱們有HSF啊。

咱們將上圖稍微改造一下：

如今從圖中能夠看着，client和server之間有一條長鏈接，而且咱們有本身的協議體：RpcRequest和RpcResponse。

RPC就講到這裏，畢竟重點是HSF，想要更多的瞭解RPC，能夠上wiki或者網上查詢。

2. HSF架構

其實在咱們的應用中，通常狀況下你的應用不只僅是client，也是server，由於你不只須要去調用其餘應用提供的服務，也提供服務給其餘應用，因此這樣一來，整個hsf的服務調用鏈路也會很複雜。

從上面兩幅圖中咱們很顯然的發現一個問題，就是服務提供者如何告知客戶端他提供的服務，因此須要有一個服務註冊與發現的地方，在HSF架構中提供這個功能的是configserver， 以下圖：

從上圖能夠看出server端啓動的時候會向configserver註冊本身提供的服務，client會向configserver訂閱須要的服務，configserver經過訂閱信息將相關服務提供者的地址以及其餘關鍵信息推送給client。

上面已經實現了基本的能力，可是如何動態配置負載（線程池大小）、默認配置（configserver地址等）、還有一些特性功能（如路由規則），這時候就須要有一個持久化配置中心， 以下圖：

client和server啓動的時候會先去diamond獲取須要的配置信息，如最關鍵的服務註冊中心的類型和地址，除此以外以外還有服務治理的類型和地址等。

重點說一下路由規則，舉個例子：經過路由規則配置在服務調用的時候只調用同機房的server，這樣子服務調用的耗時確定比跨機房的耗時短。除此以外hsf裏還單獨寫了unitService進行服務單元發佈來區分中心發佈，這些番外的東西之後有時間再寫個番外篇，這裏就不過多闡述了，畢竟這些有點偏場景偏業務的內容之後可能就改爲別的方式了。

相信你們都用過hsf服務治理網站，經過這個網站能夠看到有哪些服務、服務提供者的地址是多少、有多少提供者、具體的消費者是誰，hsf經過configserver、redis、diamond裏的存儲信息獲取到這些信息。

redis功能：HSF使用Redis存儲元數據， 每個HSF Consumer/Provider 都會在啓動後、每隔一段時間向redis上報元數據，這些元數據採集起來又提供給HSFOPS作服務治理，包括應用名和服務的映射、服務的元數據等。

參考：
https://www.jianshu.com/p/6f5a328e4543