分布式服务框架HSF

最近在读阿里巴巴中台战略思想与架构这本书，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