摘要：Cloudflare刚刚推出了一个面向垂直微前端（VMFE）的Worker模板"。正如Cloudflare全栈工程师Brayden Wilmoth所说"nbsp;最后，在2024年底"，Vercel通过采用垂直方法也获得了类似的收益，将预览构建时间减少了40%，但他们也遇到了一些问题。
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/"
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的讨论"中，有人发出了一个涉及基于边缘的路由计费模型的警告：
最后，在2024年底"，Vercel通过采用垂直方法也获得了类似的收益，将预览构建时间减少了40%，但他们也遇到了一些问题。在本地测试这些配置仍然比较麻烦，经常有些功能需要采取手动的临时措施。行业对这一理念也还存在分歧。虽然垂直切片对大型企业来说堪称救星，但许多小型团队意识到，如果开发人员少于15人，额外的架构“成本”可能得不偿失。
原文链接：
https://www.infoq.com/news/2026/02/cloudflare-vmfe-template/"