gRPC & netty
背景
- 开发MQ测试环境多版本引流功能，复用RocketMQ的remoting模块netty通信模块，client以近原生的方式请求元信息服务控制消息引流
- 开发故障检测过程中使用gRPC通信能力，java-gRPC底层默认由netty实现
- SkyWalking多版本链路传递功能，学习SkyWalking通信部分设计
gRPC简介
一个高性能、开源通用RPC框架
亮点
CNCF孵化中
gRPC使用protobuf作为
从protobuf开始
protubuf是gRPC中的核心概念之一，gRPC使用protobuf同时作为接口定义语言（IDL）和底层消息交换的序列化结构（实际上也可以替换为json等），protobuf中即可以定义rpc（端点），也可以定义数据结构，也支持目录包引用、oneof、enum等特性，protobuf的定义和常用的编程语言数据结构还是有些区别的，例如没有继承关系（protobuf3不再支持extend，实际上可以通过oneof关键字曲线救国）
以下面故障检测服务的其中一个protobuf定义为例，import可以从其他包下引入定义，option则是代码生成的一些选项，service下定义了一个rpc：StreamChannel，入参和出参都是stream类型，表示是双向流；enum和message的数据结构中都由Field var=number的格式组成，其中number的值会在序列化时转成二进制，用来表示字段code。protobuf序列化时number在1~15时占用1个字节，16~2047会占用2个字节，所以最佳实践是把前15的序号保留给最常使用的字段。
syntax = "proto3";
import "command/server/register.proto";
import "command/client/thread_snapshot.proto";
import "command/client/profile.proto";
import "command/server/hot_thread.proto";
package com.enmonster.platform.hts.grpc;
option java_multiple_files = true;
option java_package = "com.enmonster.platform.hts.grpc";
option java_outer_classname = "CommandDispatcherRPC";
service CommandDispatcher {
// 双向流，server和client可互相通讯
rpc StreamChannel (stream StreamDataPackage) returns (stream StreamDataPackage) {}
}
// 保证向前兼容，添加命令请勿修改已有命令的field_value
enum Command {
REGISTER = 0; // client注册到server
RECORD_HOT_THREAD = 1; // 记录热点线程
// 以上为server端支持的命令，以下为client端支持的命令
THREAD_SNAPSHOT = 11; // 采集线程快照
PROFILE = 12; // 开始async-profiler采样
}
// 双向流的逻辑数据包，response_body为空表示是请求，不为空表示是响应
message StreamDataPackage {
string job_id = 1; // 命令所属的job id
Command command = 2; // 命令
string client_ip = 3; // 客户端ip, aka node ip
oneof request { // 命令请求payload
RegisterRequest register_request = 10;
ThreadSnapshotRequest thread_snapshot_request = 11;
HotThreadRequest hot_thread_request = 12;
ProfileRequest profile_request = 13;
}
BaseResponse response = 20; // 命令响应payload，不为null表示是命令结果，否则是命令请求
}
message BaseResponse {
bool ok = 1; // 是否成功
string message = 2; // 消息
// 命令结果body
oneof body {
RegisterResponse register_response = 3;
ThreadSnapshotResponse thread_snapshot_response = 4;
HotThreadResponse hot_thread_response = 5;
ProfileResponse profile_response = 6;
ProfileResultResponse profile_result_response = 7;
}
}
大部分字段类型都和常用编程语言类型相似，包括支持map<string, string>表示map、repeated表示数组等，同时也支持复用包里的数据结构，例如google.protobuf.Timestamp
编译protobuf
protobuf的优势在于其是跨平台、跨语言的DSL，比高级编程语言更抽象一级，所以写起来非常简洁（有点像写java接口哈）。这就意味着protobuf+grpc编译后的产物是高级编程语言（java、python、go、c/cpp……），有点像前端的.vue编译成css、js，不过感觉抽象级别更高一些。
这里以java编译为例，引入protobuf-maven-plugin插件执行compile就可以得到编译后的java文件（也可以直接用protoc二进制编译器，实际上这个maven插件也是去执行protoc编译的）
填充自己的业务逻辑吧
编译后的代码中可以看见对应的java类中已经有了完整的gRPC底层通讯逻辑，包括定义的RPC端点，几种同步异步的stub可以直接调用，各种数据结构的builder等，使用时可以非常方便地继承生成的ImplBase类，填充对应handler的逻辑。
可以把protobuf定义单独打到一个maven模块，server和client去引相同的依赖包，以保证版本的一致性和复用。因为是BI_DI类型的rpc，client的逻辑和server就很类似了，初始由client去主动连接server，我这里因为需要上报client的信息做了心跳保活，实际上因为gRPC基于HTTP/2的特性，如果没有显式地设置deadline/timeout，流式的rpc是可以一直传输的，而不用使用HTTP/1.X去轮询或者定时hold长链接。
@see HTC的client代码
SkyWalking是怎么玩的
SkyWalking作为tracing组件，每时每刻都会上报大量的数据到其后端server，除了对SW本身的处理能力、吞吐性有要求外，稳固可靠的传输层/RPC框架也很重要，SkyWalking使用的就是gRPC。社区在8.X后也有了走kafka消息队列的方案，但是至少就我们公司而言，gRPC在链路传输和rpc性能方面已经表现得相当稳固了。
TraceSegmentServiceClient.java
Tracing.proto
RemoteServiceHandler.java
TraceSegmentReportServiceHandler.java
我看的也比较浅，如果感兴趣可以去看SW官方的这篇博客，SkyWalking创始人吴晟写的，介绍了一些通讯、路由、整个系统架构层面的一些内容，比较干货。
有趣的是，RocketMQ在最新发布的5.0版本中也在原来的纯netty通信基础上，选用了gRPC作为默认通讯及rpc方案，由此可见gRPC的高性能和可靠性也越来越被开源社区认可。
站在巨人的肩膀上——netty
既然上面说到gRPC这么强大，除了protobuf作为二进制序列化框架、rpc DSL，以及HTTP/2的底层协议，其他都是自己实现的吗？从grpc-java的角度看，底层还少不了一位重量级角色netty，作为网络层框架。（当然这么说也不是很严谨，实际上除了序列化协议可以由protobuf替换为json等，底层网络传输层也可以由ok-http等替换，这和语言也有关系）
netty简介
netty是一个异步的、事件驱动的网络应用框架，netty的性能众所周知非常强大，资料也非常多，我并没有写过原生的netty，最近在写虚拟环境MQ相关内容时发现RocketMQ的通讯模块对netty封装的也非常好，所以拿过来看下内部是怎么实现的，以及分享下如何基于rocket-remoting模块去拓展MQ client的逻辑，得到和原生consumer<->broker一致的rpc能力。
org.apache.rocketmq.remoting.netty.NettyRemotingAbstract#processRequestCommand