最近在讀阿里巴巴中台戰略思想與架構這本書，so和大家分享一些我get到的東東。
HSF是阿里巴巴內部的分布式服務框架，這個大家都很熟悉了，先上一張HSF的工作原理圖：
這個圖說明了HSF框架中每個組件在整個框架中扮演的角色，下面分別介紹下：
（1).服務節點對配置服務器列表的獲取。伴隨着web容器的啟動，服務提供者和服務調用者向地址服務器獲取配置服務器和Diamond服務器的ip列表信息，過程見上圖的1、2步驟。
（2).服務的注冊發布。服務提供者獲取配置服務器列表后，將服務的相關信息（接口類全名、服務版本等）包含當前服務器的ip地址、端口等信息注冊到配置服務器，即上圖的3步驟。
(3).服務的訂閱。當服務調用者的應用啟動並獲取配置服務器列表后，發送服務消費的相關信息（服務接口全名、服務版本等）到配置服務器訂閱，然后配置服務器會通過“服務接口全名+服務版本”作為條件在內存中搜索，一旦獲取到服務注冊信息，就將對應的服務提供者的ip和端口發送到服務調用者的節點上，即上圖的4 、5步驟。
(4).服務規則推送（如果需要）。如果對服務安全管控和流量控制有需求時，可以通過Diamond服務器提供規則設置界面，對指定的服務提供者和服務調用者設置相關規則，規則保存后，會在5秒內推送到與設置相關的服務器節點上。
(5).服務交互。在應用進行業務請求處理過程中，出現服務調用者對服務提供者的調用時，服務調用者會從已經保存在該應用節點上的服務提供者服務器列表里選擇（阿里巴巴內部使用隨機模式）其中一台服務進行請求的發送，服務交互期間是調用者和提供者兩台服務器間的調用，無需通過中間別的服務器，這就是稱為“去中心化”的主要原因，即上圖中的步驟7
接下來具體介紹HSF框架的高效交互、高可用性和擴展能力。
1.HSF框架的采用Netty+Hession數據序列化協議實現服務交互
HSF采用網絡通信框架Netty+Hession數據序列化協議實現服務間的調用，主要考慮點在大並發量時，服務的交互性達到最佳。這類RPC協議采用多路復用的TCP長連接方式，即在服務調用者和服務提供者之間有多個服務請求同時調用時會共用一個長連接，一個長連接交替傳輸不同請求的字節塊。它既避免了反復建立連接開銷，也避免了連接的等待閑置從而減少了系統的連接總數，同時還避免了TCP順序傳輸中的線頭阻塞問題。
2.HSF框架的容錯機制
為了保證服務的高可用性，在生產環境中相同的服務往往會有很多個應用實例來提供服務，在進行服務調用時，服務調用者端已經保存了它需要調用的服務的服務器列表信。假如有三台服務器提供了相同的服務，當采用隨機方式獲取其中一台進行服務交互時，不論這台服務器已經發生故障無法回應請求，還是該服務器已經接收了請求，在服務請求處理過程中出現了服務器故障（宕機、網絡問題）造成該服務器沒有在規定的時間（一般服務調用會設置超時時間）內返回處理結果，則服務調用端會獲取服務調用失敗的反饋，會立即從剩下的兩台機器中選擇一台進行服務調用。從而保證了個別服務提供者出現問題，完全不影響該服務提供正常的服務。因為配置服務器是采用長連接的方式與服務器節點進行通信，一旦發現有服務實例出現故障，此時會將這台服務器提供者的信息從服務器的服務列表中刪除，然后將更新后的服務列表以推送的方式同步給予該服務相關的所有服務調用者端，這樣當下次進行服務調用時，就不會因為隨機而對已經停止提供服務的服務器發送請求。
3.HSF框架的線性擴展支持
HSF最為重要的一個特性就是服務能力的可擴展性，真正做到某個服務的業務處理能力隨着服務器資源的增加得到線性的增長。基於HSF框架的運行機制，面對超級大的服務調用壓力時，新增的服務提供實例（即增加一台服務器）可在幾秒內（完成服務的注冊發布、更新后的服務列表推送到服務調用端）開始進行服務請求處理，達到分擔其他服務器實例壓力的作用，實現服務能力整體水位恢復到正常的狀態。據說雙十一的時候阿里的多個服務中心所部署的服務實例節點數量超過2000個，即同一個服務由超過2000個服務實例同時提供負載均衡的服務。w(ﾟДﾟ)ww(ﾟДﾟ)w