阿里巴巴集團內部使用的分佈式服務框架 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 年中間件領域行業經驗。