1. 评估与准备（选型与账号准备）
a. 选择供应商与机房：建议选台湾本地或邻近亚太机房（如台北、台中、高雄）以降低延迟；确认是否支持弹性IP/浮动IP、云负载均衡与VPC。
b. 规格规划：根据QPS与并发估算CPU、内存、带宽、IOPS，至少两台应用节点+两台LB（主动/被动或双活）+两台DB（主从或Galera）。
c. 账号与网络准备：在控制台开通VPC、子网、路由表、安全组/防火墙规则，保存API凭证便于自动化。
2. 网络与子网设计（子网划分与ACL）
a. 子网规划：将管理面、应用面、数据库面分别放到不同子网（eg. 10.0.1.0/24 管理，10.0.2.0/24 应用，10.0.3.0/24 DB）。
b. 安全组规则：只允许LB到应用的80/443，应用到DB的3306/5432，管理IP白名单SSH(22)。配置NAT或公网跳板机做维护访问。
c. 弹性IP与公网出口：为负载均衡器或浮动IP分配弹性公网IP，确保故障切换时公网IP能被快速切换或DNS TTL足够短。
3. 部署基础镜像与实例（自动化与配置）
a. 制作基础镜像：在一台实例上安装常用组件（nginx/haproxy、监控agent、日志收集agent、时区/ntp），打包为镜像。
b. 使用脚本或Terraform/Ansible批量启动应用实例并注入公钥、环境变量。示例（Ubuntu）安装HAProxy：sudo apt update && sudo apt install -y haproxy。
c. 时间同步与安全：配置chrony/ntp，关闭不必要端口，启用SELinux或AppArmor（视发行版）。
4. 负载均衡器设计（云LB与软件LB选型）
a. 云厂商LB优先：若云厂商提供L4/L7负载均衡（包括健康检查与自动扩缩），优先使用以降低运维复杂度。
b. 软件LB方案：若自建，常用HAProxy做L4/L7，Nginx做HTTP反向代理，配合keepalived实现浮动IP高可用。
c. 会话与SSL：为避免粘滞会话问题，推荐使用Redis/Session共享（或JWT无状态）。SSL建议在LB端终止（减轻后端负担）并使用Certbot自动续签。
5. keepalived + VRRP 实现浮动IP（主动-被动切换）
a. 安装：Ubuntu示例 sudo apt install -y keepalived；CentOS sudo yum install -y keepalived。
b. keepalived.conf 示例（两节点）：
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication { auth_type PASS; auth_pass 1111; }
virtual_ipaddress { 203.0.113.10 }
}
将BACKUP节点priority设为90，并确保interface名称正确。
c. 健康脚本：配置notify_script或track_script，若后端服务异常则降低priority触发漂移。示例track_script指向检查haproxy的脚本。
6. HAProxy/Nginx 配置与健康检查示例
a. HAProxy最小配置（/etc/haproxy/haproxy.cfg）：
global
daemon
defaults
mode http
timeout connect 5s
frontend http-in
bind *:80
default_backend app_pool
backend app_pool
balance roundrobin
option httpchk GET /health
server app1 10.0.2.11:80 check
server app2 10.0.2.12:80 check
b. Nginx upstream 示例：使用proxy_pass并设置health_check（需要nginx-plus或第三方模块）建议用云LB或HAProxy实现健康检查。
c. 测试：在LB节点上运行 curl -I http://localhost/health 确认返回200；通过临时停止后端服务（systemctl stop nginx）验证LB移除不健康节点。
7. 数据库高可用与复制（主从/集群与故障切换）
a. 关系型数据库：推荐使用主从+semi-sync或Galera（MySQL/MariaDB）实现读写分离与自动故障切换，或采用云托管DB（有自动故障切换）。
b. 配置要点：同步延迟监控、心跳检测、自动提升脚本（利用Orchestrator或MHA），并保持binlog与GTID配置一致以便于切换。
c. 备份与恢复：每天全量备份+增量binlog备份，测试恢复流程（restore到另一台实例并验证应用连接）。
8. DNS故障切换与低TTL策略
a. 短TTL：将DNS记录TTL设置为30-60秒（根据DNS解析器实际行为），便于发生切换时快速生效。
b. 主动故障转移：结合监控平台（如Prometheus+Alertmanager）在检测到区域中断时触发API更新DNS或调用云厂商的LB切换API。
c. 使用全局流量管理：若需跨区域云容灾，可使用Cloudflare、AWS Route53等支持健康探测的流量管理服务做流量切换。
9. 监控、日志与演练（不可或缺的SOP）
a. 监控项：CPU/内存/网络/磁盘/连接数、LB后端健康、DB复制延迟、应用接口RT和错误率。
b. 日志集中化：使用ELK/EFK或SaaS日志平台聚合日志并做告警。
c. 灾备演练：定期演练切换（停掉主LB、主DB、部分可用区），检验Runbook（包括回滚步骤）并记录时间点与问题。
10. 常见操作命令与测试用例（快速上手清单）
a. 启停服务：sudo systemctl start|stop|status haproxy keepalived nginx mysql。
b. 健康检查curl示例：curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" http://10.0.2.11/health。
c. 模拟切换：在主LB上 sudo systemctl stop haproxy && systemctl stop keepalived，检查浮动IP是否漂移到备节点（ip addr 查看）。
11. 问：在台湾云主机上如何实现0-1分钟的故障切换？
答：要接近0-1分钟，需结合低TTL DNS（30s）、浮动公网IP（keepalived VRRP）或云厂商的弹性IP快速切换、以及健康检测自动漂移。优先将公网流量接在可快速漂移的LB/浮动IP上，保证后端实例在故障时立即被剔除并切走流量；同时用自动化脚本更新DNS备用策略以处理极端跨区域故障。
12. 问：如果我使用云厂商自带负载均衡和DB托管，还需要部署keepalived吗？
答：若云厂商的LB和托管数据库具备SLA且提供自动故障切换，通常不需要自建keepalived。但建议仍在应用层设计无状态或共享会话、并做好跨可用区冗余与备份，以应对云厂商层面的区域性事件。
13. 问：如何验证我的故障切换流程真正可用？
答：通过预设的演练清单（停主LB、断主DB网络、模拟磁盘故障等），执行并记录每一步时间点、流量变更、错误率和回滚时间。使用真实流量回放或分阶段流量切换（canary）验证无缝切换，演练后修正Runbook并重复测试直至满足RTO/RPO目标。
来源：高可用架构服务器租用台湾云主机负载均衡与故障切换设计要点
