我的开源项目：Piral——为微前端而生的框架

这是我"我的开源项目"系列的第三篇文章，我会回顾一些我发起或维护的开源项目，讲讲它们背后的故事。第一篇是 AngleSharp，然后是 MAGES。这一次：Piral——一个用于微前端的框架，也是这个系列里第一个并非来自飞机旅途或游戏工作室资助、而是来自客户项目实践的项目。

Piral 到底是什么？

Piral 让你可以把一个前端应用构建成稳定的应用外壳（app shell），再由独立开发、独立部署的模块——称为pilets——在运行时对它进行扩展。一个 pilet 自带代码和资源，可以注册页面、扩展其他 pilet 的扩展点，并且完全按照自己团队的节奏来构建、测试和发布——不需要任何人动一下甚至重新部署外壳。

如果这听起来像"微前端"，那确实就是。Piral 是该领域最早的专门框架之一，其核心理念是：一个主框架（通常是 React）驱动外壳，而单个 pilet 如果需要，可以自由地引入完全不同的技术——Vue、Angular，甚至一些短暂存在、为特定目的而写的方案。外壳不在乎。它只在乎契约。

我之前写过一篇更详细的技术介绍，如果你想深入了解可以读读：Introduction to Microfrontends with Piral。这篇文章更多讲它从哪来、以及它如何成长。

它真正的起点：一家德国能源公司，然后是 ZEISS

Piral 不是作为"让我们做个框架"而诞生的。它是作为"这次我们真的把这个客户门户做出来"而诞生的。

我当时刚完成一家德国大型能源公司智能家居门户的大规模重写。在那次项目中，微服务支撑、松耦合前端的做法效果远超所有人的预期。后端团队早就出于自己的原因走了微服务路线——扩展性、所有权、独立的发布周期——而这些独立性一旦到达前端就被浪费了，因为一切又被焊回一个共享代码库。所以我们没有这么做。多个团队可以独立交付而不互相踩脚——如果你曾在一个大型前端巨石应用里工作过、十几个团队同时往同一个App.tsx提交代码，你就会知道这句话有多难得。

后来我成了ZEISS（蔡司）一个新的数字客户门户的首席架构师——这是一家德国大公司，而在此之前，他们已经多年尝试、却始终没能做成这样类型的门户。不是没努力，也不是缺少优秀工程师——"让许多团队为一个连贯的面向客户的应用做贡献"本来就是一个真正困难的组织和技术问题，之前的尝试都撞上了同一堵墙：一个每个团队都得碰、得协调、最终甚至不惜一切代价避免去碰的单一前端代码库。

我注意到这与 RWE SmartHome 项目里刚刚成功过的做法有相似之处，于是沿用了同一套思路：微服务后端配上我们现在会称之为微前端的前端——尽管当时还没人这么叫，这个词也还没进入日常用语。它奏效了。多个团队以真正称得上"思维的速度"在贡献，而不是"请再对你的分支 rebase 到共享前端仓库，另外这是本周六个人动过的文件的合并冲突"的速度。

那时候最明显的问题就是：为什么要为每个客户重新发明一遍？为什么不把这种方法泛化成一个真正的框架？

命名（并意外地预示了什么）

我在 2019 年 2 月加入了smapiot，方向从第一天就明确了：除了常规的咨询工作，还要留出专门的时间来构建一个微前端框架。到 2019 年 3 月，我们定下了一个名字：Piral，"Portals that can go viral"（可以走红的门户）的缩写。一年后，名字里的"viral"以绝对没有人能预料到的方式应验了。我们现在还会提起这件事。

我们在 2019 年 11 月的O'Reilly 柏林软件架构大会上正式发布了 Piral。事后看来，那场大会是 O'Reilly 该系列的最后一场——疫情之后它再也没有恢复过，至少据我所知是这样。所以 Piral 的公开首秀，恰好发生在那场大会的一个时代终结之时。不过当时的反响确实非常好——人们立刻就想试用，这在一个软件架构大会上拿出"又一个前端框架"时并不总是有保证的。我们做好了迎接一轮"这和 iframe 有什么区别"的准备，结果得到的却是令人耳目一新的"我们下个季度能不能试点一下"。

