The Cloudflare Blog – Brought to you by EmDash

Cloudflare 博客 – 由 EmDash 呈现 | Cloudflare 博客

post

EmDash

性能

Cloudflare Workers

开发者平台

开发者

2026年8月24日

Cloudflare 博客 – 由 EmDash 呈现

Kody Jackson , Â Diogo Carneiro , Â 和Â Amy Dutton

11分钟阅读

复制链接

您可能已经注意到 Cloudflare 博客最近的改版。我们新增了深色模式，更新了视觉风格，并在过程中进行了许多其他小改进。

您可能没有注意到的是（除了那些极度联网的用户），这次改版是更大规模迁移项目的一部分。8月12日星期三，我们将博客迁移至 EmDash，这是一个专门为 Astro 和 Cloudflare 构建的内容管理系统（CMS）。

我们将带您深入了解迁移过程——我们学到了什么以及 EmDash 如何改进——同时分享新平台为我们带来的优势。

我们是首个客户

在 Cloudflare，Cloudflare 本身是“首个客户”。这意味着我们使用自己的产品。并且——在使用过程中——我们通过自身和客户的需求来改进产品。

这是 Cloudflare 非常真实的文化价值观。如果您想使用外部供应商，证明责任在您身上。为什么那个团队无法支持您？存在哪些空白？为什么这些空白无法填补？这些“空白”是否真的是必要需求？

这种偏好甚至被写入了我们的内部工程标准，即我们的《Codex》。

我们不仅为他人构建产品，还构建用于运行 Cloudflare 本身的产品。我们是自己最首要、最苛刻的客户。在付费客户接触产品之前，我们已经在自己的大规模基础设施上验证了产品的可扩展性、安全性和可用性。如果产品出现故障，首先影响到的是我们自己。这迫使我们立即解决问题，确保在功能到达企业用户之前，它已经经受过地球上最严苛的生产环境考验。

随着 EmDash 的发布以及当前 CMS 供应商的一些限制，我们意识到在 Cloudflare 内部，我们很可能会成为 EmDash 的“首个客户”。

“首个客户”的实践

当我们开始最初的迁移讨论时，我们首先提出了两个主要问题：

• EmDash 是否适合我们？

• EmDash 是否具备可扩展性？

平台是否可用？

我们第一个问题最为宽泛：EmDash 是否适合我们？这是您在了解任何新平台时都应关注的问题，尤其是那些尚未达到 1.0 版本的平台。

为回答这个问题，我们测试了一系列常见用户流程，例如：

• 发布并随后取消发布一篇文章

• 创建新文章

• 安排文章发布时间

• 添加媒体内容

总体而言，EmDash 在这些可用性测试中表现良好。我们发现的差距主要涉及：

• Cloudflare 博客的规模（媒体、内容实体搜索和作者署名）

• 本地化、SEO 和内容安全策略（CSP）方面的细节

• 管理员编辑器的可用性功能——特别是可能延迟文章发布的功能，例如自定义 HTML 块的更易查找性、实体内容编辑器中的错误以及更长文章中格式工具栏的可视性。

我们发现的最大疏漏是关于定时发布功能，直到 EmDash 0.19.0 版本之前，该功能均无法使用。考虑到 EmDash 的早期版本，这一差距是可以理解的，但我们也绝对不希望在文章预定发布时间之后才意识到这一问题。

EmDash能否扩展？

我们最大的担忧是，我们提出的EmDash架构是否能够应对Cloudflare博客所经历的流量。

我们的博客流量模式极其多样化。正常负载约为每秒75次请求（RPS），但有时会激增到超过5000 RPS。一些流量高峰与新文章的发布时间重合，这意味着这些文章迅速走红并吸引了大量关注。其他高峰则出现在全天任何时间，这可能意味着有人故意发送额外流量来测试我们的系统。

性能对我们的系统（和读者）同样重要。毕竟Cloudflare是一家专注于网络性能的公司，页面加载速度变得至关重要。

带着这两个担忧，我们使用k6（一个开源性能测试工具）构建了以下测试场景：

• 渐进式：逐步增加请求量至生产环境基准值的三倍，然后逐渐减少。
• 阈值测试：在10分钟内将请求从0增加到100 RPS，直到出现系统故障。
• 突发式：立即发送7000 RPS的流量，观察系统表现。

