多地域高可用架构总收口：一张总架构图 + 一套运维 Runbook 完整梳理

本文是我自己整理多地域架构的收尾笔记，纯粹是个人学习与运维实践记录，不涉及任何商业推广，文中不会出现任何购买链接或联系方式。所有配置和命令，请先在你自己的测试环境里验证过再上生产。

写在前面

前前后后折腾了挺长时间，这套多地域的架构算是搭得差不多了：DNS 做了就近接入，入口层做了双机热备，Web 层做了负载均衡，数据层做了跨地域同步，最后还专门做了一轮故障演练把各个环节打了一遍。

但真正让这套东西"能用"的，不是某个组件配得多漂亮，而是最后这一步——把散落各处的配置和零散的经验，收拢成一张图、一本手册。

为什么这么说？因为我踩过一个很典型的坑：有一次半夜入口切换异常，我爬起来处理，结果发现光是"主入口机器是哪台、VIP 是多少、故障时该先看哪个日志"，我就翻了好几个笔记文件才凑齐。那一刻我意识到——架构搭得再好，如果出事了找不到北，等于白搭。

所以这一篇不做新的技术点，专门做两件事：

1. 一张总架构图：把前面所有组件放回它们该在的位置，看清数据怎么流、故障谁兜底；
2. 一套 Runbook：把日常巡检、变更流程、常见故障的处置步骤，全部写成可以照着做的清单。

这篇算是整个系列的收口。如果你是跟着前面几篇一路搭过来的，这一篇可以直接拿去当你的架构文档模板；如果你还没搭，也可以先看看"一个完整的多地域架构到底长什么样"，心里有个全局。

一、我的实验环境

先说明这套架构跑在什么环境上，避免脱离实际：

这里补充一句：香港那几台是我日常一直在用的 LuckVM 机器，断断续续跑了快一年，稳定性和 IO 都挺省心，这套总收口就是在这批机器上整理出来的；换成别家的机器，架构和手册内容都通用，不影响技术本身。

再次提醒：下面所有涉及生产操作的流程，我都是先在测试环境跑通、确认没问题之后才对照着做，不要拿生产环境当试验田。

二、整套架构长什么样

先把全局图放出来。这张图我画了很多版，最终这一版是我自己看着最不容易迷路的：

┌─────────────────────┐ │ 用户 / 客户端 │ └──────────┬──────────┘ │ 1. 解析域名 ▼ ┌───────────────────────────────────┐ │ 权威 DNS（BIND，主从 2 台） │ │ 按来源地区返回就近的入口 IP │ ← GeoDNS 就近接入 │ 健康检查失败则摘除对应记录 │ └───────────────────┬───────────────┘ │ 2. 返回最近入口 ▼ ┌────────────────────────────────────────────┐ │ 入口层：Nginx + Keepalived（VIP） │ │ 主备两台，VIP 漂移，服务级探活 │ ← 入口高可用 └──────────────────────┬─────────────────────┘ │ 3. 转发到 Web 层 ▼ ┌────────────────────────────────────────────┐ │ Web 层：Nginx 负载均衡（2 台） │ │ least_conn / 会话一致性 / 故障转移 │ ← 横向扩容 └───────┬───────────────────────┬────────────┘ │ 4. 读写请求 │ 5. 推理请求 ▼ ▼ ┌──────────────────────────┐ ┌──────────────────────┐ │ 数据层：MySQL 主从 + │ │ GPU 推理服务 │ │ Redis 主从（跨地域复制） │ │ （vLLM / Ollama） │ └──────────────────────────┘ └──────────────────────┘ │ 6. 静态/媒体文件 ▼ ┌──────────────────────────┐ │ MinIO 对象存储（站点复制） │ └──────────────────────────┘ 贯穿所有层：Prometheus + Grafana + Alertmanager（监控与告警）

一句话概括这套架构的设计哲学：

每一层只解决一件事，出了事由下一层兜底；任何一层都不要成为"唯一的那一个"。

分层职责表

这张表是我自己在脑子里过故障流程时用的——逐行问自己"这层挂了会怎样"，答不上来就是还没想清楚。

三、一次请求的完整旅程

架构图是静态的，更直观的是跟着一次请求走一遍。假设一个国内用户访问站点首页：

关键认知：一次请求要穿过 8 个环节，每个环节都有独立的失效模式。所以"高可用"从来不是某一个组件的事，而是整条链路没有单一断点。这也是为什么前面每一层我都单独做了一次，而不是指望某一个大组件全包。

