RPC、SOAP、REST的区别

RPC（remote procedure call，远程过程调用）如thrift grpc rpcx(最好的go语言rpc)等

SOAP(simple object access protoal，简单对象访问协议) 如webservice

REST(representational state transfer，表达性状态转移)

可以都理解为调用远程方法的一些通信技术“风格”：

· RMI就好比它是本地工作，采用tcp/ip协议，客户端直接调用服务端上的一些方法。优点是强类型，编译期可检查错误，缺点是只能基于JAVA语言，客户机与服务器紧耦合。

· RPC是一个泛化的概念，严格来说一切远程过程调用手段都属于rpc范畴，包括rmi、hessian、soap、thrift、protobuf等等。

· SOAP是在XML-RPC基础上，使用标准的XML描述了RPC的请求信息（URI/类/方法/参数/返回值）。因为XML-RPC只能使用有限的数据类型种类和一些简单的数据结构，SOAP能支持更多的类型和数据结构。优点是跨语言，非常适合异步通信和针对松耦合的C/S，缺点是必须做很多运行时检查。

· REST一般用来和SOAP做比较，它采用简单的URL方式来代替一个对象，优点是轻量，可读性较好，不需要其他类库支持，缺点是URL可能会很长，不容易解析

比较 RPC over HTTP 和 RESTful。

首先 RPC 的客户端和服务器端师紧耦合的，客户端需要知道调用的过程的名字，过程的参数以及它们的类型、顺序等。一旦服务器更改了过程的实现，

客户端的实现很容易出问题。RESTful基于 http的语义操作资源，参数的顺序一般没有关系，也很容易的通过代理转换链接和资源位置，从这一点上来说，RESTful 更灵活。

其次，它们操作的对象不一样。 RPC 操作的是方法和过程，它要操作的是方法对象。 RESTful 操作的是资源(resource)，而不是方法。

第三，RESTful执行的是对资源的操作，增加、查找、修改和删除等,主要是CURD，所以如果你要实现一个特定目的的操作，比如为名字姓张的学生的数学成绩都加上10这样的操作，RESTful的API设计起来就不是那么直观或者有意义。在这种情况下, RPC的实现更有意义，它可以实现一个Student.Increment(Name, Score)的方法供客户端调用。

我们再来比较一下 RPC over TCP 和 RESTful。

如果我们直接使用socket实现 RPC，除了上面的不同外，我们可以获得性能上的优势。

RPC over TCP可以通过长连接减少连接的建立所产生的花费，在调用次数非常巨大的时候(这是目前互联网公司经常遇到的情况,大并发的情况下)，这个花费影响是非常巨大的。

当然 RESTful 也可以通过 keep-alive 实现长连接， 但是它最大的一个问题是它的request-response模型是阻塞的 (http1.0和 http1.1, http 2.0没这个问题)，

发送一个请求后只有等到response返回才能发送第二个请求 (有些http server实现了pipeling的功能，但不是标配)， RPC的实现没有这个限制。

在当今用户和资源都是大数据大并发的趋势下，一个大规模的公司不可能使用一个单体程序提供所有的功能，微服务的架构模式越来越多的被应用到产品的设计和开发中，

服务和服务之间的通讯也越发的重要， 所以 RPC 不失是一个解决服务之间通讯的好办法。

什么是rpc？

RPC全称为Remote Procedure Call，意为远程过程调用。调用远程的过程就像调用本地的子程序一样方便，从而屏蔽了通讯复杂性，使开发人员可以无需关注网络编程的细节，将更多的时间和精力放在业务逻辑本身的实现上，提高工作效率。

假设有两台服务器A,B.A服务器上部署着一个应用a，B服务器上部署着一个应用b，现在a希望能够调用b应用的某个函数(方法)，但是二者不在同一个进程内，不能直接调用，就需要通过网络传输，在AB服务器之间建一条网络传输通道，a把参数传过去，b接收到参数调用自己的方法得到结果，再通过网络传回给a。

简单讲就是A通过网络来调用B的过程，这个过程要涉及的东西很多，比如多线程、Socket、序列化反序列化、网络I/O，很复杂。于是牛掰的程序员把这些封装起来做成一套框架供大家使用，就是RPC框架。

RPC本质上是一种 Inter-process communication（IPC）——进程间通信的形式。常见的进程间通信方式如管道、共享内存是同一台物理机上的两个进程间的通信，而RPC就是两个在不同物理机上的进程之间的通信。概括的说，RPC就是在一台机器上调用另一台机器上的方法，这种调用在远程机器上对代码的执行就像在本机上对代码的执行一样，只是迁移了一个执行环境而已。

