码迷,mamicode.com
首页 > Web开发 > 详细

HTTP与RPC(Thrift)

时间:2019-07-10 20:14:12      阅读:396      评论:0      收藏:0      [点我收藏+]

标签:建立   回调函数   扩展   出现   协议栈   org   har   消息   protocol   

什么是RPC

从网络协议来说,Http协议与Rpc同属于应用层, 他们的底层都是tcp协议。

      RPC(即Remote Procedure Call,远程过程调用)和HTTP(HyperText Transfer Protocol,超文本传输协议)他们最本质的区别,就是RPC主要工作在TCP协议之上,而HTTP服务主要是工作在HTTP协议之上,我们都知道HTTP协议是在传输层协议TCP之上的,所以效率来看的话,RPC当然是要更胜一筹。

1、RPC服务

(1)RPC架构
      先说说RPC服务的基本架构吧。一个完整的RPC架构里面包含了四个核心的组件,分别是Client ,Server,Client Stub以及Server Stub,这个Stub大家可以理解为存根。分别说说这几个组件:
    1)客户端(Client),服务的调用方。
    2)服务端(Server),真正的服务提供者。
    3)客户端存根,存放服务端的地址消息,再将客户端的请求参数打包成网络消息,然后通过网络远程发送给服务方。
    4)服务端存根,接收客户端发送过来的消息,将消息解包,并调用本地的方法。

      RPC主要是用在大型企业里面,因为大型企业里面系统繁多,业务线复杂,而且效率优势非常重要的一块,这个时候RPC的优势就比较明显了。实际的开发当中是这么做的,项目一般使用maven来管理。比如我们有一个处理订单的系统服务,先声明它的所有的接口(这里就是具体指Java中的interface),然后将整个项目打包为一个jar包,服务端这边引入这个二方库,然后实现相应的功能,客户端这边也只需要引入这个二方库即可调用了。为什么这么做?主要是为了减少客户端这边的jar包大小,因为每一次打包发布的时候,jar包太多总是会影响效率。另外也是将客户端和服务端解耦,提高代码的可移植性。

(2)同步调用与异步调用
      什么是同步调用?什么是异步调用?同步调用就是客户端等待调用执行完成并返回结果。异步调用就是客户端不等待调用执行完成返回结果,不过依然可以通过回调函数等接收到返回结果的通知。如果客户端并不关心结果,则可以变成一个单向的调用。这个过程有点类似于Java中的callable和runnable接口,我们进行异步执行的时候,如果需要知道执行的结果,就可以使用callable接口,并且可以通过Future类获取到异步执行的结果信息。如果不关心执行的结果,直接使用runnable接口就可以了,因为它不返回结果,当然啦,callable也是可以的,我们不去获取Future就可以了。

(3)流行的RPC框架

    目前流行的开源RPC框架还是比较多的。下面重点介绍三种:
    1)gRPC是Google最近公布的开源软件,基于最新的HTTP2.0协议,并支持常见的众多编程语言。 我们知道HTTP2.0是基于二进制的HTTP协议升级版本,目前各大浏览器都在快马加鞭的加以支持。 这个RPC框架是基于HTTP协议实现的,底层使用到了Netty框架的支持。
    2)Thrift是Facebook的一个开源项目,主要是一个跨语言的服务开发框架。它有一个代码生成器来对它所定义的IDL定义文件自动生成服务代码框架。用户只要在其之前进行二次开发就行,对于底层的RPC通讯等都是透明的。不过这个对于用户来说的话需要学习特定领域语言这个特性,还是有一定成本的。
    3)Dubbo是阿里集团开源的一个极为出名的RPC框架,在很多互联网公司和企业应用中广泛使用。协议和序列化框架都可以插拔是及其鲜明的特色。同样 的远程接口是基于Java Interface,并且依托于spring框架方便开发。可以方便的打包成单一文件,独立进程运行,和现在的微服务概念一致。

2、HTTP服务