四、每个组件解决什么问题

收口的时候我把组件和“它到底解决什么问题”一一对应了一遍，避免出现“配了但不知道为什么配”的情况：

这张表建议你也对着自己的架构填一遍，凡是“不配会怎样”这一栏填不出来的，多半是冗余配置。

五、域名与寻址规划

这套架构涉及的域名不少，如果命名乱，运维时会非常痛苦。我定了一套统一规则：

• 所有节点之间互相引用，一律用域名，不写裸 IP（换机器时只改 DNS，不动配置）；
• 对外入口用统一的业务域名，各层用子域名区分；
• 内部服务用内网域名 + 内网解析，不暴露到公网。

这里说明一下寻址怎么落地：example.com指的是你自己的域名，像app.qq.com、app.baidu.com、app.luckvm.com这种二级或三级域名都行，通常在域名管理后台加几条 A 记录就能解析过来，不用额外申请什么资质。

命名规范表：

好习惯是：把这张表写进架构文档，任何人接手都能一眼看懂谁是谁。

六、配置即代码：把所有配置纳入版本管理

这是我这次收口最大的收获——故障演练那次，我为了找“某台机器上改过的某个参数”翻了两个小时。后来我把所有配置都纳入了一个 Git 仓库：

infra/ ├── dns/ # named.conf、zone 文件 ├── entrance/ # keepalived.conf、入口 nginx.conf ├── web/ # 各节点 nginx.conf、应用配置模板 ├── data/ # my.cnf、redis.conf、复制配置 ├── storage/ # minio 配置 ├── monitor/ # prometheus.yml、告警规则 ├── scripts/ # 巡检、备份、切换脚本 └── runbook/ # 本手册（对，手册也进版本库）

好处有三个：

1. 可追溯：任何改动都有记录，能回答“这个参数什么时候改的、为什么改”；
2. 可回滚：改坏了直接git revert；
3. 可复制：搭新节点时直接拉配置，不用手抄。

配置下发就用最朴素的rsync+ 重启命令封装成脚本，不搞复杂工具：

#!/usr/bin/env bash# sync_conf.sh —— 把本地仓库的配置推到目标机器并重载set-euopipefailTARGET_HOST="$1"TARGET_PATH="/opt/infra"rsync-avz--delete./"${TARGET_HOST}:${TARGET_PATH}/"ssh"${TARGET_HOST}"bash-s<<'REMOTE' set -euo pipefail # 校验后再重载，避免把坏配置推上去 nginx -t && systemctl reload nginx named-checkconf && rndc reload REMOTEecho"[OK]${TARGET_HOST}配置已同步并重载"

注意：nginx -t/named-checkconf这类校验一定要放在重载前面，永远不要让一个没校验过的配置直接生效。

七、运维 SOP：日常巡检清单

日常巡检是“小事化无”的关键。我把巡检分成三档：

每日巡检（5 分钟）

#!/usr/bin/env bash# daily_check.sh —— 每日一次，输出异常项set-uopipefailecho"===== 1. 磁盘 ====="df-h|awk'NR==1 || $5+0 >= 80 {print}'echo"===== 2. 内存 ====="free-m|awk'NR==1 || NR==2'echo"===== 3. 负载 ====="uptimeecho"===== 4. 关键服务 ====="forsvcinnginx keepalived mysql redis-server named;dosystemctl is-active--quiet"$svc"\&&echo"$svc: OK"\||echo"$svc: FAILED"doneecho"===== 5. MySQL 复制延迟 ====="mysql-N-e"SHOW REPLICA STATUS\G"2>/dev/null\|grep-E"Seconds_Behind_Source|Last_Error"||echo" (非数据库节点)"echo"===== 6. Redis 主从偏移 ====="redis-cli info replication2>/dev/null|grep-E"role|offset"||echo" (非 Redis 节点)"

每周巡检

• 检查告警历史，看有没有“响了又自动好了”的抖动；
• 检查备份是否成功产出（没验证过的备份等于没有备份）；
• 检查证书有效期（剩余 < 30 天就续）；
• 检查 VIP 当前在哪台（确认没漂到预期外的机器）。

每月巡检

• 做一次数据恢复演练（从备份恢复到一个临时实例，验证可用）；
• 更新系统安全补丁（先在备机做）；
• 复盘本月告警，优化阈值。

八、变更流程：怎么改才不出事

