满帮微前端

前言

大家好，我是王坤明，作为满帮集团微前端的发起和推动落地人来分享一下整个过程，为什么想分享一下这个过程，因为集团内开发Web项目的同学应该都在微前端基座上开发过自己的项目，享受着微前端项目开发带来的便利和约束。最近1年半新项目几乎都是微前端方案，微前端方案已经成为集团开发Web项目事实上的标准方案。一个方案从提出方案，落地实践，推广扩大，变成标准。整个过程和大家想想的不一样，没有所谓的有个架构师从一开始就整体的指明方向，更多的是我们本着贴合公司实际情况，解决实际问题，解决全局问题，还有公司的快速发展给整个方案带来的天时地利的环境，让这个方案更快的推动下去。希望通过这次的分享，让大家更贴合实际的感受在前方没有参考目标或者参考目标不适合我们时，如何找到最适合我们自己的路。

微前端提出它其实是一个类似后端微服务架构的概念，将 微服务 的概念扩展到了前端世界，简单理解就是将一个大型前端应用拆分为多个小型前端应用，这样每个小型前端应用都有自己的仓库，可以独立开发，部署，降低整个项目的复杂度。

在实际的发展过程中，因这几年前端技术快速发展，很多公司的项目都是既有jquery，又有vue或者react，如何让这些不同技术栈的项目能很好地融合在一起这成为很多公司更实际的需求，所以前端行业推出的比较知名微前端解决方案无论是Single-span ,qiankun，wujie 他们的重点都是如何让不同技术栈的项目融合在一起看着像一个项目，这些方案更多的精力就是在解决不同类型的项目融合在一起后如何进行项目之间的隔离，防止不同的技术栈融合在一起后带来的相互影响的问题，如下图。

满帮的集团的Web项目因为在最初项目大量爆发之前就提供了统一的项目摸版和脚手架，虽然创建了很多项目，但是每个项目基本上技术栈，项目结构，都是差不多的，所以满帮的Web项目历史负债相对较少，业界的微前端方案解决多个不同技术栈融合到一起的述求在公司没有太多团队有，所以虽然初期在微前端方案被业界提出的时候，公司内部个别团队在案这个方向探索，但是业界这套微前端方案最终没能在公司更广的铺开，核心还是没有足够的场景。

我们结合满帮集团项目的特点以及我们实际面对的要解决的问题，最终满帮微前端方案落地后的整体架构如下。

可以看到我们相比行业内的微前端架构在公共能力层做的更加的深入，这得益于满帮的Web项目较轻的历史负债，90%的项目的公共能力都是相同的，我们把这些相同的公共能力进行了剥离，独立成了一个基座项目，业务项目只保留业务逻辑代码，运行在统一的基座上，这就是满帮微前端整体的架构。通过这套方案让满帮Web项目在面对研发效率，性能体验，稳定性，持续性 几个方面做提升的时候能更好的面对。

研发效率方面

典型场景就是满帮Web项目有上千个，日常在迭代的也有好几百个，在没有微前端方案之前，如果要推动基础能力的改造，比如某个安全库的升级，或者某个埋点库的优化，需要上下协同所有业务部门，涉及到非常多的项目进行改造，升级，发布。一是时间周期长，二是容易有遗漏。而现在在满帮微前端架构基础上，由于基础能力都在一个独立的基座项目进行维护，那么这些基础的能力迭代对业务是基本无感的，业务专注做业务相关的需求，基础能力由Web基础团队独立负责。大大提高了基础能力的覆盖效率。

性能体验方面

一个Web项目打开最多的耗时就是基础能力的加载和执行占掉70%，在满帮现有的微前端架构上，由于所有业务项目依赖的基础能力相同，并且是一个独立的项目，我们可以通过提前运行这个项目，来减少用户在打开业务项目那一刻运行基础能力的时间。大大减少Web项目的开屏时间，满帮在App内的FCP值能做到300ms左右。

稳定性方面

基座配合配合客户端做了很多稳定性的提升，比如离线基座，加载重试等，这些能力我们通过基座对100%加载业务项目上也做了很多稳定性加强，比如业务资源多CDN容灾，离线缓存，加载或执行失败后的错误兜底，自动修护，灰度发布等。让Web项目白屏率能像0.001%靠齐，并且Web项目的故障率也能保持很低的水平。

持续性方面

伴随着2021年公司快速发展，人员快速壮大，新的人有新的想法，带来了很多推翻重做的项目，在这个背景下，2022年开始Web基础组在考虑所做的事的时候会优先考虑持续性，做有生命的产品而不是项目。微前端的架构下，因为所有项目有统一的基座，我们通过基座的集中管控上层所有项目，基座定好上层业务必须要满足的规则，包括但不限于依赖组件，项目结构，优化方案等。确保就算没有现在的Web基础组，公司的Web项目也能按这个规则持续下去，做到真正的完成落地。

