4. 可用性架构：SLO/SLI设定、冗余设计、故障切换、多活策略

可用性架构是AI产品在生产环境中持续提供服务的基石。相比传统软件，AI服务依赖模型推理、特征工程、数据管道等多环节，任何一环的抖动都可能导致整体可用性坍缩。本章从SLO/SLI指标定义出发，剖析冗余、故障切换与多活策略的选型边界，并给出落地路径。

4.1 边界划分

可用性架构需首先界定“服务可用”的含义。AI产品的可用边界应覆盖以下三层：

• 基础设施层：计算节点、GPU集群、网络、存储的可用性。
• 推理服务层：模型加载、请求-响应通路的可用性，含推理超时与错误率。
• 数据流层：特征获取、日志回传、模型热更新的可用性。

可用性设计必须向上对齐业务承诺（如SLA），向下分解为可量化的SLI指标。

4.2 系统分层与组件职责

可用性架构分为以下四个组件层，每层有明确的职责边界：

1. 健康探测层：运行Liveness/Readiness探针，周期性检测GPU显存、模型推理速度、内存泄漏等。
2. 负载管理层：基于SLI做加权或一致性哈希转发，识别异常实例并摘流。
3. 故障切换引擎：检测到主节点失效后，将流量转移至备用节点，切换时间受心跳间隔与探针超时影响。
4. 多活协调层：维护多副本状态一致性（如模型版本、特征缓存），确保切换后服务不降级。

4.3 冗余设计与故障切换策略

冗余不是简单的节点加倍，而是围绕“故障域”做隔离。AI产品常见的冗余模式：

故障切换的关键控制流路径设计：

• 探针 → 健康状态变更 → 负载管理器剔除实例 → 流量切换。
• 两次探针失败（含重试间隔）才触发切换，避免网络闪断导致误切换。
• 限制切换频率（如每分钟最多切换1次），防止反复震荡。

4.4 多活策略与数据流/控制流

多活策略解决“单地域故障”问题，但数据一致性挑战最大。AI服务的多活设计要点：

• 模型版本同步：跨地域模型文件通过对象存储同步，使用版本号避免滚动不一致。
• 特征缓存一致性：建议只读副本+本地缓存，写操作只在主地域完成。
• 控制流：全局配置中心（如Etcd/Consul）负责下发SLO阈值与切换策略，跨地域通过gRPC双向流同步。

以下SVG展示了AI服务可用性架构的核心数据流与控制流链路：

4.5 选型权衡与风险点

4.6 落地步骤

1. 定义SLO基线：采集现有服务的p99延迟与错误率，设定可容忍的SLO窗口。
2. 部署健康探针：为每个推理容器注入Liveness探针（检查GPU状态与推理响应）。
3. 搭建冗余节点：至少保证主备节点在独立故障域（不同物理机/机架）。
4. 配置自动切换阈值：设定连续失败次数与切换冷却时间。
5. 灰度实施双活：先从静态路由演练，再逐步切为动态流量。
6. 持续监控与演练：每周混沌工程注入节点故障，验证切换时间。

4.7 验收标准