事情发生在今年3月，一次突如其来的物理服务器宕机，导致我香港数据中心托管的主业务网站出现访问中断，前后持续了将近17分钟。虽然在技术层面上我们很快通过热备服务器接管了服务，但客服那边却收到了大量投诉，SEO排名也在之后两天内出现了下滑。这一次“代价高昂”的故障让我彻底意识到，仅靠“备用机+人工切换”已不足以支撑一个需要全年无休运行的服务系统。于是，我开始着手构建一个真正具备自动故障转移（failover）与多点负载均衡（load balancing）能力的高可用架构。
以下是我在香港服务器上实操落地高可用系统的完整过程与技术方案，涵盖从网络拓扑设计、Keepalived配置到Nginx负载均衡与MySQL主主复制的实际部署细节。
一、架构设计思路：从单点故障到多活架构
1.1 核心目标
- 实现7×24小时无人工介入的服务连续性
- 支持故障自动检测与主备切换
- 动态流量均衡，提升并发响应能力
1.2 网络与节点分布
我选用了 A5数据香港T2型双路高频服务器 作为基础硬件，配置如下：
| 项目 | 参数说明 |
|---|---|
| CPU | 双路 Intel Xeon Gold 6330 |
| 内存 | 256GB DDR4 ECC |
| 存储 | 2TB NVMe SSD + RAID1 |
| 网络 | 1Gbps 独享带宽 |
| 系统 | Debian 12 / AlmaLinux 9 |
采用3台主机构建如下拓扑：
- 节点 A（主业务节点）
- 节点 B（热备节点 + 数据复制）
- 节点 C（负载均衡器 + Keepalived VRRP master）
二、负载均衡层部署：Nginx + Keepalived 高可用漂移IP
2.1 Keepalived 虚拟IP配置（VRRP）
# /etc/keepalived/keepalived.conf（在节点C上）
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 123456
}
virtual_ipaddress {
192.168.88.100 # 虚拟IP
}
}
在节点B上，配置为 state BACKUP，并将 priority 设置为80。这样，当节点C故障时，VIP将自动漂移至节点B，继续提供入口服务。
2.2 Nginx 四层TCP负载均衡配置（前端入口）
# /etc/nginx/nginx.conf
stream {
upstream backend_mysql {
server 192.168.88.10:3306 max_fails=3 fail_timeout=10s;
server 192.168.88.11:3306 max_fails=3 fail_timeout=10s;
}
server {
listen 3307;
proxy_pass backend_mysql;
}
}
同时我还部署了 HTTP 层负载均衡入口，用于均衡前端Nginx服务，支持 sticky session。
三、应用服务层配置：高可用与健康探测
3.1 后端应用服务配置（Java / Node.js）
每台业务节点部署相同的容器化应用，配合 Nginx 的 upstream 模块按轮询方式调度请求：
upstream app_cluster {
server 127.0.0.1:8080;
server 192.168.88.11:8080;
keepalive 32;
}
Nginx 使用 proxy_next_upstream 与 fail_timeout 参数增强故障识别：
proxy_next_upstream error timeout http_502 http_503 http_504;
3.2 自建健康检查脚本（用于Keepalived）
我增加了自定义健康检查脚本 /opt/check_nginx.sh，并结合 Keepalived 的 vrrp_script 模块定期调用：
#!/bin/bash
curl -s --max-time 2 http://127.0.0.1:80/healthz || exit 1
四、数据库层：MySQL 双主同步+自动切换
4.1 配置主主复制（双向复制）
-- 节点A
CHANGE MASTER TO MASTER_HOST='192.168.88.11', MASTER_USER='repl', MASTER_PASSWORD='secret', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=4;
-- 节点B
CHANGE MASTER TO MASTER_HOST='192.168.88.10', MASTER_USER='repl', MASTER_PASSWORD='secret', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=4;
使用 GTID 模式避免冲突：
gtid_mode = ON
enforce-gtid-consistency = true
log_slave_updates = true
4.2 MHA 或 Orchestrator 实现自动故障切换（可选）
我测试过 Orchestrator 来监控复制拓扑并自动触发故障转移，同时结合 Consul 或 DNS 记录更新应用端访问路径。
五、监控与报警机制：Prometheus + Alertmanager
部署 Prometheus 对各节点进行健康探测，配置如下：
- job_name: 'keepalived'
static_configs:
- targets: ['192.168.88.10:9100', '192.168.88.11:9100']
Alertmanager 配置了针对节点失联、服务端口无响应、VIP漂移等情况的报警推送到 Telegram。
六、实战总结与上线后反馈
完成该高可用架构上线后，我们的业务服务在过去4个月内实现了：
- 0次人为干预的服务中断
- 平均切换时间 < 5s
- 系统可用性达到 99.997%
我还通过故障注入测试（如强制关闭主节点网络）验证了整套 failover 能力，并将这一机制推广到多个香港及新加坡节点集群。
没有“万无一失”，但我们可以尽量靠近
构建高可用架构不是一次性的项目，而是一套持续优化的工程体系。它需要硬件冗余、软件层协同、健康监控与自动化调度能力共同配合。对于业务部署在香港、需要低延迟、高可用的系统来说，这种基于VIP + Nginx + 双主复制的方式，是一套成熟可靠的参考路径。
