如何选择 RPC 消息交互方式？
| 类型 | 交互 | 适用场景 | 约束 |
|---|
| PingPong | 一次请求、一次响应 | 常规 RPC | 默认选择 |
| Oneway | 只发送、不等待业务响应 | 可丢失通知 | 仅 Thrift; 不推荐承担可靠业务 |
| Streaming | 一个调用内多次收发 | 推送、上传、对话 | 处理 EOF、半关闭与取消 |
- Thrift: 支持 PingPong、Oneway，以及 TTHeader Streaming 或基于 HTTP/2 的 streaming;
- Kitex Protobuf: 支持 unary PingPong，不支持 streaming;
- gRPC: 支持 unary、client streaming、server streaming、bidirectional streaming;
如何选择连接模型？
- 短连接: 每次请求建连; 成本高，只在实例数量或连接约束要求时使用;
- 长连接池: Kitex 默认模型; 每个 address 维护可复用连接;
- gRPC: HTTP/2 原生多路复用，一条连接可承载多个并发 stream;
如何调整长连接池？
MaxIdlePerAddress: 每个目标保留的空闲连接上限；池空时会新建连接，因此它不是并发连接硬上限;MaxIdleTimeout: 空闲回收时间；官方页的示例配置与文字默认值不一致，实际工程显式设置并核对所用版本;MaxIdleGlobal: 全局空闲连接上限; 过小会降低复用率;- 调整依据: 下游实例数、并发、请求耗时、突发流量与文件描述符预算;
- 经验: 先观察 active/idle 和复用率，再调参数，不要拍脑袋;
如何判断连接池是否有效复用？
- 连接数: 按目标实例观察 active、idle 与建连失败;
- 复用率: 过低通常意味着池过大、idle timeout 过短或 Client 未复用;
- 延迟: 分离 discovery、connect、write、server 与 read 阶段;
- 状态报告: 可实现连接池
Reporter 接口接入监控;