import
{ randomPageVisit }
from
"../random-page-visit.ts"
;
/**
* 突发式：7000 RPS的流量冲击。
*/
export
const
options
=
{
scenarios: {
burst: {
executor:
"constant-arrival-rate"
,
rate:
7000
,
timeUnit:
"1s"
,
duration:
"1m"
,
preAllocatedVUs:
4000
,
maxVUs:
10000
,
},
},
summaryTrendStats: [
"avg"
,
"min"
,
"med"
,
"max"
,
"p(90)"
,
"p(95)"
,
"p(99)"
,
"count"
,
],
thresholds: {
http_req_failed: [
"rate<0.01"
],
"http_req_duration{status:200}"
: [
"p(95)<500"
,
"p(99)<1000"
],
checks: [
"rate>0.99"
],
},
};
export
default
randomPageVisit;

针对这些场景，我们评估了以下指标：

• 可用性：当超过0.01%的HTTP请求导致5xx错误时判定为失败，意味着应用无法处理流量。
• 延迟：P95延迟：当超过5%的响应时间超过500ms时判定为失败；P99延迟：当超过1%的响应时间超过1000ms时判定为失败。

通过这些测试（以及大量内部讨论和数据验证），我们最终确定了生产环境架构：

• EmDash运行在Cloudflare Worker上
• 部署在新的Workers Cache后端（我们相信是首个大规模采用该技术的网站）
• 使用专为我们的使用场景构建的EmDash对象缓存（基于Workers KV）
• 集成Cloudflare最新的一线Hyperdrive方案与PlanetScale

我们部署的多级缓存体系在保障博客速度和弹性方面发挥了关键作用。在下图中，这些缓存按距离用户的远近从上到下排列：

通过这种架构，我们通常能从缓存中提供99.5%的静态文件和70%的请求，显著提升了前端性能并降低了数据库负载。

在确定架构后，我们开始思考前端的重新设计。

前端重构

除了更新后端架构，这次迁移还为我们提供了绝佳机会，使博客界面与Cloudflare更新后的视觉语言保持一致。我们基于Kumo设计系统建立的模式重构了前端体验，实现了Cloudflare首页、仪表盘和营销网站之间视觉和结构的一致性。最终成果是一种连贯的阅读体验，自然地融入更广泛的Cloudflare生态系统。

博客改版前后

此次改版的一项主要优先事项，也是读者长期期待的功能，是原生支持浅色和深色模式。我们实现了与系统偏好直接联动的主题切换功能，并提供了显式的切换按钮，同时确保两种主题都严格遵循无障碍指南。无论用户偏好哪种模式，更新后的配色方案和代码语法高亮都能无缝适配，且不影响可读性。

我们还借此机会解决了一些长期存在的用户体验问题，首先从电子邮件订阅表单开始。此前，订阅框位于页面右上角。由于这个位置，读者经常误将其认作搜索栏，直接在输入框中输入搜索查询。

旧版博客页眉及订阅表单

为了解决这个问题，我们将电子邮件订阅功能移至文章底部的专属行动号召区块。

电子邮件订阅改版

现在，当读者阅读完一篇文章并希望保持更新时，订阅提示会自然地出现在文章末尾。

最后，我们在内部文章页面引入了两个专属侧边栏功能，以提升导航和社区互动性。右侧的“本文目录”表格会跟踪您的阅读进度，并允许您直接跳转到长篇技术文章的特定部分。左侧新增的“在线讨论”区块则让分享文章和在社交平台及开发者社区中展开对话变得轻而易举。

部署策略

随着我们逐步接近迁移，我们开始关注更广泛的问题：“我们如何安全地实现这一变更？”确保读者零停机时间是不可妥协的要求，同时还需要保证在最后一刻出现问题时能无缝回退到旧版。

