首页 / m.itcdj.com / 正文

微前端不是前端界的拆积木游戏

上次跑南京的技术沙龙,散场通道里被三个不同团队的前端拉住吐槽。

说他们上线半年的微前端架构,现在比之前的老单体还难维护。

没人信。

毕竟当初拍板上微前端的时候,PPT里写的可是“独立发版、技术栈自由、团队解耦”的美好愿景。怎么才半年,就成了人人避之不及的烫手山芋。

最先掉的不是代码,是团队的边界感

很多团队第一次碰微前端,第一反应就是把代码仓库拆成好几个,主应用拉个壳,剩下的子应用各自部署,以为这样就算大功告成。

太天真了。

之前碰到个团队,主应用是跑了五年的Vue2老项目,拆出来三个子应用——一个用React18做的中后台模块,一个用Vue3写的用户中心,还有个常年靠外包维护的jQuery活动页。一开始确实爽,活动页想半夜上就半夜上,不用等整个前端团队的周度发版窗口。

麻烦是从第三周开始的。

React子应用的开发图方便,在window上挂了个叫userInfo的全局变量存当前登录态,刚好主应用的老代码里也有个同名变量,每次从主应用切到子应用,主应用的权限校验逻辑直接读错值,一半的人跳转到登录页。

更绝的是有个子应用的同学,为了临时调个侧边栏按钮的位置,直接改了主应用挂在全局的侧边栏样式类,改完自己模块看着没问题了,另外两个子应用的侧边栏全歪到屏幕外面。

微前端主应用子应用运行时加载流程图

没人提前定规则。

大家都默认“我的代码我做主”,忘了所有子应用最后都是跑在同一个浏览器页面里的,共享同一套DOM环境,同一个全局上下文。微前端从来不是技术选型的终点,是团队协作规则的起点。拆代码只需要半小时,定清楚全局变量的命名规范、样式隔离的边界、路由跳转的拦截逻辑,可能要花半个月。

很多人跳过了这步,直接把代码拆完上线,最后自然要为混乱的边界感买单。

算清楚隐形成本再谈收益

大部分团队算微前端的收益时,只会算看得见的部分——发版不用等了,技术栈可以随便选了,团队解耦了。

没人算那些藏在水下的成本。

主应用要做的事比之前多太多了。要写适配层兼容不同框架的子应用生命周期,要做沙箱隔离防止全局变量串味,要处理子应用的资源加载失败兜底,要拦截所有子应用的JS错误避免拖垮整个页面。光这套适配层的代码量,就够搭一个小型的内部管理系统了。

还有用户端的体验折损。

之前单体项目的页面跳转,就是本地路由切换,快到几乎感知不到延迟。现在切子应用,要先从服务器拉子应用的静态资源包,碰到网差的环境,白屏两三秒是常事。为了把这个白屏盖住,团队又得加骨架屏,加资源预加载策略,加子应用的加载进度条,又多了一堆需要维护的代码。

微前端样式隔离运行时沙箱原理示意图
微前端样式隔离运行时沙箱原理示意图

之前碰到个团队,当初上微前端的原因特别实在——两个前端团队要合并,原来的项目一个是Vue写的,一个是React写的,谁也不想重写自己写了两年的代码,就把微前端当和事佬拉出来,两边各占一半的主应用页面。

结果合并之后的半年,一半的前端人力都在处理两个框架的兼容问题,业务需求的迭代速度,比合并之前两个团队各干各的时候还慢。

真的,别把微前端当万能膏药,哪疼贴哪。

疼是暂时的。

等你贴完发现,膏药粘的地方连带着周围好皮肤都被扯得发红,原来的疼没好,又添了新的痒。

什么时候真的需要微前端

什么时候真的需要微前端
什么时候真的需要微前端

这事没那么玄。

不是所有项目都配得上微前端。

如果你的团队总共就三个前端,项目拢共十几个页面,代码仓库拉下来跑五分钟就能启动,改个按钮的提交当天就能上线,迭代节奏全团队都是同频的,那拆什么微前端?拆完之后维护适配层花的时间,都够你把单体项目的代码重构三遍了。

真正适合上微前端的场景其实特别窄。

比如你的项目已经大到单体仓库两个G,本地拉代码跑项目要二十分钟,改个小需求要等整个团队的月度发版窗口,不同业务线的迭代节奏完全错开——有的活动模块要一周更三次,有的基础功能模块三个月才发一次版,凑不到同一个发版时间点,每次发版都要互相等。这种时候,微前端的独立部署价值才真的能体现出来。

还有个常见的误区。

很多人觉得微前端就是后端微服务在前端的复刻,拆完之后每个子应用都是完全独立的,出问题了也不会影响别人。别闹。后端的微服务是跑在不同服务器上的,有独立的进程和内存,前端的微应用呢?拆得再开,最后也是塞在同一个浏览器页面里的一堆JS和CSS代码,共享同一个浏览器内存,同一个DOM树。没有绝对的隔离,所有的隔离效果,都是你写规则硬卡出来的。

真正适合上微前端的团队,一定是已经把单体项目的规则、权限、路由梳理得明明白白的。如果你自己的单体项目都是一团乱麻,全局变量满天飞,样式类名重名是常事,路由跳转连个统一的拦截逻辑都没有,那拆成微前端之后,这团乱麻只会变成好几个互相缠在一起的乱线团,理都理不清。

上次沙龙最后,那个一开始吐槽的前端哥们自己也说,他们团队拆了四个月的微前端,现在已经把最容易出问题的两个中后台子应用合回主仓库了,只留了两个迭代节奏完全错开的活动模块做独立部署。算下来,整体的维护成本比之前全拆的时候降了快一半。

你看,哪有什么一劳永逸的技术方案。

所有的技术选型,本质上都是在算取舍的账。你拿了独立发版的爽,就要付兼容隔离的累。没有谁对谁错,就看你付的成本,能不能换回来你想要的收益。