tRPC – 介绍

Docs: tRPC介绍

Mon, 01 Jan 0001 00:00:00 +0000

tRPC是什么

tRPC是基于插件化理念设计的一款支持多语言、高性能的RPC开发框架，整体设计遵循以下原则：

简单：用户基于框架进行服务开发简单方便；
高性能：框架具备高性能，能适用互联网海量访问场景；
插件化：框架在架构设计和具体实现上进行分层和模块化，各个核心模块可拔插，并能够独立演进；

你可以使用它：

搭建多个端口支持多个协议(一个端口只能对应一个协议)的服务(tRPC/HTTP(s)/gRPC等)，并能同步/异步处理客户端请求；
以同步、异步、单向的方式访问各种协议后端服务(tRPC/HTTP(s)/gRPC等)，调用各种存储系统(redis等)；
流式RPC编程，目前支持tRPC流式、gRPC流式、HTTP流式等，实现类似Push、文件上传/下载、AI类等流式应用服务；
插件化支持各种协议和对接服务治理系统，比如：开发自定义的协议、对接业务使用的各种名字服务/监控系统/调用链系统/配置系统/日志系统等，方便服务互通和服务运营；

tRPC特点

跨语言：基于Protocol Buffers来实现跨语言之间的服务通信；
多通信协议：支持多种通信协议，能够与不同框架进行互通（比如gRPC）；
流式rpc：支持流式RPC，更好地适用于大文件上传/下载、消息Push、AI类语音识别/视频理解等多种应用场景；
丰富插件生态：提供大量对接业界微服务组件的插件（比如Consul/Promethues/OpenTelemetry等），方便用户构建适合自己的服务治理体系；
可扩展性：基于框架插件化的设计，用户可以进行二次开发来扩展框架能力，比如：RPC请求参数校验、鉴权、请求录制等；
流控和过载保护：提供多种应用场景下的流量控制和过载保护插件，防止服务因为访问突增造成过载而不可用；

支持语言

如何使用tRPC

可以在 tRPC官网找到tRPC每个语言的快速入门、基础教程等学习资料，也可以到tRPC各个语言的仓库查看详细的用户指南文档和代码示例.

如何参与建设

非常欢迎大家给tRPC做贡献!

建议您在为tRPC贡献之前, 先阅读一下如何参与建设 , 它会指导你了解贡献代码的整个流程, 比如: 如何提PR/如何构建代码/如何运行单元测试等;

Docs: tRPC架构设计

Mon, 01 Jan 0001 00:00:00 +0000

前言

本文主要介绍一下tRPC诞生的背景、插件化设计思路、以及整体架构。

背景

互联网发展早期，业务场景差异大，试错迭代速度很快。这导致其后台服务使用的语言技术栈、开发框架、通信协议、服务治理系统、运维平台等或多或少存在差异。

业务发展到一定阶段后，跨业务合作越来越多，组织架构调整也愈发频繁。技术体系差异，特别是开发框架的不统一，给业务互通带来巨大成本，也导致开发和运营的效率难以快速提高。

同时，随着云原生技术的发展，业务越来越多地使用开源技术和云组件。拥抱云原生已经是一种主流趋势。

上述问题在腾讯内部也同样存在，且因为规模大、业务类型多，更加难以解决，更必须解决。tRPC就是在这种背景下诞生的。

插件化设计

既要与存量技术体系互联互通，又要适配云原生技术并且快速发展。这就要求开发框架必须具备开放性和可扩展性。为了达到这个目的，tRPC在架构设计上采用插件化设计思想。

tRPC插件化在整体设计上遵循如下的思想：

首先tRPC对框架整体进行分层和模块化，并把核心功能模块抽象封装成一个个独立的插件。然后由框架来负责这些独立插件的串联和拼装，从而实现框架所要支持的功能和特性。

在具体实现上，则采用以下的关键技术

基于接口机制的插件工厂；
基于AOP思想的拦截器；

插件工厂

插件工厂的整体实现思路是框架只定义插件的标准接口，并提供注册能力，不做具体实现。与外部服务互通，或者对接某个服务治理系统时，只需要开发对应的具体插件即可。

例如: 框架对多协议的支持，定义了统一的Codec，不同协议只需要按照Codec接口即可实现即可。

