HAOVP 所谓高可用，边界到底在哪里

HAOVP 的名字里有“高可用”，项目设计也把高可用作为重点。项目做到这个阶段，我需要把这个词重新拆开：哪些只是技术方案，哪些已经进入仓库和部署文件，哪些经过了实际验证，以及哪些故障发生时系统仍然会不可用。

如果只看组件清单，Nacos、Gateway、Sentinel、Redis Sentinel、MySQL 主从、多节点 Compose、MinIO 副本、RocketMQ、Prometheus 和 Grafana 都与高可用有关。但把这些组件放进项目，不等于整套系统已经达到生产级高可用。

我用三层证据描述能力

为了避免把设计目标写成结果，我把每项能力分成三层：

理论设计
    -> 这个方案理论上解决什么问题

仓库实现
    -> 依赖、代码、配置和部署文件实际有什么

已验证结果
    -> 在什么环境、什么前提和什么故障下得到过什么结果

三层之间不能跳级。配置文件存在，只能证明项目有相应配置；容器启动成功，只能证明进程进入运行状态；接口能够返回预期结果，也不能自动证明节点切换和数据恢复已经完成。

当前部署形态分别解决什么

项目提供三种部署方式：

单机环境对复现和接口验收很有价值。4 月 18 日的 115 条分批接口用例就是在单机 Docker Compose 环境完成的。但这批结果不能用于证明多节点容灾，因为测试环境没有发生跨主机调度和故障切换。

统一入口的边界

Gateway 提供统一路由、JWT 校验、公开路径控制、CORS 和流量治理入口。客户端只需要访问统一入口，不必知道每个业务服务的位置。

外部入口验收中，29 条预设用例得到预期结果，其中包括正常业务请求和预期被拒绝的认证请求。这能够说明当时的入口、路由、认证及若干核心业务链路可以连通。

它不能证明：

• Gateway 已经部署多个实例并由外部负载入口自动切换；
• 网关宿主机不可用时流量会迁移；
• 所有动态路由变更都能无损生效；
• 高并发下网关不会成为瓶颈；
• 入口证书、DNS 和反向代理没有单点。

统一入口解决访问收敛问题，但统一入口本身也需要冗余和健康检查。

Nacos 的边界

多节点方案为 Nacos 安排了多个节点，业务服务通过 Nacos 获取服务实例和配置。它能减少服务地址写死，也为多实例调用提供基础。

但需要区分三种状态：

Nacos 进程存活
    < Nacos 集群能够选举并提供服务
    < 业务服务能发现正确实例并完成完整调用

注册中心看到服务健康，不代表数据库、Redis、对象存储和业务依赖都正常。服务可能成功注册，却因为配置错误或下游故障无法处理请求。

当前文档提供了多节点配置和健康检查方法，但没有足够的故障演练记录证明：任意 Nacos 节点停止、网络分区或共享数据异常时，所有服务都能按目标恢复。

业务服务多实例的边界

服务多实例可以在单个实例停止时保留其他副本，但前提很多：

• 请求入口能发现并选择健康实例；
• 服务没有依赖本机临时状态；
• 会话状态可以跨实例使用；
• 数据库和缓存仍然可用；
• 上传中的文件和异步任务能够恢复；
• 超时、重试和幂等策略不会放大故障。

一个服务启动两个容器，只能说明存在两个进程。要确认多实例容错，至少要在持续请求下停止一个实例，观察失败比例、恢复时间、连接池和日志，再验证业务副作用是否正确。

目前仓库有多节点业务服务编排，但现有验收主要是接口功能和外部入口链路，不足以给出多实例切换时间或无损恢复结论。

Sentinel 的边界

Sentinel 可以提供限流、熔断和降级能力：

限流：控制进入资源的流量
熔断：暂时停止持续失败或过慢的调用
降级：决定受保护时返回什么

项目已经接入 Sentinel 相关依赖和配置方向，但规则存在不等于保护生效。每条规则都需要受控流量、慢调用、异常比例和恢复探测验证。

Sentinel 也不能替代：

• 数据库索引和查询优化；
• 事务、幂等和消息可靠性；
• 容器资源隔离；
• 多节点部署；
• 容量评估和根因修复。

熔断可以限制故障扩散，却不会把失效的下游自动修好。

Redis Sentinel 的边界

多节点方案使用 Redis 主从和 Sentinel。Sentinel 可以监视 Redis 节点并参与主节点切换，业务服务通过 Sentinel 配置寻找当前主节点。

但高可用不仅是“Sentinel 选出新主库”：

• 主从复制可能存在延迟；
• 故障前最后一部分写入可能尚未复制；
• 客户端需要断开旧连接并连接新主节点；
• 切换期间命令可能失败或重试；
• 重试写操作需要考虑幂等；
• 缓存数据与数据库事实仍可能不一致。

Redis Sentinel 解决 Redis 服务连续性的一部分，不自动解决业务缓存一致性，也不证明验证码、令牌和权限状态在切换期间完全无损。

文档提供了验证 Sentinel 主节点和停止节点后的检查步骤，但目前没有完整结果记录可以给出实际恢复时间和数据丢失范围。

