月初做了一次微前端分享，讲稿摘录：
我们开始吧，今天聊一下微前端，从微前端概念及应用场景、五种实现方案及原理，总结规划三方面聊，希望大家有所收获。
1.微前端是一种类似后端微服务的架构，微服务是后端按功能纬度对服务再次拆分，然后在中间架设一些聚合层，比如说用到GraphQL/BFF做一些数据的聚合/网关的处理，交易服务/依赖管理/日志/监控/通信/运维等
2.微前端作为类似微服务的一种架构，是把单体的前端web应用也按照功能纬度做拆分，然后再聚合到一个整体的架构里面。什么样的业务背景会去做微前端这样一个技术架构，用起来又有什么好处？
3.微前端有两个核心的应用场景，一个是体验纬度，第二个是技术纬度，如果公司有很多系统平台，有的操作流程可能涉及多个系统，像活动页面/可配置的系统，在使用多个系统操作的时候容易遇到一些痛点：体验不一致，UI不一致，更甚者要经过不同的BFF层和网关处理，这一块可能有重复建设和不可管理的因素，就有需求搞一个全局管理的平台，它能囊括所有的平台。
4.第二个场景，系统非常大的时候，比如我们的bmo系统，安装包有2.7G，依赖关系错综复杂，技术版本和编码方式多样化，构建时间长，影响开发效率，比较核心的问题：涉及业务迭代、技术架构升级和协作的成本都很高，因为不清楚改了一些功能或者改了一个样式会对其他页面发生什么样的影响，再就是如果想接入二方的需求，基本是往我们的巨石系统添加代码。
5.综合这两种场景，我们更多希望有一套合适的架构，建立一个体验比较良好，能够持续去维护的一套系统，基于这样的诉求我们有哪些方案可以去考虑？在介绍方案之前，我们再看一下微前端的开发特性和应用效果
6.微前端开发特性
技术无关：各个开发团队自行选择技术栈，不受同一项目其他团队影响
代码独立：各个交付产物都可以被独立使用，避免和其他交付产物耦合
样式隔离：各个交付产物样式不会污染到其他组件
原生支持：各个交付产物都可以自由使用浏览器原生api
7.iframe存在的问题
iframe嵌入的显示大小不可控
Bfcachel url记录无效，页面刷新不能够被记忆，刷新返回首页
兼容性 样式显示兼容有局限
性能开销 iframe阻塞onload，占用连接池，多层嵌套页面崩溃
这些特性首先想到Iframe，它都满足，微前端其实就是把很多业务组件整合到一块，，之前我们接入三方需求，广告位/系统/服务都是使用iframe，ifame就是一个微前端，但是它存在一些问题，像性能开销和bfc（往返缓存Back/Forward cacel）都优化不了，bfc它只对浏览器地址栏生效，iframe里的操作它记录不到，性能开销也优化不了，引用iframe页面必须得去加载资源。
8.微前端具体开发要解决好的10个问题
微应用的注册、异步加载和生命周期管理
微应用主从之间的消息机制
微应用之间的隔离措施
微应用的框架无关、版本无关
微应用主从之间的公共依赖库，业务逻辑（utils）以及版本怎么管理
微应用独立调试、和主应用联调的方式，快速定位报错
微应用的发布流程
微应用打包优化问题
微应用专有云场景的出包方案
微应用平滑重构老项目
9.应用微前端的效果
（这里几张打包优化截图）
10.这样我们对微前端概念，它的业务背景，它的开发特性有基本了解，我们继续看市面有哪些微前端技术解决方案，我合计下来有五种技术解决方案
1.Mpa 老式过程， 用yog2框架分治思想，每个子应用自己做自己的事情，外面最后有一个总的集成，需要的时候及时把server和client复制过来
2.Spa 基于路由分发，由一个基座路由监听路由，通过路由规则加载不同的应用，实现应用间的解耦，然后它不能对外暴露，所有的webpack自己管理，在路由通过SystemJs引入，就是引入一个独立的js文件
3.框架 蚂蚁金服出的qiankun，阿里淘系的icestack，阿里今年4月份出的satumjs，它们基于spa路由分发模式，做了各种封装。
我们拿qiankun举例，qiankun对singspa做了封装，最核心的就是自己实现了一个沙箱，它把整个项目搂过来，把子应用的整个路由拽过来，就像iframe一样，然后它的状态管理用qiankun的来实现主从应用互通
（这里qiankun代码配置截图）
然后这里有沙箱实现的案例和源码
4.Webpack5 自带的module fedetation，原理是在配置里引入ModuleFederationPlugin插件，然后对主/子应用的webpackconfig进行配置
相关的框架有百度YY语音团队做的Emp，铃盛的fronts，github上能搜到相关的开源代码。它仓库里的wiki有相关教程的文档，这里搞了一个手写案例
（案例配置截图，配置介绍）
5.Webcomponent 是面向未来，也是微前端技术方案的终极形态，它已经跟早期的框架无关了，是全程自带沙箱的原生api 没有编译，速度快，用的时候link import的引入进来，应用案例像github，youtube国外的网站用的全是webcomponent，国内相关文档和生态也正在建设，像腾讯的omi，字节的magic，这个带来的可能是前端技术上的变革，返璞归真，让前端重新回归类似jquery调用的年代，现有的前端技术像babel、webpack、vue、react都变成过客（这里搬老袁的预言）
（这里有一个webcomponent的小案例）
11.总结规划
讲了那么多方案，到底能不能解决最开始业务背景提到的问题，我们回顾一下两种场景遇到的问题，大型应用接入二方需求时，开发效率低，技术栈升级/迁移/维护成本高，通过微前端的改造，按照功能纬度一个个拆分之后，使得我们的业务可以不断扩展
总结来说虽然微前端技术形态有很多，它做的事还是一样的，如果项目用到webpack5，那就用module federation，用emp框架，如果想快速使用那就用qiankun，如果追求技术、拥抱未来，用webcomponent
规划方面，我们的业务使用哪一种技术方案，说实在的我也在整理、探索，因为每一个技术方案，它应该基于现有的业务，然后慢慢扩展。老板可能不太关注我们用什么技术，更关注结果，关注我们有没有给他带来效益，所以有必要理清现有的项目和业务，理清要做哪些技术沉淀
微前端我觉得它把一个项目搞复杂了，不是那么必要的事情，像现有的开发模式，做私仓，做公司的组件库，规范书写和使用文档，谁要用的时候引进来，也是可以的。
再就是我们选用的技术方案，要有明确的架构说明，业务场景说明，使用和开发注意事项。业务复杂度/维护性的问题。
相关的文档和案例会进行共享，希望这次分享能起到抛砖引玉的作用
谢谢大家
评论区