这是我我的开源项目系列的第三篇文章我会回顾一些我发起或维护的开源项目讲讲它们背后的故事。第一篇是 AngleSharp然后是 MAGES。这一次Piral——一个用于微前端的框架也是这个系列里第一个并非来自飞机旅途或游戏工作室资助、而是来自客户项目实践的项目。Piral 到底是什么Piral 让你可以把一个前端应用构建成稳定的应用外壳app shell再由独立开发、独立部署的模块——称为pilets——在运行时对它进行扩展。一个 pilet 自带代码和资源可以注册页面、扩展其他 pilet 的扩展点并且完全按照自己团队的节奏来构建、测试和发布——不需要任何人动一下甚至重新部署外壳。如果这听起来像微前端那确实就是。Piral 是该领域最早的专门框架之一其核心理念是一个主框架通常是 React驱动外壳而单个 pilet 如果需要可以自由地引入完全不同的技术——Vue、Angular甚至一些短暂存在、为特定目的而写的方案。外壳不在乎。它只在乎契约。我之前写过一篇更详细的技术介绍如果你想深入了解可以读读Introduction to Microfrontends with Piral。这篇文章更多讲它从哪来、以及它如何成长。它真正的起点一家德国能源公司然后是 ZEISSPiral 不是作为让我们做个框架而诞生的。它是作为这次我们真的把这个客户门户做出来而诞生的。我当时刚完成一家德国大型能源公司智能家居门户的大规模重写。在那次项目中微服务支撑、松耦合前端的做法效果远超所有人的预期。后端团队早就出于自己的原因走了微服务路线——扩展性、所有权、独立的发布周期——而这些独立性一旦到达前端就被浪费了因为一切又被焊回一个共享代码库。所以我们没有这么做。多个团队可以独立交付而不互相踩脚——如果你曾在一个大型前端巨石应用里工作过、十几个团队同时往同一个App.tsx提交代码你就会知道这句话有多难得。后来我成了ZEISS蔡司一个新的数字客户门户的首席架构师——这是一家德国大公司而在此之前他们已经多年尝试、却始终没能做成这样类型的门户。不是没努力也不是缺少优秀工程师——让许多团队为一个连贯的面向客户的应用做贡献本来就是一个真正困难的组织和技术问题之前的尝试都撞上了同一堵墙一个每个团队都得碰、得协调、最终甚至不惜一切代价避免去碰的单一前端代码库。我注意到这与 RWE SmartHome 项目里刚刚成功过的做法有相似之处于是沿用了同一套思路微服务后端配上我们现在会称之为微前端的前端——尽管当时还没人这么叫这个词也还没进入日常用语。它奏效了。多个团队以真正称得上思维的速度在贡献而不是请再对你的分支 rebase 到共享前端仓库另外这是本周六个人动过的文件的合并冲突的速度。那时候最明显的问题就是为什么要为每个客户重新发明一遍为什么不把这种方法泛化成一个真正的框架命名并意外地预示了什么我在 2019 年 2 月加入了smapiot方向从第一天就明确了除了常规的咨询工作还要留出专门的时间来构建一个微前端框架。到 2019 年 3 月我们定下了一个名字PiralPortals that can go viral可以走红的门户的缩写。一年后名字里的viral以绝对没有人能预料到的方式应验了。我们现在还会提起这件事。我们在 2019 年 11 月的OReilly 柏林软件架构大会上正式发布了 Piral。事后看来那场大会是 OReilly 该系列的最后一场——疫情之后它再也没有恢复过至少据我所知是这样。所以 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 Federation2023 年 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再建一个接入它的新 piletnpx pilet new --source my-shell cd my-pilet npm start在 pilet 内部注册一个页面是这样的import { PiletApi } from my-shell; export function setup(piral: PiletApi) { piral.registerPage(/hello, () divHello 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 网络连接相关设置教程