(1)HTTP接口
      相比RPC,HTTP接口开发也就是我们常说的RESTful风格的服务接口。的确,对于在接口不多、系统与系统交互较少的情况下,解决信息孤岛初期常使用的一种通信手段;优点就是简单、直接、开发方便。利用现成的http协议进行传输。做后台接口开发的时候,需要写一份接口文档,严格地标明输入输出是什么?说清楚每一个接口的请求方法,以及请求参数需要注意的事项等。
      比如这个例子:POST http://www.httpexample.com/restful/buyer/info/share
      接口可能返回一个JSON字符串或者是XML文档。然后客户端再去处理这个返回的信息,从而可以比较快速地进行开发。但是对于大型企业来说,内部子系统较多、接口非常多的情况下,RPC框架的好处就显示出来了,首先就是长链接,不必每次通信都要像http一样去3次握手什么的,减少了网络开销;其次就是RPC框架一般都有注册中心,有丰富的监控管理;发布、下线接口、动态扩展等,对调用方来说是无感知、统一化的操作。

(2)restful:
      对应的中文是rest式的;Restful web service是一种常见的rest的应用,是遵守了rest风格的web服务;rest式的web服务是一种ROA(The Resource-Oriented Architecture)(面向资源的架构)。为什么会出现Restful?
    1)在Restful之前的操作:
    http://127.0.0.1/user/query   GET  根据用户id查询用户数据
    http://127.0.0.1/user/save    POST 新增用户
    http://127.0.0.1/user/update POST 修改用户信息
    http://127.0.0.1/user/delete  GET/POST 删除用户信息
    2)RESTful用法:
    http://127.0.0.1/user  GET  根据用户id查询用户数据
    http://127.0.0.1/user  POST 新增用户
    http://127.0.0.1/user  PUT 修改用户信息
    http://127.0.0.1/user  DELETE 删除用户信息
    之前的操作是没有问题的,大神认为是有问题的,有什么问题呢?你每次请求的接口或者地址,都在做描述,例如查询的时候用了query,新增的时候用了save,其实完全没有这个必要,我使用了get请求,就是查询.使用post请求,就是新增的请求,我的意图很明显,完全没有必要做描述,这就是为什么有了restful。

3、总结

    RPC服务和HTTP服务还是存在很多的不同点的,一般来说,RPC服务主要是针对大型企业的,而HTTP服务主要是针对小企业的,因为RPC效率更高,而HTTP服务开发迭代会更快。总之,选用什么样的框架不是按照市场上流行什么而决定的,而是要对整个项目进行完整地评估,从而在仔细比较两种开发框架对于整个项目的影响,最后再决定什么才是最适合这个项目的。一定不要为了使用RPC而每个项目都用RPC,而是要因地制宜,具体情况具体分析。
---------------------
作者:蓬莱道人
来源:CSDN
原文:https://blog.csdn.net/mou_it/article/details/79873612
版权声明:本文为博主原创文章,转载请附上博文链接!

 

 


 
技术图片
image.png

从概念上来说,RPC是远程过程调用,而其实Http其实也是属于RPC调用的一种。RPC是一种网络编程的模式,是我们程序员将对远程服务器调用的抽象,而且一般需要实现服务注册发现机制、序列化反序列化机制、方法派发机制,这些一般都需要我们使用的RPC框架(比如Thrift)默认实现的。

为什么要使用RPC

http协议其实是属于面向桌面浏览器的一个通信协议,对于缓存,幂等或者Cookies相关的方面做了很多的事情。但是对于服务器之间直接的交互,Rpc就能够体现出来他的优势了。

  • 自定义协议,减少数据传输:我们大概看一下http协议。请求行,请求头部,请求数据,空行。很明显对于远程调用场景,我们对于请求行的依赖不是特别的强,那么这一部分在我们应用场景下,将会成为负担,但是http协议又是固定的,我们也不可能随便修改协议的格式。所以,通过rpc协议我们可以精简请求的数据,来尽可能少的传输我们的数据。当前,rpc也可以通过http协议来进行传输。
 
技术图片
image.png
  • 使用长连接:直接基于socket进行连接,不用每个请求都重新走三次握手的流程

  • Thrift默认提供了数据与实体类的转换,不需要我们显示的进行数据与实体类的转换。

  • 性能差距:https://cnodejs.org/topic/553a1cad63b7692e48bbb715。我们这里借用一下这篇文章的结论:

     
    技术图片
    图片来源网络,侵删

     

OSI网络结构的七层模型

