分布式服務框架選型：面對Dubbo，阿里巴巴為什麼選擇了HSF？

阿里巴巴集團內部使用的分布式服務框架 HSF（High Speed Framework，也有人戲稱「好舒服」）已經被很多技術愛好者所熟知，目前已經支撐著近 2000 多個應用的運行。

其對應早期的開源項目 Dubbo（因為某些原因，Dubbo 項目在 2012 年年底，阿里巴巴就停止了對此開源項目的更新），則更是在互聯網領域有著非常高的知名度和廣泛的使用。

本文通過對阿里巴巴 HSF 服務框架的介紹，讓大家能對這類分布式服務框架架構設計、運行原理，以及如何實現作為一個 SOA 架構需要滿足的各個特性有一個清晰的認識。

HSF 服務框架主要組件

1、服務提供者

在服務框架中真正提供服務功能實現的應用實例，為了保障服務提供的高可用性，一般均是集群部署。

每一個 HSF 的應用均是以 War 包的形式存在，運行在阿里巴巴優化定製後的 Tomcat 容器中，在 Tomcat 容器層已經集成了 HSF 服務框架對服務提供者或服務調用者進行配置伺服器發現、服務註冊、訂閱、失效轉移等相關功能，所以不管是在服務提供者還是調用者開發時，只需要進行服務相關的配置操作，應用中無需引入任何 HSF 相關的 Jar 依賴包。

考慮到應用故障的隔離、更方便的服務管控，目前淘寶內部大部分應用的部署方式還是一個虛擬機（對應一個操作系統）運行一個 Tomcat 容器，每個 Tomcat 運行一個服務應用，隨著近幾年以 Docker 容器技術的發展和流行，現在阿里巴巴內部也正在進行應用容器化部署的工作，讓伺服器的資源利用更加科學和高效。

2、服務調用者

作為服務的消費者，大多數也是以 WAR 應用包的方式運行在 Tomcat 容器中，在阿里巴巴集團內部也有一部分是基於 C/C++、PHP、Node.js 等語言開發的服務調用者。

3、地址伺服器

在 HSF 服務框架中，地址伺服器肩負著給服務提供者和服務調用者提供部署環境中所有配置伺服器和 Diamond 伺服器的伺服器列表信息，是由 Nginx（ 是一個高性能的 HTTP 和反向代理伺服器）提供該服務能力。

在部署 HSF 服務環境時，會將整個環境中的配置伺服器集群（伺服器 IP 列表）和 Diamond 伺服器集群信息設置在地址伺服器上，在實際生產部署中，也會部署多台地址伺服器提供負載均衡和高可用性的服務，服務提供者和調用者通過統一域名的方式訪問這些地址伺服器（比如「xxx.tbsite.net」），通過 DNS 輪詢實現地址伺服器訪問的高可用性。

4、配置伺服器

配置伺服器在 HSF 框架中主要負責記錄環境內所有服務發布（服務提供者的 IP 地址和服務埠信息）和服務訂閱（服務調用者的 IP 地址和服務埠信息）信息，並將服務相關信息推送到服務節點上。為了追求服務發布和訂閱的推送效率，所有的服務發布和訂閱信息均是保存在內存中。

配置伺服器與所有服務者提供者和調用者均是長連接，採用心跳的方式可監控到各服務運行節點的狀況，一旦出現服務提供者服務節點出現故障時，會自動推送更新後（將出問題的服務提供者服務節點信息從列表中刪除）的服務提供者列表給相關的服務調用者端。

在生產環境中，會部署多台配置伺服器，用於服務發布、訂閱、推送的負載均衡，在多台配置伺服器間會進行實時的數據同步，保證服務發布和訂閱信息儘快能同步到各服務節點上。