满帮微前端发展过程

回顾过去几年年我们是怎么一步一步变成这样的架构，现在回想起来主要是通过解决两个核心的问题，一步步提出

微前端架构雏形提出

满帮微前端架构雏形提出和业界微前端解决的问题不一样，并不是解决项目太大要进行拆分，也不是解决多个技术栈要融合到一起，而是为了解决移动端体验问题。时间回到2020年8月份，在这个时间之前对于Web基础团队做了很多Web项目的优化手段，从最开始的雅虎35条前端优化军规到H5打包预渲染，再到App离线Web项目，除了通过SSR直出外(直出在满帮当时不是研发效率最高的方式，所以没考虑这个方向)，其他的优化方案都上了，但是最终FCP的值还是只能做到1.5到2s左右。当时每天都定这个这个统计数据看。

上图是我们的web项目在android平台的一个FCP的时间平均值分布图，核心四部分

html加载600ms(蓝线)，
js资源加载400ms(橙线)，
公共逻辑和页面执行800ms(绿线)，
页面资源加载执行预估200ms。

我们如果想进一步优化，我们想着要做到极致，那就只能把除了业务逻辑之外的内容全部提前运行，结合以前积累的一些优化方式，以及满帮已有Web项目的特点（基础能力基本无差别），我们不仅仅需要提前启动一个webview容器，还得把一个项目基础的能力都提前运行起来。这样通过空间换时间的方式，在业务页面打开的时候，使用已经执行基座的webview容器来加载业务代码运行渲染页面，这样大大加快页面打开速度。

按这个想法我们需要进行web端项目和native项目进行改造

web端改造

上面是改造之前3个前端项目打包后的产物，包含html入口文件，公共的资源库，以及每个页面的js逻辑代码。如果一个公司里面按照公司的标准规范统一创建的项目，那么大多项目引入的公共资源库在每个项目里面都是一样的。既然每个项目依赖的公共资源都一样，那我们是否可以想个办法把公共的东西当作一个项目，这个项目根据url的信息，动态加载对应url页面的js来运行，最终渲染页面，按这个想法我们调整了一下架构如下图。

可以看到我们把公共的依赖资源抽离成一个单独的项目，暂且叫做微前端框架。通过 static.ymm56.com/microweb 可以进行访问。社区项目的某个页面可以通过如下链接进行访问 static.ymm56.com/microweb/#/...

可以看到我们把具体项目的路由信息放到hash后面（你完全可以定义自己的规则不使用hash）。微前端框架通过获取hash值，分析出是social项目的D页面。然后通过动态加载D页面的逻辑js。执行并创建页面，最终渲染。

经过上面的调整，我们统一了所有前端项目的公共库，集中到了一个项目里面进行维护。这一步统一后我们就好去提前加载微前端框架项目并执行这些公共逻辑了。要知道基础框架初始化这个过程占了项目的90%时间，这个时间节省下来了，那200ms打开就不是问题了。

接下来需要app启动后预先加载一个webview。这个webview会直接加载微前端框架项目，当app被告知要打开一个h5页面。判断端该h5页面是否支持微前端，支持的话，就给预加载的这个微前端框架发一个消息告诉他加载这个页面，并让这个预加载的webview显示。

整个流程用户感知到的时间只有加载页面的js，直接执行。体验上是非常快的。

有想法了。接下来就是找客户端兄弟配合做细节完善了。走找客户端兄弟去。

客户端改造

客户端要做的事不复杂，直接上图，主要关注的问题如下

如何区分一个链接是微前端的，还是非微前端的（可以自行通过url域名等信息定好规则）非微前端的项目还是走老的流程直接打开页面，微前端的项目则是给预加载好的webview发消息，并显示出来。
如何判断一个微前端框架已经加载好了，因为微前端项目最终需要接受容器的消息去加载一个页面的js，如果发消息之前微前端的容器还没加载好，那么收到这个消息也是没用的，所以一定需要微前端基础框架加载好后通知客户端，容器已经准备好了。
如果加载一个微前端页面的时候，容器还没初始化好。那就直接打开该页面。不用走微前端的形式打开
可以自行做队列控制最大初始化微前端容器的数量，来提供微前端的命中率。

具体我们内部的流程如下。

App启动就初始化一个微前端容器，容器的html加载完，并且js逻辑执行完后会告诉客户端该微前端容器可用了。这个时候如果App接收到打开一个微前端页面，那么客户端会进过一系列逻辑判断后，给微前端容器发送打开的url信息，并把该微前端容器显示出来。

