一、被动感知——靠状态事件回调最直接的方式是状态事件回调实例掉线时 Eyun 推送状态变更事件程序收到通知就知道掉线了。被动感知零延迟——掉线瞬间就能知道。但被动感知有盲区程序自身重启后丢失回调记录不知道当前状态。所以被动感知只能告诉你什么时候变了不能告诉你现在是什么状态。二、主动探测——定期查实例状态补上被动感知盲区的是主动探测定时调实例状态接口查当前是否在线。探测频率不宜太高5-10分钟一次足够每次探测记录状态到数据库。主动探测的价值是恢复认知——程序重启、网络恢复后主动查一次就知道当前状态不依赖回调历史。被动主动组合才能在任何时刻都知道准确状态。三、状态判定逻辑——不止在线和掉线两种实际状态不是非黑即白。程序要区分四种状态在线正常接口可用、在线但异常接口可用但频繁报错、掉线状态回调通知、未知刚重启还没探测到。在线但异常是最容易漏的状态——接口返回成功但部分功能不正常比如能收消息但发不出去。靠接口调用成功率监控来发现成功率突然下降说明在线但不健康。四、知道状态后做什么知道状态后的动作分两类在线正常时做业务掉线时做应急。应急动作包括告警通知管理员发消息给管理员微信号、暂停所有发送操作避免堆积失败请求、标记待重发消息恢复后补发。状态感知策略对照感知方式怎么做优势盲区被动感知状态事件回调零延迟重启后丢失状态主动探测定时查实例状态恢复认知有探测间隔延迟健康监控接口调用成功率发现在线但不健康需数据积累四态判定正常/异常/掉线/未知覆盖真实场景逻辑稍复杂状态感知完整方案import threading, time class InstanceMonitor: def __init__(self): self.status unknown # 四态normal/abnormal/offline/unknown self.error_count 0 self.total_count 0 # 被动感知状态回调 def on_status_event(self, d): if d.get(status) offline: self.status offline self.on_offline(d[wId]) elif d.get(status) online: self.status normal self.on_recover(d[wId]) # 主动探测定时查询 def probe(self): r api(getInstanceStatus, {wId: WID}) if r.get(code) 1000: if self.status offline: self.status normal self.on_recover(WID) else: self.status offline self.on_offline(WID) # 健康监控记录接口成功率 def record_call(self, success): self.total_count 1 if not success: self.error_count 1 if self.total_count 20 and self.status normal: rate self.error_count / self.total_count if rate 0.3: # 错误率超30% self.status abnormal alert(f{WID} 在线但异常成功率 {1-rate:.0%}) def on_offline(self, wid): sendText(ADMIN_WID, ADMIN_ID, f{wid} 掉线) db.set_flag(paused, True) # 暂停发送 def on_recover(self, wid): sendText(ADMIN_WID, ADMIN_ID, f{wid} 已恢复) resend_pending() # 补发待发消息落地建议状态感知不是接个回调就完事——回调告诉你变化主动探测给你当前快照健康监控发现隐性异常。三者缺一不可。建议上线时三套机制都配好掉线告警要发给人能收到的渠道管理员微信。状态接口和回调说明参考 Eyun 开发文档。