某種程度上，配置伺服器在 HSF 框架中扮演了服務調用調度的指揮官，通過給服務調用者端推送不同的服務提供者列表就可以輕易的調整服務調用的路由，這一特性在淘寶平台實現單元化（即某一客戶在訪問淘寶時，訪問請求一旦路由到某一個淘寶機房後，在淘寶上進行的所有業務的操作均可以在該機房完成，而無需訪問其他機房的服務，也是實現異地多活的基礎）、異地多活起到了至關重要的作用。

5、Diamond 伺服器

本質上，Diamond 伺服器是一個通用的統一配置管理服務，類似 ZooKeeper，給應用提供統一的配置設置和推送服務，使用場景非常廣泛，在阿里巴巴內部有很多的產品在需要進行配置的保存和獲取時都會使用 Diamond 伺服器。

在 HSF 服務框架中，則主要承擔了服務調用過程中對於服務調用安全管控的規則、服務路由權重、服務 QPS 閥值等配置規則的保存，所有的信息均是持久化保存到了後端的 MySQL 伺服器中，在生產環境中，會有多台 Diamond 伺服器提供負載均衡的服務。

使用 Diamond 伺服器進行服務相關設置的典型場景如下：

• 通過設置白名單（服務調用者所在服務節點 IP 地址）的方式設置某些服務或服務中的方法只能讓特定 IP 地址的伺服器調用；

• 通過用戶認證的方式控制服務是否能夠調用；

• 按照不同的伺服器權重設置服務調用者對多個服務提供者服務節點的訪問；

• 設置某些服務的 QPS 能力上限值，一旦該服務的 QPS 達到該閥值，則拒絕服務的繼續調用，這也是實現服務限流的技術實現，在平台進行大促或秒殺場景時，保障平台的穩定的重要屏障。

通過這樣規則的設置，Diamond 除了將這些規則保存在自身的資料庫中外，會自動將這些規則推送到相關的服務節點上（實際實現上是服務節點會定時從 Diamond 伺服器上同步相關配置信息），使這些規則能立即在服務運行環境中生效。

如圖 3-5 所示是阿里巴巴 HSF 服務框架的工作原理，按照服務註冊發布、服務訂閱、服務規則推送、最終服務提供者和服務調用者間的服務交互的順序說明了 HSF 服務框架中每個組件在整個框架中所扮演的角色。

圖 3-5 HSF 服務框架工作原理示意圖

1）服務節點對配置伺服器列表的獲取。

服務調用者和服務提供者在隨著 Tomcat 容器啟動後，會以域名（比如「xxx.tbsite.net」）的方式獲取到可用的地址伺服器，通過向地址伺服器分別發送獲取配置伺服器和 Diamond 伺服器服務 IP 列表請求的方式，在容器啟動完成後，就已經在該服務節點上獲取到了配置伺服器和 Diamond 伺服器的 IP 列表信息。整個過程如圖 3-5 中的步驟①②。

2）服務的註冊發布。

作為服務提供者，當獲取到配置伺服器的伺服器列表後，則向配置伺服器發送當前應用中包含的服務提供者相關信息（這些信息均是從應用的配置文件中獲取到，比如服務的介面類全名、服務版本、所屬服務組等信息），聯同當前伺服器的 IP 地址、服務埠等信息進行服務註冊發布，如圖 3-5 中的步驟③。這個步驟在每一個有服務提供的應用啟動時都會自動執行，比如現在有 5 個提供同一服務的應用啟動後，此時在配置伺服器上就已經保存了提供這一服務的 5 個伺服器相關信息。

3）服務的訂閱。

當作為服務調用者的應用啟動時，同樣在完成配置伺服器列表的獲取後，就進行與配置伺服器的交互，發送服務消費者相關信息（同樣包含了服務的介面全名，服務版本、所屬服務組）到配置伺服器進行服務的訂閱，此時在配置伺服器上會通過服務介面全名+服務版本作為匹配條件在當前配置伺服器的內存中進行搜索，一旦獲取到對應的服務註冊信息，則將對應的服務提供者的伺服器組 IP 地址及埠返回給服務調用者所在的應用節點上，此時也就完成了服務調用者端對於它所需要調用的服務提供者伺服器列表信息，用於在服務真正交互時使用。服務訂閱過程如圖 3-5 中的步驟④⑤。