例如: 框架对接不同名字服务系统，定义了统一的Registry和Selector抽象接口，对接不同的名字服务系统时只需要按照Registry和Selector接口即可实现即可。

通过插件工厂的设计，可以带来以下的好处:

对于框架侧: 框架只定义标准接口，没有任何插件实现，与具体平台完全解耦;
对于平台侧: 只需要按照框架插件标准接口即可实现插件，即可将平台的能力融入到框架中;
对于用户侧: 业务开发只需要通过配置进行使用，对用户透明;

拦截器

为了使tRPC框架有更强的可扩展性，满足业务个性化的需求（比如：Metrics监控、日志收集、链路跟踪、参数校验、请求回放、故障注入等），tRPC借鉴了java面向切面（AOP）的编程思想，支持了拦截器Filter。

Filter整体实现的思路是在框架处理RPC请求的流程上设置埋点，然后通过在埋点地方插入一系列的Filter。具体实现上，不同语言有所不同，cpp采用数组遍历的方式，go采用递归的方式，java采用链式的方式。

Filter工作流程如下图:

Filter的最终目的是让业务逻辑与框架进行解耦，并允许各自进行内聚性开发，可以在不修改框架代码的情况下，给业务程序动态添加或替换个性化的功能。

插件化架构

有了上面插件化的关键技术支持，接下来我们看看tRPC插件化架构是怎样设计的。

总体架构设计

tRPC多语言的总体架构设计如下:

总体架构由 “框架核心” 和 “插件” 两部分组成。其中虚线框内为tRPC，中间的红色实线框为框架核心，蓝色框为插件部分。

框架核心又可以分三层:

通信层: 负责数据的传输和协议的编解码，框架内置支持tcp、udp等通信协议，传输协议采用基于Protocol Buffers的tRPC协议来承载RPC调用，支持通过Codec插件来使用其它传输协议；
服务治理层: 负责将服务治理功能抽象成插件，通过调用插件和外部服务治理系统进行对接，实现服务发现、负载均衡、监控、调用链等功能；
调用层: 封装服务和服务代理实体，提供RPC调用接口，支持业务用同步、异步、单向以及流式调用等方式进行服务间调用；

此外框架还提供了Admin管理接口，方便用户或者运营平台可以通过调用Admin接口对服务进行管理。管理接口包括更新配置、查看版本、修改日志级别、查看框架运行时信息等功能，同时框架也支持用户自定义管理接口，以满足业务定制化需求。

插件则是框架核心和外部服务治理组件串联起来的桥梁，按功能大致分为下面几类插件:

Codec: 提供协议编解码相关的接口，允许通过插件的方式来扩展业务协议、序列化方式、数据压缩方式等协议处理;
Naming：提供了服务注册(Registry)、服务发现(Selector)、负载均衡(LoadBalance)、熔断(CircuitBreaker)等能力封装，用于对接各种名字服务系统;
Config：提供了配置读取相关的接口，支持读取本地配置文件、远程配置中心配置等，允许插件式扩展支持不同格式的配置文件、不同的配置中心，支持reload、watch配置更新;
Metrics：提供了监控上报的能力，支持常见的单维上报，如Counter、Gauge等，也支持多维上报，允许通过扩展对接不同的监控系统;
Logging：提供了通用的日志采集接口，允许通过插件的方式来扩展日志实现，输出到远程;
Tracing：提供了分布式跟踪能力，允许通过插件的方式上报到调用链系统;
Telemetry：提供了采集和上报遥测数据的能力，是一个集成了链路追踪（Tracing）、监控上报（Metrics）、日志采集（Logging）三大功能的插件；

具体插件实现时，一边需要按框架标准接口实现插件，注册到框架核心，并完成插件实例化；另一边具体插件还需要使用外部服务治理服务的SDK或API，实现如服务发现、负载均衡、监控、调用链等功能。

具体架构设计

在讲具体架构设计之前，我们先看看RPC的过程是怎样的。从开发者角度来说，它可以让你像本地函数调用一样进行跨节点的函数调用，通常一个完整的RPC过程如下图:

上图描述了一个RPC调用必须要经过的环节。基于此共性，我们把框架在横向上分为服务端和客户端，在纵向进行分层。其中，纵向上的服务端大致分为Transport、Codec、Service和Filter层，客户端分为Transport、Codec、ServiceProxy、Filter层，具体设计如下图:

在这张图中，我们新增了一层Filter层(拦截器)，其主要目的是采用AOP的思想，把业务个性化的需求（比如：校验校验、请求回放、故障注入等）、以及服务治理的大部分功能(比如：监控指标上报，调用链跟踪，远程日志，鉴权等)以横切关注点的方式，插入到请求/响应处理的流程中，通过这样的设计来增强框架的可扩展性。

同时系统对每一层进行模块化拆分，采用插件化的实现，框架通过基于接口编程的思想，串联RPC的全流程。对于一些模块，框架也采用了更细粒度的模块拆分。比如：Selector模块被细分为服务发现、服务路由、负载均衡和熔断等子模块，Codec层也被细分为编解码、序列化、压缩三个子模块。

通过上面整体的分层设计，具体模块的插件化实现和细粒度的模块拆分，使框架具备很强的扩展性和开放性。业务可以灵活替换插件，实现与不同系统的对接，也可以进行业务个性化定制能力实现。

Docs: tRPC协议设计

Mon, 01 Jan 0001 00:00:00 +0000

前言

本文主要介绍一下为什么要设计tRPC协议，以及tRPC协议具体是怎样定义。

为什么要设计tRPC协议

首先，tRPC是一个多语言的RPC框架，需要有统一的传输协议进行通信，以及通信时在一些功能上进行对齐。

其次，为什么tRPC不选择HTTP/HTTP2协议，这里主要的原因是性能问题。

最后，除了向前兼容外，tRPC在通信协议上还有强烈扩展性的诉求，能扩展支持各种业务需求的能力。

下面的表格是tRPC对通信协议的能力和诉求。

能力	诉求
RPC	远程调用像调本地接口一样
兼容性	协议设计和实现上应具有向前兼容
高性能	协议设计上需要考虑高性能问题
流式传输	协议设计上应该能支持大数据包传输和边请求边应答的流式场景
支持请求超时控制	协议设计和实现上支持设置请求超时时间
支持多种序列化方式	协议设计和实现上可扩展支持多种序列化方式，比如：Protobuf、JSON、text等
支持多种解压缩方式	协议设计和实现上可扩展支持多种解压缩方式，比如：Gzip、Snappy等
支持透传调用链信息	协议设计和实现上支持调用链信息在服务间透传
支持消息染色	协议设计和实现上支持请求消息的染色key在服务间透传
支持透传用户自定义元数据	协议设计和实现上支持用户设置自定义元数据在服务间透传

为了支持这些能力和需求，tRPC协议整体设计设计如下：

传输协议（协议头，自定义设计）+ 编码协议（协议体，默认使用Protobuf，可扩展）

tRPC协议具体设计与实现

协议设计

下面的图是tRPC协议的具体设计。

tRPC协议支持一应一答和流式两种传输方式。

对于一应一答（unary）的RPC，整个完整协议帧 = 固定帧头（16字节）+ Unary包头（变长）+ Unary包体（变长）

对于流式（stream）RPC，整个完整协议帧 = 固定帧头（16字节）+ 流帧（Init帧、Data帧、Feedback帧、Close帧）

完整的协议定义，可以查看：trpc.proto

协议具体定义

固定帧头

第1-2个字节：协议前面两个字节为魔数字，标识trpc帧的开始，为0x930
第3个字节：数据类型

// Two types are currently supported:
// 1. The data frame type for unary(one-response-one-response)
// 2. The data frame type for stream
enum TrpcDataFrameType {
TRPC_UNARY_FRAME = 0x00;

TRPC_STREAM_FRAME = 0x01;
}

第4个字节：流式帧类型，只有帧为流式的帧的时候生效

// Four types are currently supported:
// `INIT` frame: FIXHEADER + TrpcStreamInitMeta
// `DATA` frame: FIXHEADER + body (business serialized data)
// `FEEDBACK` frame: FIXHEADER + TrpcStreamFeedBackMeta (triggered strategy: high/low water level and timer)
// `CLOSE` frame: FIXHEADER + TrpcStreamCloseMeta
enum TrpcStreamFrameType {
TRPC_UNARY = 0x00;

TRPC_STREAM_FRAME_INIT = 0x01;

TRPC_STREAM_FRAME_DATA = 0x02;

TRPC_STREAM_FRAME_FEEDBACK = 0x03;

TRPC_STREAM_FRAME_CLOSE = 0x04;
}