下面这张图把从 smapiot 的第一个月到现在整个历程浓缩成一张时间线：

对任何一个围绕单一客户项目成功而建立起来的框架来说，七年仍然持续活跃开发、持续收获新采用者、还拥有自己的年度会议，都是很长的时间。2019 年在那个柏林会议室里，这些一点都不确定。关于这张时间线有几件值得说明的事：那些空白是真实的——不是每个季度都有值得写进头条的事件，我宁可展示诚实的平静期，也不愿用填充内容把时间轴塞满。另外有两个日期以我没计划过的方式对上了：Piral v1.0 发布和第一届微前端大会都落在 2023 年 6 月的同一天，这给了我们一个绝佳的庆祝理由。

这些里程碑里有几个值得单独说一说。Feed Service有自己的稳定发布节奏，与框架并行——2021 年 10 月是 1.0.0，四年后是 1.17.0。Piral.Blazor长成了它自己的小生态，从 2022 年 9 月的 v3，到 2024 年 2 月面向 .NET 8 的专用服务端变体。Piral 1.4.0 原生支持 Module Federation（2023 年 12 月）是一个低调但重要的事件——它意味着 Piral 可以与微前端领域另一大主流方法并肩存在，而不只是竞争。

值得明确指出的是："一个应用里数百个 pilet"的扩展故事，不是 Piral 在这七年里慢慢长出来的——它是从第一个版本起就是设计目标，直接源于当年在 ZEISS 式架构里观察到的大规模崩溃。2019 年以来变化的不是天花板，而是有多少生产系统真的在逼近它。

不只是理论：真正的采用，包括 Piral 之外

随后的咨询项目证明，这个概念在 ZEISS 的具体场景之外也站得住脚——这对任何一个起源于"某个项目的好主意"的东西来说，才是真正的考验。让一个你自己设计的架构工作起来是一回事（你设计了它，并且每个决策你都在场）；把它交给一个不同的团队、一个不同的项目、带着不同的约束，然后看着它照样成立，是另一回事。Piral 做到了。

不过更让我意外的是那些根本不使用 Piral 的团队的兴趣。已经建立在Single-SPA之上的大型项目开始联系我们，希望把 Piral 的松耦合集成模式引入他们现有的工作流。他们不想从已经能用的代码迁移走——没有任何理智的人会去重写一个运转良好的生产系统——但他们想要的是 Piral 背后的思想（解耦模型、独立可部署性、pilet 无需整体重新部署即可更新和回滚的方式）叠加到他们已有的微前端架构上。在实践中，这意味着引入具体的机制——比如我们处理共享依赖的方式，或者更新/回滚模型——而不用任何人扔掉几个月或几年的 Single-SPA 工作。

对任何架构来说，这都是一个好迹象：当人们保留自己的技术栈却还想借用你的模式时，它比 star 数或下载量强得多的信号——因为它意味着这些想法是可移植的，即使代码本身不是。

一个生态系统，而不仅仅是库

从一开始，Piral 就注定不只是"装个包，得个框架"。不同的工具被刻意构建成各自通用、可复用的东西——而不是死死绑在 Piral 内部。这是设计选择，不是偶然：一个只懂 Piral 特定概念的调试工具，其投入远小于一个建立在通用原语之上、恰好 Piral 也在用它们的工具；但后者更有可能在框架自身的演进中存活下来——而且对 Piral 世界之外的任何人都更有用。

