A common understanding of the RPC protocol

According to some information searched on the Internet, if there are any mistakes, please correct them.

Author: Xiao Jichao
Link : http://www.zhihu.com/question/25536695/answer/31046384
Source: Zhihu The
copyright belongs to the author, please contact the author for authorization.

In the early stand-alone era, there were multiple processes running on one computer, and everyone worked on their own, and they never communicated with each other. If process A needs a drawing function, and process B also needs a drawing function, the programmer must write a drawing function for both processes. Isn't this the whole person? So IPC (Inter-process communication, mutual communication between processes running in a single machine) appeared. OK, now that A has the drawing function, B will call the drawing function on the A process, and the programmer can finally be lazy.


In the Internet age, everyone's computers are connected. In the past, the program could only call the process on its own computer, can it call the process on other machines? So programmers extended IPC to the network, which is RPC (remote procedure call). Now not only processes on a single machine can communicate with each other, but processes on multiple machines can also communicate with each other.

You must know that it is very troublesome to implement RPC. What multithreading, what Socket, and what I/O are all things that make us ordinary programmers have a headache. So some great people developed RPC frameworks (for example, CORBA, RMI, Web Services, RESTful Web Services, etc.).

OK, now it's time to define the concept of an RPC framework. Simply put, an RPC framework is a set of tools that allow programmers to call code on remote processes. With the RPC framework, our programmers are much more relaxed, and can finally escape the bitter sea of ​​multi-threading, Socket, and I/O.
===================================================== =

Author: Mind Pavilion
Link : http://www.zhihu.com/question/25536695/answer/36197244
Source: Zhihu The
copyright belongs to the author, please contact the author for authorization.

First of all, understand what RPC is and why RPC is needed. RPC refers to remote procedure calls, that is to say, two servers A and B, an application is deployed on server A, and wants to call the functions/methods provided by the application on server B. A memory space, which cannot be called directly, needs to express the semantics of the call and convey the data of the call through the network.

For example, a method might be defined like this:
Employee getEmployeeByName(String fullName)
Then:

• First of all, to solve the problem of communication, mainly by establishing a TCP connection between the client and the server, all the exchanged data of the remote procedure call are transmitted in this connection. The connection can be an on-demand connection that is disconnected after the call ends, or it can be a persistent connection, where multiple remote procedure calls share the same connection.
• Second, to solve the problem of addressing, that is, how does the application on the A server tell the underlying RPC framework, how to connect to the B server (such as a host or IP address) and a specific port, what is the name of the method, This completes the call. For example, for RPC based on the Web service protocol stack, it is necessary to provide an endpoint URI, or to find it from the UDDI service. If it is called by RMI, an RMI Registry is also required to register the address of the service.
  
• Third, when the application on the A server initiates a remote procedure call, the parameters of the method need to be passed to the B server through the underlying network protocol such as TCP. Since the network protocol is based on binary, the value of the parameters in the memory must be serialized into binary. The form, that is, serialize or marshal, sends the serialized binary to the B server through addressing and transmission.
• 第四，B服务器收到请求后，需要对参数进行反序列化（序列化的逆操作），恢复为内存中的表达方式，然后找到对应的方法（寻址的一部分）进行本地调用，然后得到返回值。
• 第五，返回值还要发送回服务器A上的应用，也要经过序列化的方式发送，服务器A接到后，再反序列化，恢复为内存中的表达方式，交给A服务器上的应用

• 
  

（图片来源： https://www.cs.rutgers.edu/~pxk/417/notes/03-rpc.html）

为什么RPC呢？就是无法在一个进程内，甚至一个计算机内通过本地调用的方式完成的需求，比如比如不同的系统间的通讯，甚至不同的组织间的通讯。由于计算能力需要横向扩展，需要在多台机器组成的集群上部署应用，

RPC的协议有很多，比如最早的CORBA，Java RMI，Web Service的RPC风格，Hessian，Thrift，甚至Rest API。

=============================================================================================

作者：马秉尧
链接：http://www.zhihu.com/question/25536695/answer/109977506
来源：知乎
著作权归作者所有，转载请联系作者获得授权。

RPC(远程过程调用)是什么

• 简单的说，RPC就是从一台机器（客户端）上通过参数传递的方式调用另一台机器（服务器）上的一个函数或方法（可以统称为服务）并得到返回的结果。
  
• RPC 会隐藏底层的通讯细节（不需要直接处理Socket通讯或Http通讯）
  
• RPC 是一个请求响应模型。客户端发起请求，服务器返回响应（类似于Http的工作方式）
  
• RPC 在使用形式上像调用本地函数（或方法）一样去调用远程的函数（或方法）。
  

远程过程调用发展历程

• ONC RPC （开放网络计算的远程过程调用），OSF RPC（开放软件基金会的远程过程调用）
  
• CORBA（Common Object Request Broker Architecture公共对象请求代理体系结构）
  
• DCOM（分布式组件对象模型），COM+
  
• Java RMI
  
• .NET Remoting
  
• XML-RPC，SOAP，Web Service
  
• PHPRPC，Hessian，JSON-RPC
  
• Microsoft WCF，WebAPI
  
• ZeroC Ice，Thrift，GRPC
  
• Hprose
  

早期的 RPC

• 第一代 RPC（ONC RPC，OSF RPC）不支持对象的传递。
  
• CORBA 太复杂，各种不同实现不兼容，一般程序员也玩不转。
  
• DCOM，COM+ 逃不出 Windows 的手掌心。
  
• RMI 只能在 Java 里面玩。
  
• .NET Remoting 只能在 .NET 平台上玩。
  

XML-RPC，SOAP，WebService

• 冗余数据太多，处理速度太慢。
  
