参考钉钉IM后端架构思路本文聚焦IM网关后端三种主流架构模型做对比分析给出架构选型结论同时完成单机房机器规模估算最后对比Kafka与RocketMQ在IM场景下的优劣。前言IM网关的核心职责维护海量客户端长连接自研TCP、QUIC、WebSocket、协议编解码、token鉴权、前置限流、报文校验网关不适合承载过重业务逻辑。网关向后端投递上行消息一共有三种典型实现方案不同方案在故障隔离、扩容成本、延迟、运维复杂度上差异巨大。钉钉这类亿级IM核心思路就是长连接接入层与业务层、消息队列层做充分解耦避免故障传导支持接入层大规模独立扩容。方案1网关直接RPC调用WorkerWorker承担核心业务链路客户端 → IM网关 → Kitex RPC → Worker服务Worker完成全部业务逻辑消息校验、存储、会话、推送路由同步返回应答给网关。优点链路简单没有MQ引入链路最短没有消息队列带来的存储开销同步调用发送结果可以实时返回客户端消息发送成功失败即时反馈架构组件少前期开发上手快。缺点网关与Worker强耦合网关扩容会直接放大Worker的压力如果部署100台网关全部网关的上行流量全部打向Worker集群Worker很容易被打满。没有削峰能力消息突增、群消息风暴会直接压垮Worker进而造成网关大量RPC超时大批量客户端发送消息报错。Worker故障、慢逻辑、数据库抖动直接传导到网关引发大面积发送失败长连接网关本身是高可用集群后端业务抖动直接影响前端用户体验。不方便做多消费组旁路处理例如消息审计、统计、监控埋点需要额外改造。Worker既要执行业务逻辑又要处理下行推送路由职责耦合。适用场景小规模IM消息QPS不高没有大群消息风暴场景不适合亿级大规模IM。方案2网关直接写Kafka后端Worker消费Kafka承担任务链路客户端 → IM网关网关内置Kafka生产者直接将消息写入KafkaWorker消费Kafka执行业务逻辑。优点MQ天然削峰填谷消息流量突增时Kafka缓冲Worker可以按自身能力消费隔离流量风暴网关与Worker完全解耦支持多消费组审计、统计可以独立消费topic互不影响异步模型Worker故障不会直接导致网关立刻报错。缺点网关集群全部持有Kafka生产者实例。如果单机房部署100台网关则同时存在100个Kafka生产者。生产者会维护元数据、连接、后台刷新任务修改Kafka配置、生产者参数需要全量发布全部100台网关运维成本很高。网关的核心压力是维持海量长连接网关扩容时Kafka生产者实例数量同步增加会加重Kafka集群元数据压力。网关职责变重网关除长连接管理还要维护Kafka客户端、处理生产者异常、重试逻辑网关本应该只聚焦长连接引入MQ客户端会增加网关故障风险。消息发送变成异步无法同步返回发送结果给客户端客户端无法立刻知道消息是否发送成功必须依靠回执机制确认。适用场景网关数量少的小规模集群网关实例数少运维压力可控。当网关达到几十上百台规模该方案运维负担显著上升。方案3网关RPC调用接收服务接收服务写Kafka后端Worker消费处理链路客户端 → IM网关 → Kitex RPC调用接收服务 → 接收服务内部异步写入Kafka → Worker消费Kafka执行业务逻辑Worker处理完成后通过Kitex RPC回调网关完成下行消息推送。核心设计网关不直接操作KafkaKafka生产者全部收敛在少量接收服务实例网关只负责长连接、协议解析、前置校验通过内部RPC转发上行消息。优点网关集群与Kafka彻底解耦。网关可以大规模水平扩容例如单机房100台网关用于承接海量长连接网关扩容不会新增Kafka生产者实例生产者集中在接收服务。修改Kafka生产者配置仅需要发布接收服务100台网关无需变更运维成本低。资源错配资源利用率高网关数量由在线长连接总数量决定接收服务、Worker数量由消息QPS决定。在线连接很多但消息QPS不高时接收服务不需要和网关同步扩到100台少量实例即可扛住写入压力节约机器成本。故障隔离Kafka抖动、生产者重连异常故障收敛在接收服务不会影响全部网关集群网关只感知Kitex RPC调用结果具备熔断、超时、限流保护保护长连接链路稳定。接收服务统一完成消息标准化、partition key计算、生产者参数、埋点统计、异常监控逻辑收敛便于统一治理。保留RPC调用的应答能力网关可以拿到接收服务返回结果RPC失败由上层IM协议msg_id客户端重传送达回执做可靠性兜底。Kafka之后支持多消费组业务Worker、审计、统计服务独立消费互不干扰。缺点相比方案1多一跳Kitex RPC内网环境增加1‑3ms P99延迟小包IM场景可以接受。新增接收服务这一个收敛节点接收服务需要做好水平扩容防止成为上行流量瓶颈。RPC调用存在失败场景不能依靠底层链路保证消息可靠必须依靠IM上层业务msg_id幂等、客户端重传、送达回执机制兜底。消息写入Kafka采用异步发送模式接收服务返回成功不等于消息已经刷入磁盘需要监控Kafka生产者回调异常指标配置告警。适用场景大规模亿级IM网关实例数量多在线连接规模大消息流量波动大参考钉钉的分层接入思想本方案作为最终选型。架构选型结论综合故障隔离、扩容能力、运维成本最终选择方案3网关RPC调用接收服务接收服务写Kafka后端Worker消费处理。架构分层IM网关负责长连接管理自研TCP、QUIC、WebSocket、协议解析、前置鉴权限流网关通过Kitex调用接收服务网关后期底层IO可基于netpoll做扩展和Kitex技术栈统一。接收服务专门负责消息标准化、异步写入Kafka收敛所有Kafka生产者逻辑。Kafka消息缓冲层。Worker服务消费Kafka执行业务逻辑消息存储、会话、权限、推送路由Worker通过Kitex RPC回推消息到网关下发客户端。单机房机器规模估算前提单机房100台IM网关说明为工程经验估算8核16G服务器消息平均1KB峰值QPS 15万消息/秒实际生产需要根据压测结果调整预留30%冗余。IM网关100台给定条件职责承接海量长连接不执行业务不操作Kafka。接收服务Kitex服务专门写Kafka单实例稳定处理2‑3万QPS峰值15万QPS基础6台加上30%冗余部署8台接收服务。接收服务数量由消息QPS决定和网关100台数量无关网关只做RPC调用。Worker业务处理服务消费Kafka执行业务逻辑Worker要做消息解析、存储、数据库操作、会话逻辑单实例处理8000‑12000 QPS峰值15万QPS基础13台加冗余部署18台Worker服务。Kafka集群机器IM场景3副本topic分区总数建议为Broker数量2‑3倍峰值15万消息每秒。部署6台Kafka Broker3副本2个broker一组副本配套3台ZK生产环境磁盘使用SSD保障顺序写入性能。备注以上为业务消息链路机器不包含Redis集群、数据库、监控、网关四层LB等基础设施机器。Kafka与RocketMQ在IM场景优势对比对比维度KafkaRocketMQ设计定位高吞吐流式日志系统分区顺序写零拷贝sendfile追求极致吞吐面向业务消息内置重试、死信、事务消息、tag过滤面向业务语义设计吞吐量更高小消息下集群吞吐能力强适合海量消息流转吞吐略低于Kafka但足以支撑亿级IM消息量消费模型以pull模式没有内置重试、死信队列业务侧自己实现pushpull双模式原生内置重试队列、死信队列对业务更友好消息顺序保证同一个partition内顺序保证队列内顺序支持严格顺序消息事务消息原生不支持事务消息需要业务层封装原生支持事务消息适合和数据库原子落库场景运维组件无自带控制台需要第三方工具依赖Zookeeper新版本可移除ZK自带完善运维控制台运维能力开箱即用延迟消息无原生支持需要业务Redis轮询实现原生支持延迟消息IM离线通知、定时消息场景友好堆积能力极强TB级消息堆积表现优秀支持亿级消息堆积同样可以支撑IM流量峰值大厂实践大量IM、流式场景使用钉钉IM大规模生产落地万亿级消息验证IM场景选型总结如果业务侧可以自行实现重试、死信逻辑追求高吞吐、大消息堆积能力选择Kafka如果业务希望MQ自带重试、死信、事务消息、延迟消息减少业务开发工作量选择RocketMQ钉钉IM正是基于RocketMQ实现大规模企业IM消息流转。本套架构选用Kafka需要业务层自行处理消息重试、死信消息接收服务做好消息幂等生产者配置。结尾网关后端架构的核心思想网关只做长连接接入把消息生产、业务处理向外剥离做到接入层可以独立大规模扩容故障不会相互传导。方案3通过独立接收服务收敛MQ生产者在网关实例数量庞大的场景下运维与稳定性收益最为突出。