能跑和跑得久是两个工程
协议模拟的技术验证（PoC）一天能搞定，但上线跑一周就大面积封号——差距在稳定性工程。本文讲把协议服务从 demo 变成生产系统的关键设计。
稳定性问题的四个来源
1. 凭证过期：token/cookie 过期没及时刷新，请求批量失败
2. 风控累积：行为模式被风控逐步标记，通过率先缓降后跳水
3. 目标变更：App/网站更新，签名算法或接口结构变了
4. 资源枯竭：IP 被封、账号被封、设备档案被标记
对应的稳定性设计逐个讲。
凭证生命周期管理
class CredentialManager:
def __init__(self):
self.creds = {} # account_id -> credential
def get(self, account_id):
cred = self.creds.get(account_id)
if not cred or cred.expires_in() < 300: # 提前 5 分钟刷新
cred = self.refresh(account_id)
self.creds[account_id] = cred
return cred
def refresh(self, account_id):
# 优先用 refresh_token 无感刷新
# 失败则走完整登录流程
# 再失败标记账号异常，移出池
pass要点：提前刷新（别等过期）、降级链（refresh → 重登 → 标记异常）、刷新失败有告警。
成功率监控与熔断
class Monitor:
def __init__(self):
self.window = collections.deque(maxlen=100) # 滑动窗口
def record(self, success):
self.window.append(success)
if len(self.window) == 100:
rate = sum(self.window) / 100
if rate < 0.7: # 成功率跌破 70%
self.alert(f'成功率告警: {rate:.0%}')
# 熔断：暂停任务，检查是凭证问题还是风控升级成功率是最敏感的健康指标——签名失效、风控升级、IP 被封，全部第一时间反映在成功率上。配好告警（企业微信/钉钉 webhook），比用户报障早发现几小时。
版本变更的对抗
目标 App 更新是协议服务的头号杀手。防御体系：
- 版本监控：盯目标 App 的版本发布（应用市场监控），新版本发布即触发兼容性检查
- 特征校验：每次启动签名服务时，用已知输入对拍——输出和基线一致才上线，不一致立刻告警（算法变了）
- 灰度策略：App 更新期自动降速 50%，观察通过率再恢复
资源池的健康度管理
IP/账号/设备三池都要有"健康分"：
class ResourcePool:
def score_update(self, resource, success):
resource.score += 1 if success else -5 # 失败重罚
if resource.score < 0:
resource.quarantine(hours=24) # 隔离冷却
elif resource.score < -20:
resource.retire() # 永久退役核心原则：失败有成本，资源会疲劳。一个 IP 连续失败不是 IP 的运气问题，是它已经被标记了——继续用只会加深标记。
精髓：稳定性的三个认知
- 稳定性是设计出来的，不是祈祷出来的。每个"可能会挂"的点都要有对应的检测和恢复机制——列一张故障模式清单（凭证过期/风控/IP封/版本变更），逐项配对策
- 数据比直觉可靠。成功率、平均延迟、风控触发率全部落盘记录——出问题时有数据可查，比"感觉最近不太好"强一百倍
- 优雅降级优于硬扛。风控升级期的正确动作是降速保号，不是硬冲——账号池死光了，业务也就停了
总结
- 稳定性四敌：凭证过期、风控累积、目标变更、资源枯竭
- 凭证提前刷新 + 降级链 + 告警
- 成功率滑动窗口监控，跌破阈值熔断
- 资源池健康分管理，失败有成本，资源会疲劳
交流微信：run1255