第5-8个字节数据总大小对于一应一答，总数据大小 = 帧头大小 + 包头大小 + 包体大小对于流式，总数据大小 = 帧头大小 + 流帧大小
第9-10个字节：对于一应一答，包头大小对于流式，始终为0
第11-14个字节：对于一应一答，请求id 对流式，流式id
第15-16个字节保留字段，保留给以后扩容协议使用

一应一答包头

16个字节之后，对于一应一答，对应着协议的包头，分为请求包头和响应包头

请求包头

// The request header for unary
message RequestProtocol {
  // The version of protocol
  // The specific value corresponds to `TrpcProtoVersion`
  uint32    version                     = 1;

  // Call type
  // eg: unary, one-way
  // The specific value corresponds to `TrpcCallType`
  uint32    call_type                   = 2;

  // The unique id of the request(on the conneciton)
  uint32    request_id                  = 3;

  // The timeout of the request(ms)
  uint32    timeout                     = 4;

  // Caller name
  // The specification format: trpc.application_name.server_name.proto_service_name, 4 segments
  bytes     caller                      = 5;

  // Callee name
  // The specification format: trpc.application_name.server_name.proto_service_name[.interface_name]
  bytes     callee                      = 6;

  // Interface name of callee
  // The specification format: /package.service_name/interface_name
  bytes     func                        = 7;

  // The message type of the transparent transmission information
  // such as tracing, dyeing key, gray, authentication, multi-environment, set name, etc.
  // The specific value corresponds to `TrpcMessageType`
  uint32    message_type                = 8;

  // The information key-value pair transparently transmitted by the framework
  // Currently divided into two parts:
  // 1 part is the information to be transparently transmitted by the framework layer,
  // and the name of the key must be started with `trpc-``
  // 2 part is the information to be transparently transmitted by the business layer,
  // and the business can set it by itself, it is recommended to start with `app-``, not `trpc-`
  // Note: The key-value pair in trans_info will be transparently transmitted through the whole link, please use it carefully for business.
  map<string, bytes> trans_info         = 9;

  // The serialization type of the request data
  // eg: proto/json/.., default proto
  // The specific value corresponds to `TrpcContentEncodeType`
  uint32    content_type                = 10;

  // The compression type of the requested data
  // eg: gzip/snappy/..., not used by default
  // The specific value corresponds to `TrpcCompressType`
  uint32    content_encoding            = 11;

  // The size of attachment data
  uint32    attachment_size             = 12;
}

响应包头

// The response header for unary
message ResponseProtocol {
  // The version of protocol
  // The specific value corresponds to `TrpcProtoVersion`
  uint32    version                     = 1;

  // Call type
  // eg: unary, one-way
  // The specific value corresponds to `TrpcCallType`
  uint32    call_type                   = 2;

  // The unique id of the request(on the conneciton)
  uint32    request_id                  = 3;

  // Error code
  // The specific value corresponds to `TrpcRetCode`
  int32     ret                         = 4;

  // The error code of the interface
  // 0 means success, other means failure
  int32     func_ret                    = 5;

  // The result information when the call fails
  bytes    error_msg                    = 6;

  // The message type of the transparent transmission information
  // such as tracing, dyeing key, gray, authentication, multi-environment, set name, etc.
  // The specific value corresponds to `TrpcMessageType`
  uint32    message_type                = 7;

  // The information key-value pair transparently transmitted by the framework
  // Currently divided into two parts:
  // 1 part is the information to be transparently transmitted by the framework layer,
  // and the name of the key must be started with `trpc-``
  // 2 part is the information to be transparently transmitted by the business layer,
  // and the business can set it by itself, it is recommended to start with `app-``, not `trpc-`
  map<string, bytes> trans_info         = 8;

  // The serialization type of the request data
  // eg: proto/json/.., default proto
  // The specific value corresponds to `TrpcContentEncodeType`
  uint32    content_type                = 9;

  // The compression type of the requested data
  // eg: gzip/snappy/..., not used by default
  // The specific value corresponds to `TrpcCompressType`
  uint32    content_encoding            = 10;

  // The size of attachment data
  uint32    attachment_size             = 12;
}

流式流帧

16个字节完整帧头后面紧接着流帧

分为 Init、Data、Feedback、Close 帧

