前言

此前用 node 对接过一段时间的 HSF 服务，竟不知分寸地一头扎进 node 模块源码里，也没得出个所以然。直到今天偶然在《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》这本书读到有关 HSF 的内容，才理解了 HSF 实现的大致原理。心中一阵感慨。

“他山之石，可以攻玉”。谨以这篇短文留念。

HSF

HSF 全称 High Speed Framework 高速服务框架，是阿里内部广泛使用的 RPC 框架。不同于 ESB 企业服务总线，HSF 实现了服务调用方(Consumer)和服务提供方(Provider)的点对点通信。在 HSF 框架中，地址服务器用于维护全量服务器(包含服务调用方和服务提供方)和 Diamond 服务器列表信息；配置服务器用于记录服务发布(服务提供方发布了哪些服务)和服务订阅(服务调用方需要哪些服务)信息，并将相关信息推送到对应的服务器上，如配置服务器会将服务提供方的相关信息推送给服务调用方。配置服务器与服务提供方、服务调用方均保持长连接，采用心跳的方式监控各服务运行节点的状况，以便剔除故障的服务提供方。HSF 通过 ip 和端口号锁定服务提供方或服务调用方；通过服务名和版本号定位服务(因此，通过指定服务名和版本号可以直连本地服务器)。首先服务提供方会在配置服务器中完成服务的注册发布，然后服务调用方会在配置服务器中订阅服务，以便配置服务器即时推送服务提供方的 ip 和端口。为了服务发布、订阅、推送的负载均衡，生产环境上的配置服务器一般会配置多台，且在不同的配置服务器之间会作实时的数据同步。每一个 HSF 的应用均以 War 包形式存在，运行在 Ali-Tomcat 容器中。Ali-Tomcat 容器层已经集成了 HSF 服务框架对服务提供者或服务调用者进行配置服务器发现、服务注册、订阅、失效转移等相关功能，所以不管是在服务提供者还是调用者开发时，只需要进行服务相关的配置操作，应用中无需引入任何 HSF 相关的 Jar 包。

在服务提供方和服务调用方的点对点通信中，服务调用者会从服务提供者列表中随机选择一台进行通信，无需通过 ESB 中转，因此就形成“去中心化”的服务架构。当请求的服务提供方故障时，服务调用者会获得失败反馈，继而从剩下的服务提供者列表中选择一台再次通信，这就是 HSF 服务的容错机制；同时配置服务器与服务提供方的长连接通信，允许配置服务器及时剔除故障的服务提供方并推送到服务调用方。HSF 的线性扩展能力在于，只要启动一台新的服务提供方服务器，并由配置服务器推送给服务调用方，即可以分摊服务调用的压力。

Diamond

Diamond 服务器用于推送统一的配置服务。在 HSF 中，Diamond 主要用于：通过设置白名单使某些服务调用方的服务只被特定 IP 地址的服务器调用。

通过用户认证的方式控制服务是否能被调用。

按照不同的服务路由权重设置服务调用方对多个服务提供方服务节点的访问。

设置某些服务的 QPS 能力上限值，实现限流。

Diamond 会将这些规则保存在在自身的 MySql 中，并将这些规则推送到相关的服务节点上，使这些规则能立即在服务运行环境中生效。

通信和序列化协议

HSF 框架使用网络通信框架 Netty、Hession 数据序列化协议实现服务器键的交互。这类 RPC 协议采用多路复用的 TCP 长连接方式，即在服务提供方和调用方点对点通信期间会共用同一个长连接，以传输不同的请求块。Hessian 数据序列化协议精简高效，同时可以跨语言使用。另外 Hessian 可以充分利用 Web 容器的成熟功能，在处理大量用户访问时很有优势，在资源分配、线程排队、异常处理等方面都可以由 Web 容器保证。

参考