官网友情链接 wecomapi.com企微二次开发中只要系统依赖回调事件就一定会遇到处理失败。客户新增事件可能失败。群成员事件可能失败。标签同步可能失败。消息任务可能失败。大多数系统已经会做自动重试比如失败后重试3次。但如果重试3次、5次甚至10次以后仍然失败接下来怎么办很多早期系统会把错误写入日志然后任务结束。这意味着这个业务事件实际上被永久丢弃。随着系统运行时间变长类似事件不断积累最终会产生本地客户和远端不一致群成员状态错误标签漏同步CRM数据缺失。所以企业微信二次开发API的事件系统需要一个重要兜底死信队列。WeComApi 可以作为企微API接入层把企业微信客户、外部群、消息和相关事件接入业务系统。本地事件平台则负责重试、死信、人工处理和重放。一、什么是死信一个事件经过正常处理和有限次数重试后仍然无法成功。系统不再继续自动重试。把它转入dead_letter_queue。这不是删除。而是“我现在处理不了但不能丢。”二、为什么不能无限自动重试如果失败原因是参数错误客户不存在权限不足重试100次也不会成功。无限重试只会浪费资源。甚至拖慢正常任务。所以需要可重试错误不可重试错误。分类。三、一个具体例子客户新增事件 E1001。业务系统尝试同步CRM。CRM返回500。第一次失败。1分钟后重试。仍失败。5分钟后第三次。仍失败。30分钟后第四次。仍失败。达到最大重试次数。事件进入死信。死信记录event_id E1001event_type customer_added最后错误 CRM unavailable已重试4次客户 C001首次失败时间最后失败时间。CRM恢复后管理员可以批量重放。四、死信和异常中心可以连接技术上进入死信。业务上同时生成CRM同步异常。这样技术人员能看底层事件。业务人员也知道某个客户资料未同步。五、死信必须保留原始事件不能只保存错误文本。需要完整payload事件类型版本trace_id处理历史。否则以后无法真正重放。六、死信还要保存每次失败历史第一次失败timeout。第二次500。第三次connection refused。这些变化有助于判断问题类型。七、事件重放必须幂等死信恢复以后重新处理。之前可能已经完成部分动作。例如客户本地已创建只是CRM失败。重放时不能重复创建客户。步骤状态和业务幂等必须存在。八、批量死信重放需要限流如果CRM故障2小时。积压5万条死信。恢复以后不能瞬间全部发出。可以每秒固定数量按优先级分批。重点客户优先。九、死信也需要过期策略不是所有死信永久保留。普通低价值事件经过一定时间可以归档。但涉及客户、合同、重要群关系的事件可以长期保留直到处理。生命周期按事件类型配置。十、人工可以标记“无需处理”例如事件已经被全量对账修复。管理员打开死信。确认本地状态正确。标记resolved_by_reconciliation。不再重放。这也要审计。十一、WeComApi 在事件体系里的位置WeComApi 负责企业微信API事件进入。本地平台负责入库消费重试死信重放人工处理。接入层和消费层解耦以后失败不会导致原始事件消失。十二、死信队列也要按类型分类消息客户群成员CRM文件。不同类型分配不同负责人。避免所有死信堆一个列表。十三、优先级重点客户消息死信高优先级。历史统计事件低。这样人工先处理真正影响业务的事件。十四、死信数量可以作为系统健康指标正常每天10条。突然5000条。说明系统很可能出现重大故障。可以直接触发告警。十五、重复死信要聚合同一CRM接口导致10000个事件失败。异常中心应该展示CRM接口异常影响10000事件。而不是10000条独立告警。死信记录仍然逐条保留。十六、权限普通运营只能处理业务死信候选。技术管理员才能重放系统事件。批量大规模重放需要更高权限。十七、审计谁重放谁忽略谁标记已修复什么时候处理结果。全部记录。十八、总结企业微信二次开发API系统真正可靠不是因为它从来不会失败。而是失败以后事件不会消失。WeComApi 可以把客户、群、消息等企微事件持续送入业务系统。本地事件系统通过有限重试错误分类死信人工处理重放幂等保证那些暂时处理不了的事件仍然有最终去处。如果重试失败以后只有一条日志数据差异会不断积累。有了死信队列系统就具备“今天解决不了明天修复以后还能重新处理”的能力。这才是企微自动化长期运行需要的真正恢复能力。
