zoukankan      html  css  js  c++  java
  • RPC接口测试(一)什么是 RPC 框架

    什么是 RPC 框架

    RPC 框架----- 远程过程调用协议RPC(Remote Procedure Call Protocol)-----允许像调用本地服务一样调用远程服务

    RPC是指远程过程调用,也就是说两台服务器A,B,一个应用部署在A服务器上,想要调用B服务器上应用提供的函数/方法,由于不在一个内存空间,不能直接调用,需要通过网络来表达调用的语义和传达调用的数据。比如说,一个方法可能是这样定义的: 
    Employee getEmployeeByName(String fullName)那么:

    第一,首先,要解决通讯的问题,主要是通过在客户端和服务器之间建立TCP连接(socket),远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接,调用结束后就断掉,也可以是长连接,多个远程过程调用共享同一个连接。

    第二,要解决寻址的问题,也就是说,A服务器上的应用怎么告诉底层的RPC框架,如何连接到B服务器(如主机或IP地址)以及特定的端口,方法的名称名称是什么,这样才能完成调用。比如基于Web服务协议栈的RPC,就要提供一个endpoint URI,或者是从UDDI服务上查找。如果是RMI调用的话,还需要一个RMI Registry来注册服务的地址。

    第三,当A服务器上的应用发起远程过程调用时,方法的参数需要通过底层的网络协议如TCP传递到B服务器,由于网络协议是基于二进制的,内存中的参数的值要序列化成二进制的形式,也就是序列化(Serialize)或编组(marshal),通过寻址和传输将序列化的二进制发送给B服务器。

    第四,B服务器收到请求后,需要对参数进行反序列化(序列化的逆操作),恢复为内存中的表达方式,然后找到对应的方法(寻址的一部分)进行本地调用,然后得到返回值。

    第五,返回值还要发送回服务器A上的应用,也要经过序列化的方式发送,服务器A接到后,再反序列化,恢复为内存中的表达方式,交给A服务器上的应用

    总的来说可以归纳为以下几步:

     1,远程服务之间建立通讯协议

    2,寻址:服务器(如主机或IP地址)以及特定的端口,方法的名称名称是什么

    3,通过序列化和反序列化进行数据传递

    4,将传递过来的数据通过java反射原理定位接口方法和参数

    5,暴露服务:用map将寻址的信息暴露给远方服务(提供一个endpoint URI或者一个前端展示页面

     6,多线程并发请求业务

     

    什么是RPC

    提到RPC(Remote Procedure Call),就躲不开提到分布式,这个促使RPC诞生的领域。

     

    假设你有一个Calculator,以及它的实现类CalculatorImpl,那么单体应用时,要调用Calculator的add方法来执行一个加运算,你可以方法中直接使用,因为在同一个地址空间,或者说在同一块内存,这个称为本地函数调用。

     

    现在,将系统改造为分布式应用,接口调用和实现分别在两个子系统内,

    服务A里头并没有CalculatorImpl这个类,那它要怎样调用服务B的CalculatorImpl的add方法呢?可以模仿B/S架构的调用方式,在B服务暴露一个Restful接口,然后A服务通过调用这个Restful接口来间接调用CalculatorImpl的add方法。

     

    这样,已经很接近RPC了,不过,像这种每次调用时,是不是都需要写一串发起http请求的代码呢?比如httpClient.sendRequest...之类的,能不能简单一下,像本地方法调用一样,去发起远程调用,让使用者感知不到远程调用的过程。

     

    屏蔽的工作,可以使用代理模式解决,生成一个代理对象,而这个代理对象的内部,就是通过httpClient来实现RPC远程过程调用的。

    这就是很多RPC框架要解决的问题和解决的思路,比如阿里的Dubbo。

     

    总结一下,RPC要解决的两个问题:

    1. 解决分布式系统中,服务之间的调用问题。

    2. 远程调用时,要能够像本地调用一样方便,让调用者感知不到远程调用的逻辑。

     

    RPC是一种技术的概念名词

    RPC=Remote Produce Call 是一种技术的概念名词,HTTP是一种协议,RPC可以通过 HTTP 来实现,也可以通过Socket自己实现一套协议来实现.所以题目可以换一种理解,为何 RPC 还有除 HTTP 之外的实现法,有何必要,毕竟除了HTTP实现外,私有协议不具备通用性.

     

    RPC框架好处

    http接口是在接口不多、系统与系统交互较少的情况下,解决信息孤岛初期常使用的一种通信手段;

    优点就是简单、直接、开发方便。

    如果是一个大型的网站,内部子系统较多、接口非常多的情况下,RPC框架的好处就显示出来了:

    首先就是长链接,不必每次通信都要像http一样去3次握手什么的,减少了网络开销;

    其次就是RPC框架一般都有注册中心,有丰富的监控管理;发布、下线接口、动态扩展等,对调用方来说是无感知、统一化的操作。

    最后是安全性。

     

    rpc是一种概念,http也是rpc实现的一种方式。

    论复杂度,dubbo/hessian用起来是超级简单的。

    至于为什么用dubbo/hessian,有几点:

    一是调用简单,真正提供了类似于调用本地方法一样调用接口的功能 。

    二是参数返回值简单明了 参数和返回值都是直接定义在jar包里的,不需要二次解析。

    三是 轻量,没有多余的信息。

    四是便于管理,基于dubbo的注册中心。

     

    RPC能解耦服务

    RPC:远程过程调用。RPC的核心并不在于使用什么协议。RPC的目的是让你在本地调用远程的方法,而对你来说这个调用是透明的,你并不知道这个调用的方法是部署哪里。

     

    通过RPC能解耦服务,这才是使用RPC的真正目的。RPC的原理主要用到了动态代理模式,至于http协议,只是传输协议而已。简单的实现可以参考spring remoting,复杂的实现可以参考dubbo。

     

    rpc=socket + 动态代理

    服务器通讯原理就是一台socket服务器A,另一台socket客户端B,现在如果要通讯的话直接以流方式写入或读出。这样能实现通讯,但有个问题。如何知道更多信息?

     

    比如需要发送流大小,编码,Ip等。这样就有了协议,协议就是规范,就是发送的流中携带了很多的内容。那回到刚刚的问题。发送的内容就是文本类型,客户端就得序列化,那么常用的就有json,xml之类,如果想把内容变得更小,那就有二进制了。把文本变成二进制传递。

    说到 rpc 与http接口,不要太复杂了。rpc 协议更简单内容更小,那么来说效率是要高一点

    rpc 是什么?就是socket 加动态代理。

     

    总结

    学技术应该是知其然知其所以然,我们得明白什么场景,或者什么业务需要它,它能解决其他技术不能解决或者不方便解决的问题。

     

    RPC是一个软件结构概念,是构建分布式应用的理论基础。就好比为啥你家可以用到发电厂发出来的电?是因为电是可以传输的。至于用铜线还是用铁丝还是其他种类的导线,也就是用http还是用其他协议的问题了。这个要看什么场景,对性能要求怎么样。

     

    在java中的最基本的就是RMI技术,它是java原生的应用层分布式技术。我们可以肯定的是在传输性能方面,RMI的性能是优于HTTP的。

     

    那为啥很少用到这个技术?那是因为用这个有很多局限性,首先它要保证传输的两端都要要用java实现,且两边需要有相同的对象类型和代理接口,不需要容器,但是加大了编程的难度,在应用内部的各个子系统之间还是会看到他的身影,比如EJB就是基于rmi技术的。

     

    这就与目前的bs架构的软件大相径庭。用http必须要服务端位于http容器里面,这样减少了网络传输方面的开发,只需要关注业务开发即可。所以在架构一个软件的时候,不能一定根据需求选定技术。

  • 相关阅读:
    BZOJ3752 : Hack
    XIV Open Cup named after E.V. Pankratiev. GP of SPb
    XIII Open Cup named after E.V. Pankratiev. GP of Ukraine
    BZOJ2087 : [Poi2010]Sheep
    BZOJ2080 : [Poi2010]Railway
    BZOJ2082 : [Poi2010]Divine divisor
    Moscow Pre-Finals Workshop 2016. National Taiwan U Selection
    XIII Open Cup named after E.V. Pankratiev. GP of Asia and South Caucasus
    XIII Open Cup named after E.V. Pankratiev. GP of Azov Sea
    XIII Open Cup named after E.V. Pankratiev. GP of SPb
  • 原文地址:https://www.cnblogs.com/111testing/p/11296880.html
Copyright © 2011-2022 走看看