为实现这一目标，我们部署了一个代理Worker，用于智能地在旧版博客和新版EmDash驱动的网站之间路由流量。这个Worker会在请求中设置版本Cookie，从而让我们能根据Cookie将流量路由到新版或旧版体验。此外，这一策略还允许我们在新版网站出现任何500错误时回退到旧版博客。得益于Cloudflare Workers的灵活性，这个代理相对容易创建且扩展性良好。通过NEW_BLOG服务绑定配置直接Worker到Worker的连接在此过程中特别有用，因为它减少了任何通过代理的终端用户的延迟。该服务绑定让代理Worker能够直接将请求发送到新版博客Worker，而无需经过公共主机名、DNS、TLS和出站HTTP连接。

发布当天，我们启动了渐进式部署，从总流量的1%开始，随后逐步提升至5%、15%及更高比例，同时验证系统健康状况。这种分阶段的方法让我们能够观察平台如何处理实际生产负载，并在不影响绝大多数读者的情况下发现一些最后的边缘情况。到当天结束时，我们已平稳地将100%的流量迁移至新平台。

结果

可衡量的性能提升

此次迁移的主要目标之一是为读者提供更快、更可靠的网站，早期数据表明我们确实实现了这一目标。

博客.cloudflare.com桌面视图的Lighthouse评分

（此处应插入图表）

对比旧架构（绿色曲线）和新 EmDash 架构（黄色曲线）的 p95 响应延迟，我们发现了显著差异。旧平台在负载下会周期性出现延迟峰值，而新系统在负载下保持了异常平滑且一致的响应表现。通过将 EmDash 部署在 Cloudflare Workers 上并结合新的缓存层，我们在整体阅读体验上实现了显著的性能提升。

在处理高达 850 RPS 的请求时，我们看到了所有这些性能提升——同时错误率极低。

MCP 服务器

通过此次架构升级，博客对代理的可访问性也得到了两方面的提升。

首先是为 Cloudflare 博客推出了新的 Model Context Protocol（MCP）服务器。

MCP 服务器将一系列特定工具打包，代理可以使用这些工具与外部资源进行交互，几乎就像为代理提供的 API。

使用该 MCP，你现在可以为代理启用以下工具：

• search_posts
• list_posts
• get_post
• list_tags

得益于新推出的直观 EmDash API 和由 Worker 提供的 AI 搜索接口，创建这个新 MCP 仅耗时数小时。

第二个改进是——对于博客作者而言，EmDash 本身也提供了 MCP 服务器，这意味着他们可以浏览、创建和编辑内容，发布并安排文章，删除文件等。

尽管这种面向代理的工具在 CMS 行业正变得越来越标准化，但目前尚无标准做法能像我们这样实现零额外成本。MCP 只是平台的又一组成部分，这反映了我们正在遵循的一个趋势：在设计时同时考虑代理和人类用户的需求。

首次测试：Agents Week

在 Cloudflare，我们每年会举办多次创新"周"活动，为内部团队设定围绕特定主题的雄心勃勃的目标。这些活动不仅推动了我们产品的进步，也帮助客户理解 Cloudflare 不断发生的变更。

最新一次的 Agents Week 对新博客来说是一次重大考验。我们在 9 天内发布了 28 篇新文章，这些文章获得了大量流量，接近 300 万次页面浏览。

在前端，我们的新博客 Worker 表现优异，在达到 450 RPS 时没有出现任何明显问题。得益于 Cloudflare 内置的 DDoS 防护，我们在 8 月 10 日成功抵御了 28,000 RPS 的 DDoS 攻击，同样没有出现任何明显问题。

在编辑方面，我们继续发现了一些问题。其中大部分是编辑体验中的小细节问题，但也发现了一些与定时发布相关的特定错误。我们已将这些问题反馈给 EmDash 团队，并确信它们将在 Birthday Week 之前得到修复。

尝试使用 EmDash

我们要衷心感谢 EmDash 团队，他们使这次迁移尽可能顺利，并对我们的反馈做出了极高的响应。这就是 Customer Zero 应该运作的方式，能够与所有读者分享这个过程的内部视角，令人非常欣慰。

如果你正在寻找新的 CMS，今天就来试试 EmDash 吧。它非常出色，而且随着即将推出的 v1 版本，它很快会变得更好。

table of contents column

discussion column

RELATED TAGS AND SOCIAL MEDIA LINKS

Related tags

Follow on Social Media

• Cloudflare

• Diogo Carneiro

• Amy Dutton

EMAIL SIGNUP