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