RPC是一种C/S架构的服务模型，server端提供接口供client调用，client端向server端发送数据，server端接收client端的数据进行相关计算并将结果返回给client端。server端向client端发发送数据，client端执行向server端反馈结果。

远程调用原理

比如 A (client) 调用 B (server) 提供的remoteAdd方法：

首先A与B之间建立一个TCP连接；

然后A把需要调用的方法名（这里是remoteAdd）以及方法参数（10， 20）序列化成字节流发送出去；

B接受A发送过来的字节流，然后反序列化得到目标方法名，方法参数，接着执行相应的方法调用（可能是localAdd）并把结果30返回；A接受远程调用结果,输出30。

RPC框架就是把我刚才说的这几点些细节给封装起来，给用户暴露简单友好的API使用。

远程调用的好处

解耦：当server需要对方法内实现修改时，client完全感知不到，不用做任何变更；这种方式在跨部门，跨公司合作的时候经常用到，并且方法的提供者我们通常称为：服务的暴露。

RPC与Socket有什么区别？

通过上面的简单阐述，好像RPC与Socket 好像啊。都是调用远程的方法，都是client/server模式，我之前也写了一篇文章: 细说socket 那他们有啥区别呢?

RPC（远程过程调用）采用客户机/服务器模式实现两个进程之间相互通信。socket是RPC经常采用的通信手段之一，RPC是在Socket的基础上实现的，它比socket需要更多的网络和系统资源。除了Socket，RPC还有其他的通信方法，比如：http、操作系统自带的管道等技术来实现对于远程程序的调用。微软的Windows系统中，RPC就是采用命名管道进行通信。

RPC与REST有什么区别？

通过了解RPC后，我们知道是RPC是client/server模式的，调用远程的方法，REST也是我们熟悉的一套API调用协议方法，它也是基于client/server模式的，调用远程的方法的，那他俩又有啥区别呢？

REST API 和 RPC 都是在 Server端 把一个个函数封装成接口暴露出去，以供 Client端 调用，不过 REST API 是基于 HTTP协议的，REST致力于通过http协议中的POST/GET/PUT/DELETE等方法和一个可读性强的URL来提供一个http请求。而 RPC 则可以不基于 HTTP协议

因此，如果是后端两种语言互相调用，用 RPC 可以获得更好的性能（省去了 HTTP 报头等一系列东西），应该也更容易配置。如果是前端调用后端，那么用 REST API 的形式比较好（因为无论如何也避不开 HTTP 这道坎）

Call ID映射。在RPC中，所有的函数都必须有自己的一个ID。这个ID在所有进程中都是唯一确定的。客户端在做远程过程调用时，必须附上这个ID。然后我们还需要在客户端和服务端分别维护一个 {函数 <--> Call ID} 的对应表。两者的表不一定需要完全相同，但相同的函数对应的Call ID必须相同。当客户端需要进行远程调用时，它就查一下这个表，找出相应的Call ID，然后把它传给服务端，服务端也通过查表，来确定客户端需要调用的函数，然后执行相应函数的代码。

序列化和反序列化。客户端怎么把参数值传给远程的函数呢？在本地调用中，我们只需要把参数压到栈里，然后让函数自己去栈里读就行。但是在远程过程调用时，客户端跟服务端是不同的进程，不能通过内存来传递参数。甚至有时候客户端和服务端使用的都不是同一种语言（比如服务端用C++，客户端用Java或者Python）。这时候就需要客户端把参数先转成一个字节流，传给服务端后，再把字节流转成自己能读取的格式。这个过程叫序列化和反序列化。同理，从服务端返回的值也需要序列化反序列化的过程。

网络传输。远程调用往往用在网络上，客户端和服务端是通过网络连接的。所有的数据都需要通过网络传输，因此就需要有一个网络传输层。网络传输层需要把Call ID和序列化后的参数字节流传给服务端，然后再把序列化后的调用结果传回客户端。只要能完成这两者的，都可以作为传输层使用。因此，它所使用的协议其实是不限的，能完成传输就行。尽管大部分RPC框架都使用TCP协议，但其实UDP也可以，而gRPC干脆就用了HTTP2。Java的Netty也属于这层的东西。

所以，自己要想实现一个RPC框架，其实只需要把以上三点实现了就基本完成了。

