微信公众号:内核小王子
关注可了解更多关于数据库,JVM内核相关的知识;
若是你有任何疑问也能够加我pigpdong[^1]java
前面咱们了解了,服务调用方和服务提供方,如何可以经过注册中心作到水平扩展,从而知足高可用和高并发,那么服务之间如何才能实现相互调用呢?web
综合上一节的内容,服务双方无非就两种模式,一种直接经过网络调用,另外一种经过中间代理进行转发,那么不管哪种咱们只须要在服务双方经过socket,弄一个channel,一边write,一边read就能够搞定了spring
可是仔细一想,咱们要解决的问题不只仅是网络传输的问题,例如,如何定义远程调用的接口,参数,返回结果,若是解决跨语言的问题,异步,重试,如何能提供跟本地调用同样便利的接口等
不过这些问题前人已经帮咱们都想好了,bruce jay写了一遍论文,来定义RPC的标准,之后你们开发的RPC框架都是按照这个标准来,例如JAVA原生的RMI和dubbo.数据库
为了统一,咱们将服务调用方称为客户端,将服务提供方称为服务端,当客户端发起一个远程调用的时候,他须要一个STUB,做为他的本地代理,由这个stub来将接口描述和参数以约定好的格式,经过网络包发给服务端,在服务端返回后,在由这个stub将返回结果给客户端,
而这个stub须要RPC框架在调用以前就生成,生成stub他须要先经过服务端供的接口描述文件,这个描述文件若是在java环境能够是一个jar包,或者是一个约定好结构的IDL(接口描述语言)文件,RPC框架根据这个描述文件生成STUB代理程序,这个stub能够是一个进程,也能够是一个java类,不一样的框架实现不一样.
而服务端也会事先生成一个stub,由这个stub程序在收到网络请求后,根据约定的格式,将其解析出接口地址和参数,而后调用对应的服务提供方返回结果,下面咱们来分析一下每一步的实现.json
接口描述文件IDL主要是为了,描述为了让客户端怎么知道服务端提供了哪些接口,这些接口有哪些方法,方法有哪些参数,方法返回什么数据,这时候咱们想到WSDL文件,没错,基于XML的SOAP协议就是早期的
rpc程序webservice的接口描述文件,以及后来基于json的RESTFUL接口协议,这两种都是支持跨语言的,facebook开源的thrift和google的grpc也是使用这种IDL接口定义语言,以后经过编译器生成不一样语言的stub,
而若是服务双方都是java语言环境的,那么只须要将服务端的接口定义的class打成一个jar包提供给客户端既可.微信
客户端须要将调用的接口名经过网络包传给客户端,同时也要将方法参数传输过去,而方法参数多是一个java对象(对象里的属性可能仍是一个引用,指向其余对象),这时须要将这些java对象转换成二进制包从网络传输,而后服务端接收到网络包后在另一个JVM下将其还原成相应的java对象,这个过程就是
对象的序列化和反序列化,客户端的Stub在收到服务端返回的结果后也须要反序列化成java对象,服务端在发送返回结果的时候也须要进行序列化操做,因此对客户端和服务端都会有对应的序列化和反序列化,因此必定要约定好客户端和服务端使用的序列化标准是一致的
,咱们生产环境就发生过,因为双方序列化框架版本不一致致使的事故,目前开源的序列化框架有不少,阿里的fastjson在使用和性能上都还不错,还有gson,protobuffer,thrift等,这里强调一下因为各家序列化框架实现不一样,有些是经过类的属性进行反射,有些根据属性对应的get方法,因此为了下降
序列化框架带来的影响,咱们须要针对JAVA bean须要有一套标准的命名规范,例如布尔类success get方法isSuccess set方法setSuccess,千万不要将属性命名为isSuccess这种.网络
在java环境下,Stub能够直接做为一个工具类,让客户端像调用本地方法同样调用远程方法,咱们能够根据服务端提供的的接口描述,经过java动态代理或者字节码工具生成这个接口的一个实现类,在这个实现类里经过Stub去
调用远程,将参数序列化和接口地址经过网络发给服务端,并将返回结果的二进制数据反序列化为返回的对象,那么Stub做为一个工具类,处理网络链接,失败重试,序列化和反序列化等,而动态生成的代理类都依赖该工具,客户端实际用到的是这个代理类,
另外咱们能够思考下,怎么实现客户端的异步调用以及回调,异步调用是指,客户端代理类将调用请求经过stub发给服务端后不等待服务端的结果,能够直接继续后面的流程,或者也能够等到服务端返回后执行一个回调.
这里咱们能够参考dubbo的作法,将经过网络发送请求的过程封装在一个Future对象里,若是是同步调用就直接调用future.get等待结果,若是是异步调用就直接将future对象放入一个threadlocal对象RpcContext里就返回,若是须要执行异步回调,就监听这个future对象返回后执行注册的通知程序并发
目前须要进行网络传输的中间件通常都会选择netty,咱们有必要简单了解下netty的线程模型,像dubbo,grpc都会分为应用线程和netty线程框架
netty使用简单,预置了多种编解码实现,支持多种主流协议,成熟,稳定,社区活跃度高,定制能力强,经过ChannelHandler能够灵活扩展异步
netty线程模型
在服务端Stub也能够做为一个工具类,处理网络传输,序列化等,同时还须要根据解析到的接口地址,找到对应的实现类而后在调用,因为这里须要动态调用,须要用到java的反射机制,不过也有像grpc这种
将服务实现注册到stub,而后能够在Stub中实现直接调用的
RPC框架的目标就是让远程服务调用更加简单,透明,RPC框架负责屏蔽底层的网络传输方式(TCP或者UDP),序列化方式(XML,JSON,二进制)和通信细节,服务调用者能够像调用本地接口同样,调用远程的服务提供者,而不须要关心底层的通信细节和调用过程.
.下图反映了几大主流RPC框架的通用实现.
1.支持多语言的RPC框架,google的gRPC,Apache(facebook)的Thrift 2.只支持特定语言的RPC框架,例如新浪的Motan 3.支持服务治理等服务化特性的分布式框架,例如阿里的dubbo 4.拥有完整生态的spring cloud