基于Kafka的TypeScript版Notification Engine移动端推送咨询

核心结论 #

千万不要让移动端App直接作为Kafka消费者，无论使用原生客户端还是Kafka REST Proxy，这都是典型的架构反模式，完全不适合推送场景。

你现在的架构里Kafka是通知引擎内部的后端消息总线，只应该在服务端集群内部流转，绝对不要暴露给公网端侧。要让用户第一时间收到推送，用行业通用的成熟链路即可，完全不需要端侧参与Kafka消费：

• 你的Notification Engine作为Producer，按Scheduler规则把待下发的App推送消息写入对应Kafka Topic
• 后端单独部署Push Gateway消费集群，以专属消费组订阅上述推送Topic，这个集群才是真正的Kafka消费者
• Push Gateway拿到消息后，直接调用对应推送通道的服务端API发消息：海外场景走FCM/APNs，国内场景适配各厂商的系统推送通道即可
• 系统推送通道本身和手机操作系统维持着系统级的长连接，消息到达推送服务端后会在百毫秒级推送到用户设备，系统会直接唤起App展示通知，完全满足“第一时间收到”的要求。

你之前用的FCM主题订阅逻辑完全可以复用，只需要把原来各业务系统直接调用FCM的逻辑，收敛到Push Gateway层统一执行即可，不管是按主题批量推还是按设备Token精准推都支持，整体端到端延迟可以控制在1s以内。

技术上你可以写出能跑的Demo，但完全不具备生产可用性——这个组件从设计之初就不是给公网海量移动端场景准备的：

• Kafka REST Proxy的定位是给不方便集成原生Kafka客户端的后端服务、测试调试场景提供HTTP接入能力，没有针对公网高并发、弱网、海量短连接的场景做优化
• 移动端网络环境极不稳定，切网、进程后台挂起、弱网断连都会触发Kafka消费组频繁重平衡，不仅端侧消息收不全，还会拖垮整个Kafka集群的消费性能
• 安全层面完全不可控：如果把REST Proxy暴露到公网，你很难做到消息粒度的权限隔离，一旦接口泄露，攻击者可以拉取全量推送消息，存在严重的数据泄露风险。就算你在前面加鉴权、加权限校验层，本质上你已经实现了一层Push Gateway，完全没必要多此一举让端侧参与消费。

不止是端侧负载过重的问题，这个方案从根上就跑不通，负载过高只是最无关紧要的问题之一：

• 进程存活根本没法保证：iOS对后台进程限制极严，App退到后台几分钟就会被系统挂起；国产安卓ROM的后台杀进程策略非常激进，你根本没法保证App常驻后台维持消费逻辑，消息到达率会低到完全不可用
• 端侧资源消耗不可接受：维持Kafka消费需要App在后台持续轮询或者维持长连接，会大量消耗手机电量和移动流量，用户感知会非常差，卸载率会直线上升
• 维护成本爆炸：消费逻辑涉及offset提交、重连重试、消息去重、异常处理，这些逻辑在后端集群做是很简单的事，放到端侧就要适配不同系统版本、不同厂商ROM、不同网络环境，后续改Topic结构、调整消费规则还要兼容所有历史版本App，运维成本根本扛不住
• 负载问题确实存在：Kafka消费相关的协议解析、状态维护、消息拉取逻辑如果全部跑在端上，会额外占用App的内存、CPU资源，在中低端设备上很容易导致App卡顿甚至闪退。

补充：如果需要实现消息到达回执、已读上报这类能力，只需要App在收到系统推送、展示通知的时候，单独调用后端的上报接口即可，完全不需要和Kafka逻辑产生耦合。

内容的提问来源于stack exchange，提问作者Pradeep Gopi