总结 ​

微前端方案决策树 ​

微前端广义上来讲，是前端模块化的一种延伸概念。所以在做技术架构的时候，不需要刻意去造轮子，新项目不如用好现有的一些模块化的方案，老的项目也只是用微前端去过渡，终归还是要随着业务发展重构的

新项目选型 ​

• 如果前端资源足够，可以考虑BFF方案，在BFF上面可以做很多AOP。前端团队的水位高的话，SSR+CSR的混合框架也可以考虑。

• 迭代周期频繁、有成为巨石应用趋势的，可以先行开发，然后空闲时使用Monorepo做分包，一定时机下分仓，由多人维护

• 千人千面场景，运营资源多的时候，采用Module Federation模式去做会比较方便。或者简单一点用动态Script，然后服务端下发，客户端渲染。要注意技术栈收敛和解耦，不然到时候升级一次，要更新几百个组件。（别问我是怎么知道的）

旧项目改造 ​

• 技术栈已经统一的，这个时候，只需要做一些业务方面的改造，然后跟微服务对齐即可。至于框架，除了iframe相关方案，其余都可以。iframe方案会拖慢性能，有内存泄漏风险

• 技术栈比较杂，单实例无法覆盖所有场景的。此时使用wujie方案过渡，wujie方案虽然做了很多技术上面的优化，也解决了很多问题。但是我们在切换到微前端之后，还是要尽早启动重构项目，统一技术栈。解决问题最好的方法，就是解决提出问题的项目！

• 需要解决浏览器兼容相关问题的时候，可以考虑使用garfish，做了很多语法层面的兼容，使用的解决方案也是比较新的一套

• 长期维护项目。旧项目在微前端框架下已经跑起来了，这个时候我们要考虑是否要长期维护项目。需要有一个管理平台：

  • 前端的资源管理

  • 主应用的服务（鉴权、多语、客服等等）

  • html模板

  • 微应用和菜单映射关系

  • 埋点监控

  • ……

项目实践 ​

我这边的改造路径比较简单：技术栈统一 -> 微服务对齐 -> 接入统一网关 -> 路由统一成history -> 样式添加prefix -> 主应用公共服务模块开发 -> 应用生命周期处理兼容性问题 -> 管理平台发布

碎碎念 ​

干掉构建时，就没有这么多烦恼了！现代浏览器的标准推进有一个过程，无论是fetch、webcomponent、esm还是其他标准，都会越来越好用的！