7.10.1 高可用架构模式与场景分析

高可用架构的目标是在组件或节点发生故障时保证业务持续可用，并将影响面最小化。对于Web服务，常见风险包括单点故障、突发流量、发布失误、依赖中断与网络抖动，因此需要从流量入口、代理层、应用层、依赖层与运维流程多层面设计与治理。

高可用架构模式总览（原理草图）#

模式与场景要点#

入口层高可用：多入口与DNS轮询、双机热备（Keepalived VRRP）、云负载均衡；避免入口单点，保障入口可切换与自愈。
反向代理层高可用：Nginx多实例集群，配合负载均衡算法与健康检查；支持横向扩展与故障摘除。
应用层高可用：多实例部署、无状态化、配置中心与服务发现；结合灰度发布与快速回滚降低变更风险。
依赖层高可用：数据库与缓存主从/集群、消息队列高可用；通过读写分离、熔断降级、限流保护核心链路。
运维流程高可用：自动化发布、配置统一管理、监控告警闭环；减少人为操作风险并缩短故障恢复时间（MTTR）。

典型场景分析与应对#

单机Nginx承载全部流量：适合低流量测试环境，风险为单点故障与容量瓶颈；改进为双机或多机负载均衡。
业务高峰流量突增：需预估QPS与带宽，增加节点并启用缓存与静态资源分离，防止后端被打穿。
机房或可用区故障：采用跨机房/多可用区部署与全局负载均衡，配合健康检查与自动切换。
发布导致服务异常：灰度发布+健康检查+快速回滚；在入口层基于权重或路径控制流量。
依赖服务抖动：入口层限流，应用层熔断降级，防止级联故障扩大影响面。

示例：双机Keepalived + Nginx高可用入口#

场景目标：两台Nginx组成VIP入口，故障时自动漂移。
节点：
- node1: 192.168.10.11
- node2: 192.168.10.12
- VIP: 192.168.10.100

1) 安装与启动#

# 两台机器均执行
sudo yum -y install nginx keepalived

# 启动并设置开机自启
sudo systemctl enable --now nginx
sudo systemctl enable --now keepalived

2) Nginx后端负载均衡配置（/etc/nginx/conf.d/upstream.conf）#

upstream app_backend {
    least_conn;
    server 192.168.20.21:8080 max_fails=3 fail_timeout=10s;
    server 192.168.20.22:8080 max_fails=3 fail_timeout=10s;
}
server {
    listen 80;
    server_name _;
    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

关键参数解释：
- least_conn：把请求分配给当前连接数最少的后端。
- max_fails/fail_timeout：标记后端失败并暂时摘除。

3) Keepalived配置（主/备）#

node1（MASTER） /etc/keepalived/keepalived.conf

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.10.100/24
    }
    track_script {
        chk_nginx
    }
}

vrrp_script chk_nginx {
    script "pidof nginx"
    interval 2
    weight -20
}

node2（BACKUP） /etc/keepalived/keepalived.conf

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.10.100/24
    }
    track_script {
        chk_nginx
    }
}

vrrp_script chk_nginx {
    script "pidof nginx"
    interval 2
    weight -20
}

重载配置

sudo systemctl restart keepalived

4) 验证与预期效果#

# 查看VIP是否在node1
ip addr show | grep 192.168.10.100

# 模拟node1故障
sudo systemctl stop nginx

# 观察VIP漂移到node2
ip addr show | grep 192.168.10.100

预期：VIP会从node1漂移到node2，客户端访问不中断或短暂抖动。

示例：Nginx入口限流保护依赖#

目标：在依赖抖动时限制单IP请求频率，保护后端。

# /etc/nginx/conf.d/limit.conf
limit_req_zone $binary_remote_addr zone=one:10m rate=5r/s;

server {
    listen 80;
    location / {
        limit_req zone=one burst=10 nodelay;
        proxy_pass http://app_backend;
    }
}

关键参数解释：
- rate=5r/s：每IP每秒最多5个请求。
- burst=10：突发流量允许短暂放行10个请求。

常见排错与诊断命令#

# Nginx语法检查与查看配置
nginx -t
nginx -T | less

# 查看Nginx状态与错误日志
systemctl status nginx
tail -n 200 /var/log/nginx/error.log

# 检查Keepalived状态与日志
systemctl status keepalived
journalctl -u keepalived -n 100 --no-pager

# 查看VRRP组播与VIP归属
ip a | grep -E "eth0|192.168.10.100"

架构选型与指标提示#

架构选型需考虑：业务SLA、流量规模、成本预算、技术复杂度与团队运维能力。高可用不是堆叠组件，而是以可控成本实现稳定性与可恢复性的平衡。
关键指标建议：入口可用性（>99.9%）、故障恢复时间（MTTR）、请求成功率、峰值QPS、发布失败率。

练习#

在两台虚拟机上搭建VIP漂移，模拟主节点Nginx进程退出，记录故障切换时间。
将负载均衡算法从 least_conn 修改为 ip_hash，比较会话保持效果与后端负载分布。
添加 limit_req 后进行压测，观察Nginx错误日志中限流提示并统计被拒绝的请求比例。