RPC框架的简介

发表时间:2017-09-25 18:09:40 浏览量( 139 ) 留言数( 0 )

学习目标:

1、了解RPC框架

2、了解RPC的使用场景


学习过程:

一、什么是RPC

1、微服务SOA服务简介

   随着公司的规模越来越大,很多项目都有一些公共的功能模块,公司就会把这些公共的功能模块以服务的形式抽取出来,既可以提供给公司内部使用,也可以以服务收费的方式把服务提供给其他公司使用,于是很多架构师就需要在设计的时候就要面向服务搭建模型,于是就有了这种面向服务的架构——SOA。

   面向服务的架构(SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

    面向服务的架构(SOA)应该是松耦合的系统,这种具有中立的接口定义的特征称为服务之间的松耦合。松耦合系统的好处有两点,一点是它的灵活性,另一点是,当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时,它能够继续存在。与之相反,紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的,因而当需要对部分或整个应用程序进行某种形式的更改时,它们就显得非常脆弱。

   对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活,以适应不断变化的环境,比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素,这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需(On demand)业务,在按需业务中,一旦需要,就可以对完成或执行任务的方式进行必要的更改。

   SOA架构实现不依赖于技术,因此能够被各种不同的技术实现:SOAP,、RPC、REST、DCOM、CORBA、OPC-UA、Web services、DDS、Java RMI、Apache Thrift、SORCER,接下来我们主要讲的是RPC的使用,也会讲解一下REST等方式。

2、什么是RPC

    RPC(Remote Procedure Call)—远程过程调用,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在,如TCP或UDP,为通信程序之间携带信息数据。在OSI网络通信模型中,RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

   RPC采用客户机/服务器模式。请求程序就是一个客户机,而服务提供程序就是一个服务器。首先,客户机调用进程发送一个有进程参数的调用信息到服务进程,然后等待应答信息。在服务器端,进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达,服务器获得进程参数,计算结果,发送答复信息,然后等待下一个调用信息,最后,客户端调用进程接收答复信息,获得进程结果,然后调用执行继续进行。


二、RPC的使用场景

    RPC 的主要功能目标是让构建分布式计算(应用)更容易,在提供强大的远程调用能力时不损失本地调用的语义简洁性。为实现该目标,RPC 框架需提供一种透明调用机制让使用者不必显式的区分本地调用和远程调用


三、RPC的设计原则

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

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

   3、当A服务器上的应用发起远程过程调用时,方法的参数需要通过底层的网络协议如TCP传递到B服务器,由于网络协议是基于二进制的,内存中的参数的值要序列化成二进制的形式,也就是序列化(Serialize)或编组(marshal),通过寻址和传输将序列化的二进制发送给B服务器。B服务器收到请求后,需要对参数进行反序列化(序列化的逆操作),恢复为内存中的表达方式,然后找到对应的方法(寻址的一部分)进行本地调用,然后得到返回值。返回值还要发送给A服务器上的应用,也要经过序列化的方式发送,服务器A接到后,在反序列化,恢复为内存中的表达方式,交给A服务器上的应用。

   4、最后RPC框架实现SOA服务之间的通信,一般还会提供服务治理功能。

四、服务拆分原则和问题

    服务划分细粒度,以及服务独立后引发的事务等问题,都需要我们再规划服务时慎重考虑的。首先我们需要把系统中独立的业务模块抽取出来,按业务的独立性进行垂直划分,抽象出基础服务层。一般来说避免A服务中的SQL需要链接查询到B服务中的表等情况,这样在A服务与B服务进行垂直拆库时就会出错,因为分布式事务也是一个比较难解决的问题(虽然有很多解决方案,都是都有一定的缺陷的)。服务子系统的数量把控,过多会导致可能划分过细,破坏业务子系统的独立性部署维护工作量大,独立进程占用内存多;过少就是没能很好的解耦开发维护不好分工升级维护影响面大

   总之服务划分是个渐进的过程,需要不断的优化和调整才能达到最好的效果。

五、目前流行的RPC框架

广泛使用的有RMI、Hessian、Dubbo等

1、RMI(远程方法调用)

JAVA自带的远程方法调用工具

2、Hessian(基于HTTP的远程方法调用)

基于HTTP协议传输,在性能方面还不够完美,负载均衡和失效转移依赖于应用的负载均衡器,Hessian的使用则与RMI类似,区别在于淡化了Registry的角色,通过显示的地址调用,利用HessianProxyFactory根据配置的地址create一个代理对象,另外还要引入Hessian的Jar包。

3、Dubbo

国内最流行的RPC框架,是淘宝开源项目,目前已经提交到Apache的开源项目了。http://dubbo.apache.org

还有就是目前比较火的Spring Cloud,当然Spring Cloud不仅仅是一个RPC框架,而是一个提供了完整的服务。