Call ID映射可以直接使用函数字符串，也可以使用整数ID。映射表一般就是一个哈希表。

序列化反序列化可以自己写，也可以使用Protobuf或者FlatBuffers之类的。

网络传输库可以自己写socket，或者用asio，ZeroMQ，Netty之类。

thrift rpc框架介绍

Thrift 是 IDL 描述性语言的一个具体实现，适用于程序对程序静态的数据交换，需要先确定好数据结构。

Thrift 是完全静态化的，当数据结构发生变化时，必须重新编辑IDL文件、代码生成再编译载入的流程，跟其他IDL工具相比较可以视为是 Thrift 的弱项。Thrift 适用于搭建大型数据交换及存储的通用工具，在大型系统中的内部数据传输上相对于 JSON 和 XML 无论在性能、传输大小上有明显的优势

thrift通过一个中间语言IDL(接口定义语言)来定义RPC的数据类型和接口，这些内容写在以.thrift结尾的文件中，然后通过特殊的编译器来生成不同语言的代码，以满足不同需要的开发者。比如java开发者，就可以生成java代码，c++开发者可以生成c++代码，生成的代码中不但包含目标语言的接口定义、方法、数据类型，还包含有RPC协议层和传输层的实现代码。

Thrift是一种c/s的架构体系。TServer主要任务是高效的接受客户端请求，并将请求转发给Processor处理。

最上层是用户自行实现的业务逻辑代码；真正需要开发的部分，其他部分已经由thrift框架完成了

Processor是由thrift编译器自动生成的代码，它封装了从输入数据流中读数据和向数据流中写数据的操作，它的主要工作是：从连接中读取数据，把处理交给用户实现impl，最后把结果写到连接上。

TProtocol是用于数据类型解析的，将结构化数据转化为字节流给TTransport进行传输。从TProtocol以下部分是thirft的传输协议和底层I/O通信。

TTransport是与底层数据传输密切相关的传输层，负责以字节流方式接收和发送消息体，不关注是什么数据类型。

底层IO负责实际的数据传输，包括socket、文件和压缩数据流等。

gRPC

在 gRPC 里客户端应用可以像调用本地对象一样直接调用另一台不同的机器上服务端应用的方法，使得您能够更容易地创建分布式应用和服务。与许多 RPC 系统类似，gRPC 也是基于以下理念：定义一个服务，指定其能够被远程调用的方法（包含参数和返回类型）。在服务端实现这个接口，并运行一个 gRPC 服务器来处理客户端调用。在客户端拥有一个存根能够像服务端一样的方法。

gRPC 客户端和服务端可以在多种环境中运行和交互 - 从 google 内部的服务器到你自己的笔记本，并且可以用任何 gRPC支持的语言来编写。所以，你可以很容易地用 Java 创建一个 gRPC 服务端，用 Go、Python、Ruby 来创建客户端。此外，Google 最新 API 将有 gRPC 版本的接口，使你很容易地将 Google 的功能集成到你的应用里

RESTFul

资源表现层状态转化

RESTFul API有哪些特点：

基于“资源”，数据也好、服务也好，在RESTFul设计里一切都是资源。

无状态。一次调用一般就会返回结果，不存在类似于“打开连接-访问数据-关闭连接”这种依赖于上一次调用的情况。

URL中通常不出现动词，只有名词

URL语义清晰、明确

使用HTTP的GET、POST、DELETE、PUT来表示对于资源的增删改查

使用JSON不使用XML

RESTFul API的一些最佳实践原则：

使用HTTP动词表示增删改查资源， GET：查询，POST：新增，PUT：更新，DELETE：删除

返回结果必须使用JSON

HTTP状态码，在REST中都有特定的意义：200，201,202,204,400,401,403,500。比如401表示用户身份认证失败，403表示你验证身份通过了，但这个资源你不能操作。

如果出现错误，返回一个错误码。通常是这么定义的：

API必须有版本的概念，v1，v2，v3

使用Token令牌来做用户身份的校验与权限分级，而不是Cookie。

url中大小写不敏感，不要出现大写字母

使用 - 而不是使用 _ 做URL路径中字符串连接。

有一份漂亮的文档~（很重要）

更多参考

http://www.ruanyifeng.com/blog/2011/09/restful.html

http://www.ruanyifeng.com/blog/2018/10/restful-api-best-practices.html

RESTful架构：

　　（1）每一个URI代表一种资源；

　　（2）客户端和服务器之间，传递这种资源的某种表现层；

　　（3）客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。