首页天道酬勤java rpc框架,thrift rpc框架

java rpc框架,thrift rpc框架

张世龙 05-13 12:00 129次浏览

一、概述二、RPC 2.1、RPC定义2.2、RPC主要组成部分三、影响RPC框架性能的因素四、工业界如何选择RPC框架一览表4.1、国内4.2、国外五、RPC框架

一.概述

随着公司规模的扩大和业务量的激增,单机APP应用演化为服务/微服务的体系结构模式,服务间的调用往往通过rpc方式调用,或通过消息队列方式解除耦合。 大多数大型制造商要么创建自己的rpc框架,要么根据著名的rpc框架进行改造。

目前,rpc框架主要沿着两条路线发展。 一种是目标跨语言,服务端可以用不同的语言实现,客户端也可以用不同的语言实现,用不同语言实现的客户端和服务器端可以相互调用。 显然,要支持不同的语言,需要一个基于该语言实现相同协议的框架。 此外,协议设计也应该是跨语言进行的。 其中典型的是grpc,它可以基于相同的IDL生成不同语言的代码,对语言的支持也非常多。

另一个rpc框架发展的目标是支持服务治理,主要集中在服务发现、路由、容错处理等方面,主要围绕一种语言的开发,调用第三方曲折的服务作为代表,比较早的开源框架是阿里巴巴的dubbo。

一些rpc框架协议处理从一开始就没有考虑到的不同语言。 其中一些使用特定于语言的属性,如Java的object inputstream/object output stream、谷歌的Gob等。 在协议设计中,考虑到通用性,有些将JSON或Protobuffer序列化为数据。

在一些框架中,基于TCP的二进制流的数据传输、基于http的请求/响应模型的请求、基于http2的流以及受信任的UDP (例如quic和kcp )的数据传输

一些生态圈框架,如网关、代理,一些rpc框架自然支持API网关负载平衡。

二、RPC 2.1、RPC定义RPC(Remote Procedure Call Protocol)远程过程调用协议。一个通俗的描述是:客户端在不知道调用细节的情况下,调用存在于远程计算机上的某个对象,就像调用本地应用程序中的对象一样正式说明是在不了解基本网络技术的情况下通过网络从远程计算机程序请求服务的协议。 那么,至少从这样的说明中引出几个要点:

RPC是协议:既然达成协议,那么这只是一个规范,必须有人根据该规范实现。 当前典型的RPC实现是Dubbo、Thrift、GRPC、Hetty等。 在此说明,从当前技术的发展趋势来看,实现RPC协议的实用程序往往附加其他重要功能。 例如,Dubbo还包括服务治疗等功能。

33558 www.Sina.com/:既然RPC客户端认为自己正在调用本地对象。 您不需要在意传输层是使用TCP/UDP、HTTP协议还是其他网络协议。 由于网络协议是透明的,因此您不必在意在调用过程中使用的是哪个网络IO模型调用方。

网络协议和网络IO模型对其透明:我们知道在本地APP应用程序中,调用对象需要传递一些参数,然后返回调用结果。 对于如何在调用的对象内部使用这些参数和计算处理结果,调用方不需要在意。 在中,对于远程调用,这些参数以一种信息格式传递到网络上的另一台计算机。 调用方不需要在意这种信息格式是如何配置的。

信息格式对其透明呼叫方也不知道远程服务器的APP应用程序实际上是以哪种语言运行的。 在中,对于调用方来说,无论服务器端使用何种语言,这次调用都必须成功,返回值也必须以调用方程序语言能够理解的形式编写。

上面的说明可以用下图表示。

2.2、RPC的主要组成部分当然,上图是作为RPC的调用方观察到的现象(但实际上客户端需要或多或少知道调用RPC的细节)。 但是,我们要说明RPC的基本概念,所以必须明确RPC协议内部发生了什么。

应该有跨语言能力:RPC协议的调用方。 如上所述,RPC客户端在完全不知道RPC框架的存在的情况下启动远程服务调用是理想的。 但实际上,客户端需要指定RPC框架的详细信息。

33558 www.Sina.com/:在RPC规范中,此服务器不是提供RPC服务器IP、端口侦听的模块。 是远程服务方法的具体实现。 在JAVA中是RPC服务接口的具体实现。 其中的代码是最常见的业务相关代码,甚至其接口实现类本身也不知道它是从RPC远程客户端调用的。

http://www.Sina.com/: http://www.Sina.com /

C框架中的“代理”层来处理的。

Message Protocol:在上文我们已经说到,一次完整的client-server的交互肯定是携带某种两端都能识别的,共同约定的消息格式。RPC的消息管理层专门对网络传输所承载的消息信息进行编码和解码操作。目前流行的技术趋势是不同的RPC实现,为了加强自身框架的效率都有一套(或者几套)私有的消息格式。

Transfer/Network Protocol传输协议层负责管理RPC框架所使用的网络协议、网络IO模型。例如Hessian的传输协议基于HTTP(应用层协议);而Thrift的传输协议基于TCP(传输层协议)。传输层还需要统一RPC客户端和RPC服务端所使用的IO模型;

Selector/Processor:存在于RPC服务端,用于服务器端某一个RPC接口的实现的特性(它并不知道自己是一个将要被RPC提供给第三方系统调用的服务)。所以在RPC框架中应该有一种“负责执行RPC接口实现”的角色。包括:管理RPC接口的注册、判断客户端的请求权限、控制接口实现类的执行在内的各种工作。