最清晰的例子是 Piral Inspector，一个用于检查、调试运行中 Piral 实例的浏览器 DevTools 扩展——哪些 pilet 已加载、注册了哪些路由、共享了哪些依赖、切换诸如状态容器日志之类的设置，甚至能即时从根模块 URL、feed URL 或 tarball 加载新 pilet 做快速本地测试。它特意用适配器模式构建，让它的核心调试管道（后台脚本与内容脚本通信，再与 devtools 面板通信——任何需要检查页面的浏览器扩展的标准形态）不锁定在 Piral 专属场景。它支持 Firefox、Chrome、Opera 和 Edge——比大多数内部开发工具的浏览器覆盖还广——而且代码库真的又小又聚焦，是那种如果你好奇它如何与运行中的应用通信，一下午就能从头到尾读完的工具。

除此之外，生态还包括：

• 一个 VS Code 扩展，用于编写 pilet 和应用外壳，提供适当的工具支持，而不是裸文本编辑加祈祷。
• 一套模板系统（通过 CLI），几秒内就能搭建一个新 pilet 或一整个新应用外壳，而不是复制粘贴上一个项目再删到能用为止。
• Piral Cloud Feed Service——把这一切串起来的商业产品。

Feed Service：巨人脚下的基石（但不是必需）

Piral Cloud Feed Service 在实践中，是让微前端的大规模发布和更新真正变得愉悦的东西——它是 pilet 被发现、版本化、并交付到应用外壳的方式，而无需有人为每个团队手动搭一套部署流水线。推一个新 pilet 版本，feed 就会接住它，已连接的应用外壳获得更新——不用重建外壳、没有协调的发布列车、不用等下一个迭代的部署窗口。

这是我认为在哲学上最重要的一点：Piral 框架对 Feed Service 没有硬依赖。我们从第一天起就有意这么设计，尽管把它俩紧密耦合本来是更简单（也更具商业便利）的选择。如何分发和更新你的 pilet 完全由你决定——即使你判断发现/交付服务是正确选择（一旦你有不止几个团队独立交付，通常确实如此），也不一定非得是我们的。任何微前端发现机制都能接入同一个契约，因为契约本身只是"这是一份 pilet 列表以及去哪里取它们"——刻意地朴素，刻意地不绑定任何一家厂商。

我是否认为 Piral Cloud Feed Service 是市面上的最佳选择？是的，显然——我有点偏袒，毕竟我帮忙构建了它，而且我见过团队试图从零自己搭一个同款时是什么样子。但这是个大到值得单独写篇文章的话题，不适合用一段话带过。如果你想自己探索：落地页有概览，portal.piral.cloud 是登录免费社区版的地方，授权版则对需要的人完全本地化部署——当你面对有严格数据驻留规则的客户时，这是常见需求。

上手体验

搭建一个新的应用外壳：

npx piral new my-shell cd my-shell npm start

再建一个接入它的新 pilet：

npx pilet new --source my-shell cd my-pilet npm start

在 pilet 内部，注册一个页面是这样的：

import { PiletApi } from 'my-shell'; export function setup(piral: PiletApi) { piral.registerPage('/hello', () => <div>Hello from a pilet!</div>); }

对于最小场景，这真的就是大部分内容了。PiletApi表面才是真正有趣的扩展性所在——注册页面、扩展槽、共享状态、通知、菜单项等等，而外壳无需事先知道某个 pilet 存在。

它的闪光点

• 松耦合是头等公民，而不是事后想法。pilet 按设计隔离——独立构建、版本化、测试和部署。一个坏掉的 pilet 发布不会拖垮外壳或其他 pilet，一个团队可以在周五下午四点给他们的那一个 pilet 发热修复，而不需要团队以外任何人的签字。
• 它真正能扩展到大量微前端。Single-SPA 式架构大约在 10 个微前端时就开始变得不舒服，Module Federation 通常能撑到 30–40 个。据我所知，Piral 是唯一一个被设计成能舒适扩展到单个应用里数百个pilet 的微前端框架。

• pilet 层面与框架无关。React 驱动大多数外壳，但一个 pilet 可以是 Vue、Angular，或完全别的东西——对遗留系统迁移路径（一次重写一块，而不是一次性大爆炸切换）或短命的实验来说非常有用。
• 它是一个真正的生态系统。DevTools、编辑器工具、脚手架、以及发现/交付层——全部可以独立使用，没有任何一样被锁在"你必须用我们的云服务"后面。
• 不把自己商业产品锁死。Feed Service 完全可选（这是刻意设计），对一个也卖 feed 服务的公司来说，这个姿态比你想象的更罕见。

