关于RPC

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

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

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

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

1. 远程过程调用发展历程

  • 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 里面玩。
  • .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 甚至支持推送。
  • 具有良好的可扩展性,可以通过过滤器和中间件实现加密、压缩、缓存、代理等各种功能性扩展。
  • 兼容的无差别跨语言调用
  • 支持更多的常用语言和平台
  • 支持浏览器端的跨域调用
  • 没有中间语言,无需学习成本
  • 性能卓越,使用简单
时间: 2024-08-07 00:06:54

关于RPC的相关文章

下载-深入浅出Netty源码剖析、Netty实战高性能分布式RPC、NIO+Netty5各种RPC架构实战演练三部曲视频教程

下载-深入浅出Netty源码剖析.Netty实战高性能分布式RPC.NIO+Netty5各种RPC架构实战演练三部曲视频教程 第一部分:入浅出Netty源码剖析 第二部分:Netty实战高性能分布式RPC 第三部分:NIO+Netty5各种RPC架构实战演练

网络编程 -- RPC实现原理 -- RPC -- 迭代版本V1 -- 本地方法调用

网络编程 -- RPC实现原理 -- 目录 啦啦啦 V2--RPC -- 本地方法调用:不通过网络 入门 1. RPCObjectProxy rpcObjectProxy = new RPCObjectProxy(new LocalRPCClient()); : 绑定目标对象 2. IUserService userService = (IUserService) rpcObjectProxy.create(IUserService.class); :返回代理类 3. List<User> u

Spring远程服务(RPC)

Spring支持几种不同的RPC模型,包括远程方法调用(RMI).Caucho的Hessian和Burlap和Spring自带的HTTP invoker.如下: 无论选择哪一种RPC模型,我们都会发现Spring对每一种模型都提供了风格一致的支持.在所有的模型中,服务都作为Spring所管理的Bean配置到我们的应用中.这是采用一个代理工厂Bean实现的,这个Bean能够像本地对象一样将远程服务装配到其他Bean的属性中去.它的工作原理如下:

一个入门rpc框架的学习

一个入门rpc框架的学习 参考 huangyong-rpc 轻量级分布式RPC框架 该程序是一个短连接的rpc实现 简介 RPC,即 Remote Procedure Call(远程过程调用),说得通俗一点就是:调用远程计算机上的服务,就像调用本地服务一样. RPC 可基于 HTTP 或 TCP 协议,Web Service 就是基于 HTTP 协议的 RPC, 它具有良好的跨平台性,但其性能却不如基于 TCP 协议的 RPC.会两方面会直接影响 RPC 的性能,一是传输方式,二是序列化. 众所

RPC框架性能基本比较测试

gRPC是Google最近公布的开源软件,基于最新的HTTP2.0协议,并支持常见的众多编程语言. 我们知道HTTP2.0是基于二进制的HTTP协议升级版本,目前各大浏览器都在快马加鞭的加以支持. 我们可以设想一下,未来浏览器支持HTTP2.0,并通过现有开源序列化库比如protobuf等,可以直接和各种语言的服务进行高效交互,这将是多么“美好”的场景! gPRC的Java实现底层网络库是Netty,而且是用到最新的Netty5.0.0.Alpha3的开发版本,因为最新版本针对HTTP/2做了很

python通过protobuf实现rpc

由于项目组现在用的rpc是基于google protobuf rpc协议实现的,所以花了点时间了解下protobuf rpc.rpc对于做分布式系统的人来说肯定不陌生,对于rpc不了解的童鞋可以自行google,这里只是做个简单的介绍.rpc的主要功能是让分布式系统的实现更为简单,为提供强大的远程调用而不损失本地调用语义的简洁性.为了实现这个目标,rpc框架需要提供一种透明调用机制让使用者不必显示区分本地调用还是远程调用.rpc架构涉及的组件如下: 客户方像调用本地方法一样去调用远程接口方法,R

基于protobuf的RPC实现

可以对照使用google protobuf RPC实现echo service一文看,细节本文不再描述. google protobuf只负责消息的打包和解包,并不包含RPC的实现,但其包含了RPC的定义.假设有下面的RPC定义: service MyService { rpc Echo(EchoReqMsg) returns(EchoRespMsg) } 那么要实现这个RPC需要最少做哪些事?总结起来需要完成以下几步: 客户端 RPC客户端需要实现google::protobuf::RpcCh

腾讯正式对外开源高性能 RPC 开发框架与微服务平台Tars

Tars 是将腾讯内部使用的微服务架构 TAF(Total Application Framework)多年的实践成果总结而成的开源项目,目前已于4月10日正式对外开源. 作为支持多语言的高性能 RPC 开发框架和配套一体化的服务治理平台,Tars可以帮助企业或者用户以微服务的方式快速构建稳定可靠的分布式应用,它的设计灵感来源于采取分层思想,实现开发与运营之间的分离.目前该框架在腾讯内部,已经在 160 多个业务(如手机浏览器.应用宝.手机管家.手机QQ.手机游戏等).1.6 多万台服务器上运行

Avro实现RPC

场景:一个客户端,一个服务端(创建两个avro工程).客户端向服务端发送数据,服务端根据算法算出结果,返回给客户端. Http主外,RPC主内.(解决分布式环境下,节点间的数据通信或远程过程调用) 实现步骤 1.创建两个maven工程 2.引入pom文件 3.更改maven工程结构(src/main/avro) 4.创建模式文件(协议文件) 5.根据avro插件生成文件对应的接口类 6.利用API实现rpc 具体实现: 1. 创建两个maven项目,修改jdk版本和编译的版本  1.5->1.7

RPC的发展历史(本质就是双方定义好协议,传递参数后远程调用)

服务器通讯原理就是一台socket服务器A,另一台socket客户端B,现在如果要通讯的话直接以流方式写入或读出. 这样能实现通讯,但有个问题.如何知道更多信息?比如需要发送流大小,编码,Ip等. 这样就有了协议,协议就是规范,就是发送的流中携带了很多的内容. RPC的实现就是一种规范.可参考http://javatar.iteye.com/blog/1123915 这个简单RPC实现. RPC(远程过程调用)是什么 简单的说,RPC就是从一台机器(客户端)上通过参数传递的方式调用另一台机器(服