【原理】RPC与HTTP

RPC与HTTP

RPC原理

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

RPC 让远程调用就像本地调用一样，其调用过程可拆解为以下步骤。

① 服务调用方（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.0在HTTP1.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结构里也特别明显。