它的短板

• 社区比该领域的大牌小。与 Module Federation 或 Single-SPA 相比，Piral 的社区明显更小——尽管（也许部分因为）它被一些真正的大公司使用，而这些公司并不总是公开谈论自己的技术栈。企业采用不会以 GitHub star 的形式显现出来。
• 目前 React 和 React Router 仍然内置。Piral v1 的核心假定底层是 React 和 React Router，即使你愿意花功夫，也可以把两者换掉（pilet 层面有 Vue、Angular 等的转换包，但外壳的假设更深）。这正在改变——Piral v2 会从根上把两者都从硬性前提中去掉。

• 如果你对微前端这个概念本身不熟，学习曲线是真实的。pilet、扩展槽、共享依赖、feed 服务——在发布你的第一个生产应用外壳之前，需要真正的架构思考。这不是那种"npm install 就基本搞定了"的框架，它在下游移除的复杂性（独立团队部署）总得有人付出代价，而这大多发生在上游理解这个模型的过程中。
• 商业 Feed Service 虽然可选，但大量"开箱即用"的体验都在这里。自己搭发现/交付机制完全可行，但你得自己去构建和维护那部分——版本化、回滚逻辑、健康检查，全套。

社区：更小，但在对的房间里响亮

Piral 从不追逐 npm 下载量，这也看得出来——但它一直在真正讨论微前端的地方出现。这些年来我们在各种会议和 meetup 上主持过许多社区演讲，远远超出我们自己的活动，而且自 2023 年起，我们每年举办微前端大会——一个免费、一天、线上的活动，15 位以上的演讲者，其中几位确实是这个领域的奠基性人物（构建或塑造了 Module Federation、Single-SPA 以及其他你很可能已经用过的工具的人）。

2024 届在 6 月 17 日举办；两届的赞助商包括 JetBrains 和生态中的其他几家。按设计这不是 Piral 专属活动——重点一直是、也仍然是整个微前端社区，而不只是推广我们自己的框架。如果你的唯一目标是卖自己的框架，办一场刻意把竞争性方案搬上台的大会是件奇怪的事；如果你的实际目标是更健康的生态——撇开利益关系不谈，这确实就是目标——那就自然多了。

Piral 的下一步

地平线上最大的事是Piral v2，它从第一天起就抛弃历史遗留的 React 和 React Router 依赖，而不是把"框架无关"当作需要用额外转换器才能拧上的东西。对这样一个从最早版本起就 React 优先的框架来说，这是一个意义重大的转变——它意味着渲染和路由的核心假设要被重新思考，而不是打补丁绕过去，这是比一句话听起来大得多的工程。

除此之外，路线图不断回到这些主题：让"数百个 pilet"的扩展故事更加顺畅（因为真实的部署正在超过我们最初验证的范围），并继续独立于核心去壮大生态组件（inspector、编辑器工具、模板）——与最初就存在的哲学一致：构建那些即使在严格的"你必须全用 Piral"语境之外也有用的组件。如果过去七年有任何预示，有趣的采用故事还会继续来自我们没有专门设计过的地方。

这就是 Piral 的故事——从 ZEISS 一个最终成功了的客户门户，到一个能扩展到数百个独立交付 pilet 的框架，再到拥有自己的社区大会。网站有概览，仓库有代码，介绍文章有更深入的技术讲解。系列下一篇：另一个项目，另一个起源故事。敬请期待。

如果你也对微前端或前端架构感兴趣，欢迎参考本站的浏览器卡顿排查和更多实用教程。

相关阅读：

• 如何让 iPhone Safari 在后台打开新标签页
• 如何在 Safari 浏览器中允许或拦截弹窗
• Windows 网络连接相关设置教程