减少RPC调用次数需识别冗余交互、合并上下文、前置预取并收拢服务职责；批量接口替代N+1调用，限制数量≤100且保持顺序；本地缓存+布隆过滤器防穿透；推动数据就近原则重构服务；gRPC流式响应合并多次交互。
减少RPC调用次数不是靠“少发几次请求”就能解决的，关键在于识别冗余交互、合并上下文、前置数据预取，并在服务边界合理收拢职责。
用批量接口替代多次单条RPC
常见场景如订单服务查用户信息、地址、优惠券，若逐个调用用户服务、地址服务、营销服务，3次RPC变成1次超时风险陡增。应推动下游服务提供批量查询接口：
- 用户服务暴露
GetUsers(ctx, []int64{uid1, uid2})，一次返回多个用户基础信息 - 地址服务支持
GetAddressesByUserIDs(ctx, []int64{uid1, uid2})，按用户ID批量拉取 - 调用方聚合所需ID后统一发起，避免N+1查询模式
注意：批量接口需限制最大数量（如≤100），并确保返回顺序与入参一致，方便调用方映射。
引入本地缓存 + 缓存穿透防护
对读多写少、强一致性要求不高的数据（如商品类目、城市列表、配置项），Golang中可用 groupcache 或 bigcache 做进程内缓存，避免重复RPC。
立即学习“go语言免费学习笔记（深入）”；
- 首次调用走RPC获取，写入带TTL的本地缓存（如5分钟）
- 后续请求直接从内存读，延迟从毫秒级降到微秒级
- 用布隆过滤器或空值缓存拦截非法ID请求，防止缓存穿透打垮下游
慎用Redis做二级缓存——跨网络反而可能比本地缓存慢，除非数据量大、需多实例共享。
重构服务职责，推动“数据就近原则”
频繁RPC往往暴露了服务拆分过细或数据归属不清。例如“下单”需调用库存、价格、风控、积分四个服务，可考虑：
- 将价格计算逻辑下沉到商品服务，订单服务只传SKU和数量，由商品服务返回最终价
- 风控规则配置内置在订单服务启动时加载，运行期不依赖实时RPC校验（异步补偿即可）
- 积分变动改用事件驱动：订单完成发MQ消息，积分服务异步处理，解除强依赖
目标是让一次核心业务操作，RPC调用控制在1~2次以内，其余逻辑在本服务内存或DB中闭环。
用gRPC流式响应合并多次交互
当客户端需轮询或分页获取关联数据（如聊天记录+用户资料+头像URL），可定义服务器流式RPC：
- 定义
rpc StreamOrderDetails(StreamOrderRequest) returns (stream OrderDetailResponse); - 服务端一次查库+多次RPC，组装好完整对象后分块Send，客户端Recv聚合
- 相比多次Unary调用，省去连接建立、序列化/反序列化、网络往返开销
适合数据量适中、实时性要求不高、但调用频次高的场景，注意控制单次流消息大小，避免阻塞。
