《转载》RPC入门总结（一）RPC定义和原理

转载：深刻浅出 RPC - 浅出篇

转载：RPC框架与Dubbo完整使用

转载：深刻浅出 RPC - 深刻篇

转载：远程调用服务(RPC)和消息队列(Message Queue)对比及其适用/不适用场合分析

1、RPC

1. RPC是什么

RPC（Remote Procedure Call Protocol）——远程过程调用协议，它是一种经过网络从远程计算机程序上请求服务，而不须要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通讯程序之间携带信息数据。在OSI网络通讯模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，而后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器得到进程参数，计算结果，发送答复信息，而后等待下一个调用信息，最后，客户端调用进程接收答复信息，得到进程结果，而后调用执行继续进行。

2. 为何要用RPC？ 

其实这是应用开发到必定的阶段的强烈需求驱动的。

1. 若是咱们开发简单的单一应用，逻辑简单、用户很少、流量不大，那咱们用不着；

2. 当咱们的系统访问量增大、业务增多时，咱们会发现一台单机运行此系统已经没法承受。此时，咱们能够将业务拆分红几个互不关联的应用，分别部署在各自机器上，以划清逻辑并减少压力。此时，咱们也能够不须要RPC，由于应用之间是互不关联的。
3. 当咱们的业务愈来愈多、应用也愈来愈多时，天然的，咱们会发现有些功能已经不能简单划分开来或者划分不出来。此时，能够将公共业务逻辑抽离出来，将之组成独立的服务Service应用 。而原有的、新增的应用均可以与那些独立的Service应用 交互，以此来完成完整的业务功能。因此此时，咱们急需一种高效的应用程序之间的通信手段来完成这种需求，因此你看，RPC大显身手的时候来了！
其实3描述的场景也是服务化 、微服务 和分布式系统架构 的基础场景。即RPC框架就是实现以上结构的有力方式。

2、RPC的原理和框架

Nelson 的论文中指出实现 RPC 的程序包括 5 个部分：

1. User

2. User-stub

3. RPCRuntime

4. Server-stub

5. Server

这 5 个部分的关系以下图所示

这里 user 就是 client 端，当 user 想发起一个远程调用时，它实际是经过本地调用 user-stub。user-stub 负责将调用的接口、方法和参数经过约定的协议规范进行编码并经过本地的 RPCRuntime 实例传输到远端的实例。远端 RPCRuntime 实例收到请求后交给 server-stub 进行解码后发起本地端调用，调用结果再返回给 user 端。

粗粒度的 RPC 实现概念结构，这里咱们进一步细化它应该由哪些组件构成，以下图所示。

RPC 服务方经过 RpcServer 去导出（export）远程接口方法，而客户方经过 RpcClient 去引入（import）远程接口方法。客户方像调用本地方法同样去调用远程接口方法，RPC 框架提供接口的代理实现，实际的调用将委托给代理RpcProxy 。代理封装调用信息并将调用转交给RpcInvoker 去实际执行。在客户端的RpcInvoker 经过链接器RpcConnector 去维持与服务端的通道RpcChannel，并使用RpcProtocol 执行协议编码（encode）并将编码后的请求消息经过通道发送给服务方。
RPC 服务端接收器 RpcAcceptor 接收客户端的调用请求，一样使用RpcProtocol 执行协议解码（decode）。解码后的调用信息传递给RpcProcessor 去控制处理调用过程，最后再委托调用给RpcInvoker 去实际执行并返回调用结果。以下是各个部分的详细职责：

1.  RpcServer  

   负责导出（export）远程接口  

2.  RpcClient  

   负责导入（import）远程接口的代理实现  

3.  RpcProxy  

   远程接口的代理实现  

4.  RpcInvoker  

   客户方实现：负责编码调用信息和发送调用请求到服务方并等待调用结果返回  

   服务方实现：负责调用服务端接口的具体实现并返回调用结果  

5.  RpcProtocol  

   负责协议编/解码  

6.  RpcConnector  

   负责维持客户方和服务方的链接通道和发送数据到服务方  

7.  RpcAcceptor  

   负责接收客户方请求并返回请求结果  

8.  RpcProcessor  

   负责在服务方控制调用过程，包括管理调用线程池、超时时间等  

9.  RpcChannel  

   数据传输通道  

3、Java中经常使用的RPC框架

目前经常使用的RPC框架以下：

1. Thrift：thrift是一个软件框架，用来进行可扩展且跨语言的服务的开发。它结合了功能强大的软件堆栈和代码生成引擎，以构建在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 这些编程语言间无缝结合的、高效的服务。

