Cloudflare 于 8 月 12 日完成了博客向 EmDash 的迁移。EmDash 是一个为 Astro 和 Cloudflare 构建的内容管理系统，此项目并不只是重新设计界面。公司将自己的博客作为测试新平台的“零号客户”，在真实生产流量下对其进行测试，重点关注可扩展性、响应速度以及从旧系统平稳切换的安全性。
Cloudflare 表示，迁移过程暴露了与博客规模和复杂性相关的需求，也让团队得以在更大范围推广 EmDash 之前对其进行改进。由于这些结果和指标均来自公司自身，因此它们代表的是公司单方面发布的运营实践，并非对该平台进行的独立测试。
在性能测试之前测试平台
团队首先提出了一个实际问题：EmDash 是否真正满足 Cloudflare 的需求？为此，他们测试了创建、发布、取消发布和安排文章，以及添加媒体等基本流程，同时还测试了内容实体搜索和作者姓名管理。
最大的差距出现在处理大量媒体和内容，以及翻译细节、搜索引擎优化和内容安全策略（CSP）方面。管理编辑器还需要改进，以便查找自定义 HTML 块、处理内容编辑器中的错误，并在编辑长篇文章时保持格式工具栏显示。
计划发布的文章是发现的最突出问题；在 EmDash 0.19.0 版本之前，该功能都无法正常运行。这说明在依赖新系统之前测试完整运营流程的价值，因为创建内容或立即发布内容的测试未必能发现这一缺陷。
模拟波动流量的压力测试
Cloudflare Blog 的常规流量约为每秒 75 个请求，但可能超过每秒 5,000 个请求，原因可能是新文章传播，也可能是与特定发布时间无关的流量激增。因此，团队使用开源工具 k6 设计了测试，包括逐步增加负载至基线的三倍、在十分钟内从零提升至每秒 100 个请求的测试，以及在一分钟内以每秒 7,000 个请求瞬时冲击的测试。
失败标准基于三个指标：HTTP 5xx 类错误不得超过 0.01%，95% 的请求响应时间不得超过 500 毫秒，99% 的请求响应时间不得超过 1 秒。这些限制将“平台是否快速？”这一问题转化为可衡量的运营条件。
多层架构与明确的回退路径
Cloudflare 选择在 Cloudflare Worker 上运行 EmDash，并置于 Workers Cache 之后，同时使用基于 Workers KV 的 EmDash 新对象存储，并集成 Hyperdrive 与 PlanetScale。根据公司数据，多层缓存使 99.5% 的静态文件和约 70% 的全部请求能够从缓存中提供，从而减轻了数据库压力。
为避免迁移期间服务中断，团队创建了一个 Proxy Worker，将请求分发至旧博客和新网站。它通过 Cookie 确定试用版本；如果新网站出现 500 错误，还可以将请求重新导向旧系统。团队还通过名为 NEW_BLOG 的服务绑定，使用 Workers 之间的直接连接，避免经过公共域名、DNS 和 TLS 操作以及外部 HTTP 连接。
渐进式发布从 1% 的流量开始，随后提升至 5% 和 15%，最终在当天结束时达到 100%。这使团队能够监控真实负载并发现边缘情况，同时避免让大多数读者暴露于不稳定的变更之中。
实际发生了哪些变化？
Cloudflare 表示，与之前的平台相比，新架构保持了更加稳定的响应时间；在处理每秒最多 850 个请求时，性能有所提升，错误也较少。在 Agents Week 期间，团队在九天内发布了 18 篇博客文章，获得近 300 万次浏览量；新的 Worker 在没有明显问题的情况下处理了每秒最多 450 个请求。据公司称，内置的 DDoS 防护还在 8 月 10 日吸收了一次每秒 28,000 个请求的攻击。
此次变化也包括界面：界面按照 Kumo 设计系统的模式重新构建，并根据系统偏好和手动切换开关原生支持浅色和深色模式。电子邮件订阅邀请被移至文章末尾，同时新增“本页内容”目录和“在线讨论”选项，以改善导航和分享。
EmDash 的新界面和人工智能搜索端点让团队在几小时内为 Cloudflare 博客创建了 MCP 服务器，其中包含搜索、列出和获取文章以及列出标签的工具。据消息来源称，EmDash 自带的 MCP 服务器还允许作者浏览、创建、编辑、发布和安排内容，以及移除文件，且无需额外费用。
编辑体验本身仍不完整；Cloudflare 仍在记录与计划发布文章相关的小问题和错误，并表示已将其提交给 EmDash 团队，预计会在 Birthday Week 之前修复。因此，这一案例并不能证明该平台没有限制，但它展示了一种可行的实践：先测试内容流程，再测试性能；明确失败阈值；建立回退路径；然后逐步扩大发布范围，而不是一次性完成全面迁移。