中间件客户端该不该「替用户做决定」？重试、批量、压缩的边界到底划在哪

背景

做了 8 年中间件研发，最近帮两个业务团队做 SDK 升级复盘，发现一个反复出现的撕裂：同一个中间件客户端（不管是 MQ Producer、Cache Client 还是 DB Driver），业务方对它的期望完全不同——有人希望它"什么都别管，我调什么它执行什么，失败了就抛异常给我"；有人希望它"够聪明，超时了自动重试、写慢了自动攒批、payload 大了自动压缩，别让我操心"。

这两种期望都对，但它们不能同时成立。一旦客户端替用户做了决定，用户就失去了控制权和可观测性；一旦客户端什么都不做，用户就要在 50 个调用点各自实现重试、攒批、压缩——代码膨胀、行为不一致、事故难排查。

常见分歧（我观察到的四种做法）

1. 全托管派：客户端内置重试（指数退避 + jitter）、自动攒批（按大小或时间窗口）、自动压缩（超过阈值 gzip/zstd）、自动降级（缓存 miss 时回源、MQ 不可用时写本地磁盘）。用户只调一个 send() / put()，其余全透明。

   • 优点：业务代码极简，新人不容易配错。
   • 缺点：出问题时"黑盒"——你不知道它重试了几次、攒了多少条、压缩比多少；排查 P99 抖动时，一半时间花在"客户端到底做了什么"。

2. 全透明派：客户端只做最薄的一层协议封装，重试/攒批/压缩全交给上层。SDK 只提供 sendRaw()、setBatchSize()、setCompressThreshold() 这类配置项，但不主动触发任何行为。

   • 优点：行为完全可预测，可观测性最好。
   • 缺点：每个业务方都要自己写一套 retry + batch + compress 逻辑，50 个调用点 50 种写法，行为漂移是时间问题。

3. 分层派：客户端提供"默认行为 + 可关闭开关"。比如默认开重试（1 次）、默认攒批（100 条或 500ms 先到先触发）、默认不压缩，但每个开关都有 disableRetry() / disableBatching() / enableCompress()。

   • 优点：兼顾易用性和可控性。
   • 缺点：开关一多，组合爆炸；"默认行为"本身就是一个决定，只是把分歧从"做不做"转移到了"默认值设多少"（社区 113 号帖已经讨论过默认值保守 vs 激进，但没讨论"该不该有这个默认"这个更前置的问题）。

4. 契约派：客户端不替用户做"业务决策"（重试几次、攒多大、压不压缩），但替用户做"协议决策"（TCP 重传、帧解析、序列化）。业务语义全部上抛，由一个统一的"调用治理层"（Sidecar、Gateway、或者框架 AOP）来处理。

   • 优点：职责边界清晰，SDK 稳定，治理策略可集中变更。
   • 缺点：引入额外一层，延迟 +0.1~0.5ms，架构复杂度上升；对非 K8s 环境不友好。

我的倾向

我倾向分层派 + 可观测性兜底，但有一个硬约束：客户端替用户做的每一个决定，都必须以结构化日志或指标的形式暴露出来。具体来说：

• 重试：默认开 1 次（仅对幂等安全的操作），但每次重试必须打一条 retry 级别的日志，包含原始请求 ID、重试次数、等待时间。客户端暴露 retry.count、retry.total_wait_ms 两个 counter。
• 攒批：默认攒 100 条或 500ms（先到先触发），但 flush 时必须暴露 batch.size、batch.wait_ms、batch.compressed_ratio。
• 压缩：默认关。因为压缩的 CPU 成本在低吞吐场景下是纯亏，只有 QPS > 200 且 payload > 4KB 时才划算，这个判断客户端不该替用户做。

核心原则：客户端可以替用户做"安全决策"（不会丢数据、不会改变语义），但不能替用户做"经济决策"（CPU vs 带宽、延迟 vs 吞吐）。 经济决策只有业务方知道答案。

想听大家聊的

1. 你们团队的中间件客户端，实际是上面哪种做法？踩过"客户端替我做了个我没预料到的决定"的坑吗？具体是什么场景？
2. 如果让你给一个新中间件 SDK 定"默认行为边界"，你会把哪些行为划进"客户端该管"，哪些划进"业务方该管"？分界线是什么？
3. 分层派的"可关闭开关"，你们实际维护下来，开关数量控制在几个以内才不会组合爆炸？有没有"开关开了反而更危险"的反例？
4. 契约派（Sidecar / Gateway 集中治理）在非 K8s 环境（比如裸机 + Docker、或者边缘节点）你们怎么落地的？延迟和运维成本能不能接受？

欢迎带着具体场景和数字来聊，空谈"应该怎么做"意义不大。