2. Dubbo：Dubbo是一个分布式服务框架，以及SOA治理方案。其功能主要包括：高性能NIO通信及多协议集成，服务动态寻址与路由，软负载均衡与容错，依赖分析与降级等。 Dubbo是阿里巴巴内部的SOA服务化治理方案的核心框架，Dubbo自2011年开源后，已被许多非阿里系公司使用。 

3. Spring Cloud：Spring Cloud由众多子项目组成，如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等，提供了搭建分布式系统及微服务经常使用的工具，如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性token、全局锁、选主、分布式会话和集群状态等，知足了构建微服务所需的全部解决方案。Spring Cloud基于Spring Boot, 使得开发部署极其简单。

4、RPC和消息队列的差别

1. 功能差别

在架构上，RPC和Message的差别点是，Message有一个中间结点Message Queue，能够把消息存储。
消息的特色
1. Message Queue把请求的压力保存一下，逐渐释放出来，让处理者按照本身的节奏来处理。
2. Message Queue引入一下新的结点，系统的可靠性会受Message Queue结点的影响。
3. Message Queue是异步单向的消息。发送消息设计成是不须要等待消息处理的完成。
因此对于有同步返回需求，用Message Queue则变得麻烦了。
RPC的特色
同步调用，对于要等待返回结果/处理结果的场景，RPC是能够很是天然直觉的使用方式(RPC也能够是异步调用)。
因为等待结果，Consumer（Client）会有线程消耗。若是以异步RPC的方式使用，Consumer（Client）线程消耗能够去掉。但不能作到像消息同样暂存消息/请求，压力会直接传导到服务Provider。
2. 适用场合差别
1. 但愿同步获得结果的场合，RPC合适。
2. 但愿使用简单，则RPC；RPC操做基于接口，使用简单，使用方式模拟本地调用。异步的方式编程比较复杂。
3. 不但愿发送端（RPC Consumer、Message Sender）受限于处理端（RPC Provider、Message Receiver）的速度时，使用Message Queue。
随着业务增加，有的处理端处理量会成为瓶颈，会进行同步调用到异步消息的改造。这样的改造实际上有调整业务的使用方式。好比原来一个操做页面提交后就下一个页面会看处处理结果；改造后异步消息后，下一个页面就会变成“操做已提交，完成后会获得通知”。
3. 不适用场合说明
1. RPC同步调用使用Message Queue来传输调用信息。 上面分析能够知道，这样的作法，发送端是在等待，同时占用一个中间点的资源。变得复杂了，但没有对等的收益。
2. 对于返回值是void的调用，能够这样作，由于实际上这个调用业务上每每不须要同步获得处理结果的，只要保证会处理便可。（RPC的方式能够保证调用返回即处理完成，使用消息方式后这一点不能保证了。）
3. 返回值是void的调用，使用消息，效果上是把消息的使用方式Wrap成了服务调用（服务调用使用方式成简单，基于业务接口）。

5、RPC框架的核心技术点

RPC框架实现的几个核心技术点：

（1）服务暴露：

远程提供者须要以某种形式提供服务调用相关的信息，包括但不限于服务接口定义、数据结构、或者中间态的服务定义文件。例如Facebook的Thrift的IDL文件，Web service的WSDL文件；服务的调用者须要经过必定的途径获取远程服务调用相关的信息。

目前，大部分跨语言平台 RPC 框架采用根据 IDL 定义经过 code generator 去生成 stub 代码，这种方式下实际导入的过程就是经过代码生成器在编译期完成的。代码生成的方式对跨语言平台 RPC 框架而言是必然的选择，而对于同一语言平台的 RPC 则能够经过共享接口定义来实现。这里的导入方式本质也是一种代码生成技术，只不过是在运行时生成，比静态编译期的代码生成看起来更简洁些。

java 中还有一种比较特殊的调用就是多态，也就是一个接口可能有多个实现，那么远程调用时到底调用哪一个？这个本地调用的语义是经过 jvm 提供的引用多态性隐式实现的，那么对于 RPC 来讲跨进程的调用就无法隐式实现了。若是前面DemoService 接口有 2 个实现，那么在导出接口时就须要特殊标记不一样的实现须要，那么远程调用时也须要传递该标记才能调用到正确的实现类，这样就解决了多态调用的语义问题。

（2）远程代理对象：

服务调用者用的服务实际是远程服务的本地代理。说白了就是经过动态代理来实现。

java 里至少提供了两种技术来提供动态代码生成，一种是 jdk 动态代理，另一种是字节码生成。动态代理相比字节码生成使用起来更方便，但动态代理方式在性能上是要逊色于直接的字节码生成的，而字节码生成在代码可读性上要差不少。二者权衡起来，我的认为牺牲一些性能来得到代码可读性和可维护性显得更重要。