该微前端框架项目收到客户端的url后，解析url里面的hash，判断是打开什么项目的什么页面，然后在配置里面去加载该页面的js，加载完后执行，并渲染页面，当一个微前端容器使用后又接着初始化一个微前端容器，方便下次使用。

最终收益

热门活动页面打开的效果图（测试机型小米6 普通机器）

一个是微前端方式打开（除了页面过渡，以及数据loading之外，页面基本150ms就打开）
一个是不使用微前端方式（明显能加载过程中的白屏，以及进度条，在页面缓存过后打开时间也差不多在1.2s左右）

在2021年3月我们通过已有的效果推动了公司的7-8个核心项目按这套方案进行了适配，整体的效果在Web前端团队内部还是比较认可的，除了对项目的改造有一些成本外，其他的评价都是比较正向的，这就是满帮微前端架构的雏形形成，叫做满帮微前端方案名字是并不是很贴切，但是又没有更合适的名字了，也就没过于纠结，就叫满帮微前端了。

艰难成为标准

在2021年3月后一方面继续完善微前端方案，一方面推动更多项目接入，虽然陆陆续续有新的项目接入微前端方案，但是微前端的项目占比一直维持在5%左右，只有1/4的团队了解和使用了微前端方案，无法成为事实上的标准。回头看主要原因是迁移存在成本，业务团队效率优先，无法强力约束

迁移成本

微前端和普通项目存在差异，老项目的迁移成本取决于和微前端基座差别的大小，伴随着满帮融合，以及大多项目在业务团队后，每个项目发展节奏不一致带来和很多差异，这些差异和基础的项目随着这几年积累越来越大，这导致了能平滑迁移的项目很少，大多项目迁移差不多就是新开发。所以这套方案也是更适合新项目的优先选择，老项目基本上就没怎么迁移了

业务团队效率优先

对于2021年虽然体验在一些团队会优先考虑，但是大多团队第一优先级还是确保业务的完成，对Web项目体验会相对原生有差异也是共识的，都是一些非核心场景使用H5选型，所以对于H5的体验不是第一优先级考虑的。这也导致在和业务方商量迁移老项目的时候业务方大多都会因为迁移后涉及到的功能回归对研发，测试都是有很大的投入，而这些投入目前无法满足业务需求从而无限的推迟。

无法强力约束

在2021年整个前端行业还处于发展阶段，很多新技术出现，很多新组件出现，尽管每个团队的成员不同，但是他们都想着是在项目中尝试新的技术来解决自己团队的问题，而作为Web基础也没能找到一种能实际约束和规范各个业务项目的发展方向，虽然尝试过定规范，提供脚手架，统一摸版等等手段，但项目一旦到了业务团队，在不断地处理各种业务的实际问题过程中，项目就和原来的摸版慢慢有了差异。还有一个和公司发展阶段相关事件导致了这件事纯技术侧很难统一，那就是在2021年中，公司人员规模快速扩张加入很多人员，每个人员都希望做出不一样的东西，很多需求明确就要求不要和别的系统一样，各自为阵，不会第一优先考虑是否能复用，这也导致了出了很多新东西。

正是因为这些原因，虽然能微前端方案能带来Web页面的秒开体验，但是那个时间阶段秒开这件事并不是每个团队都优先考虑的，接入的动力一直不足，这个不温不火的状态一致维持了一年多。

转折点在2023年1月，几年快速的割裂的发展，大前端产生了很多相似的东西，比如App页面技术选型有原生，ReactNative，Flutter，Thresh,Web。很多一线研发非常痛苦，团队效率低，恰逢在这个时间点满帮大前端为了解决前端研发技术栈碎片化问题确定了未来大前端整体的架构方向如下图。这次确定了未来前端的项目一次编写，多平台输出，确定了App端内页面高性能的Thresh，以及非核心场景的H5技术栈，并且最为重要的就是这里的H5默认就是微前端。

在这大方针确定下，加之配合强力的项目准入申请制度，确保新的项目全部的按统一标准来，同时微前项目因为又在统一的基座上运行，进一步的加强了项目到业务团队后还能按照统一的标准发展，降低未来割裂的速度，回头看这件事的最终落地除了我们有不断的技术追求外，还需要贴合公司的发展阶段，快速发展阶段鼓励创新推动统一那就逆流而上，稳定阶段重视效率推动统一那感觉就是顺水推舟。

解决中后台研发效率问题

