宝软数字 · 产品深度解读 · 2025-09-03
高可用不是追求"永不故障"——这是不可能的。真正的工程智慧在于承认系统一定会出问题，然后在设计上确保出问题时核心功能仍然可用。就像消防通道不是为日常生活设计的，而是为火灾逃生准备的最后屏障——降级策略就是软件系统的"消防通道"。本文完整拆解EIOS的五级降级体系：从最轻量的一级（限流熔断保护）到最极端的五级（静态兜底页面），每级降级有明确的触发条件、执行动作和恢复策略。所有降级行为的最高准则只有一条：用户的核心对话不能断。
面对高负载或故障，最直觉的反应是"加机器"。但现实中有三个无法回避的约束。第一，钱不是无限的——按峰值并发（如1000并发）配置服务器意味着大部分时间（如深夜和周末）资源严重浪费。第二，机器不是马上能加的——即使你立刻启动新实例，到它热好缓存、加入负载均衡、开始处理流量，可能需要5-15分钟。这段时间里你怎么办？第三，机器解决不了所有问题——如果PostgreSQL挂了，你加100台API服务器也没有用。
降级策略的本质是在资源有限的前提下做功能取舍。核心思路是：将系统功能按重要性分为P0（核心功能——Agent对话，不可降级）、P1（重要功能——知识库搜索、文档上传，可限速但不可关闭）、P2（次要功能——使用统计、报表导出、批量操作，可限速或临时关闭）、P3（辅助功能——通知推送、suggestions推荐、非核心Agent，可关闭）。当系统面临压力时，按照P3→P2→P1的顺序逐步降级，确保P0始终可用。
这个取舍不是"出了事再想"的临场反应——每一级降级在什么条件下触发、关闭什么功能、影响多少用户、用户看到什么替代体验——都在系统设计时就确定好了，并且在代码中以Feature Flag和断路器的形式实现。降级不是"系统坏了"，而是"系统在按预定计划保护自己"。
降级的工程代价：实现完整的降级体系需要在每个功能点都编写降级逻辑——正常路径、降级路径、恢复路径。这增加了约15-20%的代码量。这个代价是否值得？从故障统计来看——在引入完整的5级降级体系后，系统的P0功能可用性从99.5%提升到99.95%（年度P0故障时间从约44小时降低到约4小时）。对于服务付费企业客户的SaaS平台，这个差异直接转化为客户信任和续约率。降级策略的代码投资，是最容易在事故复盘时被忽略的"沉默英雄"。
一级降级是最轻量的保护措施——它不关闭任何功能，而是限制请求速率和切断故障依赖。这是系统的第一道防线，大多数时候在用户完全无感知的情况下运行。
限流确保没有任何单一用户或来源可以占用过多的系统资源。EIOS实现了三层限流：入口层（Nginx的limit_req_zone，基于IP的速率限制——单IP每秒最多120个请求，防止暴力扫描和爬虫）、应用层（基于Redis的令牌桶算法，按用户维度——免费用户每分钟30次API调用，付费用户每分钟120次）、Agent层（每个Agent实例每秒最多5次LLM推理调用，防止单个对话循环消耗过多推理资源）。限流的响应不是"直接拒绝"，而是返回429 Too Many Requests并带上Retry-After头——告诉客户端"请稍后再试，X秒后你的配额会恢复"。这不是惩罚用户，而是保护系统让所有用户都能获得公平的服务。
熔断保护系统免受依赖服务故障的级联影响。如果LLM推理API开始返回大量超时（错误率超过50%且持续30秒），熔断器跳闸（OPEN状态）——后续请求不再发送到故障的LLM API，而是直接返回降级响应。熔断器定期尝试恢复（HALF-OPEN状态，每30秒尝试发送1个探针请求）——如果探针成功，熔断器关闭（恢复全流量）；如果探针仍然失败，熔断器保持OPEN并继续等待。EIOS使用opossum库实现熔断器，配置了针对不同依赖的差异化参数——LLM API的熔断阈值较低（错误率50%就触发，因为LLM推理是核心路径），外部搜索引擎的熔断阈值较高（错误率80%才触发，因为搜索结果可以用缓存兜底）。
熔断器的坑：熔断器不是配置了参数就完事的。一个隐藏的问题是"熔断器雪崩"——当多个服务共享一个依赖时（如所有Agent都依赖同一个LLM API），一旦该依赖出问题，所有服务的熔断器同时跳闸。恢复时所有熔断器又同时尝试HALF-OPEN，导致请求集中涌入刚恢复的服务，可能再次打挂它（这就是"惊群效应"）。解决方案：HALF-OPEN的探针请求加入随机抖动（Random Jitter）——每个熔断器的等待时间在基础时间上增加随机偏移（如30秒 + random(0, 15)秒），将恢复请求分散在不同时间点。
当限流和熔断无法消化当前压力（如CPU持续超过85%超过5分钟，或P95延迟超过5秒），系统启动二级降级——功能降级。这一级开始对用户可见，但影响的是非核心功能。
二级降级的第一批动作是关闭P3辅助功能。这包括：Agent对话中的个性化推荐（"你可能还想问..."）、对话历史的情感分析标签、使用量统计的实时更新（转为T+1批量更新）、非关键的通知推送（如"你的对话已保存"之类的确认通知）、实验性Agent功能（标记为Beta的Agent）。这些功能被关闭后，用户的核心对话体验不受影响——Agent仍然正常推理和回答，只是少了些"锦上添花"的辅助体验。
如果压力继续上升，二级降级进入第二批动作——限速P2次要功能。这包括：将知识库文档上传的并发处理数从50降到10（排队时间变长但功能仍然可用）、将批量操作（如批量导出、批量删除）放入低优先级队列（可能延迟数分钟到数小时执行）、将报表和仪表盘的实时更新从5秒间隔延长到5分钟间隔、停止非活跃会话的自动保存（内存中的数据在服务恢复后可能丢失）。
二级降级通过Feature Flag系统实现——每个功能点都包裹在一个Flag检查中。在正常状态下所有Flag为ON；降级触发时运维平台（或自动系统）将对应Flag设为OFF，功能即刻在全国范围内关闭。Feature Flag使用LaunchDarkly风格的架构：Flag值存储在Redis中，应用层在每个请求中检查Flag（延迟<1ms），Flag变更实时生效（不需要重启或重新部署）。
Feature Flag的工程实践：Feature Flag是降级策略的基础设施——没有它，降级就需要"改代码+部署"，这在紧急情况下是灾难性的。但Flag也带来了代码复杂度的增加——每个if(flag.isEnabled('xxx'))分支意味着你需要维护两条代码路径（Flag ON和Flag OFF）。我们的规则是：每个Flag降级路径必须被自动测试覆盖（确保降级路径不抛出异常），且Flag的默认值必须是ON（保证新服务启动时全功能正常，不会因为Flag初始化延迟导致功能缺失）。
当整个系统面临严重压力（如PostgreSQL连接数接近上限、Neo4j查询延迟飙升、LLM API大面积超时），系统启动三级降级——服务降级。这一级开始影响Agent的核心能力，但确保基础对话仍然可用。
三级降级的核心策略是关闭Agent的非核心工具。每个Agent注册了多个工具——核心工具（如知识库搜索、对话推理）和辅助工具（如网络搜索、数据图表生成、代码执行、邮件发送）。在降级状态下，Agent的工具注册表只加载核心工具——用户仍然可以与Agent对话，查询企业内部知识库，获得AI生成的回答。但Agent失去了"联网搜索最新信息"、"根据数据生成可视化图表"、"执行代码分析"等高级能力。用户在对话界面上会看到一个淡淡的降级提示："当前AI助手运行在精简模式下，部分高级功能暂不可用。基础问答不受影响。"
如果压力进一步恶化，三级降级进入第二步——使用更轻量的模型。正常状态下，复杂问题使用GPT-4级别的模型（高质量但慢且贵），简单问题使用GPT-4o-mini级别的模型（快速且便宜）。在三级降级下，所有请求统一使用最快的轻量模型——回答质量有所下降（对于需要深度分析的复杂问题），但保证了响应速度和系统吞吐量。这是服务降级中"质量换可用性"的典型案例——一个"不太精辟但能给的答案"远好于"根本没有任何答案"。
模型降级的用户体验：模型降级对用户感知的影响取决于提问的类型。对于事实性问题（"公司去年的营收是多少？"），轻量模型和重量模型的回答质量几乎没有差异。对于分析性问题（"分析我们销售团队的业绩趋势并提出改进建议"），轻量模型的回答可能缺少深度和结构性。我们做了一个AB测试——在用户不知情的情况下将一部分请求从GPT-4降级到GPT-4o-mini，然后评估用户满意度。结果：事实性问题的满意度无差异，分析性问题的满意度下降了约12%。所以在三级降级中，我们优先对事实性问题的请求做模型降级，保持分析性请求使用标准模型直到最后才降级——这样在保护系统的同时最小化对高价值用户的影响。
当数据层出现严重问题时——PostgreSQL主实例负载过高、磁盘空间告急、或者主从复制延迟过大——系统启动四级降级：读写分离降级。这一级几乎关闭了所有写入操作，但对话功能仍然正常工作。
四级降级的第一步是将所有读取操作路由到只读副本。PostgreSQL的主从架构在正常状态下是主库承担读写、从库承担只读查询。四级降级状态下，所有请求（包括本来需要写主库的）都切换到只读副本——用户的对话历史可以查阅，知识库文档可以搜索，Agent可以基于现有数据推理和回答。但任何写入操作——保存新对话、上传新文档、修改配置——返回一个友好的提示："系统正在进行紧急维护，您的操作将在恢复后自动处理。当前不影响浏览和对话功能。"
四级降级的第二步是异步化剩余写入。不能丢失的写入请求（如用户付费操作的记录）不是直接拒绝，而是记录到本地日志文件或消息队列的持久化存储中。当主数据库恢复后，后台Worker依次回放这些挂起的写入操作。这不保证写入的实时完成（可能有数分钟的延迟），但保证数据不会丢失。
四级降级的第三步是清理临时数据和日志。系统自动清理30天以上的审计日志归档（转移到冷存储）、清除过期的缓存数据、压缩并归档旧对话记录——释放存储空间和数据库资源。
只读模式的设计原则：只读模式必须在用户体验层面可见但又不过度惊吓用户。我们的方案是：界面顶部出现一个浅黄色的横幅提示（非红色——红色暗示"出问题了"，黄色暗示"在进行维护"），文案为"系统正在优化升级中，部分功能（如保存对话、上传文档）暂不可用。浏览和对话功能不受影响。预计X分钟内恢复。"关键设计：给出了大致的恢复时间——即使这个时间不一定准确，有预期的等待比无预期的等待心理感受好得多。
五级降级是最极端的保护措施——当后端服务完全不可用时（所有Pod都不健康、数据库完全无法访问、整个集群面临崩溃），系统切换为静态兜底模式。这一级只应该在极其罕见的情况下触发——通常意味着基础设施层面的严重故障（如整个可用区断电、云服务商大规模故障、严重的网络分区）。
静态兜底由CDN层面的Fallback配置实现。当后端API服务不可达时（CDN检测到源站连续返回5xx错误），自动切换到预部署在CDN边缘节点上的静态版本。这个静态版本是一个精心设计的"最小可用"页面——包含：一个清晰的状态说明（"系统正在紧急恢复中"），企业的联系信息（技术支持热线、邮箱），最近一次备份的用户文档索引（只读浏览），以及最重要的——一些预先缓存的、回答常见问题的静态FAQ页面。用户无法发起新的Agent对话（这需要后端推理服务），但可以浏览之前保存的对话记录和知识库文档。
静态兜底的实现依赖于CDN的Edge Computing能力。我们使用Cloudflare Workers在边缘节点上部署了轻量级的Fallback逻辑——当源站健康检查失败时，Worker拦截请求并返回预生成的静态HTML页面。静态页面不是空的"系统维护中"——它包含了从最近一次备份生成的用户可浏览的资源列表，以及一个异步提交问题的表单（提交的问题存储在Cloudflare KV中，系统恢复后批量推送到Agent引擎处理并邮件回复）。
静态兜底的恢复：当源站恢复健康后，CDN自动将流量切回动态源站。用户在静态模式下提交的问题被批量处理——Agent引擎恢复后，Worker将存储的问题通过API提交，Agent逐个回答并通过邮件/站内信发送给用户。这个过程可能是异步的（用户提交问题后离开，几小时后收到答案邮件），但在极端故障场景下，这是能提供的最佳体验了。
五级降级的演练：五级降级触发意味着重大故障——你不希望第一次遇到这个场景是在真实生产事故中。我们每季度进行一次"Chaos Engineering"演练——在生产环境的隔离分区中，人为触发五级降级（如通过Chaos Mesh随机关闭所有API Pod），验证静态兜底能否正确激活、CDN Fallback配置是否正确、故障恢复后的数据回放是否完整。这些演练不仅验证了技术方案的可靠性，也训练了团队的应急响应能力——知道在极端场景下应该做什么，而不是拿着手册现学。
五级降级体系的一个关键问题是：谁来触发降级？如果依赖人工判断（"运维人员发现CPU过高，决定启动二级降级"），那从发现到决策到执行可能需要5-10分钟——这在高压力场景下太慢了。而且人类的判断并不总是准确的——可能因为"再观察一下"的犹豫而延迟降级，也可能因为"保险起见"而过早降级。
EIOS的降级体系是半自动化的。一级降级（限流熔断）和二级降级（功能降级中的P3关闭）是全自动的——系统检测到触发条件后立即执行，同时发送通知给运维团队。三级降级（P2限速+服务降级）是自动触发+人工确认——系统检测到条件后提出降级建议，等待运维确认（超时5分钟未响应则自动执行）。四级和五级降级需要人工确认——因为这涉及用户可见的重大体验变化和可能的合规影响（如写入操作的延迟处理可能影响数据完整性承诺）。
降级的恢复是逐级进行的——不是"刚才的问题解决了，把开关全打开"。恢复策略是：在触发条件消失后，等待一段"冷静期"（通常为降级持续时间的2倍，最少5分钟），然后逐级恢复——先恢复P2功能，观察5分钟没有问题后再恢复P3功能。这样防止了"恢复→又被冲垮→再次降级"的震荡。
降级决策的监控：所有降级事件——触发时间、触发原因、降级级别、影响范围、恢复时间——都有完整的日志记录。这些记录不仅用于事后复盘，也用于持续优化降级策略。例如，我们发现二级降级中P3功能的关闭在某些情况下提前了——CPU使用率尚未达到阈值，但请求队列已经开始堆积。基于这个发现，我们在降级触发条件中增加了"请求队列深度"指标，使得降级能够在"CPU瓶颈"出现之前就能根据"排队压力"预判并提前启动。