Init帧用来做流初始化
Data帧用来传输流式数据
Feedback帧用来传输流控消息
Close帧用来关闭流

Init帧

// The message definition of stream `INIT` frame
message TrpcStreamInitMeta {
  // request meta information
  TrpcStreamInitRequestMeta request_meta = 1;

  // response meta information
  TrpcStreamInitResponseMeta response_meta = 2;

  // The window size is notified by the receiver to the sender
  uint32 init_window_size = 3;

  // The serialization type of the request data
  // eg: proto/json/.., default proto
  // The specific value corresponds to `TrpcContentEncodeType`
  uint32 content_type = 4;

  // The compression type of the requested data
  // eg: gzip/snappy/..., not used by default
  // The specific value corresponds to `TrpcCompressType`
  uint32 content_encoding = 5;
}

// The request meta information definition of stream `INIT` frame
message TrpcStreamInitRequestMeta {
  // Caller name
  // The specification format: trpc.application_name.server_name.proto_service_name, 4 segments
  bytes caller = 1;

  // Callee name
  // The specification format: trpc.application_name.server_name.proto_service_name[.interface_name]
  bytes callee = 2;

  // Interface name of callee
  // The specification format: /package.service_name/interface_name
  bytes func = 3;

  // The message type of the transparent transmission information
  // such as tracing, dyeing key, gray, authentication, multi-environment, set name, etc.
  // The specific value corresponds to `TrpcMessageType`
  uint32 message_type = 4;

  // The information key-value pair transparently transmitted by the framework
  // Currently divided into two parts:
  // 1 part is the information to be transparently transmitted by the framework layer,
  // and the name of the key must be started with `trpc-``
  // 2 part is the information to be transparently transmitted by the business layer,
  // and the business can set it by itself, it is recommended to start with `app-``, not `trpc-`
  // Note: The key-value pair in trans_info will be transparently transmitted through the whole link, please use it carefully for business.
  map<string, bytes> trans_info = 5;
};

// The response meta information definition of stream `INIT` frame
message TrpcStreamInitResponseMeta {
  // Error code
  // The specific value corresponds to `TrpcRetCode`
  int32 ret = 1;

  // The result information when the call fails
  bytes error_msg = 2;
};

Data帧

DATA帧对应的是实际请求的消息体

Feedback帧

// The meta information definition of stream `FEEDBACK` frame
message TrpcStreamFeedBackMeta {
  // increased window size
  uint32 window_size_increment = 1;
}

Close帧

Close帧分为正常的 Close帧和异常的 Close（Reset）帧。

// The closed type of trpc stream protocol
enum TrpcStreamCloseType {
  // normal closes unidirectional flow
  TRPC_STREAM_CLOSE = 0;

  // Exception closes bidirectional stream
  TRPC_STREAM_RESET = 1;
}

// The meta information definition of trpc stream protocol for closing stream
message TrpcStreamCloseMeta {
  // The type of stream closure, close one end, or close all
  int32 close_type = 1;

  // Error code
  // The specific value corresponds to `TrpcRetCode`
  int32 ret = 2;

  // The result information when the call fails
  bytes msg = 3;

  // The message type of the transparent transmission information
  // such as tracing, dyeing key, gray, authentication, multi-environment, set name, etc.
  // The specific value corresponds to `TrpcMessageType`
  uint32    message_type  = 4;

  // The information key-value pair transparently transmitted by the framework
  // Currently divided into two parts:
  // 1 part is the information to be transparently transmitted by the framework layer,
  // and the name of the key must be started with `trpc-``
  // 2 part is the information to be transparently transmitted by the business layer,
  // and the business can set it by itself, it is recommended to start with `app-``, not `trpc-`
  // Note: The key-value pair in trans_info will be transparently transmitted through the whole link, please use it carefully for business.
  map<string, bytes> trans_info = 5;

  // The error code of the interface
  // 0 means success, other means failure
  int32 func_ret = 6;
}

IDL

tRPC 的IDL基于Protobuf，用户编写Proto文件，通过trpc-cmdline生成相应的桩代码

一应一答RPC的IDL

syntax = "proto3";

package proto;

service StreamService {
    rpc List(Request) returns ( Response) {};
    rpc Record( Request) returns (Response) {};
    rpc Route( StreamRequest) returns ( Response) {};
}


message Point {
  string name = 1;
  int32 value = 2;
}

