HSF、HTTP、RPC

HSF 接口 和 HTTP 接口

分布式服务框架： http://www.sohu.com/a/141490021_268033

/**
* 定义hsf接口：
* 1. 分组信息： hsf服务分组 2. ID： hsf服务ID; 3. 方法： HSF服务生产者提供的RPC函数
*/
<dubbo:reference 
  id="paySuccessPageService" interface="com.aliyun.lingxiao.api.PaySuccessPageService" 
  version="1.0.0" 
  protocol="dubbo" 
  check="false"/>
/**
* 分析上述例子：
* 分组信息是:dubbo
* ID:com.aliyun.lingxiao.api.PaySuccessPageService:1.0.0
* 方法：getSubscribeData
*/

中间层：是将后端写的 HSF 接口转换成 HTTP 接口，然后交给前端

中间层主要做的工作就是：

• 配置hsf接口信息，只有配置好了信息，才能调取服务
• 实现接口 封装成前端需要的api

HSF 接口本质是：interface 类

RPC 和 HTTP

读RPC服务和HTTP服务对比有感。

RPC： remote procedure call 远程过程调用，属于传输层TCP/IP协议

HTTP： 应用层HTTP协议

网络模型

• 应用层： 数据和用户
• 传输层： 端到端
• 网络层： 网络设备之间
• 链路层： 数据包转换为数据帧，供物理层使用
• 物理层： 二进制数据

RPC服务

RPC基本架构

• 客户端 client
• 客户端存根 client stub
• 服务端 service
• 服务端存根 service stub

client 调用 client stub；client stub 返回 client；

service 调用 service stub；service stub 返回 service；

client stub 与 service stub 之间传递网络消息。

二方库

比如：订单模块，先定义好所有的接口 Java interface，打包成 jar 包。然后由 service stub 实现这些接口，同时 client stub 也可以调用这个二方库获取到服务。

优点：

• 减少客户端 jar 包大小
• 客户端和服务端解耦

同步，异步问题

同步： 客户端等待调用执行完成并返回结果 callback

异步： 客户端不等待调用执行完成返回结果 runnable

流行的RPC框架

偷偷告诉你现在已经不怎么使用 dubbo 啦，现在用的比较多的叫 HSF，又名“好舒服”。后面有可能会开源，大家拭目以待。

HTTP 和 RPC 的优势

对于接口不多，系统与系统之间的交互较少的情况下：利用现成的HTTP协议进行传输。

对于大型企业来说： 内部子系统非常多，接口非常多，这样 RPC 的好处就显示出来了。

1. 对于长连接，不必每次通信都像 HTTP 一样去3次握手，减少网络开销
2. 一般的 RPC 框架都有 注册中心，管控中心，发布，下线接口，动态扩展等。

总之： RPC 效率更高，HTTP 迭代更快。