RPC与HTTP

RPC原理

RPC服务基本架构包含了四个核心的组件,分别是Client,Server,Clent Stub以及Server Stub。

RPC 让远程调用就像本地调用一样,其调用过程可拆解为以下步骤。
image.png?imageView2/1/q/50
① 服务调用方(client)以本地调用方式调用服务;
② client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体;
③ client stub找到服务地址,并将消息发送到服务端;
④ server 端接收到消息;
⑤ server stub收到消息后进行解码;
⑥ server stub根据解码结果调用本地的服务;
⑦ 本地服务执行并将结果返回给server stub;
⑧ server stub将返回结果打包成能够进行网络传输的消息体;
⑨ 按地址将消息发送至调用方;
⑩ client 端接收到消息;
⑪ client stub收到消息并进行解码;
⑫ 调用方得到最终结果。
使用RPC框架的目标是只需要关心第1步和最后1步,中间的其他步骤统统封装起来,让使用者无需关心。例如社区中各式RPC框架(grpc、thrift等)就是为了让RPC调用更方便。

流行的RPC框架

目前流行的RPC框架有很多,下面介绍常见的三种。

  1. gRPC:gRPC是Google公布的开源项目,基于HTTP2.0协议,并支持常见的众多编程语言。HTTP 2.0协议是基于二进制的HTTP协议的升级版本,gRPC底层使用了Netty框架。
  2. Thrift:Thrift是Facebook的一个开源项目,主要是一个跨语言的服务开发框架。它有一个代码生成器来对它所定义的IDL文件自动生成服务代码框架。Thrift对于底层的RPC通讯都是透明的,用户只需要对其进行二次开发即可,省去了一系列重复的前置基础开发工作。
  3. Dubbo:Dubbo是阿里集团开源的一个极为出名的RPC框架,在很多互联网公司和企业应用中广泛使用。协议和序列化框架都可以插拔是及其鲜明的特色。

rpc和http

1、认识RPC

RPC,即 Remote Procedure Call(远程过程调用),是一个计算机通信协议。 该协议允许运行于一台计算机的程序调用另一台计算机的子程序,而程序员无需额外地为这个交互作用编程。说得通俗一点就是:A计算机提供一个服务,B计算机可以像调用本地服务那样调用A计算机的服务。
通过上面的概念,我们可以知道,实现RPC主要是做到两点:
1、实现远程调用其他计算机的服务

  • 要实现远程调用,肯定是通过网络传输数据。A程序提供服务,B程序通过网络将请求参数传递给A,A本地执行后得到结果,再将结果返回给B程序。这里需要关注的有两点:
    • 1)采用何种网络通讯协议?
      • 现在比较流行的RPC框架,都会采用TCP作为底层传输协议
    • 2)数据传输的格式怎样?
      • 两个程序进行通讯,必须约定好数据传输格式。就好比两个人聊天,要用同一种语言,否则无法沟通。所以,我们必须定义好请求和响应的格式。另外,数据在网路中传输需要进行序列化,所以还需要约定统一的序列化的方式。

2、像调用本地服务一样调用远程服务

  • 如果仅仅是远程调用,还不算是RPC,因为RPC强调的是过程调用,调用的过程对用户而言是应该是透明的,用户不应该关心调用的细节,可以像调用本地服务一样调用远程服务。所以RPC一定要对调用的过程进行封装

RPC调用流程图:

2、认识Http

Http协议:超文本传输协议,是一种应用层协议。规定了网络传输的请求格式、响应格式、资源定位和操作的方式等。但是底层采用什么网络传输协议,并没有规定,不过现在都是采用TCP协议作为底层传输协议。说到这里,大家可能觉得,Http与RPC的远程调用非常像,都是按照某种规定好的数据格式进行网络通信,有请求,有响应。没错,在这点来看,两者非常相似,但是还是有一些细微差别。

  • RPC并没有规定数据传输格式,这个格式可以任意指定,不同的RPC协议,数据格式不一定相同。
  • Http中还定义了资源定位的路径,RPC中并不需要
  • 最重要的一点:RPC需要满足像调用本地服务一样调用远程服务,也就是对调用过程在API层面进行封装。Http协议没有这样的要求,因此请求、响应等细节需要我们自己去实现。
    • 优点:RPC方式更加透明,对用户更方便。Http方式更灵活,没有规定API和语言,跨语言、跨平台
    • 缺点:RPC方式需要在API层面进行封装,限制了开发的语言环境。

