2022年8月

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