我给自己定了六条铁律，每次变更前对照一遍：

第 6 条尤其重要。我见过太多次"进程起来了、端口也在听、但业务就是不通"的情况。所以每次变更后至少要跑一遍冒烟测试：

# 冒烟测试：入口 → Web → 数据 全链路curl-sS-o/dev/null-w"入口 HTTP: %{http_code} 耗时: %{time_total}s\n"https://www.example.com/curl-sS-o/dev/null-w"健康检查: %{http_code}\n"https://www.example.com/healthz# 确认应用真的读到了数据库（不是缓存兜底）curl-sShttps://www.example.com/api/ping

九、告警响应 Runbook

这一章是整本手册的核心。我把几类常见故障整理成"现象 → 排查 → 处置 → 验证"四步，出事时照着做就行，不用临场发挥。

场景 1：站点访问超时

# 一键定位入口问题ipa|grep-winet|grep-v127.0.0.1# VIP 在不在这台systemctl is-active keepalived nginx journalctl-ukeepalived--since"10 min ago"|tail-30

场景 2：部分用户访问慢（不是全挂）

# 从不同地区验证解析结果（ECS 可模拟来源）dig+short www.example.com @ns1.example.comdig+subnet=203.0.113.0/24 +short www.example.com @ns1.example.com# 模拟美西来源

场景 3：数据库主库故障

# 提升从库（谨慎，先确认旧主真的不可用，避免双主脑裂）mysql-e"STOP REPLICA; RESET REPLICA ALL; SET GLOBAL read_only=OFF;"mysql-e"SHOW VARIABLES LIKE 'read_only';"

这里必须强调：数据库切换前，一定先确认旧主已经彻底不可用，否则会变成双主写入，数据就乱了。宁可多等一分钟，不要抢那一秒。

场景 4：磁盘写满

