聊一聊RPC远程过程调用协议

admin

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

下面我们罗列一下RPC解决方案，当然还有其他的实现方式。

• java原生的 RMI。
• Hessian
  1 k: o4 \/ n7 C# ^
• WebServices
• Restful
• HTTP Request
• RTMP/AMF
• 淘宝的 HSF、Dubbo
  
  

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

        Hessian，原则上说Hessian我并不认为它是一个远程服务框架范畴的东西。我更觉得 Hessian 是一种数据交互格式。就像是 JSON，XML-RPC，AMF，Kryo 一类的东西。Hessian 的优点是大量的兼容平台例如：“IOS、Java、.net、C++、Python、Flash、Ruby、PHP”，其次它的第二个有点是二进制格式。在大对象序列化上会占有很大的优势。百度百科 Hessian是一个轻量级的remoting onhttp工具，使用简单的方法提供了RMI的功能。 相比WebService，Hessian更简单、快捷。采用的是二进制RPC协议，因为采用的是二进制协议，所以它很适合于发送二进制数据。

       WebService，一个老牌技术解决方案。在我印象中 WebServices 是跟随着 SOA 这个东西一起出名的，他有一个最大的好处是防火墙穿透。毕竟人家是靠 80 端口吃饭的，牛叉的很。不过话说回来WebServices的最大要害就是，Xml传输格式。把一个对象序列化成为一个Xml数据是一件很容易的事，但是反序列化成本似乎是很高。再加上 SOAP 协议本身是建立在 XML 形式上，这就使得 Web Service 奇慢无比了。当然因素还有很多我就不多说了。百度百科 Web service是一个平台独立的，低耦合的，自包含的、基于可编程的web的应用程序，可使用开放的XML（标准通用标记语言下的一个子集）标准来描述、发布、发现、协调和配置这些应用程序，用于开发分布式的互操作的应用程序。Web Service技术， 能使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件， 就可相互交换数据或集成。依据Web Service规范实施的应用之间， 无论它们所使用的语言、 平台或内部协议是什么， 都可以相互交换数据。Web Service是自描述、 自包含的可用网络模块， 可以执行具体的业务功能。Web Service也很容易部署， 因为它们基于一些常规的产业标准以及已有的一些技术，诸如标准通用标记语言下的子集XML、HTTP。Web Service减少了应用接口的花费。Web Service为整个企业甚至多个组织之间的业务流程的集成提供了一个通用机制。

         Restful，其实 restful 我更觉得它是一种 API 表述规范。但在社区论坛中讨论看来，restful 的应用似乎也延伸到远程服务的领域。所以有必要说明一下。restful 最初是出现在 web 上，究其本质是还是 HTTP。例如对于：“http://xxxxx/xxxx”这个资源的访问可以利用 HTTP 的“GET、PUT、DELETE”等方法对资源操作加以描述说明。我个人觉得这东西用在 RPC 上并不合适。百度百科  一种软件架构风格，设计风格而不是标准，只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。

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

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

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

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

& p. R9 ~( @% i

       最后说明一下，真正实现分布式服务调用的也就只有“HSF、Dubbo”,貌似当当就是使用的Dubbo 然后自己修改了一下变成了DubboX，其他互联网公司，比如百度 腾讯 京东 就不是很清楚了。还有一点就是如果你想脱离 spring 的话 HSF、Dubbo 会让你失望的，因为基本上所有的配置都是基于Spring。

      上面提到了很多可用的技术方案，想必最后符合要求也就只有其中 HSF 和 Dubbo 了。为什么其它的方案都不入选呢？原因就是它们虽然可以完成 RPC 但是并不支持分布式。当然您可以通过架设集群来提高它们的可靠性，这些都是您需要额外付出的。

      

       不要止步，只要你拥有梦想。

       狄更斯曾说，这是最好的时代，这是最坏的时代；这是智慧的时代，这是愚蠢的时代；这是信仰的时期，这是怀疑的时期；这是光明的季节，这是黑暗的季节；这是希望之春，这是失望之冬；人们面前有着各样事物，人们面前一无所有；人们正在直登天堂，人们正在直下地狱。”士不可以不弘毅，任重而道远，在这个恢宏的时代，让我们来将梦想进行到底！

Smiller_xi

正在看这方面的东西，七总总结的好啊