我怎么理解RPC和Http以及REST风格

随着分布式架构，微服务的流行，一直以来，很多人一说RPC就想到dubbo，提到REST风格就想到springcloud微服务，提起这这两个又必然想到http，那么具体好好解释RPC和REST风格以及和http之间的三角恋关系相信很多人并不能全覆盖或者通俗易懂的话来解释这三者之间的“爱恨情仇”。

首先 我们先从定义上来了解这三者的关系，毕竟老祖宗说过，知己知彼，才能百胜不殆，话不多说，上菜。。。。。

百度百科如下：(最好多读读这三个百度百科的详细介绍哦)

RPC：

REST:

 HTTP:

 

首先说一下RPC架构：

RPC架构里包含如下4个组件:

 

1、 客户端(Client)：服务调用方

2、 客户端存根(Client Stub)：存放服务端地址信息，将客户端的请求参数打包成网络消息，再通过网络发送给服务方

3、 服务端存根(Server Stub)：接受客户端发送过来的消息并解包，再调用本地服务

4、服务端(Server)：真正的服务提供者。

 

具体实现步骤：

 

1、 服务调用方（client）(客户端)以本地调用方式调用服务；

2、 client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；在我们的Java

说白了就是一个序列化的过程。

3、 client stub找到服务地址，并将消息通过网络发送到服务端；

4、 server stub收到消息后进行解码,在Java里就是常说的反序列化的过程；

5、 server stub根据解码结果调用本地的服务；

6、 本地服务执行处理逻辑；

7、 本地服务将结果返回给server stub；

8、 server stub将返回结果打包成消息，Java里的序列化；

9、 server stub将打包后的消息通过网络并发送至消费方

10、 client stub接收到消息，并进行解码, Java里的反序列化；

11、 服务调用方（client）得到最终结果。

 

RPC框架的目标就是把2-10步封装起来，把调用、编码/解码的过程封装起来，这样，你看就成了这样

在看一下就是这样的了：

   RPC架构分为三部分：

1.     服务提供者，运行在服务器端，提供服务接口定义与服务实现类。

2.     服务中心，运行在服务器端，负责将本地服务发布成远程服务，管理远程服务，提供给服务消费者使用。

3.     服务消费者，运行在客户端，通过远程代理对象调用远程服务。

你说爽不爽，其实就是让用户像调用本地服务一样的调用远程服务。当然这样也不是说搞就搞好，也需要考虑一些其它问题。什么问题呢？其实就是做到如何支持把2到10这几步省略掉的东西。

1、通讯问题 : 主要是通过在客户端和服务器之间建立TCP/http连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。 

2、寻址问题 ：你说你能调用，人家该如何找到你呢？对吧，你得告诉人家你穿什么衣服，身高什么的吧，比如你说 你170，穿品如的衣服哦。。。

对于服务器来讲， A服务器上需要告诉底层的RPC框架，如何连接到B服务器（如主机或IP地址）以及特定的端口，方法的名称是什么，这样才能完成调用。比如基于Web服务协议栈的RPC，就要提供一个endpoint URI，或者是从UDDI服务上查找。如果是RMI调用的话，还需要一个RMI Registry来注册服务的地址。 

3、序列化与反序列化 ： 一台服务器发起远程过程调用时，方法的参数需要通过底层的网络协议如TCP传递到另一台服务器，由于网络协议是基于二进制的，内存中的参数的值要序列化成二进制的形式，也就是序列化（Serialize）或编组（marshal），通过寻址和传输将序列化的二进制发送给另一台服务器。 同理，接收端的服务器接收参数要将参数反序列化，然后把结果在返回给调用它的那台服务器，服务器接收也要经过反序列化才能拿到他想要的东西。

这几样搞定了，ok RPC功能就完全的透明化了。

 

Rest架构的主要原则：

1.   网络上的所有事物都被抽象为资源

2.   每个资源都有一个唯一的资源标识符

3.   同一个资源具有多种表现形式(xml,json等)

4.   对资源的各种操作不会改变资源标识符

5.   所有的操作都是无状态的

 

其中表述性状态，是指(在某个瞬间状态的)资源数据的快照，包括资源数据的内容、表述格式(XML、JSON)等信息。

 

其中无状态通信，是指服务端(响应端)不保存任何与特定HTTP请求相关的资源，应用状态必须由请求方在请求过程中提供。要求在网络通信过程中，任意一个Web请求必须与其他请求隔离，当请求端提出请求时，请求本身包含了响应端为响应这一请求所需的全部信息。

 

REST使用HTTP+URI+XML /JSON 的技术来实现其API要求的架构风格：HTTP协议和URI用于统一接口和定位资源，文本、二进制流、XML、JSON等格式用来作为资源的表述。

 

上面的可能看完还不知道个嘛意思，别着急 看下面的例子

 

在Restful之前的操作： 请求的地址对应具体的业务操作 (以用户的crud为例子)

http://localhost/user/findById/1 GET 根据用户id查询用户数据 

http://ocalhost/user/creat POST 新增用户 

http://ocalhost/user/update POST 修改用户

http://ocalhost/user/delete GET/POST 删除用户

 

RESTful用法： 请求 

http://localhost/user/1 GET 根据用户id查询用户数据 

http://localhost/user POST 新增用户 

http://localhost/user PUT 修改用户

http://localhost/user DELETE 删除用户

 

RESTful风格的体现，

get请求，就是查询；

post请求,就是新增

ut请求，就是修改

delete请求，就是删除

这样做就完全没有必要对crud做具体的描述。

我们把这样满足REST约束条件和原则的架构，就被称为是RESTful架构。

就像URL都是URI(统一资源标识)的表现形式一样，RESTful是符合REST原则的表现形式。

 

 

RPC 即远程过程调用, 很简单的概念, 像调用本地服务(方法)一样调用服务器的服务(方法).

REST：所谓的 Representational state transfer (面向资源)

HTTP：就是一个客户端和服务器端的通讯方式而已。

 

至此，以上是我对他们三个的个人理解。