分布式通信框架-RMI（分布式笔记）

RPC（Remote procedure call protocol）远程过程调用协议

1、什么是RPC

RPC协议（一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议），其实是一个规范。RPC主要解决的两个问题：

1. 解决分布式系统中，服务之间的调用问题。
2. 远程调用时，要能够像本地调用一样方便，让调用者感知不到远程调用的逻辑。

2、为什么要用RPC？

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

1. 如果我们开发简单的单一应用，逻辑简单、用户不多、流量不大，那我们用不着；
2. 当我们的系统访问量增大、业务增多时，我们会发现一台单机运行此系统已经无法承受。此时，我们可以将业务拆分成几个互不关联的应用，分别部署在各自机器上，以划清逻辑并减小压力。此时，我们也可以不需要RPC，因为应用之间是互不关联的。

3. 当我们的业务越来越多、应用也越来越多时，自然的，我们会发现有些功能已经不能简单划分开来或者划分不出来。此时，可以将公共业务逻辑抽离出来，将之组成独立的服务Service应用 。而原有的、新增的应用都可以与那些独立的Service应用 交互，以此来完成完整的业务功能。所以此时，我们急需一种高效的应用程序之间的通讯手段来完成这种需求，所以你看，RPC大显身手的时候来了！

   其实3描述的场景也是服务化、微服务和分布式系统架构的基础场景。即RPC框架就是实现以上结构的有力方式。

3、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.0 支持。
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 等

3、一个RPC框架包含的要素

4、RPC vs Restful

其实这两者并不是一个维度的概念，总得来说RPC涉及的维度更广。如果硬要比较，那么可以从RPC风格的url和Restful风格的url上进行比较。比如你提供一个查询订单的接口，用RPC风格，你可能会这样写：/queryOrder?orderId=123

用Restful风格呢？Get /order?orderId=123

RPC是面向过程，Restful是面向资源，并且使用了Http动词。从这个维度上看，Restful风格的url在表述的精简性、可读性上都要更好。

5、RPC vs RMI

严格来说这两者也不是一个维度的。RMI是Java提供的一种访问远程对象的协议，是已经实现好了的，可以直接用了。而RPC呢？人家只是一种编程模型，并没有规定你具体要怎样实现，你甚至都可以在你的RPC框架里面使用RMI来实现数据的传输，比如Dubbo：Dubbo - rmi协议。

RMI的概述

1、什么是RMI

RMI(remote method invocation) , 可以认为是RPC的java版实现，只能支持Java语言，RMI使用的是JRMP（Java Remote Messageing Protocol）Java远程信息交换协议, JRMP是专门为java定制的分布式通信解决方案

2、如何实现一个RMI程序

1. 创建远程接口， 并且继承java.rmi.Remote接口
2. 实现远程接口，并且继承：UnicastRemoteObject
3. 创建服务器程序： createRegistry方法注册远程对象
4. 创建客户端程序

自己实现一个简单的RMI

1、RMI工作原理

方法调用从客户对象经占位程序（Stub)、远程引用层(Remote Reference Layer)和传输层（Transport Layer）向下，传递给主机，然后再次经传 输层，向上穿过远程调用层和骨干网（Skeleton），到达服务器对象。 占位程序扮演着远程服务器对象的代理角色，使该对象可被客户激活。 远程引用层处理语义、管理单一或多重对象的通信，决定调用是应发往一个服务器还是多个。传输层管理实际的连接，并且追踪可以接受方法调用的远程对象。服务器端的骨干网完成对服务器对象实际的方法调用，并获取返回值。返回值向下经远程引用层、服务器端的传输层传递回客户端，再向上经传输层和远程调用层返回。最后，占位程序获得返回值。 要完成以上步骤需要有以下几个步骤：

1. 生成一个远程接口
2. 实现远程对象(服务器端程序)
3. 生成占位程序和骨干网(服务器端程序)
4. 编写服务器程序
5. 编写客户程序
6. 注册远程对象
7. 启动远程对象

2、RMI 应用各个类的交互时序图

3、实现思路

1. 编写服务器程序，暴露一个监听， 可以使用ServerSocket
2. 编写客户端程序，通过ip和端口连接到指定的服务器，并将数据序列化 传递给服务器
3. 服务器端收到数据，先反序列化，再进行业务逻辑处理，最后把处理结果序列化并返回