Article body
正文
引言
BI 已经成为许多企业的经营决策入口。管理层依赖早会看板，风控团队需要 7×24 小时监控交易。当 BI 不可用时，业务人员会失去判断依据，部分实时流程也会中断。
高可用（High Availability，HA）关注日常故障下的持续服务，容灾（Disaster Recovery，DR）关注机房或地域级事故后的恢复能力。衡石 BI 从组件冗余、故障转移、数据备份和跨机房部署几个层面构建稳定性保障。本文介绍这套架构及其实施要点。
一、用 SLA、RTO 和 RPO 定义目标
1.1 三个指标
SLA（Service Level Agreement） 表示系统在约定周期内的可用时间占比。99.9% 对应每年约 8.76 小时不可用，99.99% 对应每年约 52 分钟不可用。
RTO（Recovery Time Objective） 表示故障发生后恢复服务的目标时间。RTO 为 15 分钟，意味着团队需要在 15 分钟内恢复核心服务。
RPO（Recovery Point Objective） 表示事故发生时允许丢失的数据时间窗口。RPO 为 5 分钟，意味着恢复点最多落后故障时刻 5 分钟。
更高的 SLA 和更小的 RTO、RPO 会增加部署复杂度与成本。项目团队应根据业务连续性需求确定目标，实际承诺以双方约定和部署方案为准。
1.2 划分故障域
稳定性设计先识别故障影响范围：
- 进程级故障：单个服务进程崩溃，只影响该进程处理的请求
- 节点级故障：一台服务器宕机，影响该节点上的全部服务
- 机房级故障：机房断电或断网，影响该机房中的所有节点
- 地域级故障：城市级事故影响该地域中的多个机房
架构需要把冗余副本放在不同故障域内，避免多个副本同时失效。
二、衡石 BI 高可用架构
2.1 无状态服务冗余
接入层、API 网关和查询路由等组件不在本机保存会话数据，会话状态进入 Redis 等共享存储。
每个无状态服务至少部署两个跨节点实例，并由负载均衡器分发请求。健康检查发现实例不可用后，负载均衡器将新流量转到其他实例。业务增长时，团队可以增加实例完成水平扩容。
2.2 有状态服务高可用
查询引擎和元数据服务需要处理状态复制与主节点选举。
查询引擎
- 使用主从或多副本架构
- 主节点故障后，通过 Raft 等选举协议选择新主节点
- 查询路由只向健康节点发送请求
元数据服务
- 使用分布式 KV，或 PostgreSQL 等支持复制的关系型数据库
- 数据库主库故障后切换到备库
- 优先保护指标定义和数据集配置等平台基础元数据
2.3 数据存储冗余
OLAP 引擎
StarRocks、Doris 等引擎通过分片与多副本保存数据。单节点故障后，其他副本继续提供查询，后台再从健康副本补齐缺失数据。
对象存储
图表资源和导出文件可以存入 MinIO 集群或云对象存储，利用存储层的多副本能力抵御磁盘和节点故障。
2.4 健康检查与优雅摘除
健康检查可以分为四层：
- L4 检查 TCP 端口
- L7 检查 HTTP API
- 业务层执行探测查询
- 依赖层检查数据库和 OLAP 引擎
实例下线前，负载均衡器停止发送新请求，并等待在途请求结束后再摘除，减少用户操作中断。
三、跨机房与跨地域容灾
3.1 同城双活（Active-Active）
两个低延迟机房同时承载流量，各自运行完整服务集群。OLAP、元数据和对象存储通过对应的复制机制同步数据。
一个机房失效后，流量切换到另一机房。双活架构需要确保任一机房都能独立承载业务峰值，因此两侧都要预留足够容量。
3.2 异地灾备（Active-Standby）
主中心承载日常业务，异地灾备中心同步数据并保持待命。复制间隔决定可达到的 RPO；服务拉起和流量切换时间共同决定 RTO。
异地灾备适合需要满足跨地域恢复要求，但不需要两个中心同时承载流量的部署。
3.3 备份与恢复
双活和灾备不能替代定期备份。团队可以组合以下策略：
- 每周执行全量备份
- 每日执行增量备份
- 持续保存数据库 WAL 等日志，支持时间点恢复（Point-in-Time Recovery）
备份应保存到与生产系统不同地域的对象存储。团队还需要定期恢复到测试环境，验证数据完整性和实际恢复时间。
3.4 故障演练
架构图无法证明系统已经达到高可用目标。测试团队可以在隔离环境中终止服务进程、断开节点网络、触发数据库主备切换，并记录系统响应。
跨机房或跨地域部署还需要定期执行真实切换演练，对照 RTO、RPO 检查结果，并把暴露的问题进入改进清单。
四、可观测性支撑
4.1 核心监控指标
可用性
- 服务进程、端口和 API 的健康状态
- HTTP 5xx 比例与请求成功率
- 从用户请求到图表返回的端到端探测结果
性能
- 查询 P95、P99 延迟
- CPU、内存、I/O 和连接数
- 请求队列深度
容量
- 存储使用率
- 数据库和服务连接数
- 数据副本缺失数量
4.2 告警分级与收敛
团队可以按影响范围定义告警等级：
- P0：整体服务不可用，需要立即响应
- P1：核心功能降级，需要在约定时限内处理
- P2：资源水位等预警，由值班团队安排处理
告警平台应把同一根因产生的多个组件告警合并，并附上依赖关系和处理建议，减少重复通知。
4.3 自动恢复
平台可以自动处理部分故障：
- 服务进程崩溃后按指数退避策略重启
- 健康检查持续失败后摘除节点
- 存储副本缺失后从健康副本补全
- 突发流量超过容量时限制低优先级请求
五、高可用项目实施要点
5.1 容量规划
冗余副本会增加成本。团队需要根据流量峰值和故障切换目标规划容量：
- 单机房部署为峰值预留资源余量
- 双活部署保证任一机房能在另一侧失效后承接全部核心流量
- 灾备中心按恢复后的业务范围准备计算与存储资源
5.2 常见问题
只做应用冗余，忽略依赖
两个应用节点如果连接同一个数据库主库，数据库故障仍会让整个服务不可用。负载均衡、应用、数据库和存储都要具备与目标匹配的冗余，而且副本不能共享同一故障域。
灾备环境长期不演练
数据同步可能在无人注意时中断。团队至少应按项目约定周期执行恢复和切换演练，验证灾备数据能够支持真实业务。
RTO、RPO 脱离预算和业务需求
接近零中断和零数据丢失需要同步复制、双活容量和成熟的切换机制。项目团队应先评估停机影响，再选择匹配的架构和投入。
六、总结
企业级 BI 的稳定性来自端到端设计。无状态服务需要多实例和负载均衡，有状态服务需要复制与选举，数据层需要多副本，跨故障域部署还需要双活或灾备方案。
衡石 BI 将这些机制与健康检查、监控告警、备份恢复和故障演练组合起来。企业可以根据业务连续性目标确定 SLA、RTO 和 RPO，再选择相应的部署形态与容量。