IDL:实际上IDL(接口定义语言)并不是RPC实现中所必须的。但是需要跨语言的RPC框架一定会有IDL部分的存在。这是因为要找到一个各种语言能够理解的消息结构、接口定义的描述形式。如果您的RPC实现没有考虑跨语言性,那么IDL部分就不需要包括,例如JAVA RMI因为就是为了在JAVA语言间进行使用,所以JAVA RMI就没有相应的IDL。

一定要说明一点,不同的RPC框架实现都有一定设计差异。例如生成Stub的方式不一样,IDL描述语言不一样、服务注册的管理方式不一样、运行服务实现的方式不一样、采用的消息格式封装不一样、采用的网络协议不一样。但是基本的思路都是一样的,上图中的所列出的要素也都是具有的。

三、影响RPC框架性能的因素

在物理服务器性能相同的情况下,以下几个因素会对一款RPC框架的性能产生直接影响:

使用的网络IO模型:RPC服务器可以只支持传统的阻塞式同步IO,也可以做一些改进让RPC服务器支持非阻塞式同步IO,或者在服务器上实现对多路IO模型的支持。这样的RPC服务器的性能在高并发状态下,会有很大的差别。特别是单位处理性能下对内存、CPU资源的使用率。

基于的网络协议:一般来说您可以选择让您的RPC使用应用层协议,例如HTTP或者HTTP/2协议,或者使用TCP协议,让您的RPC框架工作在传输层。工作在哪一层网络上会对RPC框架的工作性能产生一定的影响,但是对RPC最终的性能影响并不大。但是至少从各种主流的RPC实现来看,没有采用UDP协议做为主要的传输协议的。

消息封装格式:选择或者定义一种消息格式的封装,要考虑的问题包括:消息的易读性、描述单位内容时的消息体大小、编码难度、解码难度、解决半包/粘包问题的难易度。当然如果您只是想定义一种RPC专用的消息格式,那么消息的易读性可能不是最需要考虑的。消息封装格式的设计是目前各种RPC框架性能差异的最重要原因,这就是为什么几乎所有主流的RPC框架都会设计私有的消息封装格式的原因。dubbo中消息体数据包含dubbo版本号、接口名称、接口版本、方法名称、参数类型列表、参数、附加信息

Schema 和序列化(Schema & Data Serialization):序列化和反序列化,是对象到二进制数据的转换,程序是可以理解对象的,对象一般含有 schema 或者结构,基于这些语义来做特定的业务逻辑处理。考察一个序列化框架一般会关注以下几点:
Encoding format 。是 human readable(是否能直观看懂 json) 还是 binary(二进制)。
Schema declaration 。也叫作契约声明,基于 IDL,比如 Protocol Buffers/Thrift,还是自描述的,比如 JSON、XML。另外还需要看是否是强类型的。
语言平台的中立性 。比如 Java 的 Native Serialization 就只能自己玩,而 Protocol Buffers 可以跨各种语言和平台。
新老契约的兼容性 。比如 IDL 加了一个字段,老数据是否还可以反序列化成功。
和压缩算法的契合度 。跑 benchmark (基准)和实际应用都会结合各种压缩算法,例如 gzip、snappy。
性能 。这是最重要的,序列化、反序列化的时间,序列化后数据的字节大小是考察重点。
序列化方式非常多,常见的有 Protocol Buffers, Avro,Thrift,XML,JSON,MessagePack,Kyro,Hessian,Protostuff,Java Native Serialize,FST 。

实现的服务处理管理方式:在高并发请求下,如何管理注册的服务也是一个性能影响点。您可以让RPC的Selector/Processor使用单个线程运行服务的具体实现(这意味着上一个客户端的请求没有处理完,下一个客户端的请求就需要等待)、您也可以为每一个RPC具体服务的实现开启一个独立的线程运行(可以一次处理多个请求,但是操作系统对于“可运行的最大线程数”是有限制的)、您也可以线程池来运行RPC具体的服务实现(目前看来,在单个服务节点的情况下,这种方式是比较好的)、您还可以通过注册代理的方式让多个服务节点来运行具体的RPC服务实现。

四、工业界的 RPC 框架一览 4.1、国内

Dubbo 。来自阿里巴巴 http://dubbo.I/O/
Motan 。新浪微博自用 https://github.com/weibocom/motan
Dubbox 。当当基于 dubbo 的 https://github.com/dangdangdotcom/dubbox
rpcx 。基于 Golang 的 https://github.com/smallnest/rpcx

4.2、国外

Thrift from facebook https://thrift.apache.org
Avro from hadoop https://avro.apache.org
Finagle by twitter https://twitter.github.I/O/finagle
gRPC by Google http://www.grpc.I/O (Google inside use Stuppy)
Hessian from cuacho http://hessian.caucho.com
Coral Service inside amazon (not open sourced)
上述列出来的都是现在互联网企业常用的解决方案,暂时不考虑传统的 SOAP,XML-RPC 等。这些是有网络资料的,实际上很多公司内部都会针对自己的业务场景,以及和公司内的平台相融合(比如监控平台等),自研一套框架,但是殊途同归,都逃不掉刚刚上面所列举的 RPC 的要考虑的各个部分。

五、如何选择RPC框架

选择一个rpc框架会基于多方面的考虑: 框架特性、性能、成熟度、技术支持、社区活跃度等多个方面。最重要一点,这也是往往很多技术人员进入的误区,“对于技术,不要为了使用而使用,用最简单合适的技术实现解决问题才是正道”。架构是服务于业务的,能快速方便的满足业务需求的架构才是好的架构。没有最好的,只有适合自己的。

rpc属于哪个层的协议,rpc框架有哪些 为什么要用rabbitmq,springboot netty