轻松构建微服务之远程调用

前面我们了解了,服务调用方和服务提供方,如何能够通过注册中心做到水平扩展,从而满足高可用和高并发,那么服务之间如何才能实现相互调用呢?

综合上一节的内容,服务双方无非就两种模式,一种直接通过网络调用,另一种通过中间代理进行转发,那么无论哪一种我们只需要在服务双方通过socket,弄一个channel,一边write,一边read就可以搞定了

但是仔细一想,我们要解决的问题不仅仅是网络传输的问题,例如,如何定义远程调用的接口,参数,返回结果,如果解决跨语言的问题,异步,重试,如何能提供跟本地调用一样便利的接口等 不过这些问题前人已经帮我们都想好了,bruce jay写了一遍论文,来定义RPC的标准,以后大家开发的RPC框架都是按照这个标准来,例如 JAVA 原生的RMI和dubbo.

为了统一,我们将服务调用方称为客户端,将服务提供方称为服务端,当客户端发起一个远程调用的时候,他需要一个STUB,作为他的本地代理,由这个stub来将接口描述和参数以约定好的格式,通过网络包发给服务端,在服务端返回后,在由这个stub将返回结果给客户端, 而这个stub需要RPC框架在调用之前就生成,生成stub他需要先通过服务端供的接口描述文件,这个描述文件如果在java环境可以是一个jar包,或者是一个约定好结构的IDL(接口描述语言)文件,RPC框架根据这个描述文件生成STUB代理程序,这个stub可以是一个进程,也可以是一个java类,不同的框架实现不同. 而服务端也会事先生成一个stub,由这个stub程序在收到网络请求后,根据约定的格式,将其解析出接口地址和参数,然后调用对应的服务提供方返回结果,下面我们来分析一下每一步的实现.

接口描述

接口描述文件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这种.

客户端Stub

在java环境下,Stub可以直接作为一个 工具 类,让客户端像调用本地方法一样调用远程方法,我们可以根据服务端提供的的接口描述,通过java动态代理或者字节码工具生成这个接口的一个实现类,在这个实现类里通过Stub去 调用远程,将参数序列化和接口地址通过网络发给服务端,并将返回结果的二进制数据反序列化为返回的对象,那么Stub作为一个工具类,处理网络连接,失败重试,序列化和反序列化等,而动态生成的代理类都依赖该工具,客户端实际用到的是这个代理类, 另外我们可以思考下,怎么实现客户端的异步调用以及回调,异步调用是指,客户端代理类将调用请求通过stub发给服务端后不等待服务端的结果,可以直接继续后面的流程,或者也可以等到服务端返回后执行一个回调. 这里我们可以参考dubbo的做法,将通过网络发送请求的过程封装在一个Future对象里,如果是同步调用就直接调用future.get等待结果,如果是异步调用就直接将future对象放入一个threadlocal对象RpcContext里就返回,如果需要执行异步回调,就监听这个future对象返回后执行注册的通知程序

网络传输

目前需要进行网络传输的中间件一般都会选择netty,我们有必要简单了解下netty的线程模型,像dubbo,grpc都会分为应用线程和netty线程

netty使用简单,预置了多种编解码实现,支持多种主流协议,成熟,稳定,社区活跃度高,定制能力强,通过ChannelHandler可以灵活扩展

netty线程模型

• BossGroup作为主线程池处理连接请求,workGroup作为工作线程处理IO读写
• Acceptor线程负责处理客户端的请求接入
• Connector线程负责注册监听连接事件
• I/O线程负责从SocketChannel读取报文和写入数据,协议的编码解码,NettyServerHandler的调度
• 定时任务线程负责执行心跳检测和链路空闲检测等

服务端Stub

在服务端Stub也可以作为一个工具类,处理网络传输,序列化等,同时还需要根据解析到的接口地址,找到对应的实现类然后在调用,由于这里需要动态调用,需要用到java的反射机制,不过也有像grpc这种 将服务实现注册到stub,然后可以在Stub中实现直接调用的

总结

RPC框架的目标就是让远程服务调用更加简单,透明,RPC框架负责屏蔽底层的网络传输方式(TCP或者UDP),序列化方式(XML,JSON,二进制)和通讯细节,服务调用者可以像调用本地接口一样,调用远程的服务提供者,而不需要关心底层的通讯细节和调用过程. .下图反映了几大主流RPC框架的通用实现.

几大RPC框架介绍

1.支持多语言的RPC框架,google的gRPC,Apache(facebook)的Thrift 2.只支持特定语言的RPC框架,例如新浪的Motan 3.支持服务治理等服务化特性的分布式框架,例如阿里的dubbo 4.拥有完整生态的spring cloud