我是靠谱客的博主 活力大地,最近开发中收集的这篇文章主要介绍RPC和HTTP一、为什么需要RPC,而不是简单的HTTP接口?二、RPC三、自定义RPC框架范例四、HTTP五、总结,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

一、为什么需要RPC,而不是简单的HTTP接口?

  RPC(即Remote Procedure Call,远程过程调用主要是基于TCP/IP协议;而HTTP服务主要是基于HTTP协议的。我们都知道HTTP协议是在传输层协议TCP之上的,所以效率来看的话,RPC当然是要更胜一筹啦!下面来具体说一说RPC服务和HTTP服务。

二、RPC

  从四个角度来介绍RPC服务:分别是RPC架构,RPC调用过程,同步异步调用以及流行的RPC框架。

1、RPC架构

  一个完整的RPC架构里面包含了四个核心的组件,分别是Client 、Server、Client Stub、Server Stub,这个Stub大家可以理解为存根。分别说说这几个组件:

  • 客户端(Client),服务的调用方。
  • 服务端(Server),真正的服务提供者。
  • 客户端存根(Client Stub),存放服务端的地址消息再将客户端的请求参数打包成网络消息,然后通过网络远程发送给服务方
  • 服务端存根(Server Stub),接收客户端发送过来的消息,将消息解包,并调用本地的方法  

  

  RPC主要是用在大型企业里面,因为大型企业里面系统繁多,业务线复杂,而且效率优势非常重要的一块,这个时候RPC的优势就比较明显了。实际的开发当中是这么做的,项目一般使用maven来管理。比如我们有一个处理订单的系统服务,先声明它的所有的接口(这里就是具体指Java中的interface),然后将整个项目打包为一个jar包,服务端这边引入这个二方库,然后实现相应的功能,客户端这边也只需要引入这个二方库即可调用了。为什么这么做?主要是为了减少客户端这边的jar包大小,因为每一次打包发布的时候,jar包太多总是会影响效率。另外也是将客户端和服务端解耦,提高代码的可移植性。

2、RPC调用过程

(1) 客户端(client)以本地调用方式(即以接口的方式)调用服务;

(2) 客户端存根(client stub)接收到调用后,负责将方法、参数等组装成能够进行网络传输的消息体(将消息体对象序列化为二进制);

(3) 客户端通过sockets将消息发送到服务端;

(4) 服务端存根( server stub)收到消息后进行解码(将消息对象反序列化)

(5) 服务端存根( server stub)根据解码结果调用本地的服务

(6) 本地服务执行并将结果返回给服务端存根( server stub);

(7) 服务端存根( server stub)将返回结果打包成消息(将结果消息对象序列化)

(8) 服务端(server)通过sockets将消息发送到客户端;

(9) 客户端存根(client stub)接收到结果消息,并进行解码(将结果消息发序列化);

(10) 客户端(client)得到最终结果。

RPC的目标是要把2、3、4、7、8、9这些步骤都封装起来。

注意:无论是何种类型的数据,最终都需要转换成二进制流在网络上进行传输,数据的发送方需要将对象转换为二进制流,而数据的接收方则需要把二进制流再恢复为对象。

 3、同步调用与异步调用

  什么是同步调用?什么是异步调用?同步调用就是客户端等待调用执行完成并返回结果异步调用就是客户端不等待调用执行完成返回结果,不过依然可以通过回调函数等接收到返回结果的通知。如果客户端并不关心结果,则可以变成一个单向的调用。这个过程有点类似于Java中的callablerunnable接口,我们进行异步执行的时候,如果需要知道执行的结果,就可以使用callable接口,并且可以通过Future类获取到异步执行的结果信息。如果不关心执行的结果,直接使用runnable接口就可以了,因为它不返回结果,当然啦,callable也是可以的,我们不去获取Future就可以了。

4、流行的RPC框架

     目前流行的开源RPC框架还是比较多的。下面重点介绍三种:

  (1)gRPC是Google公布的开源软件,基于最新的HTTP2.0协议,并支持常见的众多编程语言。 我们知道HTTP2.0是基于二进制的HTTP协议升级版本,目前各大浏览器都在快马加鞭的加以支持。 这个RPC框架是基于HTTP协议实现的,底层使用到了Netty框架的支持

  (2)Thrift是Facebook的一个开源项目,主要是一个跨语言的服务开发框架。它有一个代码生成器来对它所定义的IDL定义文件自动生成服务代码框架。用户只要在其之前进行二次开发就行,对于底层的RPC通讯等都是透明的。不过这个对于用户来说的话需要学习特定领域语言这个特性,还是有一定成本的。

  (3)Dubbo是阿里集团开源的一个极为出名的RPC框架,在很多互联网公司和企业应用中广泛使用。协议和序列化框架都可以插拔是及其鲜明的特色。同样的远程接口是基于Java Interface,并且依托于spring框架方便开发。可以方便的打包成单一文件,独立进程运行,和现在的微服务概念一致。

三、自定义RPC框架范例

与1.3架构图相比较,rpc-sample-client相当于client-functions,通过接口方法发起请求;而rpc-client相当于client-stub,负责把方法和参数序列化并发送给查找到的服务器。rpc-server相当于server stub,负责把客户端发送过来的消息反序列化,并通过反射调用本地服务,再把本地服务返回的结果序列化发送给客户端;rpc-sample-server则相当于server-functions,提供本地服务并返回得出的结果给rpc-server。rpc-client等待接收rpc-server返回的结果,并将结果反序列化,再把反序列化最终得到的结果返回给rpc-sample-client。

rpc-common提供基于netty的序列化与反序列化方法,并封装rpc请求和rpc响应,序列化和反序列的对象就是封装好的RpcRequest和RpcResponse。rpc-registry则是基于zookeeper设计的分布式服务器动态上下线通知的应用程序,通过rpc-registry可以查找服务器或者注册服务器,用于均衡负载。

rpc-client与rpc-server之间的通信是基于netty的,netty底层也是sockets设计,但是效率比sockets高。

四、HTTP

  其实在很久以前,我对于企业开发的模式一直定性为HTTP接口开发,也就是我们常说的restful风格的服务接口。的确,对于在接口不多、系统与系统交互较少的情况下,解决信息孤岛初期常使用的一种通信手段;优点就是简单、直接、开发方便。利用现成的http协议进行传输。我们记得之前本科实习在公司做后台开发的时候,主要就是进行接口的开发,还要写一大份接口文档,严格地标明输入输出是什么?说清楚每一个接口的请求方法,以及请求参数需要注意的事项等。比如下面这个例子:POST http://www.httpexample.com/restful/buyer/info/share
  接口可能返回一个JSON字符串或者是XML文档。然后客户端再去处理这个返回的信息,从而可以比较快速地进行开发。但是对于大型企业来说,内部子系统较多、接口非常多的情况下,RPC框架的好处就显示出来了,首先就是长链接,不必每次通信都要像http一样去3次握手什么的,减少了网络开销;其次就是RPC框架一般都有注册中心,有丰富的监控管理;发布、下线接口、动态扩展等,对调用方来说是无感知、统一化的操作

五、总结

       目前有很多Java的RPC框架,有基于Json的,有基于XML,也有基于二进制对象的。

       论复杂度,RPC框架肯定是高于简单的HTTP接口的。但毋庸置疑,HTTP接口由于受限于HTTP协议,需要带HTTP请求头, 导致传输起来效率或者说安全性不如RPC。(RPC 本身是一种框架,而http 是应用层的协议

       现在问题是,遇到怎样的瓶颈了才需要或者说更适合用RPC(比如像阿里这么大的请求并发量,简单的HTTP肯定达不到预期),但问题是大家所在的公司,要有像阿里这么大的量是比较少的,甚至说1/1000的量可能都没有,那我们还需要使用RPC吗?

       技术应该不是为了使用新技术而去使用,而应该是旧技术存在某些瓶颈,存在难以支撑或者扩展性越老越差等问题暴露出来之后,用新技术来进行解决。

       那RPC最大的优点,或者说它相比简单的HTTP接口,它的优势、更适合它的业务场景是怎样呢?简单的HTTP又哪里不足,哪些场景明显不太适合呢?

       RPC是一种技术的概念名词。 HTTP是一种协议,RPC可以通过HTTP来实现,也可以通过Socket自己实现一套协议来实现。所以楼主可以换一个问法,为何RPC还有除HTTP 之外的实现法,有何必要。毕竟除了HTTP实现外,私有协议不具备通用性。那么我想唯一的答案就在于HTTP不能满足其业务场景的地方,所以这个就要具体案例具体分析了。

       http接口是在接口不多、系统与系统交互较少的情况下,解决信息孤岛初期常使用的一种通信手段;优点就是简单、直接、开发方便。利用现成的http协议 进行传输。但是如果是一个大型的网站,内部子系统较多、接口非常多的情况下,RPC框架的好处就显示出来了,首先就是长链接,不必每次通信都要像http 一样去3次握手什么的,减少了网络开销;其次就是RPC框架一般都有注册中心,有丰富的监控管理;发布、下线接口、动态扩展等,对调用方来说是无感知、统 一化的操作。第三个来说就是安全性。最后就是最近流行的服务化架构、服务化治理,RPC框架是一个强力的支撑。

  rpc是一种概念,http也是rpc实现的一种方式。论复杂度,dubbo/hessian用起来是超级简单的。最近用dubbo和hessian比较多,http的几乎都被废弃了。

       至于为什么用,其实很简单,业务场景不一样。我最早的单位所有的代码都在一个工程里,一次要发布几百m的代码。这种架构是非常有利于小程序的。但是我们为什么要应用rpc层呢,一个功能,一套代码下来不就解决了么?我觉得有几个好处:1 灵活部署 2 解耦 至于为什么,当你用到的时候,你就会体会。

  RPC的核心并不在于使用什么协议。RPC的目的是让你在本地调用远程的方法,而对你来说这个调用是透明的,你并不知道这个调用的方法是部署哪里通过RPC能解耦服务,这才是使用RPC的真正目的。RPC的原理主要用到了动态代理模式,至于http协议,只是传输协议而已。简单的实现可以参考spring remoting,复杂的实现可以参考dubbo。

       RPC是一个软件结构概念,是构建分布式应用的理论基础。就好比为啥你家可以用到发电厂发出来的电?是因为电是可以传输的。至于用铜线还是用铁丝还是其他 种类的导线,也就是用http还是用其他协议的问题了。这个要看什么场景,对性能要求怎么样。比如在java中的最基本的就是RMI技术,它是java原 生的应用层分布式技术。我们可以肯定的是在传输性能方面,RMI的性能是优于HTTP的。那为啥很少用到这个技术?那是因为用这个有很多局限性,首先它要保证传输的两端都要要用java实现,且两边需要有相同的对象类型和代理接口,不需要容器,但是加大了编程的难度,在应用内部的各个子系统之间还是会看到他的身影,比如EJB就是基于rmi技术的。这就与目前的bs架构的软件大相径庭。用http必须要服务端位于http容器里面,这样减少了网络传输方面的开发,只需要关注业务开发即可。所以在架构一个软件的时候,不能一定根据需求选定技术。

参考:RPC原理解析 - 牧梦者 - 博客园 

RPC与HTTP - 仰望星空的脚踏实地 - 博客园

最后

以上就是活力大地为你收集整理的RPC和HTTP一、为什么需要RPC,而不是简单的HTTP接口?二、RPC三、自定义RPC框架范例四、HTTP五、总结的全部内容,希望文章能够帮你解决RPC和HTTP一、为什么需要RPC,而不是简单的HTTP接口?二、RPC三、自定义RPC框架范例四、HTTP五、总结所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(66)

评论列表共有 0 条评论

立即
投稿
返回
顶部