例如我们通过浏览器访问网站,就是通过Http协议。只不过浏览器把请求封装,发起请求以及接收响应,解析响应的事情都帮我们做了。如果是不通过浏览器,那么这些事情都需要自己去完成。

3、如何选择?

既然两种方式都可以实现远程调用,我们该如何选择呢?

  • 速度来看,RPC要比http更快,虽然底层都是TCP,但是http协议的信息往往比较臃肿
  • 难度来看,RPC实现较为复杂,http相对比较简单
  • 灵活性来看,http更胜一筹,因为它不关心实现细节,跨平台、跨语言。

因此,两者都有不同的使用场景:

  • 如果对效率要求更高,并且开发过程使用统一的技术栈,那么用RPC还是不错的。
  • 如果需要更加灵活,跨语言、跨平台,显然http更合适

那么我们该怎么选择呢?
微服务,更加强调的是独立、自治、灵活。而RPC方式的限制较多,因此微服务框架中,一般都会采用基于Http的Rest风格服务。
总结
RPC服务和HTTP服务还是存在很多的不同点的,
一般来说,RPC服务主要是针对大型企业的,
而HTTP服务主要是针对小企业的,
因为RPC效率更高,而HTTP服务开发迭代会更快。
总之,选用什么样的框架不是按照市场上流行什么而决定的,而是要对整个项目进行完整地评估,
从而在仔细比较两种开发框架对于整个项目的影响,最后再决定什么才是最适合这个项目的。
一定不要为了使用RPC而每个项目都用RPC,而是要因地制宜,具体情况具体分析。

rpc和http的区别与联系?

区别:

传输协议
  • RPC:可以基于TCP协议,也可以基于HTTP协议。
  • HTTP:基于HTTP协议。
传输效率
  • RPC:使用自定义的TCP协议,可以让请求报文体积更小,或者使用HTTP2.0协议,也可以很好地减少报文体积,提高传输效率。
  • HTTP:如果时基于HTTP1.1的协议,请求中会包含很多无用的内容;如果是基于HTTP2.0,那么简单地封装一下还是可以作为一个RPC使用的,这时标准RPC框架更多是服务治理。
性能消耗
  • RPC:可以基于thrift实现高效的二进制传输
  • HTTP:大部分是通过json实现的,字节大小和序列化耗时都比thrift要更消耗性能
负载均衡
  • RPC:基本都自带了负载均衡策略
  • HTTP:需要配置Nginx,HAProxy实现
服务治理(下游服务新增,重启,下线时如何不影响上游调用者)
  • RPC:能做到自动通知,不影响上游
  • HTTP:需要事先通知,修改Nginx/HAProxy配置

RPC主要用于公司内部服务调用,性能消耗低,传输效率高,服务治理方便HTTP主要用于对外的异构环境,浏览器调用,APP接口调用,第三方接口调用等等。

RPC和HTTP都可以用于实现远程过程调用,如何选择
  • 速度上看,RPC比HTTP更快,虽然底层都是TCP,但是http协议的信息往往比较臃肿,不过可以采用gzip压缩
  • 难度上看,RPC实现较为复杂,http相对简单
  • 灵活性上看,HTTP更胜一筹,因为它不关心实现细节,跨平台,跨语言

两者有不同的使用场景:

  • 如果对效率要求更高,并且开发过程使用统一的技术栈,那么RPC还是不错的
  • 如果需要更加灵活跨语言跨平台,显然HTTP更合适

再插一句,最近新兴的微服务概念更加强调独立自治灵活,而RPC限制较多。因此微服务框架中,一般都会采用HTTP的Restful服务,像在公司内部使用hsf协议,对接外部系统使用微服务。

总结:
  1. RPC主要⽤于公司内部的服务调⽤,性能消耗低,传输效率⾼,服务治理⽅便。
  2. HTTP主要⽤于对外的异构环境,浏览器接⼝调⽤,APP接⼝调⽤,第三⽅接⼝调⽤等。

http和rpc不同的使用场景:

  • 如果对效率要求更高,并且开发过程使用统一的技术栈,那么RPC还是不错的
  • 如果需要更加灵活跨语言跨平台,显然HTTP更合适