message Request {
  Point pt = 1;
}

message Response {
  Point pt = 1;
}

流式RPC的IDL

流式IDL和普通RPC一样，使用stream关键字表明是流式RPC

syntax = "proto3";

package proto;

service StreamService {
    rpc List(StreamRequest) returns (stream StreamResponse) {};
    rpc Record(stream StreamRequest) returns (StreamResponse) {};
    rpc Route(stream StreamRequest) returns (stream StreamResponse) {};
}


message StreamPoint {
  string name = 1;
  int32 value = 2;
}

message StreamRequest {
  StreamPoint pt = 1;
}

message StreamResponse {
  StreamPoint pt = 1;
}

注意关键字 stream，声明其为一个流方法。这里共涉及三个方法，对应关系为

List：服务器端流式RPC
Record：客户端流式RPC
Route：双向流式RPC

Docs: tRPC插件生态

Mon, 01 Jan 0001 00:00:00 +0000

前言

本文主要介绍一下tRPC目前的插件生态建设情况。

tRPC插件的成熟度分类

tRPC插件在成熟度上，目前分为以下4级：

成熟度	描述
stable	已经大规模使用，放心使用
on trial	已测试，有一定业务用过，基本靠谱
tested	已测试，还没有业务用过，可能有坑
archived	已归档，不再维护，不推荐使用

tRPC各语言的插件生态建设情况

目前tRPC在插件生态的建设上，插件类型主要包含协议、拦截器、名字服务系统、配置中心系统、监控系统、调用链系统、远程日志系统、可观测系统等。

tRPC-Cpp插件列表

插件类型	插件	成熟度	文档
协议	HTTP	stable	链接
协议	gRPC	stable	链接
序列化	Protobuf	stable	链接
序列化	JSON	stable	链接
序列化	test	stable	链接
序列化	binary	stable	链接
解压缩	Gzip	stable	链接
解压缩	lz4	stable	链接
解压缩	Snappy	stable	链接
解压缩	zlib	stable	链接
名字服务系统	MeshPolaris	tested	链接
配置中心系统	etcd	tested	链接
监控系统	Prometheus	stable	链接
调用链系统	Jaeger	stable	链接
远程日志系统	CLS	stable	链接
可观测系统	OpenTelemetry	stable	链接
拦截器	并发请求限速	stable	链接

tRPC-Go插件列表

插件类型	插件	成熟度	文档
协议	HTTP	stable	链接
协议	gRPC	stable	链接
名字服务系统	MeshPolaris	tested	链接
配置中心系统	etcd	tested	链接
监控系统	Prometheus	stable	链接
调用链系统	Jaeger	stable	链接
远程日志系统	CLS	stable	链接
可观测系统	OpenTelemetry	stable	链接
拦截器	debuglog	stable	链接
拦截器	degrade（服务端熔断限流）	stable	链接
拦截器	filterextensions（方法级别的拦截器）	stable	链接
拦截器	hystrix（服务端熔断限流）	stable	链接
拦截器	jwt (认证鉴权）	stable	链接
拦截器	masking（敏感数据脱敏）	stable	链接
拦截器	mock（client mock）	stable	链接
拦截器	recover（捕获 panic 并恢复）	stable	链接
拦截器	referer（HTTP Referer 安全校验）	stable	链接
拦截器	slime（重试/对冲）	stable	链接
拦截器	transinfo-blocker（元数据透传屏障）	stable	链接
拦截器	tvar（统计监控）	stable	链接
拦截器	validation（参数自动校验）	stable	链接

tRPC-Java 插件列表

插件类型	插件	成熟度	代码链接
协议	HTTP	stable	link
协议	TRPC	stable	link
注册中心	MeshPolaris	stable	link
注册中心	Consul	tested	link
注册中心	Nacos	tested	link
注册中心	Zookeeper	tested	link
名字服务	MeshPolaris	stable	link
名字服务	Consul	tested	link
名字服务	Nacos	tested	link
名字服务	Zookeeper	tested	link
配置中心	Nacos	tested	link
上报	Opentelemetry	tested	link
链路追踪	Opentelemetry	tested	link
日志	Opentelemetry	tested	link
限流	Sentinel	stable	link
通信框架	HTTP	stable	link
通信框架	Netty	stable	link
参数校验	PGV	stable	link
-	Code Generator	stable	link