dynamicgo 开源 ：基于原始字节流的高性能+动态化 Go 数据处理！字节跳动开源！

01背景

当前，Thrift 是字节内部主要使用的 RPC 序列化协议，在 CloudWeGo/Kitex 项目中优化和使用后，性能相比使用支持泛型编解码的协议如 JSON 有较大优势。但是在和业务团队进行深入合作优化的过程中，我们发现一些特殊业务场景并不能享受静态化代码生成所带来的高性能：

1. 动态反射：动态地 读取、修改、裁剪 数据包中某些字段，如隐私合规场景中字段屏蔽；

2. 数据编排：组合多个子数据包进行 排序、过滤、位移、归并 等操作，如某些 BFF (Backend For Frontent) 服务；

3. 协议转换：作为代理将某种协议的数据转换另一种协议，如 http-rpc 协议转换网关。

4. 泛化调用：需要秒级热更新或迭代非常频繁的 RPC 服务，如大量 Kitex 泛化调用（generic-call）用户

不难发现，这些业务场景都具有难以统一定义静态 IDL的特点。即使可以通过分布式 sidecar 技术规避这个问题，也往往因为业务需要动态更新而放弃传统代码生成方式，诉诸某些自研或开源的 Thrift 泛型编解码库进行泛化 RPC 调用。我们经过性能分析发现，目前这些库相比代码生成方式有巨大的性能下降。以字节某 BFF 服务为例，仅仅 Thrift 泛化调用产生的 CPU 开销占比就将近 40%，这几乎是正常 Thrift RPC 服务的4到8倍。因此，我们自研了一套能动态处理 RPC 数据（不需要代码生成）同时保证高性能的 Go 基础库

02设计与实现

首先要搞清楚当前这些泛化调用库性能为什么差呢？其核心原因是：采用了某种低效泛型容器来承载中间处理过程中的数据（典型如 thrift-iterator 中的 map[string]interface{}）。众所周知，Go 的堆内存管理代价是极高的 （GC +heap bitmap），而采用 interface 不可避免会带来大量的内存分配。但实际上相当多的业务场景并不真正需要这些中间表示。比如 http-thrift API 网关中的纯协议转换场景，其本质诉求只是将 JSON（或其它协议）数据依据用户 IDL 转换为 Thrift 编码（反之亦然），完全可以基于输入的数据流逐字进行翻译。同样，我们也统计了抖音某 BFF 服务中泛化调用的具体代码，发现真正需要进行读（Get）和写（Set）操作的字段占整个数据包字段不到5%，这种场景下完全可以对不需要的字段进行跳过（Skip）处理而不是反序列化。而 dynamicgo 的核心设计思想是：基于 原始字节流 和 动态类型描述 原地（in-place） 进行数据处理与转换。为此，我们针对不同的场景设计了不同的 API 去实现这个目标。

动态反射

对于 thrift 反射代理的使用场景，归纳起来有如下使用需求：

1. 有一套完整结构自描述能力