远程过程调用(Remote Procedure Call,缩写为 RPC)是一个计算机通信协议。
该协议允许运行于一台计算机的程序调用另一台计算机的子程序,而程序员无需额外地为这个交互作用编程。
远程过程调用是一个分布式计算的客户端-服务器(Client/Server) ,简单而又广受欢迎。
远程过程调用总是由客户端对服务器发出一个执行若干过程请求,并用客户端提供的参数。执行结果将返回给客户端。
类似远程访问或者web请求差不多,都是一个client向远端服务器请求服务返回结果,但是web请求使用的网络协议是http高层协议,而rpc所使用的协议多为TCP,是网络层协议,减少了信息的包装,加快了处理速度。
由于存在各式各样的变体和细节差异,对应地派生了各式远程过程调用协议,而且它们并不互相兼容。为了允许不同的客户端均能访问服务器,许多标准化的 RPC 系统应运而生了。其中大部分采用接口描述语言(Interface Description Language,IDL),方便跨平台的远程过程调用。
RPC 本身是 client-server模型,也是一种request-response 协议【请求-应答】。
注意:
RPC只是描绘了 Client 与 Server 之间的点对点调用流程,包括 stub(存根)、通信、RPC 消息解析等部分,在实际应用中,还需要考虑服务的高可用、负载均衡等问题,所以产品级的 RPC 框架除了点对点的 RPC 协议的具体实现外,还应包括服务的发现与注销、提供服务的多台Server 的负载均衡、服务的高可用等更多的功能。
目前的 RPC 框架大致有两种不同的侧重方向,一种偏重于服务治理,另一种偏重于跨语言调用。
RPC侧重方向 | 常见RPC | 特点 | 缺点 |
---|---|---|---|
服务治理型RPC | Alibab Dubbo、Motan 等 | 功能丰富,提供高性能的远程调用以及服务发现和治理功能,适用于大型服务的微服务化拆分以及管理,对于特定语言(Java)的项目可以十分友好的透明化接入。 | 语言耦合度较高,跨语言支持难度较大。 |
跨语言调用型RCP | Thrift、gRPC、rpcx等 | 关注于服务的跨语言调用,能够支持大部分的语言进行语言无关的调用,非常适合于为不同语言提供通用远程服务的场景 。 | 没有服务发现相关机制,实际使用时一般需要代理层进行请求转发和负载均衡策略控制。 |
Dubbo 是阿里巴巴公司开源的一个Java高性能优秀的服务框架,使得应用可通过高性能的 RPC 实现服务的输出和输入功能,可以和 Spring框架无缝集成。Dubbo由于跟淘宝另一个类似的框架HSF(非开源)有竞争关系,导致dubbo团队已经解散;在电商圈如当当 (dubbox)、京东、国美维护了自己的分支或者在dubbo的基础开发,但是官方的实现缺乏维护,其它电商虽然维护了自己的版本,但是还是不能做大的架构的改动和提升,相关的依赖类比如Spring,Netty还是很老的版本(Spring 3.2.16.RELEASE, netty3.2.5.Final),而且Dubbo的代码结构过于复杂。
Motan是新浪微博开源的一个Java 框架。它诞生的比较晚,起于2013年,2016年5月开源。Motan 在微博平台中已经广泛应用,每天为数百个服务完成近千亿次的调用。Motan的架构相对简单,功能也能满足微博内部架构的要求,虽然Motan的架构的目的主要不是跨语言,但是目前也在开发支持php client和C server特性。
Thrift是Apache的一个跨语言的高性能的服务框架,也得到了广泛的应用。它的功能类似 gRPC, 支持跨语言,不支持服务治理。
gRPC是Google开发的高性能、通用的开源RPC框架,其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计,基于ProtoBuf(Protocol Buffers)序列化协议开发,且支持众多开发语言。目标是跨语言开发,支持多种语言, 服务治理方面需要自行实现,所以实现一个综合的产品级的分布式RPC平台还需要扩展开发,Google内部使用的也不是gRPC,而是Stubby。
rpcx 是一个分布式的Go语言的 RPC 框架,支持Zookepper、etcd、consul多种服务发现方式,多种服务路由方式, 是目前性能最好的 RPC 框架之一。
RPC 的消息传输可以通过 TCP、UDP 或者 HTTP等,所以称之为 RPC over TCP、 RPC over HTTP。RPC 通过 HTTP 传输消息的时候和 RESTful的架构是类似的,但也有不同。
RPC over HTTP | RESTful |
---|---|
RPC 的客户端和服务器端是紧耦合的,客户端需要知道调用的过程的名字,过程的参数以及它们的类型、顺序等。一旦服务器更改了过程的实现,客户端的实现很容易出问题。 | RESTful基于HTTP的语义操作资源,参数的顺序一般没有关系,也很容易的通过代理转换链接和资源位置,故而RESTful 更灵活。 |
RPC 操作的是方法和过程,要操作的是方法对象。 | RESTful 操作的是资源(resource),而不是方法。 |
RPC提供方法调用,如果实现一个特定目的的操作,比如为名字姓张的学生的数学成绩都加上10这样的操作,可以实现一个 Student.Increment(Name, Score) 的方法供客户端调用。 | RESTful执行的是对资源的操作,增加、查找、修改和删除等,主要是CURD,如果实现一个特定目的的操作,比如为名字姓张的学生的数学成绩都加上10这样的操作,RESTful的API设计起来就不是那么直观或者有意义。 |
RPC over TCP | RESTful |
---|---|
通过长连接减少建立简介产生的资源消耗,高并发场合愈发重要。 | 通过在请求头中设置Connection: keep-alive实现长连接****,request-response模型阻塞严重,必须等前一个请求发送并完成响应后,才能发送后续请求,即使在HTTP1.1中使用了Pipeline管线化技术,依然是一个串行化的方案,且服务器端开启Pipeline管线化很可能并不会带来大幅度的性能提升,而且服务器端和代理程序对管线化的支持并不好,非标配,除非升级到HTTP2, RPC的实现没有这个限制。 |
采用TCP通讯协议,是传输层的通信协议,效率和性能高于应用层协议,普遍用于微服务架构的服务之间的通讯 | RESTful基于HTTP,是应用层协议,基于传输层协议之上,效率和性能比传输层的协议要低 |
版权说明 : 本文为转载文章, 版权归原作者所有 版权申明
原文链接 : https://blog.csdn.net/qq_43842093/article/details/121667562
内容来源于网络,如有侵权,请联系作者删除!