HSF的原理分析

时间 2019-11-21

标签 hsf 原理分析繁體版

原文原文链接

转自：http://blog.csdn.net/qq_16681169/article/details/72512819java

一．HSF的基本概念编程

HSF全称为High-Speed Service Framework，旨在为淘系的应用提供一个分布式的服务框架，HSF从分布式应用层面以及统一的发布/调用方式层面为你们提供支持，从而能够很容易的开发分布式的应用以及提供或使用公用功能模块，而不用考虑分布式领域中的各类细节技术，例如远程通信、性能损耗、调用的透明化、同步/异步调用方式的实现等等问题。json

二.知识准备缓存

经过以上的说明，大体了解了一下RPC与HSF的整体架构，可是整体架构离具体实现还想差不少，有些知识准备仍是颇有必要的。安全

1.对象的序列化服务器

对象的序列化过程在RPC过程当中是很重要的一个环节，序列化对于远程调用的响应速度、吞吐量、网络带宽消耗等一样也起着相当重要的做用。
在HSF1.0时只支持两种序列化方式：java 和 hessian，在HSF2.0以后就支持了五种序列化方式：java、hessian、hessian二、json、kyro。
可是目前版本中经常使用的序列化方式仍是java 和 hessian两种。若是想细致的了解也能够多作了解。网络

2.动态代理架构

对于消费方来讲，所存在的只有一个接口，虽然底层的实现原理咱们知道，可是为了在使用时的高度透明，在JAVA语言层面上的表现形式则是经过动态代理的方式实现的，不少的逻辑都在InvocationHandler 中处理的。关于如何实现动态代理，还动态代理的一些使用的细节也能够稍做了解。负载均衡

3.网络通讯NIO框架

若是在网络传输过程当中，采起普通的BIO,会有不少的问题存在，例如若是调用端有多个请求过来，那么就得须要多个线程去处理，每一个线程都使用独立的链接，在远端的提供者端有对应的多个线程来执行相应的服务。这种方式会使得调用者和提供者之间创建大量的链接，并且是阻塞的方式，链接并不能获得充分的利用(摘自《大型网站系统与JAVA中间件》)。采用NIO则就能够避免这样的损耗，可是HSF在使用时并非采用直接的NIO编程，而是经过第三方的框架Netty。

二．HSF 实现原理

1.提供服务的大体流程以下：
• server启动时候向configserver注册
• client启动时候向configserver请求list
• client缓存list，发现不可用的server，从缓存中remove
• configserver经过心跳包维护可用server的list
• list有更新的时候，configserver经过带version的报文通知client更新

从以上几个问题出发，看下HSF的实现方式。

2.HSF的总体实现方式：

从图中能够看出，HSF的实现方式能够理解为是C/S的架构，可是和传统的C/S架构相比仍是有很大的不一样，HSF没有真正的服务器，每一个应用均可以成为服务的调用方和提供方。具体工做方式以下：

ConfigServer：远程调用对端的地址就是由ConfigServer 来推送的，这样用户只须要配置本身的服务端或者消费端，不须要对本身的地址进行管理。

Diamond：持久化的配置中心，用于配置服务调用的规则。

服务：服务是调用方和提供方交流的依凭，通常是一个接口，表示一个业务行为以及相关的数据含义。经过使用HSFApiProviderBean可以暴露一个服务，将机器的地址注册到configserver，而且可以经过12200端口进行服务提供，经过HSFApiConsumerBean可以包装出一个客户端，它是服务接口的一个代理，而且它从configserver上订阅了服务的地址列表，可以在这个列表上完成随机调用，作到负载均衡与HA((High Available,高可用性群集)。

网络通讯:HSF的底层网络通讯是使用netty框架实现的，是基于epoll的NIO的网络通信框架，HSF在此使用的是长链接，经过合理的服务部署及负债均衡，基本不存在I/O方面的限制。

三．HSF设计架构

关于HSF的架构基本能够理解为C/S结构设计方式。（虽然HSF没有本身的服务器）
Server端除了configServer外还有一个diamond用来保存一些持久化的配置信息，这里不进行过多的介绍。

Client是HSF的重点，下面是各模块的功能介绍：
Proxy：这一层主要负责接口的代理。基本上全部的RPC框架都会用到代理模式，相信你们不陌生。须要注意的是HSF的代理层还进行了软负载和单元化的处理。
Remoting：这一层是HSF的应用层协议，定义了报文格式，各个字段的含义等信息，内容比较多，以后单独写一篇文章来介绍。
Processer：这一层主要是处理HSF自身的业务逻辑，包括埋点、限流、鉴权等。
Netty：上面三层会将一次服务调用或者服务返回包装成一个报文，而后经过这层传输。

HSF调用流程

上图是HSF整个的调用过程，从左向右看：
第一条线路至关于consumer进行服务调用的过程，首先通过proxy层，将请求通过代理类包装出去；而后是Remoting层进行协议的包装，最后io层发送出去。
第二条线路至关于provider将结果返回后解析的过程，与上一流程恰好相反。
右边的provider两条调用流程相信你们都能按照上面的过程理解，就不一一讲解了。

四．HSF处理请求流程

1.HSF提供端初始化

2.HSF消费端初始化

3.消费方请求到提供方，响应一次调用

4.实现细节

心跳检测：

一、客户端主动关闭链接：客户端第一次与服务端创建连接后，就会周期性（27s）发送心跳包的callback调用，若是连续三次收不到服务端的心跳包回应，客户端主动关闭连接

二、服务端主动关闭链接：当链接59s没有调用（对方网络不可用，或者full gc过久），至关于两次（2*27s）收不到心跳包的时间

从上图能够看出RPC要解决如下几个问题：

如何解决网络通讯问题，主要是经过在客户端和服务器之间创建TCP链接，远程过程调用的全部交换的数据都在这个链接里传输。链接能够是按需链接，调用结束后就断掉，也能够是长链接，多个远程过程调用共享同一个链接。

如何解决寻址问题，客户端如何找到制定的服务端，也就是保证准确有效的完成一次服务调用的前提。

参数的传递及服务端在收到客户端请求后如何实现其具体功能并返回，因为网络传输协议是二进制的，内存中的参数值必需要解决序列化，反序列化，以及对半包，粘包的处理。

五.HSF的优势:

1.服务的自动注册、发现

经过注册中心，实现服务的注册/注销与服务的发现。当服务启动后，会调用publish来将服务发布到中心，而服务的消费者，经过调用订阅接口传入的监听器来更新服务提供者列表。HSF提供了三种注册中心实现，分别是ConfigServer，Zookeper，和配置文件模式。

这里仅对Zookeper进行分析，ZookeeperMetadataAddressService 实现了上述接口，在初始化中实例化了一个ZookeeperRegistry来进行管理，其使用了一个封装了zookeperclient的实例-ZkclientZookeeperClient，在注册服务的时候根据url参数中的Constants.DYNAMIC_KEY来肯定建立Persistent节点仍是Ephemeral节点，Ephemeral节点生命周期与本机链接绑定，这样就能够实现本机离线后的服务自动注销的功能。

2) 服务提供者与消费者之间长链接。

