Cloudflare Blog 迁移到 EmDash：如何在大规模流量下验证、切流与重做体验

把一个高访问量内容站迁到新平台，难点从来不只是“页面能不能渲染出来”。Cloudflare Blog 迁移到 EmDash 的过程，重点在于用真实的大规模场景验证技术栈：压测性能、以可回滚的方式导入生产流量，并借迁移机会重新梳理前端体验。

这类迁移值得工程团队认真研究，因为博客看似是静态内容，实际却承受着缓存命中、全球访问、突发流量、搜索入口、旧链接兼容和编辑发布流程等一整套生产约束。

把迁移当成一次规模验证

用自家高流量站点验证 EmDash，意味着验证对象不止是 CMS 或渲染框架本身，还包括整条交付链路：内容数据如何建模，构建或动态渲染如何执行，缓存如何命中，静态资源如何加载，以及故障时怎样退回旧系统。

对于读者而言，页面性能通常体现为几个直接指标：

• 首屏 HTML 是否足够快地返回；
• 图片、脚本和字体是否阻塞内容阅读；
• 缓存未命中时，源站是否仍能稳定响应；
• 高并发访问时，错误率和延迟是否突然恶化；
• 旧文章 URL、RSS、分享链接和搜索索引是否保持可用。

这里的关键是区分“缓存命中时很快”和“系统真的扛得住”。前者可能只说明 CDN 配置正确；后者还要求在缓存穿透、冷启动、内容发布导致缓存失效等情况下，后端行为依然可预测。

压测不能只打一条首页

迁移前的压测应覆盖真实访问结构。首页、文章详情页、标签页、搜索或归档页的缓存策略和计算路径通常不同；只压一个 URL，很容易得到过于乐观的结果。

可以这样实践：准备一份按真实流量权重排列的 URL 列表，同时分别测试缓存命中与刻意绕过缓存的场景。下面的示例使用 wrk 压测一个文章页；运行前请把域名和路径替换为自己的预发布环境，并确认压测不会冲击未经授权的生产服务。

wrk \
  --threads 8 \
  --connections 200 \
  --duration 60s \
  --latency \
  https://staging.example.com/blog/how-we-built-it

关注输出时，不要只看平均延迟。更有价值的是：

• p99 延迟：尾部请求是否出现明显堆积；
• Non-2xx or 3xx responses：高压下是否产生 5xx、超时或意外跳转；
• 请求吞吐量：在达到目标并发后能否保持稳定；
• 源站 CPU、内存、数据库连接和日志中的错误峰值。

如果需要模拟不同路径的混合流量，可用 Lua 脚本让 wrk 每次请求随机挑选文章。以下文件保存为 paths.lua，并将路径替换成自己的测试页面：

math.randomseed(os.time())

local paths = {
  "/blog/edge-computing",
  "/blog/platform-update",
  "/blog/security-engineering",
  "/blog/archive"
}

request = function()
  local path = paths[math.random(#paths)]
  return wrk.format("GET", path)
end

执行命令：

wrk -t8 -c200 -d60s --latency -s paths.lua https://staging.example.com

压测结果应与发布门槛绑定，例如规定 p99、错误率和资源利用率的上限。没有明确阈值的压测，往往只能得到一份“看起来还不错”的报告，无法帮助发布决策。

用可观测、可回滚的方式接入生产流量

安全切流的核心不是一次性切换 DNS 或反向代理，而是让新旧版本能够并存，并且每一步都能观察和撤回。典型路径是内部验证、小比例外部流量、逐步扩大、全量接管，期间持续对比新旧站点的状态码、延迟、跳转和关键页面内容。

下面是一个可改造的 NGINX 金丝雀路由示例。它根据请求 ID 将约 5% 的访问转发到新站点，其余流量保持在旧站点。示例仅展示分流机制；生产使用前还应补充 TLS、健康检查、日志脱敏和具体的缓存配置。

upstream blog_legacy {
    server legacy-blog.internal:8080;
}

upstream blog_emdash {
    server emdash-blog.internal:8080;
}

split_clients "${request_id}" $blog_upstream {
    5%      blog_emdash;
    *       blog_legacy;
}

server {
    listen 80;
    server_name blog.example.com;

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Request-ID $request_id;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://$blog_upstream;
    }
}

这种方式的价值在于，分流比例可以从 1% 缓慢提高到 5%、25%、50%，而回滚只需把新站点比例调回 0%。实际迁移中还应特别检查以下兼容性：

• 旧 URL 是否返回相同内容，或使用正确的永久重定向；
• canonical URL、站点地图、RSS 和 robots.txt 是否连续；
• 404 页面和重定向链是否符合预期；
• 发布后缓存失效是否及时，且不会让源站被瞬时请求击穿；
• 用于分析、同意管理或广告归因的前端脚本是否重复加载。

需要注意的是，按请求随机分流会让同一用户在相邻请求中看到不同版本。对于带登录态、实验分组或交互式功能的网站，应改用稳定 cookie、用户 ID 或边缘会话标识做粘性路由。内容博客的无状态页面通常更适合先采用简单的请求级分流。

前端重做不是只换一套视觉样式

摘要提到前端体验也随迁移重新设计。这是迁移项目最容易被低估的部分：新技术栈给了团队重建信息结构的机会，但也可能在不经意间损失阅读效率和可访问性。

对于技术博客，前端优先级通常应放在内容本身：文章标题、发布日期、作者信息、目录、代码块、脚注、相关链接和移动端排版，都应比装饰性动效更早被验证。可以在预发布环境中用自动化检查覆盖一些基础约束，例如确认关键页面没有明显的性能回退：

npx lighthouse \
  https://staging.example.com/blog/edge-computing \
  --only-categories=performance,accessibility,seo \
  --output=json \
  --output-path=./lighthouse-report.json \
  --chrome-flags="--headless"

Lighthouse 适合作为回归信号，而不是唯一发布标准。它无法代替真实用户网络、全球缓存行为和长尾设备的观测。更可靠的组合是：实验室压测发现容量问题，真实流量指标验证用户体验，合成探针持续检查关键 URL。

迁移完成前的工程检查单

将高流量博客迁入 EmDash 的案例说明，平台迁移应被视为一次端到端的生产演练，而不是单纯的内容搬运。准备上线时，可以用下面这份检查单收口：

• 明确缓存命中、缓存未命中和发布后缓存失效三种场景的性能基线；
• 为延迟、错误率和资源利用率设定可执行的发布阈值；
• 保留新旧站点并行运行和快速回滚的能力；
• 验证 URL、重定向、SEO 元数据、RSS 与站点地图的连续性；
• 在小流量阶段对比新旧版本的日志、状态码和核心页面；
• 将可访问性、移动端阅读和代码展示纳入前端验收。

真正可靠的迁移，不是上线当天没有报错，而是在流量增长、缓存波动和内容持续发布之后，团队仍能快速判断系统状态，并能用明确的开关控制风险。