HSF原理剖析

文章转载自：HSF原理剖析

前言

HSF是一个分布式的远程服务调用框架，其实我更喜欢把分布式几个字去掉，因为HSF本身并不是一个单独的服务（指一个进程），他是附属在你的应用里的一个组件，一个RPC组件(远程过程调用——Remote Procedure Call，是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发分布式应用更加容易)，当然HSF完全的内容肯定不止这些。

​ HSF(High-speed Service Framework)，高速服务框架，是阿里系主要采用的服务框架，其目的是作为桥梁联通不同的业务系统，解耦系统之间的实现依赖。其高速体现在底层的非阻塞I/O以及优秀的序列化机制上，实现了同步和异步调用方式，并且有一套软负载体系，实现分布式应用。

RPC

我们先来看一张图：

很多同学看了这张图可能会觉得这跟http的过程有什么区别？

有这么一个场景（本来想举一个便具体业务的例子，想想还是已技术实现相关的比较好），监控平台：监控所有主机的状态，这时候每台主机上有一个agent，每个几秒向监控平台上传一次数据（主机内存使用率、硬盘状况、CPU、load、进程信息等等）。

可能在开发的时候最简单的方式就是监控平台有一个http接口，agent每隔几秒请求一次，能够满足需求，但是如果主机数快速增长了很多、监控项越来越多、请求体越来越大，你会发现http的传输效率下降了，每一次调用的耗时增加了。

这时我们会去研究http协议，想去优化这个过程，发现http的过程是：建立连接、发送请求信息、发送响应信息、关闭连接，看到这个过程首先想优化的就是能不能不要每次都去建立连接关闭连接，因为数据上报是个持续的过程；紧接着去研究http头，发现很多协议用不到，繁杂，白白增加了消息体；后来又觉得http的协议解析还原过程很复杂，可以自己开发一个提升性能……

RPC来了，他能满足这些需求，但是前提是需要开发，需要前期成本，所以想项目设计时就要去衡量，不过没事，我们有HSF啊。

我们将上图稍微改造一下：

现在从图中可以看着，client和server之间有一条长连接，并且我们有自己的协议体：RpcRequest和RpcResponse。

RPC就讲到这里，毕竟重点是HSF，想要更多的了解RPC，可以上wiki或者网上查询。

HSF架构

其实在我们的应用中，一般情况下你的应用不仅仅是client，也是server，因为你不仅需要去调用其他应用提供的服务，也提供服务给其他应用，所以这样一来，整个hsf的服务调用链路也会很复杂。

从上面两幅图中我们很显然的发现一个问题，就是服务提供者如何告知客户端他提供的服务，所以需要有一个服务注册与发现的地方，在HSF架构中提供这个功能的是configserver，如下图：

从上图可以看出server端启动的时候会向configserver注册自己提供的服务，client会向configserver订阅需要的服务，configserver通过订阅信息将相关服务提供者的地址以及其他关键信息推送给client。

上面已经实现了基本的能力，但是如何动态配置负载（线程池大小）、默认配置（configserver地址等）、还有一些特性功能（如路由规则），这时候就需要有一个持久化配置中心，如下图：

client和server启动的时候会先去diamond获取需要的配置信息，如最关键的服务注册中心的类型和地址，除此之外之外还有服务治理的类型和地址等。

重点说一下路由规则，举个例子：通过路由规则配置在服务调用的时候只调用同机房的server，这样子服务调用的耗时肯定比跨机房的耗时短。除此之外hsf里还单独写了unitService进行服务单元发布来区分中心发布，这些番外的东西以后有时间再写个番外篇，这里就不过多阐述了，毕竟这些有点偏场景偏业务的内容以后可能就改成别的方式了。

相信大家都用过hsf服务治理网站，通过这个网站可以看到有哪些服务、服务提供者的地址是多少、有多少提供者、具体的消费者是谁，hsf通过configserver、redis、diamond里的存储信息获取到这些信息。

redis功能：HSF使用Redis存储元数据，每一个HSF Consumer/Provider 都会在启动后、每隔一段时间向redis上报元数据，这些元数据采集起来又提供给HSFOPS做服务治理，包括应用名和服务的映射、服务的元数据等。