[OSPP] Dubbo-Go Triple Protocol Performance Analysis and Optimization
- Dominant language
- Go
- Stars
- 5k
- Forks
- 1k
- Avg merge
- 3d 6h
- Merged PRs (30d)
- 29
Description
项目导师 @Alanxtl
项目owner @lizining1231
### 背景与目标
Triple 是 Dubbo 3 的核心 RPC 协议,也是 Dubbo-Go 面向生产环境的主力协议。项目以可复现的 benchmark 与 profiling 数据为依据,系统化定位 Triple模块的性能瓶颈,在保持兼容性安全性的前提下落地优化,产出多个可合并的PR与显著的性能收益。
### 当前进度面板
#### Step 1: 基线建立
- [x] profiling 工具链(pprof CPU/内存火焰图、runtime/trace、benchstat 显著性检验)`26-8-17 Done`
- [x] 三端基准测试(Dubbo-Go / gRPC-Go / Dubbo-Java,以及补充场景)`26-08-17—26-08-18 Done`
https://github.com/apache/dubbo-go/discussions/3673#discussioncomment-18071388
- [x] 兼容性回归基线(Triple 协议兼容、gRPC 兼容、Dubbo-Java 互通)`26-8-18—26-8-19 Done`
https://github.com/apache/dubbo-go/pull/3677
https://github.com/apache/dubbo-go/pull/3689
#### Step 2: 瓶颈对应issue
已定位的低风险固定开销开始验证,再根据正式 profiling 数据决定是否深入优化 Envelope、Buffer 或 Codec 热路径
- [x] io.Pipe 交接与每请求 goroutine `26-8-19—26-8-21 Done`
https://github.com/apache/dubbo-go/issues/3694
- [x] 分析codec层内存分配可优化点 `26-9-2—26-9-3 Done`
https://github.com/apache/dubbo-go/issues/3717
- [x] 消掉 wrapper 层的分配 `2026-9-12—26-9-13 Done`
https://github.com/apache/dubbo-go/issues/3726
- [ ] envelope 写路径(prefix 与 body 分离写入、多次 flush)`于26-9-14起 推进中`
- [ ] buffer 复用(Reset 不缩容:小消息占大缓冲、大消息反复扩容)
- [ ] header/metadata 处理(重复拷贝与规范化)
- [ ] codec 序列化与反序列化(非 protobuf 场景分配放大)
- [ ] http2.Transport 参数与连接池调优(可选)
#### Step 3: 落地合入并验证优化有效性
- [x] 消除io.Pipe 交接固定开销 `26-8-20—26-9-2 Done`
https://github.com/apache/dubbo-go/pull/3706
- [x] 落地codec层内存分配优化 `26-9-4—26-9-6 Done 于26-9-13起扩大优化范围 推进中`
https://github.com/apache/dubbo-go/pull/3718
https://github.com/apache/dubbo-go/pull/3727
- [ ] header/metadata 路径优化(合并拷贝、去除重复规范化)
- [ ] buffer 复用优化(按消息长度预扩容、分级缓冲池)
- [ ] codec 复用与压缩/解压输出预扩容
- [ ] 写路径对齐缓冲(合并 prefix 与 body 的大块写入)
- [ ] http2.Transport 参数与连接池调优(可选)
### 总验收标准
基础要求6项:
- [x] 能够基于现有benchmark完成Dubbo-Go,Dubbo-Java与gRPC-Go的性能对比。 `Done`
- [x] 给出优化前后的性能数据。 `Done`
- [x] 至少定位2-3个明确的性能瓶颈。`当前2个`
- [x] 至少完成1-2项实际优化。`当前2个`
- [x] 不破坏现有Triple功能、gRPC兼容性和Dubbo-Java互通能力。`Done`
- [x] 提交的PR能够通过社区review或具备明确合入价值,至少4个PR `当前4个 第5个推进中`
进阶要求3项:
- [x] 在至少一个核心benchmark场景中取得可量化性能提升。`当前2个`
- [x] 降低‘B/op’,‘allocs/op’或P99延迟。`Done`
- [ ] 完成codec可插拔层相关设计或实现。
Contributor guide
Research direction
Start by reading the benchmark and profiling baseline and the completed PRs linked in the issue. Then select one unchecked Triple area, such as envelope writes, buffer reuse, metadata handling, codec allocation, or HTTP/2 transport tuning, and confirm its bottleneck with reproducible measurements. Done means a focused optimization, compatibility regressions avoided, and before-and-after benchmark data with a reviewable PR.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend-api-design, networking, performance
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100