（3）通讯：

RPC框架与具体的协议无关。RPC 可基于 HTTP 或 TCP 协议，Web Service 就是基于 HTTP 协议的 RPC，它具备良好的跨平台性，但其性能却不如基于 TCP 协议的 RPC。

1. TCP/HTTP：众所周知，TCP 是传输层协议，HTTP 是应用层协议，而传输层较应用层更加底层，在数据传输方面，越底层越快，所以，在通常状况下，TCP 必定比 HTTP 快。

2. 消息ID：RPC 的应用场景实质是一种可靠的请求应答消息流，和 HTTP 相似。所以选择长链接方式的 TCP 协议会更高效，与 HTTP 不一样的是在协议层面咱们定义了每一个消息的惟一 id，所以能够更容易的复用链接。

3. IO方式：为了支持高并发，传统的阻塞式 IO 显然不太合适，所以咱们须要异步的 IO，即 NIO。Java 提供了 NIO 的解决方案，Java 7 也提供了更优秀的 NIO.2 支持。

4. 多链接：既然使用长链接，那么第一个问题是到底 client 和 server 之间须要多少根链接？实际上单链接和多链接在使用上没有区别，对于数据传输量较小的应用类型，单链接基本足够。单链接和多链接最大的区别在于，每根链接都有本身私有的发送和接收缓冲区，所以大数据量传输时分散在不一样的链接缓冲区会获得更好的吞吐效率。因此，若是你的数据传输量不足以让单链接的缓冲区一直处于饱和状态的话，那么使用多链接并不会产生任何明显的提高，反而会增长链接管理的开销。
5. 心跳：链接是由 client 端发起创建并维持。若是 client 和 server 之间是直连的，那么链接通常不会中断（固然物理链路故障除外）。若是 client 和 server 链接通过一些负载中转设备，有可能链接一段时间不活跃时会被这些中间设备中断。为了保持链接有必要定时为每一个链接发送心跳数据以维持链接不中断。心跳消息是 RPC 框架库使用的内部消息，在前文协议头结构中也有一个专门的心跳位，就是用来标记心跳消息的，它对业务应用透明。

（4）序列化：

两方面会直接影响 RPC 的性能，一是传输方式，二是序列化。

1. 序列化方式：毕竟是远程通讯，须要将对象转化成二进制流进行传输。不一样的RPC框架应用的场景不一样，在序列化上也会采起不一样的技术。 就序列化而言，Java 提供了默认的序列化方式，但在高并发的状况下，这种方式将会带来一些性能上的瓶颈，因而市面上出现了一系列优秀的序列化框架，好比：Protobuf、Kryo、Hessian、Jackson 等，它们能够取代 Java 默认的序列化，从而提供更高效的性能。

2. 编码内容：出于效率考虑，编码的信息越少越好（传输数据少），编码的规则越简单越好（执行效率高）。以下是编码须要具有的信息：

-- 调用编码 -- 1. 接口方法 包括接口名、方法名 2. 方法参数 包括参数类型、参数值 3. 调用属性 包括调用属性信息，例如调用附件隐式参数、调用超时时间等 -- 返回编码 -- 1. 返回结果 接口方法中定义的返回值 2. 返回码 异常返回码 3. 返回异常信息 调用异常信息 

除了以上这些必须的调用信息，咱们可能还须要一些元信息以方便程序编解码以及将来可能的扩展。这样咱们的编码消息里面就分红了两部分，一部分是元信息、另外一部分是调用的必要信息。若是设计一种 RPC 协议消息的话，元信息咱们把它放在协议消息头中，而必要信息放在协议消息体中。下面给出一种概念上的 RPC 协议消息设计格式：

-- 消息头 --  
magic      : 协议魔数，为解码设计  
header size: 协议头长度，为扩展设计  
version    : 协议版本，为兼容设计  
st         : 消息体序列化类型  
hb         : 心跳消息标记，为长链接传输层心跳设计  
ow         : 单向消息标记，  
rp         : 响应消息标记，不置位默认是请求消息  
status code: 响应消息状态码  
reserved   : 为字节对齐保留  
message id : 消息 id body size : 消息体长度 -- 消息体 -- 采用序列化编码，常见有如下格式 xml : 如 webservie soap json : 如 JSON-RPC binary: 如 thrift; hession; kryo 等 

以上就是RPC的核心技术点，包含内容繁多，下面本博就在学习的基础上以三种RPC框架为例介绍RPC的各项关键技术。