16boke - 一路博客

RPC介绍

什么是RPC

RPC(Remote Procedure Call Protocol)——远程过程调用协议,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。 
简言之,RPC使得程序能够像访问本地系统资源一样,去访问远端系统资源。 
比较关键的一些方面包括,通讯协议,序列化,资源(接口)描述,服务框架,性能,语言支持等。 

稍微总结一下:

1、简单的说,RPC就是从一台机器(客户端)上通过参数传递的方式调用另一台机器(服务器)上的一个函数或方法(可以统称为服务)并得到返回的结果。

2、RPC 会隐藏底层的通讯细节(不需要直接处理Socket通讯或Http通讯)

3、RPC 是一个请求响应模型。客户端发起请求,服务器返回响应(类似于Http的工作方式)

4、RPC 在使用形式上像调用本地函数(或方法)一样去调用远程的函数(或方法)。

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 里面玩,利用java.rmi包实现,基于Java远程方法协议(Java Remote Method Protocol) 和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 甚至支持推送。

  • 具有良好的可扩展性,可以通过过滤器和中间件实现加密、压缩、缓存、代理等各种功能性扩展。

  • 兼容的无差别跨语言调用

  • 支持更多的常用语言和平台

  • 支持浏览器端的跨域调用

  • 没有中间语言,无需学习成本

  • 性能卓越,使用简单

RPC技术及实现简介

一个完整的 RPC 模块需要可以分为三个层次:

  • 服务层(service):RPC 接口定义与实现

  • 协议层(protocol):RPC 报文格式和数据编码格式

  • 传输层(transport):实现底层的通信(如 socket)以及系统相关的功能(如事件循环、多线程)

在实际的大型分布式系统中,不同的服务往往会使用不同的语言来实现,所以一般的 RPC 系统会提供一种跨语言的过程调用功能,比如一段用C++实现的客户端代码可以远程调用一个用 Java 实现的服务。

实现跨语言 RPC 有两种方法:

1、静态代码生成:开发者用一种中间语言(IDL,接口定义语言)来定义 RPC 的接口和数据类型,然后通过一个编译器来生成不同语言的代码(如C++, Java, Python),并由生成的代码来负责 RPC 协议层和传输层的实现。例如,服务的实现用C++,则服务端需要生成实现RPC协议和传输层的C++代码,服务层使用生成的代码来实现与客户端的通信;而如果客户端用 Python,则客户端需要生成Python代码。

2、基于“自省”的动态类型系统来实现:协议和传输层可以只用一种语言实现成一个库,但是这种语言需要关联一个具备“自省”或者反射机制的动态类型系统,对外提供其他语言的绑定,客户端和服务端通过语言绑定来使用 RPC。比如,可以考虑用 C 和 GObject 实现一个 RPC 库,然后通过 GObject 实现其他语言的绑定。

第一种方法的优点是RPC的协议层和传输层的实现不需要和某种动态类型系统(如GObject)绑定在一起,同时避免了动态类型检查和转换,程序效率比较高,但是它的缺点是要为不同语言提供不同的 RPC 协议层和传输层实现。第二种方法的主要难度在于语言绑定和通用的对象串行化机制的实现,同时也需要考虑效率的问题。

RPC  Thrift