• RPC 风格的 Web Service 跨语言性不佳，而 Document 风格的 Web Service 又太过难用。
  
• Web Service 没有解决用户的真正问题，只是把一个问题变成了另一个问题。
  
• Web Service 的规范太过复杂，以至于在 .NET 和 Java 平台以外没有真正好用的实现，甚至没有可用的实现。
  
• 跨语言跨平台只是 Web Service 的一个口号，虽然很多人迷信这一点，但事实上它并没有真正实现。
  

PHPRPC

• 基于 PHP 内置的序列化格式，在跨语言的类型映射上存在硬伤。
  
• 通讯上依赖于 HTTP 协议，没有其它底层通讯方式的选择。
  
• 内置的加密传输既是特点，也是缺点。
  
• 虽然比基于 XML 的 RPC 速度快，但还不是足够快。
  

Hessian

• 二进制的数据格式完全不具有可读性。
  
• 官方只提供了两个半语言的实现（Java，ActionScript 和不怎么完美的 Python 实现），其它语言的第三方实现良莠不齐。
  
• 支持的语言不够多，对 Web 前端的 JavaScript 完全无视。
  
• 虽然是动态 RPC，但动态性仍然欠佳。
  
• 虽然比基于 XML 的 RPC 速度快，但还不是足够快。
  

JSON-RPC

• JSON 具有文本可读性，且比 XML 更简洁。
  
• JSON 受 JavaScript 语言子集的限制，可表示的数据类型不够多。
  
• JSON 格式无法表示数据内的自引用，互引用和循环引用。
  
• 某些语言具有多种版本的实现，但在类型影射上没有统一标准，存在兼容性问题。
  
• JSON-RPC 虽然有规范，但是却没有统一的实现。在不同语言中的各自实现存在兼容性问题，无法真正互通。
  

Microsoft WCF，WebAPI

• 它们是微软对已有技术的一个 .NET 平台上的统一封装，是对 .NET Remoting、WebService 和基于 JSON 、XML 等数据格式的 REST 风格的服务等技术的一个整合。
  
• 虽然号称可以在 .NET 平台以外来调用它的这些服务，但实际上跟在 .NET 平台内调用完全是两码事。它没有提供任何在其他平台的语言中可以使用的任何工具。
  

ZeroC Ice，Thrift，GRPC

• 初代 RPC 技术的跨语言面向对象的回归。
  
• 仍然需要通过中间语言来编写类型和接口定义。
  
• 仍然需要用代码生成器来将中间语言编写的类型和接口定义翻译成你所使用的编程语言的客户端和服务器端的占位程序（stub）。
  
• 你必须要基于生成的服务器代码来单独编写服务，而不能将已有代码直接作为服务发布。
  
• 你必须要用生成的客户端代码来调用服务，而没有其它更灵活的方式。
  
• 如果你的中间代码做了修改，以上所有步骤你都要至少重复一遍。
  

Hprose

• 无侵入式设计，不需要单独定义类型，不需要单独编写服务，已有代码可以直接发布为服务。
  
• 具有丰富的数据类型和完美的跨语言类型映射，支持自引用，互引用和循环引用数据。
  
• 支持众多传输方式，如 HTTP、TCP、Websocket 等。
  
• 客户端具有更灵活的调用方式，支持同步调用，异步调用，动态参数，可变参数，引用参数传递，多结果返回（Golang）等语言特征，Hprose 2.0 甚至支持推送。
  
• 具有良好的可扩展性，可以通过过滤器和中间件实现加密、压缩、缓存、代理等各种功能性扩展。
  
• 兼容的无差别跨语言调用
  
• 支持更多的常用语言和平台
  
• 支持浏览器端的跨域调用
  
• 没有中间语言，无需学习成本
  
• 性能卓越，使用简单

=====================================================================================
作者：iseeyou
链接：http://www.zhihu.com/question/25536695/answer/113449098
来源：知乎
著作权归作者所有，转载请联系作者获得授权。

RPC是系统间的一种通信方式，系统间常用的通信方式还有http,webservice，rpc等，一般来讲rpc比http和webservice性能高一些，常见的RPC框架有：thrift，Finagle，dubbo，grpc，json-rpc等。

一个通用的网络RPC框架，它应该包括如下功能：

1.具有服务的分层设计，借鉴Future/Service/Filter概念
2.具有网络的分层设计，区分协议层、数据层、传输层、连接层
3.独立的可适配的codec层，可以灵活增加HTTP，Memcache，Redis，MySQL/JDBC，Thrift等协议的支持。
4.将多年各种远程调用High availability的经验融入在实现中，如负载均衡，failover，多副本策略，开关降级等。
5.通用的远程调用实现，采用async方式来减少业务服务的开销，并通过future分离远程调用与数据流程的关注。
6.具有状态查看及统计功能
7.当然，最终要的是，具备以下通用的远程容错处理能力，超时、重试、负载均衡、failover……

QiuRPC是一个采用JAVA实现的小巧的RPC框架，一共3K多行代码，已在github开源出来，项目地址为： GitHub - i1see1you/QiuRPC: 一个简单的RPC框架，实现了RPC的基本功能，开发者也可以自定义扩展，可以供大家学习探讨或者在小项目中使用，目前QiuRPC具有如下特点：
1. 服务端基于注解，启动时自动扫描所有RPC实现，基本零配置
2. 客户端实现Filter机制，可以自定义Filter
3. 基于netty的Reactor IO多路复用网络模型
4. 数据层提供protobuff和hessian的实现，可以扩展ISerializer接口自定义实现其他
5. 负载均衡算法采用最少活跃调用数算法，可以扩展ILoadBlance接口自定义实现其他
6. 客户端支持服务的同步或异步调用