EmDash
Performance
Cloudflare Workers
Developer Platform
Developers
EmDash
Performance
The Cloudflare Blog — 由 EmDash 呈现
Kody Jackson、Diogo Carneiro 和 Amy Dutton
你很可能已经注意到 Cloudflare Blog 最近的重设计。我们加入了 dark mode，现代化了 look and feel，并在过程中做了许多其他小改进。
你可能没有注意到 — 好吧，除了那些 更常驻线上的人 — 是这次重设计其实是一个大得多的 migration 项目的一部分。在 8 月 12 日星期三，我们把博客迁移到了 EmDash，一个专为在 Astro 上并与 Cloudflare 一起工作而构建的 content management system (CMS)。
我们会带你了解 migration 的故事 — 我们学到了什么，以及 EmDash 如何变得更好 — 也会介绍我们已经从一个新平台看到的好处。
我们是 Customer Zero
在 Cloudflare，Cloudflare 自己就是 Customer Zero。这意味着我们会使用自己的产品。而且 — 在使用中 — 我们会为自己和客户把它们变得更好。
这在 Cloudflare 是一种非常真实的文化价值。如果你想使用外部 vendor，举证责任在你。为什么那个团队不能支持你？存在哪些 gaps？为什么这些 gaps 不能被填补？那些“gaps”是真正的 requirements 吗？
这种偏好甚至被写进了我们的内部 engineering standards，也就是我们的 Codex。
*我们不只是为他人构建产品；我们构建它们来运行 Cloudflare 自身。我们是我们自己第一个、最苛刻的 customer。*我们在自己的大规模 infrastructure 上验证 scale、security 和 usability，然后付费 customer 才会接触产品。如果产品坏了，它会先弄坏我们。这迫使我们立即修复问题，确保当某个 feature 到达 enterprise 时，它已经在世界上最严苛的 production environment 中存活下来。
Customer Zero 实践
当我们开始最初的 migration 对话时，我们从两个主要问题开始：
- EmDash 对我们来说能工作吗？
- EmDash 能 scale 吗？
平台能工作吗？
我们的第一个问题最宽泛，EmDash 对我们来说能工作吗？这是你会想广泛了解任何新平台的东西，尤其是 pre-1.0 的平台。
为了回答这个问题，我们跑了一堆常见 user flows，比如：
- 发布一篇 post，然后取消发布
- 创作一篇新 post
- 定时发布一篇 post
- 添加 media items
总的来说，EmDash 在这些 usability tests 中表现得相当不错。我们发现的 gaps 通常与以下方面有关：
- Cloudflare Blog 的巨大 scale（media、content entity search 和 bylines）
- 围绕 localization、SEO 和 Content Security Policies (CSPs) 的细微差别
- admin editor 的 usability features — 尤其是那些可能延迟 post 发布的 — 比如 custom HTML blocks 更容易被找到、in-entity content editor 中的 bugs，以及 让 formatting toolbar 在较长的 posts 中保持可见。
我们发现的最大疏忽与 scheduled posts 有关，它在 EmDash version 0.19.0 之前都无法工作。考虑到 EmDash 的早期版本，这个 gap 可以理解，但它也绝对是我们不想在 post 的 scheduled time 之后 才发现的事情。
EmDash 能 scale 吗？
我们最大的担忧是，我们提议的 EmDash setup 是否能处理我们在 Cloudflare Blog 上看到的 traffic。
我们博客的 traffic pattern 极其多变。正常 load 大约在 75 requests per second (RPS) 左右，但也会飙升到超过 5,000 RPS。有些 spikes 与新 posts 的发布时间吻合，意味着那些 posts 走红了并吸引了大量关注。其他 spikes 则发生在白天和夜间的各个时间点，这很可能意味着人们在向我们发送一些 extra traffic，只是想看看会发生什么。
Performance 对我们的系统（以及我们的读者）也很重要。毕竟 Cloudflare 是一家 web performance 公司，所以页面加载的速度变得极其重要。
考虑到这两个担忧，我们使用 k6（一个 open-source performance testing tool）构建了一些 scenarios：
- Ramp：我们逐渐增加 requests，直到达到 prod baseline 的三倍，然后 cool down。
- Breakpoint：我们在 10 分钟内从 0 ramp 到 100 RPS，在某个东西坏掉时停止。
- Burst：我们立即施加 7,000 RPS 的 traffic load，然后看看会发生什么。
import
{ randomPageVisit }
from
"../random-page-visit.ts"
/**
* Sudden burst to 7,000 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;
对于这些 scenarios 中的每一个，我们都评估了：
- **Availability:**当超过 0.01% 的 HTTP requests 导致 5xx errors 时失败，意味着应用无法处理 traffic。
- Latency：P95 latency：当超过 5% 的 responses 超过 500ms 时失败。P99 latency：当超过 1% 的 responses 超过 1000ms 时失败。
有了这些 tests — 以及大量内部讨论和数据点 — 我们得出了我们的 production architecture：
- EmDash，运行在一个 Cloudflare Worker 上
- 运行在新的 Workers Cache 之后（我们相信是第一个这样做的大型站点）
- 使用基于 Workers KV 构建的新 EmDash object cache，这是 EmDash 团队专门为我们的 use case 构建的。
- 使用 Cloudflare 新的、first-party 的 Hyperdrive integration with PlanetScale。
我们部署的多层 caching 在让博客既快速又有韧性方面发挥了关键作用。在下图中，它们按照与用户的接近程度从上到下排列：
通过这个 setup，我们通常从 cache 提供 99.5% 的 static files，并从 cache 提供 70% 的 requests，从而改善 frontend performance 并减少 database 上的 load。
一旦这个 architecture 就位，我们就可以开始考虑 frontend redesign 了。
Frontend redesign
除了更新 backend architecture，这次 migration 还给了我们一个绝佳机会，让博客的 interface 与 Cloudflare 更新后的 visual language 保持一致。我们使用 Kumo design system 确立的 patterns 重建了 frontend experience，在 Cloudflare homepage、dashboard 和 marketing sites 之间创造了视觉和结构上的一致性。结果是一种连贯的阅读体验，感觉像是更广泛的 Cloudflare ecosystem 的自然延伸。
这次 redesign 的一个主要优先事项，也是我们读者长期以来的请求，是原生支持 light and dark modes。我们实现了直接与 system preferences 绑定的 theme switching，同时还有显式 toggle，并确保两个 themes 都严格满足 accessibility guidelines。无论偏好如何，更新后的 palette 和 code syntax highlighting 都能无缝适应，而不会牺牲 legibility。
我们还借此机会解决了一些长期存在的 user experience quirks，从我们的 email subscription form 开始。以前，subscription box 位于页面右上角。由于它的位置，读者经常把它误认为 search bar，并直接在 input field 中输入他们的 search queries。
为了解决这个问题，我们把 email sign-up 移到了 posts 底部一个专门的 call-to-action block 中。
现在，一旦读者读完一篇文章并希望保持更新，订阅提示会自然出现在 post 末尾。
最后，我们在 interior post pages 上引入了两个专门的 sidebar features，以改善 navigation 和 community engagement。在右侧，一个 “On this page” table of contents 会跟踪你的进度，并让你直接跳转到较长 technical posts 的特定 sections。在左侧，一个新的 “Discuss Online” section 让你可以轻松分享文章，并在 social platforms 和 developer communities 中参与对话。
Rollout strategy
随着我们越来越接近 migration，我们开始关注一个更广泛的问题：“我们如何安全地做出这个改变？”确保读者 zero downtime 是不可协商的要求，同时还要保证如果最后一刻出问题，有一个无缝的 fallback mechanism。
为了实现这一点，我们部署了一个 proxy Worker，在 legacy blog 和新的 EmDash-powered site 之间智能地路由 traffic。这个 Worker 会在 requests 上设置一个 version cookie，然后让我们据此将传入 traffic 路由到新的或 legacy experience。此外，这个 strategy 还允许我们在新站点遇到任何 500 errors 时回退到 legacy blog。得益于 Cloudflare Workers 的灵活性，这个 proxy 创建起来相对简单，并且毫无问题地 scale。通过 NEW_BLOG service binding 配置直接的 worker-to-worker connection 的能力在这里特别有用，因为它降低了任何通过 proxy 的 end user 的 latency。这个 service binding 让 proxy Worker 将传入 requests 直接 dispatch 到新的 blog Worker，而不是通过 public hostname、DNS、TLS 和 outbound HTTP connection 发送它们。
在 launch day，我们启动了 gradual rollout，从总 traffic 的仅 1% 开始，然后在验证 system health 时逐步提升到 5%、15% 以及更高。这种 phased approach 让我们能够观察平台如何处理真实世界的 production load，同时在不影响绝大多数 audience 的情况下捕捉一些最后一刻的 edge cases。到当天结束时，我们已经轻松地将 100% 的 traffic 切换到了新平台。
Results
可衡量的 performance 提升
这次 migration 的主要目标之一是为我们的读者提供一个更快、更可靠的站点，而早期数据表明我们正是做到了这一点。
比较旧 architecture（绿线）和新 EmDash setup（黄线）之间的 p95 response latencies，显示出明显差异。以前的平台在 load 下会经历周期性的 latency spikes，而新系统保持着非常平坦、一致的 response profile。通过在 Cloudflare Workers 上运行 EmDash，并配合我们新的 caching layers，我们在所有方面都交付了显著更快、更高 performance 的阅读体验。
我们在 serving 高达 850 RPS 的同时，看到了所有这些 performance gains — 以及极少的 errors。
MCP servers
通过这次改变，博客对 agents 来说也变得更易访问，体现在两个不同的方面。
第一个是，我们为 Cloudflare Blog 发布了一个新的 Model Context Protocol (MCP) server。
一个 MCP server 会打包一组特定的 tools，你的 agent 随后可以使用这些 tools 与外部 resource 交互，几乎就像为 agents 提供的 API。
使用那个 MCP，你现在可以在你的 agents 中使用以下 tools：
- search_posts
- list_posts
- get_post
- list_tags
借助我们 Worker 暴露出的新的、直观的 EmDash APIs 和 AI search endpoints，创建这个新 MCP 只花了几个小时的工作。
第二个是 — 对于我们的博客 authors 来说 — EmDash 有一个针对 EmDash 自身的 MCP server，这意味着他们可以浏览、创建和编辑 content、发布和定时 posts、移除 files 等等。
虽然这类 agentic tooling 在 CMS 行业正变得越来越标准化，但不标准的是它没有任何额外成本即可使用。MCP 只是平台的另一部分，反映了 designing for agents 以及为人类设计的日益增长的趋势。
第一次测试：Agents Week
在 Cloudflare，我们每年会举办多个创新“周”，在这些周里，我们会围绕特定主题为内部团队设定雄心勃勃的目标。这些周推动我们的产品前进，也帮助客户消化 Cloudflare 不断发生的变化。
其中最新的一次 Agents Week，对新博客来说是一次相当大的测试。我们在 9 天内发布了 28 篇新 posts。而那些 posts 获得了大量 traffic，接近 3 million pageviews。
在 frontend 方面，我们新的 blog Worker 表现得非常好，serving 高达 450 RPS 而没有任何明显问题。得益于 Cloudflare 的 built-in DDoS protection，我们还在 8 月 10 日吸收了一次 28,000 RPS 的 DDoS attack，同样没有任何明显问题。
在 editing 方面，我们继续发现一些问题。其中大多数涉及 editing experience 的 small quirks，不过我们也发现了一些专门围绕 scheduled posts 的 bugs。我们此后已将这些反馈给 EmDash 团队，并相信它们会在 Birthday Week 之前修复。
试试 EmDash
我们想向 EmDash 团队致以衷心的感谢，他们让这次 migration 尽可能顺利，并且非常乐于接受我们的 feedback。这就是 Customer Zero 应该运作的方式，而能与所有读者分享这个过程的内幕也令人非常欣慰。
如果你正在市场上寻找新的 CMS，今天就试试 EmDash 吧。它相当 amazing，而且 — 随着即将到来的 launch to v1 — 它很快会变得更好。
相关 tags
Cloudflare Workers
Developer Platform
Developers
EmDash
Performance
在社交媒体上关注
- Cloudflare
- Diogo Carneiro
- Amy Dutton