ICP备案

网站高可用架构怎么做？负载均衡、多节点与故障转移全解析

作者：备案源头内容团队内容审核：备案源头内容团队更新于 2026年7月6日

单台服务器承载的网站，只要这台机器宕机、升级重启或被打满，网站就整体不可用。当业务对可用性有要求时，就需要从"单点"走向"高可用（HA）架构"——通过冗余和自动故障转移，让任何单一组件失效都不至于让整站瘫痪。本文系统讲清高可用的核心组件与落地要点。

先理解：可用性和单点故障

可用性常用"几个 9"衡量：99.9%（全年停机约 8.8 小时）、99.99%（约 53 分钟）。要提升可用性，核心是消除单点故障（SPOF）——任何一个坏了就导致全站不可用的环节，都要做冗余。典型单点包括：唯一的 Web 服务器、唯一的数据库、唯一的负载均衡入口、甚至唯一的机房。

负载均衡：流量入口的冗余与分发

负载均衡器（LB）把用户请求分发到多台后端服务器，是高可用的核心。既能分摊压力，也能在某台后端故障时把它摘除。

常见分发算法	说明	适用
轮询（round robin）	依次分发	后端性能相近
加权轮询	按权重分发	后端配置不均
最少连接	发给当前连接最少的	长连接、请求耗时不均
IP 哈希	按客户端 IP 固定到某后端	需要会话粘性

常见实现：Nginx/HAProxy（软件 LB）、云厂商的 SLB/CLB/ELB（托管 LB）。用 Nginx 做负载均衡的最小配置：

upstream app_backend {
    least_conn;
    server 10.0.0.11:3000 weight=1 max_fails=3 fail_timeout=15s;
    server 10.0.0.12:3000 weight=1 max_fails=3 fail_timeout=15s;
}
server {
    listen 443 ssl;
    server_name example.com;
    location / {
        proxy_pass http://app_backend;
        proxy_next_upstream error timeout http_502 http_503;
    }
}

健康检查：自动摘除故障节点

高可用的关键不是"有多台"，而是"坏了能自动发现并摘除"。健康检查分两类：

被动健康检查：如上面 Nginx 的 max_fails/fail_timeout，请求失败到阈值就临时摘除该节点。
主动健康检查：LB 周期性访问后端的健康检查接口（如 /health），不通就摘除、恢复了再加回。云 LB 和 HAProxy、OpenResty 都支持。

应用应提供一个轻量的 /health 端点，只检查关键依赖（数据库、缓存连通性），返回 200/非 200，供 LB 判断。

会话与状态：别让多节点互相打架

多台后端并存时，"状态"是最大的坑。用户第一次请求落在 A 节点、下一次落在 B 节点，如果会话（登录态）只存在 A 的内存里，用户就"莫名其妙掉登录"。解决思路：

会话外置：把 session 存到 Redis 等共享存储，所有节点读同一份（推荐）。
会话粘性：LB 用 IP 哈希/cookie 把同一用户固定到同一节点（简单但节点故障时该用户会话丢失）。
无状态化：用 JWT 等把状态放客户端，后端不存会话。

上传的文件同理，不要存本地磁盘，应放对象存储或共享存储，否则不同节点看到的文件不一致。

数据库高可用：主从与读写分离

Web 层无状态化后，数据库往往成为新的单点。常见方案：

主从复制：一主多从，主库写、从库读（读写分离分摊读压力），主库故障时把从库提升为主。
自动故障转移：借助 MHA、Orchestrator 或云数据库的高可用版本，主库挂了自动切换，减少人工介入。
备份兜底：高可用不等于备份，误删/逻辑错误会同步到从库，仍需独立的数据备份与恢复。

故障转移与容灾：从多节点到多机房

同机房多节点：防单机故障，是最基础的高可用。
多可用区：把节点分布在同城不同可用区，防单个机房级故障。
异地容灾：核心业务再做异地备份/灾备，防区域性灾难。容灾要定期演练切换，否则真出事时未必切得动。

备案与高可用架构的注意点

多节点、换 IP、加负载均衡都可能改变实际接入的服务器与 IP，需注意备案接入信息与实际一致：

增减服务器、更换 IP 时，核对是否需要更新备案接入，见更换服务器或 IP 要不要重新备案。
多台服务器分属不同接入商时，涉及多个接入备案，接入信息都要如实登记。
用境内云 LB/CDN 时，域名需已完成备案；境外节点的合规边界见香港/海外服务器免备案是真的吗。

别过度设计

高可用有成本。展示型小站用"一台服务器 + 好备份 + 监控"往往就够；只有当停机的业务损失明显高于冗余成本时，才逐步引入负载均衡、多节点、数据库主从。先用运维监控看清真实的故障率和瓶颈，再按需加冗余，比一上来堆架构更划算。

常见问题

Q：加了负载均衡就高可用了吗？
不完全。LB 分发流量并摘除故障后端，但如果 LB 自身、数据库、机房是单点，照样会整站不可用。高可用要逐个消除单点，并确保故障能自动转移。

Q：多节点后用户老掉登录怎么办？
把会话外置到 Redis 等共享存储，或用 LB 会话粘性、JWT 无状态方案，避免会话只存在单个节点内存里。

Q：小网站有必要做高可用吗？
多数小站不必。先做好备份和监控，单机足够；等停机损失明显超过冗余成本，再逐步引入负载均衡与多节点。

资料来源

Nginx 官方文档 - HTTP 负载均衡：https://nginx.org/en/docs/http/load_balancing.html
HAProxy 官方文档：https://docs.haproxy.org/
各云服务商负载均衡与高可用数据库官方文档

以上为通用架构思路，具体组件与配置以你使用的服务器、负载均衡与数据库产品文档为准。

联系客服