图1-1 通用RPC调用流程
gRPC的RPC调用与上述流程相似,下面我们一起学习下gRPC的客户端创建和服务调用流程。
以gRPC入门级的helloworld Demo为例,客户端发起RPC调用的代码主要包括如下几部分:
相关示例代码如下所示:
(点击放大图像)
gRPC的客户端调用主要包括基于Netty的HTTP/2客户端创建、客户端负载均衡、请求消息的发送和响应接收处理四个流程。
gRPC的客户端调用总体流程如下图所示:
(点击放大图像)
图1-2 gRPC总体调用流程
gRPC的客户端调用流程如下:
需要指出的是,客户端同步阻塞RPC调用阻塞的是调用方线程(通常是业务线程),底层Transport的I/O线程(Netty的NioEventLoop)仍然是非阻塞的。
ManagedChannel是对Transport层SocketChannel的抽象,Transport层负责协议消息的序列化和反序列化,以及协议消息的发送和读取。ManagedChannel将处理后的请求和响应传递给与之相关联的ClientCall进行上层处理,同时,ManagedChannel提供了对Channel的生命周期管理(链路创建、空闲、关闭等)。
ManagedChannel提供了接口式的切面ClientInterceptor,它可以拦截RPC客户端调用,注入扩展点,以及功能定制,方便框架的使用者对gRPC进行功能扩展。
ManagedChannel的主要实现类ManagedChannelImpl创建流程如下:
(点击放大图像)
图1-3 ManagedChannelImpl创建流程
流程关键技术点解读:
ManagedChannel实例构造完成之后,即可创建ClientCall,发起RPC调用。
完成ManagedChannelImpl创建之后,由ManagedChannelImpl发起创建一个新的ClientCall实例。ClientCall的用途是业务应用层的消息调度和处理,它的典型用法如下:
- call = channel.newCall(unaryMethod, callOptions);
- call.start(listener, headers);
- call.sendMessage(message);
- call.halfClose();
- call.request(1);
- // wait for listener.onMessage()
ClientCall实例的创建流程如下所示:
(点击放大图像)
图1-4 ClientCallImpl创建流程
流程关键技术点解读:
ClientCallImpl实例创建完成之后,就可以调用ClientTransport,创建HTTP/2 Client,向gRPC服务端发起远程服务调用。
gRPC客户端底层基于Netty4.1的HTTP/2协议栈框架构建,以便可以使用HTTP/2协议来承载RPC消息,在满足标准化规范的前提下,提升通信性能。
gRPC HTTP/2协议栈(客户端)的关键实现是NettyClientTransport和NettyClientHandler,客户端初始化流程如下所示:
(点击放大图像)
图1-5 HTTP/2 Client创建流程
流程关键技术点解读:
1.NettyClientHandler的创建:级联创建Netty的Http2FrameReader、Http2FrameWriter和Http2Connection,用于构建基于Netty的gRPC HTTP/2客户端协议栈。
2.HTTP/2 Client启动:仍然基于Netty的Bootstrap来初始化并启动客户端,但是有两个细节需要注意:
3. WriteQueue创建:Netty的NioSocketChannel初始化并向Selector注册之后(发起HTTP连接之前),立即由NettyClientHandler创建WriteQueue,用于接收并处理gRPC内部的各种Command,例如链路关闭指令、发送Frame指令、发送Ping指令等。
HTTP/2 Client创建完成之后,即可由客户端根据协商策略发起HTTP/2连接。如果连接创建成功,后续即可复用该HTTP/2连接,进行RPC调用。
HTTP/2在TCP连接之初通过协商的方式进行通信,只有协商成功,才能进行后续的业务层数据发送和接收。
HTTP/2的版本标识分为两类:
HTTP/2连接创建,分为两种:通过协商升级协议方式和直接连接方式。
假如不知道服务端是否支持HTTP/2,可以先使用HTTP/1.1进行协商,客户端发送协商请求消息(只含消息头),报文示例如下:
- GET / HTTP/1.1
- Host: 127.0.0.1
- Connection: Upgrade, HTTP2-Settings
- Upgrade: h2c
- HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
服务端接收到协商请求之后,如果不支持HTTP/2,则直接按照HTTP/1.1响应返回,双方通过HTTP/1.1进行通信,报文示例如下:
- HTTP/1.1 200 OK
- Content-Length: 28
- Content-Type: text/CSS
- body...
如果服务端支持HTTP/2,则协商成功,返回101结果码,通知客户端一起升级到HTTP/2进行通信,示例报文如下:
- HTTP/1.1 101 Switching Protocols
- Connection: Upgrade
- Upgrade: h2c
- [ HTTP/2 connection...
101响应之后,服务需要发送SETTINGS帧作为连接序言,客户端接收到101响应之后,也必须发送一个序言作为回应,示例如下:
- PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n
- SETTINGS帧
客户端序言发送完成之后,可以不需要等待服务端的SETTINGS帧,而直接发送业务请求Frame。
假如客户端和服务端已经约定使用HTTP/2,则可以免去101协商和切换流程,直接发起HTTP/2连接,具体流程如下所示:
(点击放大图像)
图1-6 HTTP/2 直接连接过程
几个关键点:
gRPC支持三种Protocol Negotiator策略:
下面我们以PlaintextNegotiator为例,了解下基于Netty的HTTP/2连接创建流程:
(点击放大图像)
图1-7 基于Netty的HTTP/2直连流程
总体上看,RPC的负载均衡策略有两大类:
外部负载均衡模式如下所示:
(点击放大图像)
图1-8 代理负载均衡模式示意图
以代理LB模式为例:RPC客户端向负载均衡代理发送请求,负载均衡代理按照指定的路由策略,将请求消息转发到后端可用的服务实例上。负载均衡代理负责维护后端可用的服务列表,如果发现某个服务不可用,则将其剔除出路由表。
代理LB模式的优点是客户端不需要实现负载均衡策略算法,也不需要维护后端的服务列表信息,不直接跟后端的服务进行通信,在做网络安全边界隔离时,非常实用。例如通过Ngix做L7层负载均衡,将互联网前端的流量安全的接入到后端服务中。
代理LB模式通常支持L4(Transport)和L7(Application)层负载均衡,两者各有优缺点,可以根据RPC的协议特点灵活选择。L4/L7层负载均衡对应场景如下:
客户端负载均衡策略由客户端内置负载均衡能力,通过静态配置、域名解析服务(例如DNS服务)、订阅发布(例如Zookeeper服务注册中心)等方式获取RPC服务端地址列表,并将地址列表缓存到客户端内存中。每次RPC调用时,根据客户端配置的负载均衡策略由负载均衡算法从缓存的服务地址列表中选择一个服务实例,发起RPC调用。
客户端负载均衡策略工作原理示例如下:
(点击放大图像)
图1-9 客户端负载均衡策略示意图
gRPC默认采用客户端负载均衡策略,同时提供了扩展机制,使用者通过自定义实现NameResolver和LoadBalancer,即可覆盖gRPC默认的负载均衡策略,实现自定义路由策略的扩展。
gRPC提供的负载均衡策略实现类如下所示:
gRPC负载均衡流程如下所示:
(点击放大图像)
图1-10 gRPC客户端负载均衡流程图
流程关键技术点解读:
对于扩展者而言,可以继承NameResolver实现自定义的地址解析服务,例如使用Zookeeper替换DnsNameResolver,把Zookeeper作为动态的服务地址配置中心,它的伪代码示例如下:
第一步:继承NameResolver,实现start(Listener listener)方法:
- void start(Listener listener) {
- //获取ZooKeeper地址,并连接
- //创建Watcher,并实现process(WatchedEvent event),监听地址变更
- //根据接口名和方法名,调用getChildren方法,获取发布该服务的地址列表
- //将地址列表加到List中
- // 调用NameResolver.Listener.onAddresses(),通知地址解析完成
第二步:创建ManagedChannelBuilder时,指定Target的地址为Zookeeper服务端地址,同时设置nameResolver为Zookeeper NameResolver,示例代码如下所示:
- this(ManagedChannelBuilder.forTarget(zookeeperAddr)
- .loadBalancerFactory(RoundRobinLoadBalancerFactory.getInstance())
- .nameResolverFactory(new ZookeeperNameResolverProvider())
- .usePlaintext(false));
3. LoadBalancer负责从nameResolver中解析获得的服务端URL中按照指定路由策略,选择一个目标服务端地址,并创建ClientTransport。同样,可以通过覆盖handleResolvedAddressGroups实现自定义负载均衡策略。
通过LoadBalancer + NameResolver,可以实现灵活的负载均衡策略扩展。例如基于Zookeeper、etcd的分布式配置服务中心方案。
gRPC默认基于Netty HTTP/2 + PB进行RPC调用,请求消息发送流程如下所示:
(点击放大图像)
图1-11 gRPC请求消息发送流程图
流程关键技术点解读:
gRPC客户端响应消息的接收入口是NettyClientHandler,它的处理流程如下所示:
(点击放大图像)
图1-12 gRPC响应消息接收流程图
流程关键技术点解读:
gRPC客户端调用原理并不复杂,但是代码却相对比较繁杂。下面围绕关键的类库,对主要功能点进行源码分析。
NettyClientTransport的主要功能如下:
以启动HTTP/2客户端为例进行讲解:
(点击放大图像)
根据启动时配置的HTTP/2协商策略,以NettyClientHandler为参数创建ProtocolNegotiator.Handler。
创建Bootstrap,并设置EventLoopGroup,需要指出的是,此处并没有使用EventLoopGroup,而是它的一种实现类EventLoop,原因在前文中已经说明,相关代码示例如下:
(点击放大图像)
创建WriteQueue并设置到NettyClientHandler中,用于接收内部的各种QueuedCommand,初始化完成之后,发起HTTP/2连接,代码如下:
(点击放大图像)
NettyClientHandler继承自Netty的Http2ConnectionHandler,是gRPC接收和发送HTTP/2消息的关键实现类,也是gRPC和Netty的交互桥梁,它的主要功能如下所示:
协议消息的发送:无论是业务请求消息,还是协议指令消息,都统一封装成QueuedCommand,由NettyClientHandler拦截并处理,相关代码如下所示:
(点击放大图像)
协议消息的接收:NettyClientHandler通过向Http2ConnectionDecoder注册FrameListener来监听RPC响应消息和协议指令消息,相关接口如下:
(点击放大图像)
FrameListener回调NettyClientHandler的相关方法,实现协议消息的接收和处理:
(点击放大图像)
需要指出的是,NettyClientHandler并没有实现所有的回调接口,对于需要特殊处理的几个方法进行了重载,例如onDataRead和onHeadersRead。
ProtocolNegotiator用于HTTP/2连接创建的协商,gRPC支持三种策略并有三个实现子类:
(点击放大图像)
gRPC的ProtocolNegotiator实现类完全遵循HTTP/2相关规范,以PlaintextUpgradeNegotiator为例,通过设置Http2ClientUpgradeCodec,用于101协商和协议升级,相关代码如下所示:
(点击放大图像)
LoadBalancer负责客户端负载均衡,它是个抽象类,gRPC框架的使用者可以通过继承的方式进行扩展。
gRPC当前已经支持PickFirstBalancer和RoundRobinLoadBalancer两种负载均衡策略,未来不排除会提供更多的策略。
以RoundRobinLoadBalancer为例,它的工作原理如下:根据PickSubchannelArgs来选择一个Subchannel:
(点击放大图像)
再看下Subchannel的选择算法:
(点击放大图像)
即通过顺序的方式从服务端列表中获取一个Subchannel。
如果用户需要定制负载均衡策略,则可以在RPC调用时,使用如下代码:
(点击放大图像)
ClientCalls提供了各种RPC调用方式,包括同步、异步、Streaming和Unary方式等,相关方法如下所示:
(点击放大图像)
下面一起看下RPC请求消息的发送和应答接收相关代码。
请求调用主要有两步:请求Frame构造和Frame发送,请求Frame构造代码如下所示:
(点击放大图像)
使用PB对请求消息做序列化,生成InputStream,构造请求Frame:
(点击放大图像)
Frame发送代码如下所示:
(点击放大图像)
NettyClientHandler接收到发送事件之后,调用Http2ConnectionEncoder将Frame写入Netty HTTP/2协议栈:
(点击放大图像)
响应消息的接收入口是NettyClientHandler,包括HTTP/2 Header和HTTP/2 DATA Frame两部分,代码如下:
(点击放大图像)
如果参数endStream为True,说明Stream已经结束,调用transportTrailersReceived,通知Listener close,代码如下所示:
(点击放大图像)
读取到HTTP/2 DATA Frame之后,调用MessageDeframer的deliver对Frame进行解析,代码如下:
(点击放大图像)
将Frame 转换成InputStream之后,通知ClientStreamListenerImpl,调用messageRead(final InputStream message),将InputStream反序列化为响应对象,相关代码如下所示:
(点击放大图像)
当接收到endOfStream之后,通知ClientStreamListenerImpl,调用它的close方法,如下所示:
(点击放大图像)
最终调用UnaryStreamToFuture的onClose方法,set响应对象,唤醒阻塞的调用方线程,完成RPC调用,代码如下:
(点击放大图像)
李林锋,华为软件平台开放实验室架构师,有多年Java NIO、平台中间件、PaaS平台、API网关设计和开发经验。精通Netty、Mina、分布式服务框架、云计算等,目前从事软件公司的API开放相关的架构和设计工作。
联系方式:新浪微博 Nettying 微信:Nettying
Email:neu_lilinfeng@sina.com
感谢郭蕾对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ,@丁晓昀),微信(微信号:InfoQChina)关注我们。
评价本文
来源: http://www.infoq.com/cn/articles/grpc-server-creation-and-invocation-principle