经过2022年一年的时间，对于移动端的项目基本上已经确定未来最佳实践的方式，这个时候回看PC端的项目，还有很多需要优化的空间。 2023年2月我们在做年度规划的时候定的大方向就是要解决中后台研发效率的问题。那时候中后台面临两个主要的效率问题，规范无法统一和基础能力覆盖慢

规范无法统一

团队内部每次讨论结论都是要提效，首先的统一规范，虽然这几年一直在尝试统一规范，但在实际过程中发现很难推动，很多时候不仅仅是技术上的问题，更多的是因为公司在高速发展过程中，处于其中的人或者系统各自有不同的惯性，时间会慢慢放大这些系统和人的差异，如果没有很好地机制来调节各个系统的惯性，那么在时间的积累过程中所有系统就会越来越难统一，比如我们经常提到的设计规范，编码规范，组件规范。

设计规范上每一位设计师都会有自己的标准，都会有自己的坚持，在满帮发展的几年中因为设计负责人的变动和业务团队设计师有自己的想法导致中后台的设计规范一致在变化，这种变化直接导致的就是中后台的体验样式等会按设计负责人的加带来明显的前后不一致，而这个不一致的差异会随着时间积累越来越大。
编码规范上一方面是前端行业还处于快速发展中，很多规范都不算是行业标准，很多是某个大公司的标准，更多的情况是每个公司每个阶段都有自己的标准，伴随着2015年到2022年前端行业也是快速发展的时间段，每年都有新的解决方案，这导致所在这个行业的前端研发在团队有新项目的时候控制不住的就想用行业新方案，站在个人或者小团队来说这没问题，能用新的技术快速解决问题，但是对于公司整体效率长远来看是留下了很多问题的。正是因为这几年每个团队都是这样才会导致公司几百个中后台项目很难在项目结构上，编码规范上进行统一。
组件规范上因为下层的编码规范，项目规范不一致，在不同项目中开发的组件依赖的环境不同，导致我们有很多组件，但是这些组件并不能在公司各个项目中平滑互通使用。

规范统一简单，我们只需要敲定一个规范后面按这个规范来就行，但是如何保障这个规范在未来可持续的统一需要我们更多的思考，我们需要一种能长期管控的方式，而不是简单的规范。

基础能力覆盖慢

2022年集团发展过程中做了很多埋点对齐，合规，风控，权限多方面的基础能力治理，这些治理过程中涉及到了公司全部的中后台系统，拿埋点库的升级来说，集团500多个项目依赖埋点库，日常使用的150个，每次埋点库的升级，功能的修改都需要联系同步所有后台的负责人，需要他们配合，可能需要调整，可能需要回归，一方面基础库负责人很难快速覆盖基础能力到各个系统，一方面业务放会觉得基础一直在调整，一直在升级，整体来说基础能力在那段时间的迭代推动过程效率很低。

我们思考很久得出这两个问题，核心是缺少长期可持续的集中控制机制。正是因为缺少这个机制，才会导致中后台在长时间的发展中每个中后台的步调不一致，慢慢的就会变得不统一，最终影响各方面的研发效率。我们希望有一个方式能否提供中后台长期可持续的集中控制机制，这个时候在移动端推动两年的满帮微前端方案已然成为我们的最佳选择。

满帮微前端最核心的部分就是有一个各个业务项目依赖的基座，业务专注业务逻辑开发，基座管理项目运行需要的基础能力的迭代更新，比如埋点，水印，安全相关，统计，组件，主题等。业务只使用基座提供的能力进行业务开发。

最终收益

在统一架构的基础上，我们能提效的方式就有更多了，比如提供一站式的中后台管理平台，从创建，准入，菜单权限，打包，发布等，以前需要多个平台完成，现在只需要一个地方就快速添加。又比如我们把中后台页面按难易程度进行分级，不同级别的页面有最高效率的开发方式，适合前端，以及后端，让更多的角色加入进来，让整个研发链路能提效。

中后台创建演示	L2简单逻辑开发	L3轻交互页面搭建
专业前端开发	非前端开发人员，选摸版，简单修改代码，快速上线	非开发人员，选摸版，简单配置，快速上线

截止2024年12月，整体的方案在线上已经运行了1年半，在中后台管理平台上又新建了200多个项目，未来还会有更多的项目，目前运行在基座上的中后台项目拥有很多以前很难想象的能力。典型的场景有如果未来有新的设计师进来有新的设计方案，那么只需要基座进行对接就好，业务项目无需任何投入，集团中后台主题算是做到真正的持久统一。再比如基础做的基础能力的升级可以快速覆盖到这200个项目上，以及我们定了一些检查规范可以约束或者告警业务的代码，是否有风险，最佳实践是什么，可以在开发过程中就能提示出来。减少上线后变成历史无法修护的问题。