df-hdu-sh/var/*2>/dev/null|sort-rh|head-10journalctl --vacuum-size=500Mfind/var/log-name"*.log"-size+200M-exectruncate-s0{}\;

场景 5：告警“响了又自己好”

# Prometheus 告警加持续时间，过滤瞬时抖动-alert:HighCPUexpr:100-(avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)>85for:3m# 连续 3 分钟才触发labels:severity:warning

十、故障场景速查矩阵

把上面的场景汇总成一张速查表，贴在文档最显眼的位置：

这张表的价值在于：出事的时候，你能一秒判断"这事要不要我动手"。

十一、灾备与数据恢复

高可用解决“局部故障不中断”，灾备解决“整体被端掉还能恢复”。这两件事不能互相替代。

备份策略（3-2-1 原则）

• 3 份数据：主库 + 本地备份 + 异地备份；
• 2 种介质：磁盘 + 对象存储；
• 1 份异地：跨地域。

#!/usr/bin/env bash# backup_all.sh —— 数据库 + 站点文件 + 配置，打包异地set-euopipefailSTAMP=$(date+%F_%H%M)DEST="/backup/${STAMP}"mkdir-p"$DEST"# 1. 数据库mysqldump --single-transaction--routines--triggers--all-databases\|gzip>"${DEST}/db.sql.gz"# 2. 站点文件tar-czf"${DEST}/site.tar.gz"-C/var/www app# 3. 配置仓库tar-czf"${DEST}/infra.tar.gz"-C/opt infra# 4. 推到异地对象存储（rclone 已配置远端）rclone copy"$DEST"remote:backup/$(hostname)/# 5. 清理本地 7 天前的备份find/backup-maxdepth1-typed-mtime+7-execrm-rf{}\;echo"[OK] 备份完成：${DEST}"

恢复演练（每月必做）

备份没验证过等于没有。每月抽一次，把备份恢复到一个临时实例，确认能起来：

# 恢复到临时库验证gunzip-c/backup/2026-10-01_0300/db.sql.gz|mysql-htemp-db mysql-htemp-db-e"SHOW DATABASES;"|head

十二、成本与资源盘点

收口时顺手把资源盘了一遍，也提醒自己“每一台机器是不是都必要”：

一个体会：这套架构跑在清一色的小配置机器上（最大也就 2 核 4G），并没有想象中那么“重”。高可用不是靠堆配置，是靠消除单点——这一点我用一年多的实际运行验证过，2 核 2G 的机器跑负载均衡、跑热备、跑监控，CPU 长期是空闲的，真正的瓶颈永远在链路上、在数据库上，而不是这些小机器本身。

把上面的资源盘点画成一张图，一眼就能看清各层机器数量与配置分布：

从图里能直观看到：真正吃配置的只有数据层（2核4G），其余各层 2核2G 就够用。这也印证了前面那句话——高可用不是靠堆配置，是靠消除单点。

十三、十个踩坑

1. 配置散落各处：没有版本管理，改过什么都不记得，出事就抓瞎。→ 全部纳入 Git。
2. 只配不校验：直接 reload 坏配置，服务起不来。→ 重载前必-t/-checkconf。
3. 手册没有版本：改架构不改手册，手册变废纸。→ 手册和配置一起入库。
4. 巡检只看进程不验业务：进程在、业务不通。→ 巡检带冒烟测试。
5. 备份不验证：真出事发现备份是空的。→ 每月恢复演练。
6. 告警阈值过紧：天天响，最后没人看。→ 加for持续时间。
7. 数据库切换不确认旧主状态：双主写入，数据污染。→ 切换前必须确认旧主彻底不可用。
8. VIP 漂移后没清理陈旧 ARP：切换后短暂不通。→ 入口层配好 ARP 抑制。
9. 健康检查脚本有 bug 却没人测：演练才发现探活永远返回"健康"。→ 定期故意停服务验证。
10. 没有止损预案：演练/变更出问题只能干等。→ 每步都配一键回退。

十四、总结

这套多地域架构从“想到什么配什么”，到最后收拢成一张图和一本手册，我自己最有价值的几个体会：

• 架构图要能被“读着走一遍”：看图就能复述一次请求的旅程，才说明你真的懂了；
• 手册要能照着做：Runbook 不是给领导看的文档，是自己半夜爬起来能用的东西；
• 每层都别当“唯一”：单点在哪里，故障就从哪里来；
• 高可用靠练，不靠配：配置只代表意图，演练才验证结果；
• 简单的一致性策略最省心：把“写集中在一处”这一个决定落下，后面所有冲突处理都省了。

写到这里，整个多地域系列基本收口了：就近接入解决“快”，入口热备解决“活”，负载均衡解决“扛”，数据同步解决“一致”，故障演练解决“信”，总收口与 Runbook 解决“稳”。六件事合起来，才算一套能真正交付、能被人接手、能在半夜救命的架构。

十五、后续计划

1. 把 Runbook 做成在线文档：方便手机上随时翻，出事不用找电脑；
2. 巡检全自动化：daily_check.sh挂到 cron，异常自动推告警，人只看异常；
3. 变更纳入 CI：配置改动走流水线，自动校验 + 灰度 + 冒烟，不合格不允许合并；
4. 混沌演练常态化：把安全场景做成周任务，趋势化观察稳定性；
5. 梳理成本与容量趋势：按季度看资源增长，提前规划扩容。

附录：命令速查

# ---------- 入口层 ----------ipa|grep-winet# 看 VIP 在不在这台systemctl status keepalived nginx journalctl-ukeepalived--since"10 min ago"|tail-30# ---------- 配置校验与重载 ----------nginx-t&&systemctl reload nginx named-checkconf&&rndc reload named-checkzone app.example.com /etc/bind/dynamic/app.example.com.zone# ---------- DNS 验证 ----------dig+short www.example.com @ns1.example.comdig+subnet=203.0.113.0/24 +short www.example.com @ns1.example.com# ---------- 数据层 ----------mysql-e"SHOW REPLICA STATUS\G"|grep-E"Seconds_Behind_Source|Last_Error"redis-cli info replication|grep-E"role|offset|link"# ---------- 磁盘与日志 ----------df-hdu-sh/var/*2>/dev/null|sort-rh|head-10journalctl --vacuum-size=500Mfind/var/log-name"*.log"-size+200M-exectruncate-s0{}\;# ---------- 备份与恢复 ----------mysqldump --single-transaction --all-databases|gzip>db.sql.gz gunzip-cdb.sql.gz|mysql-htemp-db rclone copy /backup/ remote:backup/$(hostname)/# ---------- 冒烟测试 ----------curl-sS-o/dev/null-w"HTTP: %{http_code} 耗时: %{time_total}s\n"https://www.example.com/curl-sShttps://www.example.com/healthz

以上就是我这次多地域架构总收口与运维手册的完整整理。搭架构是一次性的事，把架构整理成一张图、一套能照着做的手册，才是让它长期"活着"的事。如果你也在维护多机环境，欢迎评论区交流你的收口经验，看到都会回。