远程过程调用协议（RPC）

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

1、Java原生的 RMI。

2、Hessian

3、WebServices

4、Restful

5、HTTP Request

6、RTMP/AMF

7、淘宝的 HSF、Dubbo

 1）RMI

       RMI，缺点是速度太慢。优处是Java原生，使用 RMI 不需要引入其它任何第三方软件包。RMI(Remote Method Invocation，远程方法调用)是用Java在JDK1.2中实现的，它大大增强了Java开发分布式应用的能力。Java作为一种风靡一时的网络开发语言，其巨大的威力就体现在它强大的开发分布式网络应用的能力上，而RMI就是开发百分之百纯Java的网络分布式应用系统的核心解决方案之一。其实它可以被看作是RPC的Java版本。但是传统RPC并不能很好地应用于分布式对象系统。而Java RMI 则支持存储于不同地址空间的程序级对象之间彼此进行通信，实现远程对象之间的无缝远程调用。

2）Hessian

        Hessian，原则上说Hessian我并不认为它是一个远程服务框架范畴的东西。我更觉得 Hessian 是一种数据交互格式。就像是 JSON，XML-RPC，AMF，Kryo 一类的东西。Hessian 的优点是大量的兼容平台例如：“IOS、Java、.net、C++、Python、Flash、Ruby、PHP”，其次它的第二个有点是二进制格式。在大对象序列化上会占有很大的优势。

3）WebService

        WebService，一个老牌技术解决方案。在我印象中 WebServices 是跟随着 SOA（面向服务架构） 这个东西一起出名的，他有一个最大的好处是防火墙穿透。毕竟人家是靠 80 端口吃饭的，牛叉的很。不过话说回来WebServices的最大要害就是，Xml传输格式，把一个对象序列化成为一个Xml数据是一件很容易的事，但是反序列化成本似乎是很高。再加上 SOAP 协议本身是建立在 XML 形式上，这就使得 Web Service 奇慢无比了。当然因素还有很多我就不多说了。

4）Restful

         Restful，其实 restful 我更觉得它是一种 API 表述规范。但在社区论坛中讨论看来，restful 的应用似乎也延伸到远程服务的领域。所以有必要说明一下。restful 最初是出现在 web 上，究其本质是还是 HTTP。例如对于：“http://xxxxx/xxxx”这个资源的访问可以利用 HTTP 的“GET、PUT、DELETE”等方法对资源操作加以描述说明。我个人觉得这东西用在 RPC 上并不合适。

5）HTTP

        HTTP，这是我用过最多的一种远程交互方式。远离很见dna，服务发布者将服务发布成为一个http资源。调用者请求这个http资源。数据传输格式完全程序双方自行协商。这种方法简单粗暴行之有效。缺点：自己补充通信协议，例如请求参数和响应数据格式。常规的交互格式有 JSON、XML。

6）RTMP/AMF

        RTMP/AMF，这个组合的确是一套很完善的远程调用解决方案。RTMP协议中专门为 Invoke 开辟了一条通道，在配合 AMF 格式极大的方便了 Flash 下远程服务访问。不过这些都是 Flash下的东西，即使是拥有 Red5 这样的神器让我们在 java 下可以使用 rtmp 但是究其目的还是为了和 flash 通信。一般 flash 调用业务系统的方式还都停留在 http 请求或者通过 red5 服务器代为转发。

7）HSF

       HSF，这个东西是淘宝内部用的很广泛的远程服务框架。它是使用NIO、Mina 并且工作在长连接模式下。话说这个东西的确是个好东西，淘宝也将其开源了！只可惜，开源了 hsf 但是相关配套依赖没有开源。在加上 hsf 依赖繁杂。这个东西也就只能让局外人膜拜一下，在淘系之外的同学们是无福享受了。

8）Dubbo

        Dubbo 也是Alibaba开源的分布式服务框架，它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。关于注册中心、协议支持、服务监控等内容。它比较 HSF 来说要轻巧很多，依赖会少一些。

        注意：真正实现分布式服务调用的也就只有“HSF、Dubbo”。还有一点就是如果你想脱离 Spring 的话 HSF、Dubbo 会让你失望的，因为基本上所有的配置都是基于Spring。上面提到了很多可用的技术方案，想必最后符合要求也就只有其中 HSF 和 Dubbo 了。为什么其它的方案都不入选呢？原因就是它们虽然可以完成 RPC 但是并不支持分布式。当然可以通过架设集群来提高它们的可靠性，这些都是需要额外付出的。

RPC 是一个“请求-响应”协议：

客户端程序── 调用客户端存根 Stub 程序。就像调用本地方法一样，参数会被压入栈中。

客户端 Stub 程序── 将请求过程的 ID 和参数打包进请求信息中。

客户端通信模块── 将信息从客户端发送至服务端。

服务端通信模块── 将接受的包传给服务端存根 Stub 程序。

服务端 Stub 程序── 将结果解包，依据过程 ID 调用服务端方法并将参数传递过去。

        请求消息的结构：

1、接口名称

2、方法名，形式：class_name.method_name

3、参数类型及参数值

4、超时时间

5、requestID：由 Client Stub 生成，用于唯一标识一个请求，Client 调用方法后将回调对象 Callback 存放到全局ConcurrentHashMap里，形式<requestID, Callback>。Server 处理完请求后，将requestID放到 response 里返回给 Client，Client 通过requestID找到对应的 Callback。

通过代理机制实现透明化的 RPC：

怎么封装通信细节才能让用户像以本地调用方式调用远程服务呢？对 Java 来说就是使用代理：

1、字节码生成

2、动态代理 JDK

例如：

TestServicets=(TestService)RPCProxyClient.getProxy(TestService.class);

ts.do();

消息编码&消息解码：

消息编码：序列化

消息解码：反序列化

通信：

       现在在 linux 平台上，大家基本都使用 epoll 模型。这个是非阻塞的事件驱动模型，能够根据请求事件来触动业务逻辑。所以具有很强的负载能力。现在主流的服务器，比如：nginx、mina、netty等等，都基本采用这种底层模型。

PRC 优缺点

       RPC 专注于暴露方法。RPC 通常用于处理内部通讯的性能问题，这样你可以手动处理本地调用以更好的适应你的情况。

       遵循REST的 HTTP API 往往更适用于公共 API。

RPC缺点：

1、RPC 客户端与服务实现捆绑地很紧密。

2、一个新的 API 必须在每一个操作或者用例中定义。

3、RPC 很难调试。

4、你可能没办法很方便的去修改现有的技术。

RPC 与 WebService

WebService主要有两种形式：

REST：基于 XML 格式，基于 HTTP 协议。

SOAP：可以基于不同的格式 JSON, XML，基于 HTTP 协议。

       可以看出，WebService 都是基于 HTTP 协议。HTTP 接口由于受限于 HTTP 协议，需要带 HTTP 请求头，导致传输起来效率或者说安全性不如 RPC。

RPC：

       RPC可以通过 HTTP 来实现,也可以通过 Socket 自己实现一套协议来实现.RPC框架一般都有注册中心，有:

1、丰富的监控管理

2、发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作

3、安全性

4、服务化架构、服务化治理，RPC 框架是一个强力的支撑

RPC 与 RMI

RPC：

跨语言，不支持对象的概念

RMI：

只支持 Java，支持 Java 对象及基本数据结构

转自链接：https://www.jianshu.com/p/961304dddb3e