--- theme: condensed-night-purple --- # 前言本章基于dubbo3.2.0版本，分析Triple协议的实现。先前的所有分析，都没有分析到通讯层，主要原因是因为dubbo rpc协议是个私有协议，不具备普适性。 > 先前分析的所有东西，在目前版本都有借鉴意义，比如2.x的暴露、引用、调用，2.7.5的应用级别服务注册发现。 dubbo3.0推出了三代协议Triple，基于http2，兼容grpc，可能是未来的主力协议，详细信息参见官网。 > dubbo3.0将部分扩展点实现从主项目中拆分到**dubbo-spi-extensions**，其中就包含部分rpc协议，所以主力协议都在主项目中。 **本文将分析以下内容**： - 基于unary方式调用的原理（简单理解unary为传统一个请求一个响应） - 基于stream方式调用的原理 - triple兼容grpc原理 - Stub的运行原理（基于dubbo-compiler） - 端口协议复用特性 **通过这次Triple协议阅读，收获会很多**： - 对于http2不仅停留在八股文层，有一个体感的认知 - dubbo对于triple的实现，很多地方和grpc-java类似，所以顺带理解grpc-java - 巩固理解netty 注：通讯层仅支持netty4，netty基础可能要复习一下。 # 铺垫 ## 案例采用官方dubbo-demo-triple，做了一些小改动，方便调试。注：使用IDL（Interface Description Language）+unary方式调用。 ``` syntax = "proto3"; option java_multiple_files = true; option java_package = "org.apache.dubbo.demo.hello"; option java_outer_classname = "HelloWorldProto"; option objc_class_prefix = "HLW"; package helloworld; message HelloRequest { string name = 1; } message HelloReply { string message = 1; } ``` ### 服务提供者这里register-mode=instance，采用应用级别注册。 ``` public static void main(String[] args) { ServiceConfig serviceConfig = new ServiceConfig<>(); serviceConfig.setInterface(GreeterService.class); serviceConfig.setRef(new GreeterServiceImpl()); // 默认端口50051 ProtocolConfig protocol = new ProtocolConfig("tri", -1); // 应用级别注册 ApplicationConfig applicationConfig = new ApplicationConfig("dubbo-demo-triple-api-provider"); applicationConfig.setRegisterMode("instance"); DubboBootstrap bootstrap = DubboBootstrap.getInstance(); bootstrap.application(applicationConfig) .registry(new RegistryConfig("zookeeper://127.0.0.1:2181")) .protocol(protocol) .service(serviceConfig) .start() .await(); } ``` 这里服务实现，我加入了attachment。每个响应会回复一个responseId，可以观察这个attachment在http2中体现在哪里。 ``` @Override public HelloReply sayHello(HelloRequest request) { // requestId Object requestId = RpcContext.getServerAttachment().getObjectAttachment("requestId"); System.out.println("requestId=" + requestId); // responseId String responseId = UUID.randomUUID().toString(); System.out.println("responseId=" + responseId); RpcContext.getServerResponseContext().setAttachment("responseId", responseId); return HelloReply.newBuilder().setMessage("Hello " + request.getName()).build(); } ``` ### 服务消费者服务消费者强制走应用级别发现FORCE_APPLICATION。当收到控制台输入回车，发送一次rpc请求，每个请求携带requestId。 ``` public static void main(String[] args) throws InterruptedException { System.setProperty("dubbo.application.service-discovery.migration", "FORCE_APPLICATION"); ReferenceConfig referenceConfig = new ReferenceConfig<>(); referenceConfig.setInterface(GreeterService.class); referenceConfig.setCheck(false); referenceConfig.setProtocol(CommonConstants.TRIPLE); referenceConfig.setTimeout(100000); DubboBootstrap bootstrap = DubboBootstrap.getInstance(); bootstrap.application(new ApplicationConfig("dubbo-demo-triple-api-consumer")) .registry(new RegistryConfig("zookeeper://127.0.0.1:2181")) .protocol(new ProtocolConfig(CommonConstants.TRIPLE, -1)) .reference(referenceConfig) .start(); while (true) { try { // wait user enter System.in.read(); // requestId String requestId = UUID.randomUUID().toString(); System.out.println("requestId=" + requestId); RpcContext.getClientAttachment().setAttachment("requestId", requestId); // send request final HelloReply reply = referenceConfig.get() .sayHello(HelloRequest.newBuilder().setName("triple").build()); System.out.println("Reply: " + reply.getMessage()); // responseId Object responseId = RpcContext.getClientResponseContext().getAttachment("responseId"); System.out.println("responseId=" + responseId); } catch (Exception e) { e.printStackTrace(); Thread.sleep(3000); } } } ``` ## 引入要了解Triple，还是得先了解一下HTTP2。这里不会长篇大论HTTP2，就说一下和dubbo中源码相关的内容。下图是根据案例抓的包： ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/019a35e7d93e42c7a1e92ba18ef4a4c8~tplv-k3u1fbpfcp-zoom-1.image) ### 流Stream和帧Frame 流：虚拟概念，建立在连接之上，支持双向通讯。每个连接上可以有多个流，每个流有一个StreamId标识。帧：传输数据的最小单元，每个帧包含StreamId标识，每个流上可以有多个帧。以37号Stream为例，37号Stream对应一轮unary请求+响应。 567和569对应客户端请求，将http请求头和请求体分为两个帧传输。 575和577对应服务端响应，将http响应头和响应体分为三个帧传输（2个HeaderFrame和1个DataFrame）。 ### 帧的结构一个Frame由两部分组成：Header（注意不是http请求头）和Payload。下图是No=567数据包，只发送了一个Frame，Payload是http请求头。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/15435d1aca00403cadb032e00379d9a1~tplv-k3u1fbpfcp-zoom-1.image) 下图是No=569数据包，只发送了一个Frame，Payload是http请求体。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a0e64c15918d41fdb88cd879f6c66d74~tplv-k3u1fbpfcp-zoom-1.image) 帧的Header固定**9个字节**长度： - **Length**：3个字节，表示Payload的长度，比如567数据包表示http头长度是49字节。 - **Type**：1个字节，表示Frame的类型。我们只需要关注两个类型，HEADER代表这个Frame对应http头，DATA代表http体。 - **Flags**：1个字节，一些标志位，最关键的是**EndStream**标志位。客户端发送EndStream=true，代表客户端请求已经发完了，等待服务端响应，服务端发送EndStream=true，代表服务端响应已经发完了，流可以关闭。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/869a53af8e5a4472a648a9d9802d83f1~tplv-k3u1fbpfcp-zoom-1.image) - Reserved：保留位，1个bit。 - **Stream Identifier**：Stream ID，标识当前帧属于哪个流，31个bit。 Payload我们只关注Header和Data类型。比如No=567，Frame类型是Header，Payload就是http请求头，其中就包括我们通过attachment设置的requestId。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3e322a52528d4bafa505ca3102ac8aa7~tplv-k3u1fbpfcp-zoom-1.image) 比如No=569，Frame类型是Data，Payload就是http请求体。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/611df31fbb5340da88ab266b4f57d2d3~tplv-k3u1fbpfcp-zoom-1.image) # 服务端（Unary） ## 暴露阶段通过前面几章的了解，直接定位到rpc协议层，TripleProtocol#export。 triple协议暴露分为几步： 1）封装**Invoker**为**Exporter**； > 这里invoker就是后续调用阶段的调用链（Filter->Proxy），最终调用到目标service方法。 2）将serviceKey和invoker的映射关系，保存到**PathResolver**； > 这个PathResolver就理解为springmvc中的RequestMappingHandlerMapping，管理接口路径到目标方法的映射关系。 3）初始化服务端线程池； > 一个port对应一个线程池，默认200线程数，之前提到过。 4）**PortUnificationExchanger**#bind开启底层Netty服务端；这里涉及到多协议端口复用的特性，我们后面再看。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/cc1c93d9bc2041b894f18ad8ab786a10~tplv-k3u1fbpfcp-zoom-1.image) ## 调用阶段跳过PU多协议端口复用相关逻辑，直接进入Triple协议逻辑。当客户端Channel注册完毕，触发**TripleHttp2Protocol#configServerProtocolHandler**配置Channel的pipeline。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/905f697a13b64a858072f4cc138adedc~tplv-k3u1fbpfcp-zoom-1.image) 所有逻辑都在各个ChannelHandler中，接下来我们重点关注几个核心的ChannelHandler。 - **Http2FrameCodec**：创建Stream抽象对象，负责ByteBuf与帧的转换，比如请求头帧、请求体帧，传递读写事件； - **Http2MultiplexHandler**：创建子Channel，将父Channel中的读写事件传播到子Channel中； - **TripleHttp2FrameServerHandler**：接收请求头帧和请求体帧，调用目标Invoker； - **TripleCommandOutBoundHandler**：Invoker返回值解析为响应头帧和响应体帧，写到父Channel； ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/07b79d71a0bc4619ae5f8ea7d97a5b0f~tplv-k3u1fbpfcp-zoom-1.image) ### 解码（Http2FrameCodec） Http2FrameCode继承ByteToMessageDecoder在收到ByteBuf时转换为帧Frame。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f5cd6eae10dc4b87a51d88a9339491cb~tplv-k3u1fbpfcp-zoom-1.image) DefaultHttp2FrameReader#processPayloadState：解析固定9字节长度Frame头，得到Frame类型，Payload长度等。在Triple中一次请求最少要有两个Frame，一个是请求头，一个是请求体。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/46cd4c3441fe4d1c8fb4a3f5133d6195~tplv-k3u1fbpfcp-zoom-1.image) 对于请求头来说，有一个比较关键的逻辑。 DefaultHttp2ConnectionDecoder.FrameReadListener#onHeadersRead：收到请求头后，会构造一个**Stream**，触发**Http2FrameStreamEvent**用户事件，这个事件会被Http2MultiplexHandler处理，下面再看。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/88c62617049549c5800ed46cee8a6de7~tplv-k3u1fbpfcp-zoom-1.image) Http2FrameCodec#onHttp2Frame：无论是HeaderFrame还是DataFrame，最终都会传递给下一个ChannelHandler。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2e73b995fc5844a6a083815f50d08fd8~tplv-k3u1fbpfcp-zoom-1.image) ### 父子转换（Http2MultiplexHandler） > An HTTP/2 handler that creates child channels for each stream. This handler must be used in combination with Http2FrameCodec. 这是javadoc里的描述，Http2MultiplexHandler的作用就是针对一个连接Channel，创建基于Stream的子Channel，**需要和Http2FrameCodec组合使用**。 #### 构造子Channel **Http2MultiplexHandler**#userEventTriggered：下一个Handler收到事件，创建子Channel，即**Http2MultiplexHandlerStreamChannel**。所以**一个tcp连接对应一个父Channel，一个tcp连接上可以有多个Stream，每个Stream对应一个子Channel**。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/faa17fc6ff0344d28d252e76e0d72771~tplv-k3u1fbpfcp-zoom-1.image)子Channel会和父Channel注册到同一个EventLoop上（Selector、同一个线程）。注册会触发子Channel的初始化，子Channel的pipeline会有两个核心ChannelHandler。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6cb0eac299864d7889ef416a2df2e92a~tplv-k3u1fbpfcp-zoom-1.image) #### 向子Channel传播read 根据Http2FrameCodec传来的StreamFrame，这里可以拿到Stream对应的子Channel，在子Channel中继续传播read。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a835dd7d4980464a8444463618447571~tplv-k3u1fbpfcp-zoom-1.image) ### 请求头处理（TripleHttp2FrameServerHandler）一个Netty的Stream对应一个TripleHttp2FrameServerHandler，一个TripleHttp2FrameServerHandler会对应一个TripleServerStream，之后很多逻辑都在**TripleServerStream**之中。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0bff5de6f2a6438998a728cb9c1d7260~tplv-k3u1fbpfcp-zoom-1.image) TripleHttp2FrameServerHandler#channelRead：终于来到了业务逻辑部分，此时我们在一个StreamChannel中。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c7962f478e8d41299e70c9aa6cf1ec46~tplv-k3u1fbpfcp-zoom-1.image) TripleHttp2FrameServerHandler#onHeadersRead：为当前Stream分配执行线程池，默认还是每个port对应200线程。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/65642a6155204e1b9063ac019e3b6cba~tplv-k3u1fbpfcp-zoom-1.image) TripleServerStream.ServerTransportObserver#onHeader： **线程切换**，netty的worker线程提交头处理任务到dubbo线程池。 > 如何保证请求头和请求体丢到线程池后**顺序处理**，见**SerializingExecutor**，思路和Netty的EventLoop差不多。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/54cb25e4320c4115a218741919d958c3~tplv-k3u1fbpfcp-zoom-1.image) TripleServerStream.ServerTransportObserver#processHeader： **收到请求头服务端主要是做一些数据准备**，我们只梳理比较核心的部分。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1cd5d2fbaebf4436becf8a430e3b8282~tplv-k3u1fbpfcp-zoom-1.image) **TripleServerStream#getInvoker**：根据请求头里的数据，**从PathResovler里定位Invoker**。 - 请求头path：如/org.apache.dubbo.demo.GreeterService/sayHello，可以拿到接口名； - 请求头tri-service-version：服务版本； - 请求头tri-service-group：服务分组； ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a558e122615f4106aaaf38aba3cf96e3~tplv-k3u1fbpfcp-zoom-1.image) **ReflectionAbstractServerCall** **#buildInvocation**：根据invoker中的url，**构造** **RpcInvocation**。注意，**请求头被放到attachment中**了，融入了dubbo的模型。此时RpcInvocation并不能直接执行，因为还没有请求体，没入参。 > 其实就是将一次rpc调用，分成了多阶段处理。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e141ce3f9ca94b8486bd033d91f2445b~tplv-k3u1fbpfcp-zoom-1.image) ### 请求体处理（TripleHttp2FrameServerHandler） TripleHttp2FrameServerHandler#onDataRead：收到请求体，还是交给TripleServerStream。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/274e4258f4274a1bb4e6345919883d83~tplv-k3u1fbpfcp-zoom-1.image) TripleServerStream.ServerTransportObserver#onData：同上线程切换。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/00ffa68627c74777ae89af015f9c909b~tplv-k3u1fbpfcp-zoom-1.image) TripleServerStream.**ServerTransportObserver#doOnData**： 1）反序列化请求体；2）如果客户端说流结束，执行rpc方法调用。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/233927809b494a458ee993a199048973~tplv-k3u1fbpfcp-zoom-1.image) #### 反序列化请求 **TriDecoder#processHeader**：在http头之下，triple和grpc一样，还有个头，固定5字节。 1个字节标记是否压缩，4个字节标识业务报文长度。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/eb1353bf73e249798a75eaa3e0b51256~tplv-k3u1fbpfcp-zoom-1.image) ReflectionAbstractServerCall#parseSingleMessage：这里反序列化有两个分支。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a87a9d20db5144fbb9990c8bd0d74daa~tplv-k3u1fbpfcp-zoom-1.image) **PbUnpack**：如果用IDL生成请求定义，直接走protobuf反序列化。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/015b2789a78e47388922862c81aebfc7~tplv-k3u1fbpfcp-zoom-1.image) ReflectionPackableMethod.**WrapRequestUnpack#unpack**：用普通pojo请求，走包装逻辑。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/02ea0d3346ec4b59949a9409b2ab1c10~tplv-k3u1fbpfcp-zoom-1.image) 本质上是proto定义了**TripleRequestWrapper**，包含序列化方式、参数列表、参数类型列表。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/82de140a15d54f1da9f102e9f1626ff4~tplv-k3u1fbpfcp-zoom-1.image) UnaryServerCallListener#onMessage：将参数列表注入RpcInvocation，至此所有数据准备完成。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a7fbf3c785fc4be2ac3f59e236f163eb~tplv-k3u1fbpfcp-zoom-1.image) #### 执行目标方法 UnaryServerCallListener#onComplete：普通的unary方式调用，一个请求一个响应。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5d8d01a74cd54c6483d7d5f9378fc519~tplv-k3u1fbpfcp-zoom-1.image) **AbstractServerCallListener#invoke**：最终执行Invoker调用，和原有逻辑一致。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/dbc54844991b4b4cbb6cfd9c448a4228~tplv-k3u1fbpfcp-zoom-1.image) ## 响应阶段 ### 业务线程 UnaryServerCallListener#onReturn：如果是异步方法，这里是用户定义线程池，如果是同步方法，这里还是DubboServerHandler线程。在这一步会再次发生线程切换，响应会提交到netty的worker线程 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e1e38173c92f497d87a9f5f8f43d9bde~tplv-k3u1fbpfcp-zoom-1.image) #### onNext ServerCallToObserverAdapter#onNext->AbstractServerCall#doSendMessage： 1）发送标准http响应头；2）发送序列化响应体 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e53c17da3a544d30a1994bfaa85b7240~tplv-k3u1fbpfcp-zoom-1.image) AbstractServerCall#sendHeader：发送http响应头，比如status、content-type等。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ed0aecb08d9a4358999296636a16637b~tplv-k3u1fbpfcp-zoom-1.image) 序列化同反序列化，如果通过IDL定义，走PbArrayPacker#pack，调用Message#toByteArray。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a90c266ff819486e996f06271bbbc3df~tplv-k3u1fbpfcp-zoom-1.image) 否则走pojo包装WrapResponsePack#pack。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/780f6e8131854177971488c4607e35af~tplv-k3u1fbpfcp-zoom-1.image) #### onCompleted ServerCallToObserverAdapter#onCompleted->TripleServerStream#complete：这里会再发送一部分响应头，称为**trailer**。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a7bd29670c894da0aaaaf41f5100b67c~tplv-k3u1fbpfcp-zoom-1.image) trailer中包含服务端给客户端的**attachment**，即RpcContext.getServerResponseContext。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ee58413384d04fbe869bf88270adfa41~tplv-k3u1fbpfcp-zoom-1.image) 并且这个Frame会被标记上**endStream**，告知客户端当前流已经结束。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fcdfcf0bcea64c0c859ced5acf889ce7~tplv-k3u1fbpfcp-zoom-1.image) #### 提交 BatchExecutorQueue#enqueue：头和体都会封装为一个Command，提交到TripleWriteQueue。 TripleWriteQueue是个性能优化，支持批量flush，减少用户线程和io线程切换次数。（见issue#10915） ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/57fd7bee14fb441380007f101b7dfbf5~tplv-k3u1fbpfcp-zoom-1.image) ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7d4428327166475fbae4404d0c10fbc7~tplv-k3u1fbpfcp-zoom-1.image) Command提交到channel对应EventLoop上。具体run方法细节不看了，就是优先channel.write(command)，如果queue中没数据了，再channel.flush。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8ec39ec97fe841d2b36b121f32a8770f~tplv-k3u1fbpfcp-zoom-1.image) ### netty线程 #### TripleCommandOutBoundHandler 上面channel对应子channel，来到子channel的TripleCommandOutBoundHandler。执行不同Command的send方法。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7dacec6ea7124c4296b837f750434ce4~tplv-k3u1fbpfcp-zoom-1.image) **HeaderQueueCommand**：封装**DefaultHttp2HeadersFrame**头帧。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6030ae4018ac458c89f0ae9c34cb4536~tplv-k3u1fbpfcp-zoom-1.image) **DataQueueCommand**：封装**DefaultHttp2DataFrame**数据帧，和grpc一致。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/01519a9710964d1799546d77d3ccf0a9~tplv-k3u1fbpfcp-zoom-1.image) #### 子父转换（Http2ChannelUnsafe）最终无论write还是flush，都会从Stream子Channel传播到父Channel。 AbstractHttp2StreamChannel.Http2ChannelUnsafe#writeHttp2StreamFrame： ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0d06f43dbd034416b8a4311e87ec5035~tplv-k3u1fbpfcp-zoom-1.image) AbstractHttp2StreamChannel.Http2ChannelUnsafe#flush： ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1591eb74ca9c44238b9ed6fff6986a9a~tplv-k3u1fbpfcp-zoom-1.image) #### 编码（Http2FrameCodec） Http2FrameCodec#write：回到父channel后，netty提供的http2编码器将DataFrame和HeadersFrame编码。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9fee3382a9324a5590210764fce74528~tplv-k3u1fbpfcp-zoom-1.image) # 客户端（Unary） ## 引用阶段 TripleProtocol#refer： 1）初始化consumer共享线程池； 2）创建netty客户端，与对端建立连接； 3）封装TripleInvoker返回； ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/df28d60a16bc45749342813b74446fc9~tplv-k3u1fbpfcp-zoom-1.image) 当客户端与服务端建立连接完成，**TripleHttp2Protocol#configClientPipeline**配置客户端channel的pipeline。其中包括了两个和服务端一样的netty http2 handler组件： - **Http2FrameCodec**：在read和write过程中，ByteBuf与Frame帧转换； - **Http2MultiplexHandler**：在子channel的pipeline中传播帧； ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ec4ee578acec4a7b97e04587438e4977~tplv-k3u1fbpfcp-zoom-1.image) ## 调用阶段 TripleInvoker#doInvoke：对于unary调用方式，走TripleInvoker#invokeUnary。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/13693c7949474d298153b22c354da2b6~tplv-k3u1fbpfcp-zoom-1.image) TripleInvoker#invokeUnary：核心方法在最后三行。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9592e5c4b7b44a95be9238e346da1e7c~tplv-k3u1fbpfcp-zoom-1.image) ### 子channel注册 TripleClientCall#start：核心方法是构造**TripleClientStream**抽象，和server端的TripleServerStream可以类比。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/149af4d1828a492fb2ba4c6709ef6696~tplv-k3u1fbpfcp-zoom-1.image) 在TripleClientStream构造阶段，TripleClientStream#initHttp2StreamChannel做了很重要的操作。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d090c74202c5408b9f4a627360f0a7d3~tplv-k3u1fbpfcp-zoom-1.image) **TripleClientStream#initHttp2StreamChannel**：利用netty的**Http2StreamChannelBootstrap**创建子channel。 1）bootstrap#handler：为子channel定义pipeline，当子channel注册到EventLoop上之后触发； 2）CreateStreamQueueCommand：提交到io线程，执行子channel创建和注册； ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/cead04dc077649bc9c307ac045db6bd9~tplv-k3u1fbpfcp-zoom-1.image)Http2StreamChannelBootstrap#open0：创建Stream并创建子StreamChannel，注册到父channel的EventLoop上。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/84eb78a749d544b380737878625fd0af~tplv-k3u1fbpfcp-zoom-1.image) ### 发送请求 **StreamObserver#onNext**->TripleClientCall#sendMessage：将请求头和请求体封装为Command提交到io线程，和server端类似，不再赘述。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9f1c91cc2c3e4518a7f34dee571df1a7~tplv-k3u1fbpfcp-zoom-1.image) **StreamObserver#onCompleted**->TripleClientStream#halfClose：发送一个frame，包含endStream标识，告知服务端本次请求已经发送完成。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4a9ef0033c4546f9be2cfd930fbe77e5~tplv-k3u1fbpfcp-zoom-1.image) 本质上EndStreamQueueCommand会转换为只包含endStream=true的空DataFrame。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8ec4c96ee05c4850b5a5995be3ae0435~tplv-k3u1fbpfcp-zoom-1.image) **为什么抓包客户端只有2个frame给服务端，而这里看到有3个frame？** 因为在流控里有merge操作，支持将同类型frame合并。比如DataFrame合并，DefaultHttp2ConnectionEncoder.FlowControlledData#merge。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/76dcd0061acb4aa7985e9ca912594fb9~tplv-k3u1fbpfcp-zoom-1.image) 如果赶的巧业务线程提交Command在一批里，那么就能执行合并。 TripleClientCall#halfClose：比如这里业务线程故意睡一秒，netty的io线程就会先发送2个frame过去，随后业务线程提交EndStreamQueueCommand，会发送一个无payload帧到对端。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/86fe1e6f638647a591bf9e79b62fb3bc~tplv-k3u1fbpfcp-zoom-1.image) ## 响应阶段和server端请求阶段类似。 Http2FrameCodec将ByteBuf转换为Frame； Http2MultiplexHandler找到streamId对应子Channel，传播Frame。 TripleHttp2ClientResponseHandler#channelRead0：收到server端返回Frame。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ded1b70a23394b86bf7c12fc5602a25b~tplv-k3u1fbpfcp-zoom-1.image) 根据收到的frame类型不同，走不同逻辑，最终都会来到**UnaryClientCallListener**。当收到数据，设置反序列化后的appResponse；当收到trailer（endStream），完成future。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6741e60c166c4dfc94de1748c4432ff8~tplv-k3u1fbpfcp-zoom-1.image) org.apache.dubbo.rpc.protocol.AbstractInvoker#waitForResultIfSync，2.x的AsyncToSyncInvoker被优化调了，异步适配同步的逻辑内聚到AsyncRpcResult。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8e388a4398a145ad8ac144e5acc56d87~tplv-k3u1fbpfcp-zoom-1.image) # 流调用 ## 案例 ### ServerStream 服务端流，简单理解：一轮rpc调用，一个客户端请求，对应多个服务端响应（Stream）。提供者实现：针对每个HelloRequest返回5个HelloReply。 ``` @Override public void sayMultiHello1(HelloRequest request/*客户端请求*/, StreamObserver responseStream/*响应流*/) { System.out.println("sayMultiHello1[" + Thread.currentThread().getName() + "] request = " + request); for (int i = 0; i < 5; i++) { responseStream.onNext(HelloReply.newBuilder().setMessage("Hello " + request.getName() + i).build()); try { Thread.sleep(500); } catch (InterruptedException e) { throw new RuntimeException(e); } } System.out.println("sayMultiHello1 complete..."); responseStream.onCompleted(); } ``` 消费者： ``` private static void serverStreamCall(ReferenceConfig referenceConfig) { GreeterService greeterService = referenceConfig.get(); while (true) { try { System.in.read(); CountDownLatch cdl = new CountDownLatch(1); greeterService.sayMultiHello1( // 请求参数 HelloRequest.newBuilder().setName("ServerStream").build(), // 响应流仅打印server返回 new StdoutObserver<>(cdl)); // 等待server complete cdl.await(); } catch (Exception e) { e.printStackTrace(); } } } ``` 消费者接收服务端响应流输出： ``` static class StdoutObserver implements StreamObserver { private final CountDownLatch countDownLatch; public StdoutObserver() { this(new CountDownLatch(0)); } public StdoutObserver(CountDownLatch countDownLatch) { this.countDownLatch = countDownLatch; } @Override public void onNext(T data) { System.out.println(Thread.currentThread().getName() + " Server Reply: " + data); } @Override public void onError(Throwable throwable) { System.out.println(Thread.currentThread().getName() + " Server Error: " + throwable.getMessage()); countDownLatch.countDown(); } @Override public void onCompleted() { System.out.println(Thread.currentThread().getName() + " Server complete"); countDownLatch.countDown(); } } ``` 客户端输出：注意处理服务端响应的线程是consumer公用线程池。 ``` DubboServerHandler-xxx:50051-thread-32 Server Reply: message: "Hello ServerStream0" DubboServerHandler-xxx:50051-thread-33 Server Reply: message: "Hello ServerStream1" DubboServerHandler-xxx:50051-thread-34 Server Reply: message: "Hello ServerStream2" DubboServerHandler-xxx:50051-thread-35 Server Reply: message: "Hello ServerStream3" DubboServerHandler-xxx:50051-thread-36 Server Reply: message: "Hello ServerStream4" DubboServerHandler-xxx:50051-thread-37 Server complete ``` 服务端输出： ``` sayMultiHello1[DubboServerHandler-xxx:50051-thread-1] request = name: "ServerStream" sayMultiHello1 complete... ``` ### ClientStream/BiStream 客户端流（双向流），简单理解：一轮rpc调用，包含多个客户端请求，对应多个服务端响应。提供者实现：入参是响应流，出参是请求流。每个HelloRequest对应一个HelloReply，在客户端complete后，回复一个Bye，服务端执行complete。 ``` public StreamObserver/*请求流*/ sayMultiHello2(StreamObserver responseStream/*响应流*/) { System.out.println("sayMultiHello2当前线程:" + Thread.currentThread().getName()); return new StreamObserver() { @Override public void onNext(HelloRequest request) { System.out.println("sayMultiHello2.onNext[" + Thread.currentThread().getName() + "] request: " + request); responseStream.onNext(HelloReply.newBuilder().setMessage("Hello " + request.getName()).build()); } @Override public void onError(Throwable throwable) { throwable.printStackTrace(); } @Override public void onCompleted() { System.out.println("sayMultiHello2.onCompleted[" + Thread.currentThread().getName() + "]"); responseStream.onNext(HelloReply.newBuilder().setMessage("Bye!!!").build()); responseStream.onCompleted(); } }; } ``` 客户端：对于服务端响应仅输出打印，发送5个HelloRequest后complete。 ``` private static void clientStreamCall(ReferenceConfig referenceConfig) { while (true) { try { System.in.read(); GreeterService greeterService = referenceConfig.get(); StreamObserver requestStream = greeterService.sayMultiHello2(new StdoutObserver<>()); for (int i = 0; i < 5; i++) { requestStream.onNext(HelloRequest.newBuilder().setName("ClientStream" + i).build()); Thread.sleep(200); } requestStream.onCompleted(); } catch (Exception e) { e.printStackTrace(); } } } ``` 客户端输出： ``` DubboServerHandler-xxx:50051-thread-1 Server Reply: message: "Hello ClientStream0" DubboServerHandler-xxx:50051-thread-2 Server Reply: message: "Hello ClientStream1" DubboServerHandler-xxx:50051-thread-3 Server Reply: message: "Hello ClientStream2" DubboServerHandler-xxx:50051-thread-4 Server Reply: message: "Hello ClientStream3" DubboServerHandler-xxx:50051-thread-5 Server Reply: message: "Hello ClientStream4" DubboServerHandler-xxx:50051-thread-6 Server Reply: message: "Bye!!!" DubboServerHandler-xxx:50051-thread-7 Server complete ``` 服务端输出： ``` sayMultiHello2当前线程:DubboServerHandler-xxx:50051-thread-22 sayMultiHello2.onNext[DubboServerHandler-xxx:50051-thread-23] request: name: "ClientStream0" sayMultiHello2.onNext[DubboServerHandler-xxx:50051-thread-24] request: name: "ClientStream1" sayMultiHello2.onNext[DubboServerHandler-xxx:50051-thread-25] request: name: "ClientStream2" sayMultiHello2.onNext[DubboServerHandler-xxx:50051-thread-26] request: name: "ClientStream3" sayMultiHello2.onNext[DubboServerHandler-xxx:50051-thread-27] request: name: "ClientStream4" sayMultiHello2.onCompleted[DubboServerHandler-xxx:50051-thread-28] ``` ## 小总结 **无论是哪种Stream，在http2层面上，只要不发送endStream=true的帧，当前端（client/server）就可以持续发送数据**。 **所以unary可以认为是stream的特例，双向流StreamObserver调用被dubbo框架托管，由框架主动调用StreamObserver的onNext和onCompleted**。此外，无论哪种Stream，无论在服务端还是在客户端，在方法层面上： **入参StreamObserver是响应流处理，出参StreamObserver是请求流处理，StreamObserver是dubbo框架提供给用户的操作流的api**。 ## 客户端对于客户端来说，unary/serverStream/clientStream/biStream的区别在于TripleInvoker#doInvoke。第一点，对于stream调用，**所有服务端流StreamObserver默认都用consumer公共线程池处理**。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/cf58b1f95bf14e2b9530fc5bcb7b4c37~tplv-k3u1fbpfcp-zoom-1.image) ### ServerStream 对于serverStream： 1）和unary相同，由dubbo框架发送请求，执行客户端Stream的onNext和onCompleted调用，发送请求和endStream； 2）与unary不同，返回AsyncRpcResult中的CompletableFuture是已完成状态，不会阻塞业务线程（unary同步调用需要阻塞等待响应）； ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/145c21f0f3b848328c0a87e6d5d82ee8~tplv-k3u1fbpfcp-zoom-1.image) ### ClientStream/BiStream 对于clientStream/biStream： 1）与unary不同，由用户代码通过出参StreamObserver发送onNext/onCompleted，以此实现客户端流； 2）与unary不同，返回AsyncRpcResult中的CompletableFuture是已完成状态，包含客户端流StreamObserver，不会阻塞业务线程； ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4905f51066864602bb643c1d1d278690~tplv-k3u1fbpfcp-zoom-1.image) 出参客户端流StreamObserver和unary一致，都是**ClientCallToObserverAdapter，onNext发送请求，onCompleted发送endStream** **，都是流操作api**。此外还要强调一点，**同一个Stream，客户端只会在第一个onNext中发送请求头**，针对ClientStream和BiStream就很重要。 TripleClientCall#sendMessage： ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/93dd4eb335fe43fd9c1838b53cfff205~tplv-k3u1fbpfcp-zoom-1.image) ### Stream共同点 stream的共同点在于**TripleInvoker#streamCall**。 stream传入TripleClientCall#start的是**ObserverToClientCallListenerAdapter**，主要作用是回调入参StreamObserver响应流处理器，让客户端接收服务端响应。 unary传入TripleClientCall#start的是**UnaryClientCallListener**，主要作用是收集server端响应，设置future结果。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4ef9376815c848159b17dcc8180cb578~tplv-k3u1fbpfcp-zoom-1.image) **ObserverToClientCallListenerAdapter**收到对端响应，回调方法入参StreamObserver。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2d47878b313e4a7db58fc71f753c0d92~tplv-k3u1fbpfcp-zoom-1.image) ## 服务端对于服务端来说，区别在于收到http请求头后，执行**AbstractServerCall#startInternalCall**，做一些准备工作。注意ClientStream和BiStream情况下，只会收到一个http请求头。无论是那种rpcType，都会构造响应流responseObserver，只不过unary是托管框架调用流api。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0da9d29b33b4483494277ea175192a57~tplv-k3u1fbpfcp-zoom-1.image) ### ServerStream ServerStream和Unary类似的点在于，需要收到完整的客户端请求后，才执行目标方法。区别在于ServerStream方法入参需要传入给用户代码使用的ObserverStream流api，用于响应客户端。 ServerStreamServerCallListener#onMessage：当收到http请求body，ServerStream和Unary一致，设置方法入参。区别在于方法入参除了客户端的请求message之外，还注入了框架提供的流api，即ObserverStream响应流。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bf2a0793faba4d47a1bf2caf6a591e01~tplv-k3u1fbpfcp-zoom-1.image) ServerStreamServerCallListener#onComplete：当收到endStream帧后，执行目标方法。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f940ab92dae54674b038b94410a391c4~tplv-k3u1fbpfcp-zoom-1.image) ServerStreamServerCallListener#onReturn：目标方法执行完毕，不需要处理响应结果。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ca196c2704be45c0a2d4b067e6412988~tplv-k3u1fbpfcp-zoom-1.image) ### ClientStream/BiStream 双向流比较特殊的一点是，在收到http请求头时，就执行了业务方法，拿到业务返回的请求流ObserverStream。和ServerStream一样，入参设置为响应流ObserverStream。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b1dc9c7f21c04a4798780fb2002cdd55~tplv-k3u1fbpfcp-zoom-1.image) ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f139a7bb4a9648d693dfefe0bb65c389~tplv-k3u1fbpfcp-zoom-1.image) 当收到http请求体时，回调请求流的onNext方法。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ace055526fc348eb91344fb6a32e8c82~tplv-k3u1fbpfcp-zoom-1.image) 当收到客户端endStream时，回调请求流的onCompleted方法。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8dc21e4b69194c75b48d05dfa8294e13~tplv-k3u1fbpfcp-zoom-1.image) # grpc打通 ## 案例官网说triple与grpc直接打通，可以来验证一下。书写一个proto定义，与官方dubbo-demo-triple的区别在于： 1）package与javapackage一致； 2）新增GreeterService定义； ``` syntax = "proto3"; package org.apache.dubbo.demo; message HelloRequest { string name = 1; } message HelloReply { string message = 1; } service GreeterService { rpc sayHello(HelloRequest) returns (HelloReply); } ``` 这里直接用Postman做客户端来验证，导入proto。注：如果要用dubbo客户端来验证，需要服务提供者主动开启triple+grpc多协议，这样不能确定triple与grpc完全互通。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d3eb63f0df20434aa1b8519b7a94dec8~tplv-k3u1fbpfcp-zoom-1.image) 看到triple协议能够正常响应grpc请求。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6ee73a2750214b32a88fdec8f31c770c~tplv-k3u1fbpfcp-zoom-1.image) ## 原理本质上grpc协议完全继承自triple协议，且按照工程结构划分，grpc被分在dubbo-rpc-triple模块之中。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/10295ac9f8794bf09db37e3f2938023e~tplv-k3u1fbpfcp-zoom-1.image) ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/be66dd27438b435e872544dcf897c28e~tplv-k3u1fbpfcp-zoom-1.image) 所以grpc可以认为是triple的一种特例。 # Stub 这里说的Stub不是本地存根特性，而是基于**dubbo-compiler**生成像grpc一样的Stub。 ## 案例这里引用dubbo-samples项目下的dubbo-samples-triple模块。书写IDL。 ``` message GreeterRequest { string name = 1; } message GreeterReply { string message = 1; } service Greeter{ rpc greet(GreeterRequest) returns (GreeterReply); } ``` 使用dubbo-compiler生成Stub。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/cad4f0b8bf974324bf4e273b4ac1b244~tplv-k3u1fbpfcp-zoom-1.image) 生成服务端**GreeterImplBase**。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/af2536606e22403cbf281404c9674e9b~tplv-k3u1fbpfcp-zoom-1.image) 服务端，**GreeterImpl**继承compiler生成的GreeterImplBase，实现业务逻辑。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6ea4d1f5f66e4fb4ab5173c555a6b5ef~tplv-k3u1fbpfcp-zoom-1.image) 客户端，直接引用生成的Greeter。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d295f2f74eb44840bf44709fe6b4fa73~tplv-k3u1fbpfcp-zoom-1.image) ## 服务端 ### 启动阶段 ServiceConfig#buildAttributes会解析服务端实现类实现**ServerService**，会设置使用nativeStub对应ProxyFactory，在创建Invoker时，不走javasist实现，走**StubProxyFactory**。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1227dc507e0d4df98469a4eec51304fa~tplv-k3u1fbpfcp-zoom-1.image) StubProxyFactory会返回通过Stub构造的Invoker。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c78192589fb440978b74ab78d3114d54~tplv-k3u1fbpfcp-zoom-1.image) GreeterImplBase#getInvoker：生成StubInvoker，里面包含path到目标方法的映射关系。 ``` private static final StubMethodDescriptor greetMethod = new StubMethodDescriptor("greet", org.apache.dubbo.sample.tri.GreeterRequest.class, org.apache.dubbo.sample.tri.GreeterReply.class, serviceDescriptor, MethodDescriptor.RpcType.UNARY, obj -> ((Message) obj).toByteArray(), obj -> ((Message) obj).toByteArray(), org.apache.dubbo.sample.tri.GreeterRequest::parseFrom, org.apache.dubbo.sample.tri.GreeterReply::parseFrom); @Override public final Invoker getInvoker(URL url) { PathResolver pathResolver = url.getOrDefaultFrameworkModel() .getExtensionLoader(PathResolver.class) .getDefaultExtension(); // 标记path对应nativeStub Map> handlers = new HashMap<>(); pathResolver.addNativeStub( "/" + SERVICE_NAME + "/greet" ); // 将业务实现的greet方法，存储到StubInvoker BiConsumer> greetFunc = this::greet; handlers.put(greetMethod.getMethodName(), new UnaryStubMethodHandler<>(greetFunc)); return new StubInvoker<>(this, url, Greeter.class, handlers); } ``` 同样的TripleProtocol会将层层包装后的StubInvoker加入到PathResolver中。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5a437f02da764843acdf1ba6a92e035e~tplv-k3u1fbpfcp-zoom-1.image) ### 运行阶段运行阶段通过PathResolver拿到StubInvoker，最终进入目标方法。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/282027fa3e2d438e8a0d4e99bae0d5b8~tplv-k3u1fbpfcp-zoom-1.image) ## 客户端 ### 启动阶段客户端需要设置Reference的proxy为nativeStub。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a348c10f1d844c0c8a40a19e4ab60839~tplv-k3u1fbpfcp-zoom-1.image) ReferenceConfig#init：这个阶段识别proxy=nativeStub，做了特殊处理。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/738da54f8a9b44ecb742bef8f5e6e3db~tplv-k3u1fbpfcp-zoom-1.image) StubSuppliers#getServiceDescriptor：主动加载**Dubbo+接口名+Triple**这个类。这个类就是由dubbo-complier生成的。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/97097fd274fb4a4989e74d37938bac1d~tplv-k3u1fbpfcp-zoom-1.image) 比如Greeter接口对应DubboGreeterTriple这个类，在静态代码块中将构造Stub方法和service描述都注册到全局map中。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/287d2e47c57b4cbf85b1d03bbdb3de53~tplv-k3u1fbpfcp-zoom-1.image) newStub方法如下，将invoker用GreeterStub包装。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/204f4e3400714f1681b2c88d42fcab61~tplv-k3u1fbpfcp-zoom-1.image) 在引用的最后阶段，通过StubProxyFactory，用GreeterStub包装invoker作为客户端代理。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f99c4fef83984dc4abcfd109abe5370c~tplv-k3u1fbpfcp-zoom-1.image) ### 运行阶段 GreeterStub运行阶段，走StubInvocationUtil。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7573ce4395b945c7b340249cc84d70e9~tplv-k3u1fbpfcp-zoom-1.image) StubInvocationUtil#call：组装RpcInvocation，最终走和非stub一样的InvocationUtil.invoke。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3268d38b33074b02a20eacaa7d118a49~tplv-k3u1fbpfcp-zoom-1.image) # 端口协议复用（PU）这个端口协议复用主要是针对服务端，目前主要针对dubbo和triple（grpc）协议。因为单独用triple，也会走这段逻辑，所以提一下端口协议复用的实现方式。在**NettyPortUnificationServer**开启时，定义了客户端建立连接后的pipeline中只有**NettyPortUnificationServerHandler**。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f958702752d84db7ba06b4f3a4a4b0f2~tplv-k3u1fbpfcp-zoom-1.image) **NettyPortUnificationServerHandler#decode**： 1）在首次收到请求时，会循环所有WireProtocol，找到一个可以处理这个Bytebuf的WireProtocol； 2）执行这个WireProtocol的configServerProtocolHandler方法定义pipeline； 3）最后将自己NettyPortUnificationServerHandler从pipeline中移除； ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9cd39ca23e36474c95a15cff4a64e32f~tplv-k3u1fbpfcp-zoom-1.image) 对于Triple协议来说。 **Http2ProtocolDetector**需要读到客户端发送**PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n**这个数据包，才能识别为http2协议。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e61138c4cb9c4a9a9375cdf5a97dd99b~tplv-k3u1fbpfcp-zoom-1.image) **那么客户端什么时候会发送这个数据包呢？** 当客户端连接成功，pipeline中加入**Http2FrameCodec**就会触发。 Http2ConnectionHandler.PrefaceDecoder#sendPreface：从注释来看，这段称为**preface**的数据包必须作为第一波数据发送到服务端。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/be8e27d6022243d292d6981bd55ab291~tplv-k3u1fbpfcp-zoom-1.image) # 总结 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ff1baec71a0b418eb55972c4fdb2a074~tplv-k3u1fbpfcp-zoom-1.image) Triple协议在暴露阶段，将path（serviceKey）和invoker的映射关系保存到PathResolver用，供运行时反查。特殊的，如果采用Stub，底层invoker是StubInvoker，StubInvoker中包含path到具体方法的映射关系。 Triple协议在引用阶段，与服务端建立连接，封装为TripleInvoker，供运行时调用。无论是客户端还是服务端，netty的pipeline都类似。 **主channel（连接纬度）** ： 1）**Http2FrameCodec**：netty提供，在read和write过程中，ByteBuf与Frame帧转换； 2）**Http2MultiplexHandler**：netty提供，和Http2FrameCodec配合使用，在子channel的pipeline中传播帧； **子channel（流纬度）** ： 1）**TripleHttp2FrameServerHandler**：server端，重点在于read，接收请求头和请求体，根据unary/stream调用方式不同，走不同逻辑，调用业务方法； 2）**TripleHttp2ClientResponseHandler**：client端，重点在于read，接收响应，根据unary/stream调用方式不同，走不同逻辑； 3）**TripleCommandOutBoundHandler**：通用，将业务Command（http头/体/endStream）write/flush到子channel；（子channel具备write到父channel的能力，见AbstractHttp2StreamChannel） **何时创建Stream/子Channel**： 1）客户端：发起调用时会创建Stream并创建子Channel，注册子Channel到父Channel（TripleClientStream#initHttp2StreamChannel）； 2）服务端：Http2FrameCodec收到请求头，根据头帧（注意不是请求头）中的客户端提供的streamId，创建一个Stream，封装为一个Http2FrameStreamEvent事件发送。Http2MultiplexHandler收到Http2FrameStreamEvent事件，创建子channel，并注册到父channel； **unary/serverStream/client(bi)Stream**：本质上unary和stream调用的区别在于，unary由dubbo框架主动操作**StreamObserver**流api，而stream由用户操作StreamObserver流api。 - **onNext**：发送请求/接收请求，注意，**http请求头在一个stream中只能发送一次**，这是由客户端实现的。 - **onCompleted**：发送endStream/接收endStream，**只要在当前端不发送endStream帧之前，当前端都可以持续onNext发送数据**。 **StreamObserver在使用上**： **方法入参StreamObserver是响应流**，对于客户端来说接收响应，对于服务端来说发送响应。 **方法出参StreamObserver是请求流**，对于客户端来说发送请求，对于服务端来说接收请求。 **unary**： 1）客户端：调用直接触发请求流onNext和onCompleted，发送所有数据，同步调用等待future完成 2）服务端：接收到请求头，构造部分RpcInvocation 3）服务端：接收到请求体，反序列化，执行目标方法 4）服务端：目标方法执行完毕，执行响应流onNext和onCompleted（trailer头包含attachment） 5）客户端：收到响应体，反序列化，存储在UnaryClientCallListener 6）客户端：收到trailers（endStream），UnaryClientCallListener完成future **serverStream**： 1）客户端：调用直接触发请求流onNext和onCompleted，发送所有数据，业务线程直接返回 2）服务端：接收到请求头，构造部分RpcInvocation 3）服务端：接收到请求体，反序列化，执行目标方法，目标方法由用户代码调用响应流onNext和onCompleted 4）客户端：收到响应体，反序列化，执行入参响应流StreamObserver#onNext回调 5）客户端：收到endStream，执行入参响应流StreamObserver#onCompleted回调 **client(bi)Stream**： 1）客户端：调用立即返回请求流ObserverStream，客户端按需通过请求流onNext和onCompleted发送请求 2）服务端：收到请求头，立即执行目标方法，传入响应流ObserverStream，返回请求流ObserverStream 3）客户端/服务端：都可以通过ObserverStream#onNext向对端发送数据，对端通过ObserverStream#onNext收到数据 4）客户端/服务端：都可以通过ObserverStream#onCompleted向对端发送endStream结束流；对端通过ObserverStream#onCompleted收到endStream **普通pojo模型进行triple调用**：简单点来说，如果模型没有实现com.google.protobuf.Message接口，则使用dubbo框架内部通用TripleRequestWrapper包装请求参数，也就实现了Message接口， **TripleRequestWrapper**，包含序列化方式、参数列表、参数类型列表。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f1680cfce343460f9e34c34f62f5c39f~tplv-k3u1fbpfcp-zoom-1.image) **关于grpc**：从代码层面，GrpcProtocol完全继承TripleProtocol，所以Triple的实现完全兼容了grpc。 **关于stub**：通过dubbo-compiler可以生成stub。服务端StubProxyFactory创建Invoker，走生成的serviceBase#getInvoker生成StubInvoker，运行时走StubInvoker执行目标方法。客户端StubProxyFactory创建客户端代理，会生成接口Stub，运行时走接口Stub执行远程调用。 **关于PU端口协议复用特性**：用Triple协议一定会走端口复用逻辑。当服务端收到客户端首次数据包时，**NettyPortUnificationServerHandler**循环所有**WireProtocol**识别ByteBuf，如果某个WireProtocol能够识别，则交由WireProtocol重新配置pipeline，并将NettyPortUnificationServerHandler从pipeline中移除。针对http2协议，客户端在建立连接时，**Http2FrameCodec**会发送**PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n**数据包，服务端就能识别到当前channel是Triple协议。 > 欢迎大家评论或私信讨论问题。 > > 本文原创，未经许可不得转载。 > > 欢迎关注公众号【程序猿阿越】。