再插一句,最近新兴的微服务概念更加强调独立自治灵活,而RPC限制较多。因此微服务框架中,一般都会采用HTTP的Restful服务,像在公司内部使用hsf协议,对接外部系统使用微服务。

有HTTP协议,为什么还要有RPC

其实,TCP是70年代出来的协议,而HTTP是90年代才开始流行的。
而直接使用裸TCP会有问题,可想而知,这中间这么多年有多少自定义的协议,
而这里面就有80年代出来的RPC。
所以我们该问的不是既然有HTTP协议为什么要有RPC,而是为什么有RPC还要有HTTP协议

那既然有RPC了,为什么还要有HTTP呢?

现在电脑上装的各种联网软件,比如xx管家,xx卫士,它们都作为客户端(client) 需要跟服务端(server) 建立连接收发消息,此时都会用到应用层协议,在这种client/server (c/s) 架构下,它们可以使用自家造的RPC协议,因为它只管连自己公司的服务器就ok了。
但有个软件不同,浏览器(browser) ,不管是chrome还是IE,它们不仅要能访问自家公司的服务器(server) ,还需要访问其他公司的网站服务器,因此它们需要有个统一的标准,不然大家没法交流。于是,HTTP就是那个时代用于统一 browser/server (b/s) 的协议。
也就是说在多年以前,HTTP主要用于b/s架构,而RPC更多用于c/s架构。但现在其实已经没分那么清了,b/s和c/s在慢慢融合。 很多软件同时支持多端,比如某度云盘,既要支持网页版,还要支持手机端和pc端,如果通信协议都用HTTP的话,那服务器只用同一套就够了。而RPC就开始退居幕后,一般用于公司内部集群里,各个微服务之间的通讯。
那这么说的话,都用HTTP得了,还用什么RPC?
仿佛又回到了文章开头的样子,那这就要从它们之间的区别开始说起。

HTTP和RPC有什么区别

我们来看看RPC和HTTP区别比较明显的几个点。

服务发现

首先要向某个服务器发起请求,你得先建立连接,而建立连接的前提是,你得知道IP地址和端口。这个找到服务对应的IP端口的过程,其实就是服务发现
HTTP中,你知道服务的域名,就可以通过DNS服务去解析得到它背后的IP地址,默认80端口。
RPC的话,就有些区别,一般会有专门的中间服务去保存服务名和IP信息,比如consul或者etcd,甚至是redis。想要访问某个服务,就去这些中间服务去获得IP和端口信息。由于dns也是服务发现的一种,所以也有基于dns去做服务发现的组件,比如CoreDNS
可以看出服务发现这一块,两者是有些区别,但不太能分高低。

底层连接形式

以主流的HTTP1.1协议为例,其默认在建立底层TCP连接之后会一直保持这个连接(keep alive),之后的请求和响应都会复用这条连接。
RPC协议,也跟HTTP类似,也是通过建立TCP长链接进行数据交互,但不同的地方在于,RPC协议一般还会再建个连接池,在请求量大的时候,建立多条连接放在池内,要发数据的时候就从池里取一条连接出来,用完放回去,下次再复用,可以说非常环保。

由于连接池有利于提升网络请求性能,所以不少编程语言的网络库里都会给HTTP加个连接池,比如go就是这么干的。
可以看出这一块两者也没太大区别,所以也不是关键。

传输的内容(主要原因)

基于TCP传输的消息,说到底,无非都是消息头header和消息体body。
header是用于标记一些特殊信息,其中最重要的是消息体长度
body则是放我们真正需要传输的内容,而这些内容只能是二进制01串,毕竟计算机只认识这玩意。所以TCP传字符串和数字都问题不大,因为字符串可以转成编码再变成01串,而数字本身也能直接转为二进制。但结构体呢,我们得想个办法将它也转为二进制01串,这样的方案现在也有很多现成的,比如json,protobuf。
这个将结构体转为二进制数组的过程就叫序列化,反过来将二进制数组复原成结构体的过程叫反序列化

对于主流的HTTP1.1,虽然它现在叫超文本协议,支持音频视频,但HTTP设计初是用于做网页文本展示的,所以它传的内容以字符串为主。header和body都是如此。在body这块,它使用json序列化结构体数据。
我们可以随便截个图直观看下。