4）服務規則的推送（如果需要）。

如果沒有上文提到對於服務安全管控、流量控制等需求的時候，對於 Diamond 伺服器的使用並不是必需的，在有這樣的需求場景時，可通過 Diamond 提供的規則設置界面，可以對指定服務的服務提供者和調用者設置相關的規則，一旦保存規則後，則此規則配置將會在 5 秒內推送到與所設置服務相關的服務節點上。如圖 3-5 中的步驟⑥。

5）服務交互。

在應用進行業務請求處理過程中，出現了服務調用者對服務提供者的調用時，服務調用者會從已經保存在該應用節點上的服務提供者伺服器列表中選擇（阿里巴巴內部使用隨機模式）其中一台進行服務請求的發送，服務交互期間完全是服務調用者和服務提供者間兩台伺服器間的，無需通過中間伺服器的中轉，這就是相比於「中心化」 ESB 模式，所有服務交互都需要「中心」 ESB 進行服務路由，而當前這種架構稱為「去中心化」的主要原因。如圖 3-5 中的步驟⑦。

阿里巴巴的分布式服務框架核心是以服務化的方式構建整個應用體系的同時，要保證在高並發的情況下，服務具備高效交互、高可用性和擴展能力。接下來對於 HSF 框架如何給服務提供以上能力具體加以說明。

1、HSF 框架採用 Netty + Hession 數據序列化協議實現服務交互

HSF 框架中採用如今流行的網路通信框架 Netty 加上 Hession 數據序列化協議實現 HSF 服務間的交互，主要考慮點是在大並發量時，服務交互性能達到最佳。這類 RPC 協議採用多路復用的 TCP 長連接方式，在服務提供者和調用者間有多個服務請求同時調用時會共用同一個長連接，即一個連接交替傳輸不同請求的位元組塊。它既避免了反覆建立連接開銷，也避免了連接的等待閑置從而減少了系統連接總數，同時還避免了 TCP 順序傳輸中的線頭阻塞（head-of-line blocking）問題。

Hessian 是 HSF 框架中默認使用的數據序列化協議，在數據量較小時性能表現出眾，Hessian 的優點是精簡高效，同時可以跨語言使用，目前支持 Java, C++, .net, Python, ruby 等語言。另外 Hessian 可以充分利用 Web 容器的成熟功能，在處理大量用戶訪問時很有優勢，在資源分配、線程排隊、異常處理等方面都可以由 Web 容器保證。

HSF 框架同時也支持切換使用 Java 序列化，Hession 相比 JDK 標準的序列化方式（即基於 Serializable 介面的標準序列化），在典型場景中，其序列化時間開銷可能縮短 20 倍。雖然 Hessian 不是最快的序列化協議，但它對於複雜業務對象的序列化正確率、準確性相較於最穩定的 Java 序列化並不遜色太多。

業界還有一些比 Hessian 更快的序列化協議，但它們相對於 Hessian 在複雜場景下的處理能力還是會差一些，所以 Hessian 是在性能和穩定性同時考慮下最優的序列化協議。

阿里巴巴當時在對多種通信協議和數據序列化組件等測試中，Netty + Hession 的組合在互聯網高並發量的場景下,特別是在 TPS 上達到 10w 以上時，性能和效率遠比 REST 或者 Web Service 高。

2、HSF 框架的容錯機制

因為要保證服務的高可用性，所以在生產環境部署中一定會有多個應用實例作為服務提供者提供某一相同服務。

基於之前所提到的服務框架的運行原理的說明，在進行服務調用時，服務調用者端已經保存了它所需要調用的服務提供者的伺服器列表信息（如圖 3-6 中為例，則保存了三台服務提供者所在伺服器的列表）。