MySQL 主从的边界

多节点拓扑中，MySQL 使用一个主库和多个从库，业务写入仍指向主库。这说明项目具备复制与副本方案。

它还不等于：

• 读请求已经稳定分流到从库；
• 主库不可用时从库会自动提升；
• 旧主库会被可靠隔离；
• 应用数据库入口会自动迁移；
• 事务在切换期间不会丢失或重复；
• 原主库恢复后能自动安全加入。

真正的故障切换需要检测、仲裁、隔离、选主、拓扑重建、入口迁移、连接恢复和数据核对。当前文档能支持主从复制和主库写入方向，不能支持未经演练的自动切换结论。

MinIO 副本的边界

HAOVP 的多节点 MinIO 方案是主节点承担业务写入，再把对象同步到另一个节点；还有备用实例，但不能描述为已经自动同步的原生集群。

这套方案能够增加一份对象副本，却不是 MinIO 原生分布式纠删码集群。

它没有自动解决：

• 主写入点故障后的业务入口切换；
• 同步尚未完成时的数据缺口；
• 删除和覆盖操作的冲突；
• 副本一致性校验；
• 备用节点自动接管；
• 多节点同时故障。

所以更准确的说法是“主写入点加镜像副本方案”，而不是“对象存储集群已经高可用”。

RocketMQ 和异步链路的边界

RocketMQ 用于把部分非核心更新从同步链路中拆出去。异步消息可以降低服务间同步等待，但消息可靠性需要生产、存储、消费、重试和幂等一起成立。

4 月接口验收期间，消息路由仍存在异常。内容服务通过主表降级更新，使相关接口在当前用例中得到预期结果。

这条事实非常适合说明高可用的边界：

业务接口在降级路径下符合预期
≠
消息链已经恢复正常

降级保证了当前核心结果，却可能带来异步事件缺失、重复执行或统计状态来源不一致。消息路由仍需要单独修复和重放验证。

监控的边界

项目包含 Actuator、Prometheus 和 Grafana 相关配置。监控可以帮助观察服务状态、资源和指标，但它本身不会修复故障。

一套真正有用的监控还需要：

• 指标采集目标正确；
• 告警阈值与业务容量匹配；
• 告警能够送达；
• 日志、指标和请求标识能够关联；
• 仪表盘可以区分实例、服务和依赖；
• 有人知道收到告警后怎样处理。

配置文件和仪表盘存在，只能说明具备观测基础，不能证明告警链路和应急流程已经验证。

两组验收结果能说明什么

4 月 18 日有两组不同口径的结果：

• 三批后端接口明细：29、63、23 条，合计 115 条，均符合预期；
• 外部统一入口验收：29 条，均符合预期，其中包含预期拒绝用例。

两组结果可能覆盖相同业务链路，因此不能相加成 144 个独立接口。

它们能够支持的结论是：在当时的验收环境、数据和请求前提下，认证、用户、内容、评论、推荐、后台管理及统一入口的指定用例能够得到预期结果。

它们不能支持：

• 节点故障时请求无损切换；
• MySQL 或 Redis 自动切换结果；
• Nacos 网络分区恢复；
• MinIO 写入点自动迁移；
• RocketMQ 故障后消息不丢不重；
• 高并发和长期运行稳定性；
• 生产级恢复时间与恢复点目标。

我会怎样验证下一层高可用

如果继续验证，测试需要从“接口是否正确”转向“故障发生时系统怎样变化”。

建立持续、可重复的业务流量
    -> 记录正常基线
    -> 注入单一故障
    -> 观察检测、切换和降级
    -> 核对请求失败与业务副作用
    -> 恢复节点
    -> 检查数据追平和旧节点角色

故障场景至少包括：

• 停止一个业务服务实例；
• 停止一个 Nacos 节点；
• Redis 主节点不可用；
• MySQL 主库不可用；
• 对象存储主写入点不可用；
• 消息组件不可用或积压；
• 节点间网络中断；
• 整台宿主机停止。

每次只改变一个主要变量，并记录：

• 故障检测时间；
• 请求失败数量和类型；
• 恢复耗时；
• 是否需要人工操作；
• 是否丢失、重复或错乱数据；
• 恢复后是否存在双主或旧连接；
• 监控和告警是否准确。

没有这类记录，就不应该给出具体恢复时间或数据零丢失承诺。

我对 HAOVP 高可用的当前定义

到 6 月 13 日，我更愿意这样描述 HAOVP：它是一个以学习、实验和工程实践为目标的微服务视频平台，仓库中已经包含服务治理、流量保护、缓存、数据复制、多节点编排、对象副本和监控等高可用方向；指定接口和统一入口链路已经完成一轮功能验收。

它还不是经过完整故障演练和长期负载验证的生产级高可用系统。单机部署仍有宿主机单点，多节点方案中的数据库、缓存和对象存储各有切换与一致性边界，消息链也保留已知异常。

“高可用”在这里不是一个已经完成的标签，而是一组可以逐项设计、实现和验证的能力。把没有验证的部分明确留下，才能知道下一步应该测试什么，也能避免组件数量掩盖真实的单点和数据风险。