企业微信二次开发实战：如何搭建一个自动化消息处理系统

消息自动化不是写几个回调处理器就完事。消息量大了之后超时、重复、乱序、积压这些问题会一个个冒出来。我们从一个简单的回调服务演进到能扛日均十万条消息的处理系统中间加了队列、状态机、幂等、降级四层保障。这篇讲系统架构和每层解决的问题。底层用的是Eyun 平台开放的企微 API凭证在Eyun 平台首页开通Webhook 收消息message 模块发消息。系统架构四层拆解系统分四层接入层、队列层、处理层、发送层。接入层只做一件事收 Webhook 回调验签去重落库推队列。5 秒内返回 200不做任何业务处理。队列层用 Redis List按会话uin 或 roomId分队列。同一会话的消息串行处理不同会话并行既保序又保吞吐。处理层从队列取消息做意图识别、业务调用、生成回复。处理结果发回发送层。发送层调 message/sendText 或 sendRichText 发消息发完存流水。幂等delivery_id 去重回调至少一次投递同一条消息可能推多次。用X-Eyun-Delivery请求头做去重键Redis SET NX 判断24 小时内只处理一次。delivery_id request.headers.get(X-Eyun-Delivery) if not redis.setnx(fmsg:{delivery_id}, 1): return ok # 重复投递直接跳过 redis.expire(fmsg:{delivery_id}, 86400)去重放在接入层处理层不用关心重复问题。消息体字段在开发文档里有完整说明。保序按会话串行客户连发三条消息如果并发处理可能乱序回复。按会话分队列同一 uin 的消息进同一个队列消费线程串行处理。实现上用 Redis 的lpush入队、brpop阻塞出队。多个消费者轮询多个队列同一队列只有一个消费者在处理。降级处理超时回兜底处理层调业务接口或模型可能超时。单条消息处理超过 3 秒走降级逻辑——回正在处理请稍候后台异步重试结果出来后再补发。降级保证用户不会等太久也不会因为一次超时导致整条链路阻塞。监控四个核心指标系统稳定不稳看四个数回调接收量每分钟收到多少条突然下降说明回调链路有问题队列积压量积压超过阈值告警说明处理速度跟不上处理成功率低于 99% 告警端到端延迟从收到到回复超过 5 秒告警这四个数稳定系统就基本稳定。接口字段在开发文档里有完整说明。架构的价值在可扩展四层拆开后每层可以独立扩展。消息量大了加处理消费者发送慢了加发送线程队列满了换 Kafka。系统从日均几千条到十万条只加了机器没改架构。