當採用隨機方式獲取其中一台進行服務交互時（如圖 3-6 步驟①），不管是第一台伺服器已經某種故障造成了服務請求無法響應，還是該伺服器已經接收了服務請求，在進行服務請求處理過程中出現了伺服器故障（比如宕機、網路問題），造成該伺服器沒有在規定的時間（一般服務調用會設置到期時間）返回服務處理的結果，服務調用者端則會獲取到服務調用失敗的反饋（如圖 3-6 步驟②）。

在 HSF 服務調用的代碼中會立即從剩下的服務提供者伺服器列表中選擇另外一個伺服器再次進行服務請求（如圖 3-6 步驟③），這一次這個服務提供者實例正常提供了此次服務的請求（如圖 3-6 步驟④），從而保證了在個別服務提供者出現故障時，完全不會影響該服務正常提供服務。

圖 3-6 HSF 服務框架實現服務高可用性原理示意圖

同時，因為配置伺服器是採用長連接的方式與服務節點進行網路通訊，一旦發現有服務提供者實例出現故障，配置伺服器在秒級就會感知到（如圖 3-6 步驟⑤），此時會將出問題這台服務提供者的信息從該服務的伺服器列表中刪除，並將更新後的伺服器列表採用推送的方式同步給與該服務相關的所有服務調用者端（如圖 3-6 步驟⑥），這樣當下次服務調用者再進行此服務的調用時，就不會因為隨機的方式再次對已經停止服務提供的伺服器發起服務的調用。

3、HSF 框架的線性擴展支持

作為 HSF 框架設計之初，最為重要的一個特性就是服務能力的可擴展性。也就是真正的做到某個服務的業務處理能力能隨著伺服器資源的增加得到線性的增長。

其實在傳統架構中一直也會強調平台的擴展能力，但均會程度不一的出現服務節點數量到達一定量後，出現阻礙平台服務能力擴展的問題，有的是出現網路傳輸的瓶頸、也有服務節點接入數量上的限制，前文所描述的 ESB 架構帶來的「雪崩」效應也均是這類架構給服務能力的擴展帶來影響的原因所在。

如圖 3-7 中所描述的場景，當服務面對較大的服務調用壓力或將要面臨如天貓雙11大促、秒殺等活動前，已有的服務提供者各伺服器水位（CPU、內存、IO等）處於比較高的情況或現有服務能力滿足不了業務訪問量的要求時，則需要通過增加服務節點數量的方式提升該服務的服務處理能力。

圖 3-7 HSF 服務框架對服務能力線性擴展支持1

此時，只需要通過增加該服務的服務提供者實例（如圖 3-8 所示，增加了一個服務），基於 HSF 框架的運行機制，新增加的服務提供者實例一旦應用啟動完成後，可在幾秒內開始進行服務請求的處理（主要完成服務註冊發布、更新後服務列表推送到服務調用者端），從而達到分擔其他伺服器實例壓力的作用，實現服務能力整體水位恢復到正常的狀態（如圖 3-9）。

圖 3-8 HSF服務框架對服務能力線性擴展支持2

圖 3-9 HSF 服務框架對服務能力線性擴展支持3

正是基於 HSF 框架這一特性，從而真正實現了只要增加服務實例就能實現該服務能力擴展的目標，目前在阿里巴巴共享服務事業部中多個服務中心在天貓雙 11 那天各自所部署的服務實例節點數量均超過 2000，即同一個服務由超過 2000 個服務實例同時提供負載均衡的服務。

本文節選自機械工業出版社《企業IT架構轉型之道——阿里巴巴中台戰略思想與架構實戰》第 3 章。由機械工業出版社華章 IT 授權。基於移動閱讀的考慮，部分內容進行了排版調整，想了解本書全部詳細內容，可以在各大書店購買。

作者：鍾華（花名：古謙） 阿里巴巴中間件首席架構師，15 年中間件領域行業經驗。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！