可以看到这里面的内容非常多的冗余,显得非常啰嗦。最明显的,像header里的那些信息,其实如果我们约定好头部的第几位是content-type,就不需要每次都真的把"content-type"这个字段都传过来,类似的情况其实在body的json结构里也特别明显。
而RPC,因为它定制化程度更高,可以采用体积更小的protobuf或其他序列化协议去保存结构体数据,同时也不需要像HTTP那样考虑各种浏览器行为,比如302重定向跳转啥的。因此性能也会更好一些,这也是在公司内部微服务中抛弃HTTP,选择使用RPC的最主要原因。


当然上面说的HTTP,其实特指的是现在主流使用的HTTP1.1,HTTP2在前者的基础上做了很多改进,所以性能可能比很多RPC协议还要好,甚至连gRPC底层都直接用的HTTP2。
那么问题又来了。

为什么既然有了HTTP2,还要有RPC协议?

这个是由于HTTP2是2015年出来的。那时候很多公司内部的RPC协议都已经跑了好些年了,基于历史原因,一般也没必要去换了。

总结

  • 纯裸TCP是能收发数据,但它是个无边界的数据流,上层需要定义消息格式用于定义消息边界。于是就有了各种协议,HTTP和各类RPC协议就是在TCP之上定义的应用层协议。
  • RPC本质上不算是协议,而是一种调用方式,而像gRPC和thrift这样的具体实现,才是协议,它们是实现了RPC调用的协议。目的是希望程序员能像调用本地方法那样去调用远端的服务方法。同时RPC有很多种实现方式,不一定非得基于TCP协议
  • 从发展历史来说,HTTP主要用于b/s架构,而RPC更多用于c/s架构。但现在其实已经没分那么清了,b/s和c/s在慢慢融合。 很多软件同时支持多端,所以对外一般用HTTP协议,而内部集群的微服务之间则采用RPC协议进行通讯。
  • RPC其实比HTTP出现的要早,且比目前主流的HTTP1.1性能要更好,所以大部分公司内部都还在使用RPC。
  • HTTP2.0HTTP1.1的基础上做了优化,性能可能比很多RPC协议都要好,但由于是这几年才出来的,所以也不太可能取代掉RPC。

最后留个问题吧,大家有没有发现,不管是HTTP还是RPC,它们都有个特点,那就是消息都是客户端请求,服务端响应。客户端没问,服务端肯定就不答,这就有点僵了,但现实中肯定有需要下游主动发送消息给上游的场景,比如打个网页游戏,站在那啥也不操作,怪也会主动攻击我,这种情况该怎么办呢?

同步调用与异步调用

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

protobuf

protobuf的序列化流程

  • 定义 .proto 文件
  • protoc 编译器编译 .proto 文件生成一系列接口代码
  • 调用生成的接口实现对 .proto 定义的字段的读取以及 message 对象的序列化、反序列化方法

go的struct通过grpc传输的时候,是一个二进制的字节流,struct变成字节流的过程?是怎么拼成字节流的?(不会)

基于TCP传输的消息,说到底,无非都是消息头header和消息体body。
header是用于标记一些特殊信息,其中最重要的是消息体长度
body则是放我们真正需要传输的内容,而这些内容只能是二进制01串,毕竟计算机只认识这玩意。所以TCP传字符串和数字都问题不大,因为字符串可以转成编码再变成01串,而数字本身也能直接转为二进制。但结构体呢,我们得想个办法将它也转为二进制01串,这样的方案现在也有很多现成的,比如json,protobuf。
这个将结构体转为二进制数组的过程就叫序列化,反过来将二进制数组复原成结构体的过程叫反序列化

对于主流的HTTP1.1,虽然它现在叫超文本协议,支持音频视频,但HTTP设计初是用于做网页文本展示的,所以它传的内容以字符串为主。header和body都是如此。在body这块,它使用json序列化结构体数据。
我们可以随便截个图直观看下。

可以看到这里面的内容非常多的冗余,显得非常啰嗦。最明显的,像header里的那些信息,其实如果我们约定好头部的第几位是content-type,就不需要每次都真的把"content-type"这个字段都传过来,类似的情况其实在body的json结构里也特别明显。

查看全部
点赞(43) 打赏

评论列表 共有 0 条评论

暂无评论

微信小程序

微信扫一扫体验

立即
投稿

微信公众账号

微信扫一扫加关注

发表
评论
返回
顶部