HSF采用长链接方式进行通讯，相比短链接，长链接更具性能优点，避免链接重复建立与销毁带来的缓冲区申请与释放。HSF抽象了链接AbstractClient(Client)，并采用了netty框架做为底层实现。netty是一个性能很是优秀的通讯框架，基于反应器模式，内部采用了管线模式来解耦不一样层次的逻辑之间的耦合问题。HSF为了强化TCP链接的可用性，增长HeartBeat功能，使用了一个Netty提供的 HashedWheelTimer 的定时任务调度器来执行心跳包的发送(补充：此HashedWheelTimer原理采用轮片式的桶结构，避免每次操做对所有任务的迭代操做，只对将要到期的桶进行操做，此原理也可用于缓存系统设计，在须要进行垃圾回收的状况下只须要按照桶为单位进行内存回收)。

3) 非侵入性

HSF最大优势是非侵入性，它使用了JAVA的Proxy机制来实现这一特色，在经过xml配置文件配置Consumer的时候，其实是调用了 HSFApiConsumerBean ，在它的初始化方法中，读取了配置的实现接口，并在ProcessComponent中用一个封装了Proxy注册功能，并实现了InvocationHandler接口的类HSFServiceProxy去管理。使用者在本身的代码中无需作任何特殊处理，就像使用本地方法同样去调用其方法。

4) 版本管理

这一特性能够很灵活的帮助上线运营的服务在升级过程当中避免服务不可用的状况。

5) 服务治理

能够经过网页可视化查看、管理、测试服务的可用。

6) 扩展灵活

能够接入自动服务降级功能(熔断) - 根据配置或服务的执行结果，在调用级控制服务是否调用执行，避免服务总体瘫痪，提高服务的可用性。

和淘宝HSF相比，Dubbo的特色是什么？

1.  Dubbo比HSF的部署方式更轻量，HSF要求使用指定的JBoss等容器，还须要在JBoss等容器中加入sar包扩展，对用户运行环境的侵入性大，若是你要运行在Weblogic或Websphere等其它容器上，须要自行扩展容器以兼容HSF的ClassLoader加载，而Dubbo没有任何要求，可运行在任何Java环境中。

2.  Dubbo比HSF的扩展性更好，很方便二次开发，一个框架不可能覆盖全部需求，Dubbo始终保持平等对待第三方理念，即全部功能，均可以在不修改Dubbo原生代码的状况下，在外围扩展，包括Dubbo本身内置的功能，也和第三方同样，是经过扩展的方式实现的，而HSF若是你要加功能或替换某部分实现是很困难的，好比支付宝和淘宝用的就是不一样的HSF分支，由于加功能时改了核心代码，不得不拷一个分支单独发展，HSF现阶段就算开源出来，也很难复用，除非对架构重写。

3.  HSF依赖比较多内部系统，好比配置中心，通知中心，监控中心，单点登陆等等，若是要开源还须要作不少剥离工做，而Dubbo为每一个系统的集成都留出了扩展点，并已梳理干清全部依赖，同时为开源社区提供了替代方案，用户能够直接使用。

4.  Dubbo比HSF的功能更多，除了ClassLoader隔离，Dubbo基本上是HSF的超集，Dubbo也支持更多协议，更多注册中心的集成，以适应更多的网站架构。

Dubbo在安全机制方面是如何解决的？

Dubbo主要针对内部服务，对外的服务，阿里有开放平台来处理安全和流控，因此Dubbo在安全方面实现的功能较少，基本上只防君子不防小人，只防止误调用。 Dubbo经过Token令牌防止用户绕过注册中心直连，而后在注册中心上管理受权。Dubbo还提供服务黑白名单，来控制服务所容许的调用方。