Cloudflare 刚刚推出了一个面向垂直微前端（VMFE）的Worker模板。该架构可以将独立的Cloudflare Worker映射到同一域名的特定 URL 路径上。通过整合 Service Bindings 和 Speculation Rules API，该模板使分散的团队能够管理自己的技术栈和 CI/CD 管道，同时仍然给用户带来流畅的单页应用（SPA）体验。
这里的变化是从横向组件混合转为纵向的基于路径的所有权。本质上，如果一个团队拥有/docs 路径，他们便能掌控整个纵向栈——从选择Astro或React等框架到管理完整的 CI/CD 管道——而且完全不会与管理/marketing 或/dashboard 的团队产生冲突。
该技术粘合层可以归结为三个部分。服务绑定允许 Router Worker 直接在边缘与子应用 Worker 通信，通过避免使用公网来保持低延迟。然后是 Router Worker 本身，它充当前门，根据路径前缀引导请求。最后，HTMLRewriter 会自动调整 HTML 响应以修复路径问题（通常出现在对服务做反向代理时），例如在图像源中添加/docs。
为了保持连贯的用户体验，模板内置了两个现代浏览器 API。首先，CSS View Transitions 有助于在页面更改期间保持 DOM 元素（如导航栏）可见，这消除了多页应用中经常出现的“白屏”现象。此外，它使用 Speculation Rules API 将相关联的微前端预加载到内存中。实话实说，这目前只在基于 Chromium 的浏览器中有效，不过，这使得物理上相互分离的 Worker 之间几乎可以瞬间完成切换。
实际上，Cloudflare 自己的内部仪表板便是使用这种模型将核心功能与 Zero Trust 等产品分开。正如 Cloudflare 全栈工程师 Brayden Wilmoth所说：
随着团队的增长，他们面临的问题在于，不同的框架服务于不同的用例……多个团队添加新功能的更新可能会因为一个团队出现了回归问题而不得不令人沮丧地回滚。
向垂直微前端的转变反映了我们软件思考方式的大幅转变。在最近发表的一篇InfoQ文章中，亚马逊云科技首席解决方案架构师 Luca Mezzalira 指出，微前端应该真正关注团队自治和“流程（flow）”，而不仅仅是重用代码。他认为，端到端的垂直切片是完美的“试验场”，让团队可以处理像认证和可观察性这样的复杂问题，而不必经历“大爆炸”式迁移的噩梦。
虽然这种架构带来了组织方面的好处，但也引入了特有的运营方面的权衡。在Reddit的讨论中，有人发出了一个涉及基于边缘的路由计费模型的警告：
注意：添加 Router Worker 意味着所有静态资源请求现在都会首先触发计费的 Worker（即路由器），即使底层的静态资源 Worker 是免费的。这相当于将没有使用限制的免费静态请求转换为按量计费的 Router 请求，而目的仅仅是为了实现基于路径的路由功能。
最后，在2024年底，Vercel 通过采用垂直方法也获得了类似的收益，将预览构建时间减少了 40%，但他们也遇到了一些问题。在本地测试这些配置仍然比较麻烦，经常有些功能需要采取手动的临时措施。行业对这一理念也还存在分歧。虽然垂直切片对大型企业来说堪称救星，但许多小型团队意识到，如果开发人员少于 15 人，额外的架构“成本”可能得不偿失。
原文链接：
https://www.infoq.com/news/2026/02/cloudflare-vmfe-template/
