版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/m_review/article/details/90903439
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 的好处就显示出来了。
- 对于长连接,不必每次通信都像 HTTP 一样去3次握手,减少网络开销
- 一般的 RPC 框架都有 注册中心,管控中心,发布,下线接口,动态扩展等。
总之: RPC 效率更高,HTTP 迭代更快。