为什么我们会过度依赖 Cloudflare?#

1. 免费且强大 - Cloudflare 免费套餐提供了极其丰富的功能
2. 性能优异 - 全球 CDN 网络,访问速度快
3. 安全防护 - DDoS 防护、WAF 等安全功能
4. 简单易用 - 配置简单,上手门槛低
5. 生态完善 - Workers、Pages、R2 等产品线丰富

正是这些优势,让我们忽视了单点依赖的风险。

单点故障的可怕之处#

当 Cloudflare 出现故障时:

• ✗ 网站完全无法访问
• ✗ 备份方案无法及时生效
• ✗ 用户流失,品牌形象受损
• ✗ 收入损失(对于商业网站)
• ✗ dashboard不可访问(无法修改DNS解析)
• ✗ 被动等待官方修复

1. 不要完全依赖Cloudflare#

Cloudflare 不仅是全球最大的 CDN 和安全服务提供商之一,更提供了 Workers、Pages 等多种网站部署服务。在本次全球服务中断事件中,部署在 Cloudflare Workers、Pages 等平台上的网站也无一幸免,全部陷入瘫痪。

因为早期就意识到 Cloudflare 部署的网站在国内访问速度不够理想（其实就是嫌弃CF在国内访问太慢了）,所以将主要服务分散部署到了 Vercel 和 Netlify 等平台。这一决策在此次故障中得到了验证 —— 本站几乎不受影响,只有少数部署在 Workers 上的辅助服务(如 Cloudmail 邮件服务、LLM API 中转、短链服务以及图床)暂时不可用。这恰好印证了”不要把所有鸡蛋放在一个篮子里”的重要性。

仪表盘上不去咋办？ 改 NS 记录

在域名注册商处配置多个 NS 记录，或者直接改掉（）

1
ns1.cloudflare.com
2
ns2.cloudflare.com
3
ns1.dnspod.net  (备用)
4
ns2.dnspod.net  (备用)

2. 源站高可用#

确保源站本身也有冗余:

服务器层面:

• 多地域部署(国内 + 海外)
• 负载均衡(Nginx/HAProxy)
• 容器化部署(Docker/K8s)

数据层面:

• 数据库主从复制
• 定期备份到多个云存储
• 使用对象存储(S3/OSS)作为静态资源源

3. 监控#

监控工具:

• UptimeRobot - 免费的网站监控
• Pingdom - 专业监控服务
• 自建监控

4. 静态资源分散存储#

不要把所有静态资源都放在一个地方:

分散策略:

• 图片: 主要使用 Cloudflare R2 + 备用 AWS S3
• CSS/JS: 使用 jsDelivr、unpkg 等 CDN
• 字体文件: Google Fonts + 本地备份
• 视频: B站、YouTube 等平台 + 自建备份

这次故障教会我们什么?#

1. 永远不要 100% 依赖单一服务商

   • 再大的公司也会出故障

2. 容灾方案要提前准备,不是临时抱佛脚

   • 故障发生时再准备已经晚了

3. 监控是必须的

   • 尽早发现问题
   • 自动化响应

4. 文档化你的架构

   • 记录所有配置
   • 团队成员都能快速响应