gRPC服务端流订单推送最佳实践：全量返回还是按strategy_id过滤

优先选择支持客户端通过strategy_id过滤订阅指定订单更新的实现方案，全量推送所有订单仅可作为特殊场景的可选补充，不能作为默认实现，核心原因如下：

• 资源效率差距极大：全量推送会导致全链路的无效资源消耗。假设当日产生10万条订单，每条订单更新都推给所有订阅客户端的话，服务端要处理大量重复的消息分发请求，带宽会被无关数据占满，客户端还要额外消耗CPU做本地过滤，弱网、移动端环境下体验会极差。按strategy_id过滤的方案只推客户端需要的消息，三方资源开销都只有全量推送的几十分之一甚至更低。
• 符合数据安全规范：不同客户端的订单归属于不同的账户、策略，全量推送会将不属于当前客户端的敏感订单数据暴露出去，违反数据最小权限原则，金融交易场景下甚至会违反合规要求。
• 扩展性更强：过滤方案可以非常方便的扩展批量订阅能力，只需要调整SubscribeRequest的定义，新增repeated string target_strategy_ids = 1;字段即可，客户端既可以订阅单个订单，也可以一次订阅自己名下的所有订单，灵活性远高于全量推送。
• 实现成本极低：gRPC服务端流式本身就需要为每个连接维护独立的上下文，只需要在每个连接的存储中记录订阅指定的strategy_id列表，订单更新触发时匹配对应连接推送即可，开发成本不到全量推送后做性能优化的十分之一。

如果你确实有全量订阅的场景需求（比如全局监控、对账服务），可以在SubscribeRequest中新增可选的bool enable_full_subscribe = 2;字段，仅对有权限的特权客户端开放全量订阅能力，避免普通客户端误用。

内容的提问来源于stack exchange，提问作者Gabriel Ribeiro