各层的具体描述如下:

  第七层:应用层     定义了用于在网络中进行通信和数据传输的接口 - 用户程式;提供标准服务,比如虚拟终端、文件以及任务的传输 和处理; 
  第六层:表示层     掩盖不同系统间的数据格式的不同性; 指定独立结构的数据传输格式; 数据的编码和解码;加密和解密;压缩和 解压缩 
  第五层:会话层     管理用户会话和对话; 控制用户间逻辑连接的建立和挂断;报告上一层发生的错误 
  第四层:传输层     管理网络中端到端的信息传送; 通过错误纠正和流控制机制提供可靠且有序的数据包传送; 提供面向无连接的数 据包的传送; 
  第三层:网络层     定义网络设备间如何传输数据; 根据唯一的网络设备地址路由数据包;提供流和拥塞控制以防止网络资源的损耗 
  第二层:数据链路层 定义操作通信连接的程序; 封装数据包为数据帧; 监测和纠正数据包传输错误 
  第一层:物理层      定义通过网络设备发送数据的物理方式; 作为网络媒介和设备间的接口;定义光学、电气以及机械特性。

 在上述7层中,http协议是应用层协议。HTTP协议是超文本传送协议(HyperText Transfer Protocol)的缩写,它是万维网(World Wide Web,www,也简称为Web)的基础。HTTP协议设计之初就是为了实现Web的想法。HTTP协议位于TCP/IP协议栈的应用层。基于HTTP协议的客户/服务器模式的信息交换过程,分四个过程:建立连接、发送请求信息、发送响应信息、关闭连接。

而关于RPC的基本概念介绍如下:


英文原义:Remote Procedure Call Protocol
中文释义:(RFC-1831)远过程调用协议
   注解:一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在,如TCP或UDP,为通信程序之间携带信息数据。在OSI网络通信模型中,RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加轻易。
   RPC采用客户机/服务器模式。请求程序就是一个客户机,而服务提供程序就是一个服务器。首先,调用进程发送一个有进程参数的调用信息到服务进程,然后等待应答信息。在服务器端,进程保持睡眠状态直到调用信息的到达为止。当一个调用信息到达,服务器获得进程参数,计算结果,发送答复信息,然后等待下一个调用信息,最后,客户端调用过程接收答复信息,获得进程结果,然后调用执行继续进行。
RPC信息协议由两个不同结构组成:调用信息和答复信息。

 

同时也注意到 了 这样的信息

远程通信的几种选择(RPC,Webservice,RMI,JMS的区别)

几种基于HTTP协议的RPC性能比较

RPC和Socket的区别

http://blog.163.com/fanning_7213/blog/static/249650520113124540501/

RPC(Remote Procedure Call,远程过程调用)是建立在Socket之上的,出于一种类比的愿望,在一台机器上运行的主程序,可以调用另一台机器上准备好的子程序,就像LPC(本地过程调用).

    越底层,代码越复杂、灵活性越高、效率越高;越上层,抽象封装的越好、代码越简单、效率越差。Socket和RPC的区别再次说明了这点。

不论是程序员在编写基于C/S(客户端服务器)的程序时,还是网络工程师在处理RPC问题时,他们问的最多的就是RPC和Socket有什么区别和联系? 
   RPC(Remote Procedure Call,远程过程调用)是建立在Socket之上的,出于一种类比的愿望,在一台机器上运行的主程序,可以调用另一台机器上准备好的子程序,就像 LPC(本地过程调用).RPC带来了开发C/S程序的简单可靠的手段,它通过一种叫XDR的数据表达方法描述数据,程序员书写伪代码,然后由 rpcgen程序翻译为真正的可编译的C语言源代码,再编译成真正的Client端和Server端程序。 
  RPC作为普遍的C/S开发方 法,开发效率高效,可靠.但RPC方法的基本原则是--以模块调用的简单性忽略通讯的具体细节,以便程序员不用关心C/S之间的通讯协议,集中精力对付实 现过程.这就决定了 RPC生成的通讯包不可能对每种应用都有最恰当的处理办法,与Socket方法相比,传输相同的有效数据,RPC占用更多的网络带宽. 
  RPC是在Socket的基础上实现的,它比socket需要更多的网络和系统资源.另外,在对程序优化时,程序员虽然可以直接修改由rpcgen产生的令人费解的源程序,但对于追求程序设计高效率的RPC而言,获得的简单性则被大大削弱. 
RPC与是Socket的类比



 
参考:HTTP与RPC(Thrift)

参考:rpc与http的区别

参考:Http和RPC区别

HTTP与RPC(Thrift)

标签:建立   回调函数   扩展   出现   协议栈   org   har   消息   protocol   

原文地址:https://www.cnblogs.com/aspirant/p/11166097.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!