高可用架构实操：利用 Cloudflare 实现多服务器 DNS 轮询与全站缓存

单点故障（SPOF）是任何线上服务的噩梦。如果你只有一个服务器，那么它宕机之时，就是你博客离线之日。

为了追求极端的稳定性，我给自己的博客搞了一套 多服务器轮询 (Round Robin) + 边缘缓存 的架构。简单来说，就是把流量分散到四个不同的节点：GitHub Pages、Serv00、CT8 和 zz.ac。无论哪家厂商抽风，用户依然能秒开网页。

核心原理：DNS 轮询与 CNAME 拉平

在常规 DNS 中，一个域名通常指向一个 IP。但 Cloudflare 支持为同一个名称（如 @）添加多条记录。当用户请求域名时，Cloudflare 会在这些记录之间进行随机轮询。

得益于 Cloudflare 的 CNAME Flattening (CNAME 拉平) 技术，我们可以把 A 记录（IP）和 CNAME 记录（域名）混在一起绑定到根域名上，无需担心协议冲突。

第一步：构建 DNS 轮询矩阵

登录 Cloudflare -> DNS -> Records，依次添加以下记录。关键点：所有记录必须开启「代理状态 (Proxied)」，即点亮黄色小云朵。

1. GitHub Pages (CNAME):
   • 名称: @ -> 目标: username.github.io
2. Serv00 (A):
   • 名称: @ -> IPv4: [Serv00_IP]
3. CT8 (A):
   • 名称: @ -> IPv4: [CT8_IP]
4. zz.ac (A/CNAME):
   • 名称: @ -> 地址: [zz.ac_Address]

此时，你的 DNS 列表中会出现四条名称同为 @ 的记录。这意味着流量将被分发到这四个不同的物理节点。

第二步：开启「全站强力缓存」 (核心环节)

默认情况下，Cloudflare 只缓存图片、CSS 等静态资源，而 HTML 页面是不缓存的。如果轮询到了一个宕机的服务器，用户依然会看到报错。

我们要强制 Cloudflare 将整个静态站 100% 缓存到全球边缘节点：

1. 进入 Rules (规则) -> Page Rules (页面规则) -> Create Page Rule。
2. URL 匹配: *yourdomain.com/* (匹配所有路径)。
3. 设置选项:
   • Cache Level (缓存级别) -> Cache Everything (缓存所有内容)。
   • Edge Cache TTL (边缘缓存 TTL) -> 设置为 1天 或 7天。

这样一来，HTML 页面也被缓存到了边缘节点。即使后端四台服务器全部宕机，只要缓存没过期，用户依然能看到网页内容。

第三步：开启 Always Online™ (最后一道防线)

在 Caching (缓存) -> Configuration (配置) 中，将 Always Online™ 开关开启。当所有源站都不可用时，Cloudflare 将利用历史缓存数据继续维持网站在线。

⚠️ Bosh 的避坑指南 (Critical Pitfalls)

1. SSL/TLS 证书噩梦： 由于四个主机的证书配置各异（有的支持，有的不支持自定义域名证书），建议在 SSL/TLS 中将加密模式设为 Flexible (灵活)。
   • 原理：用户 \(\leftrightarrow\) Cloudflare (加密) -> 服务器 (不加密)。
   • 目的：完美避开 ERR_SSL_VERSION_OR_CIPHER_MISMATCH 错误。
2. 内容更新延迟 (Cache Lag)： 开启了「缓存所有内容」后，执行 hexo d 推送更新后，用户可能看不到最新内容。
   • 对策：每次更新完博客，必须前往 Caching -> Configuration -> 点击 Purge Everything (清除所有内容)，强制全球节点刷新。

架构总结

通过这次配置，我的博客实现了： 多厂商分发 -> DNS 随机轮询 -> 边缘 HTML 缓存 -> 灵活 SSL 兼容 -> 自动故障切换。

这套方案让博客的可用性从 99% 提升到了 99.99%。只要互联网还没崩溃，我的博客就在线。 💻⚡️