rpc
-
什么是 RPC
- RPC 是远程过程调用（Remote Procedure Call）的缩写形式，Birrell 和 Nelson 在 1984 发表于 ACM Transactions on Computer Systems 的论文《Implementing remote procedure calls》对 RPC 做了经典的诠释。RPC 是指计算机 A 上的进程，调用另外一台计算机 B 上的进程，其中 A 上的调用进程被挂起，而 B 上的被调用进程开始执行，当值返回给 A 时，A 进程继续执行。调用方可以通过使用参数将信息传送给被调用方，而后可以通过传回的结果得到信息。而这一过程，对于开发人员来说是透明的。
- 远程过程调用采用客户机/服务器(C/S)模式。请求程序就是一个客户机，而服务提供程序就是一台服务器。和常规或本地过程调用一样，远程过程调用是同步操作，在远程过程结果返回之前，需要暂时中止请求程序。使用相同地址空间的低权进程或低权线程允许同时运行多个远程过程调用。
-
RPC 的基本操作
- 当消息到达服务器时，服务器上的操作系统将它传递给服务器存根（server stub）。服务器存根是客户存根在服务器端的等价物，也是一段代码，用来将通过网络输入的请求转换为本地过程调用。服务器存根一般先调用 receive ，然后被阻塞，等待消息输入。收到消息后，服务器将参数由消息中提取出来，然后以常规方式调用服务器上的相应过程（如图3所示）。从服务器角度看，过程好像是由客户直接调用的一样：参数和返回地址都位于堆栈中，一切都很正常。服务器执行所要求的操作，随后将得到的结果以常规的方式返回给调用方。以 read 为例，服务器将用数据填充 read 中第二个参数指向的缓冲区，该缓存区是属于服务器存根内部的。
- 调用完后，服务器存根要将控制权教会给客户发出调用的过程，它将结果（缓冲区）打包成消息，随后调用 send 将结果返回给客户。事后，服务器存根一般会再次调用 receive，等待下一个输入的请求。
- 客户机器接收到消息后，客户操作系统发现该消息属于某个客户进程（实际上该进程是客户存根，只是操作系统无法区分二者）。操作系统将消息复制到相应的缓存区中，随后解除对客户进程的阻塞。客户存根检查该消息，将结果提取出来并复制给调用者，而后以通常的方式返回。当调用者在 read 调用进行完毕后重新获得控制权时，它所知道的唯一事就是已经得到了所需的数据。它不指导操作是在本地操作系统进行，还是远程完成。
- 整个方法，客户方可以简单地忽略不关心的内容。客户所涉及的操作只是执行普通的（本地）过程调用来访问远程服务，它并不需要直接调用 send 和 receive 。消息传递的所有细节都隐藏在双方的库过程中，就像传统库隐藏了执行实际系统调用的细节一样。
- 概况来说，远程过程调用包含如下步骤：
客户过程以正常的方式调用客户存根；
客户存根生成一个消息，然后调用本地操作系统；
客户端操作系统将消息发送给远程操作系统；
远程操作系统将消息交给服务器存根；
服务器存根调将参数提取出来，而后调用服务器；
服务器执行要求的操作，操作完成后将结果返回给服务器存根；
服务器存根将结果打包成一个消息，而后调用本地操作系统；
服务器操作系统将含有结果的消息发送给客户端操作系统；
客户端操作系统将消息交给客户存根；
客户存根将结果从消息中提取出来，返回给调用它的客户存根。
-
实现远程过程调用如何传递参数
-
将参数放入消息中，并在消息中添加要调用的过程的名称或者编码。
消息到达服务器后，服务器存根堆该消息进行分析，以判明需要调用哪个过程，随后执行相应的调用。
服务器运行完毕后，服务器存根将服务器得到的结果打包成消息送回客户存根，客户存根将结果从消息中提取出来，把结果值返回给客户端。
-
常见的RPC框架
dubbo
阿里巴巴公司开源的一个Java高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成
motan
新浪微博开源的一个Java 框架。它诞生的比较晚，起于2013年，2016年5月开源。Motan 在微博平台中已经广泛应用，每天为数百个服务完成近千亿次的调用。
rpcx
Go语言生态圈的Dubbo， 比Dubbo更轻量，实现了Dubbo的许多特性，借助于Go语言优秀的并发特性和简洁语法，可以使用较少的代码实现分布式的RPC服务。
gRPC
Google开发的高性能、通用的开源RPC框架，主要面向移动应用开发并基于HTTP/2协议标准而设计，基于ProtoBuf(Protocol Buffers)序列化协议开发，且支持众多开发语言。本身它不是分布式的，所以要实现上面的框架的功能需要进一步的开发。
thrift
Apache的一个跨语言的高性能的服务框架 -
RPC与MQ
- 异步MQ，同步RPC
- 关注下游执行执行结果，用RPC；
- 不关注下游执行结果，用MQ，不用RPC；
-
RPC和Http:
- RPC并没有规定数据传输格式，这个格式可以任意指定，不同的RPC协议，数据格式不一定相同。
- Http中还定义了资源定位的路径，RPC中并不需要
- RPC需要满足像调用本地服务一样调用远程服务，也就是对调用过程在API层面进行封装。Http协议没有这样的要求，因此请求、响应等细节需要我们自己去实现。
- 论复杂度，RPC框架肯定是高于简单的HTTP接口的。但毋庸置疑，HTTP接口由于受限于HTTP协议，需要带HTTP请求头， 导致传输起来效率或者说安全性不如RPC。（RPC 本身是一种框架，而http 是应用层的协议 ）
- RPC是一种技术的概念名词。 HTTP是一种协议，RPC可以通过HTTP来实现，也可以通过Socket自己实现一套协议来实现。所以楼主可以换一个问法，为何RPC还有除HTTP 之外的实现法，有何必要。毕竟除了HTTP实现外，私有协议不具备通用性。那么我想唯一的答案就在于HTTP不能满足其业务场景的地方，所以这个就要具体 案例具体分析了。
- http接口是在接口不多、系统与系统交互较少的情况下，解决信息孤岛初期常使用的一种通信手段；优点就是简单、直接、开发方便。利用现成的http协议 进行传输。但是如果是一个大型的网站，内部子系统较多、接口非常多的情况下，RPC框架的好处就显示出来了，首先就是长链接，不必每次通信都要像http 一样去3次握手什么的，减少了网络开销；其次就是RPC框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统 一化的操作。第三个来说就是安全性。最后就是最近流行的服务化架构、服务化治理，RPC框架是一个强力的支撑。