了解一下微前端

微前端不知道什么时候开始变得非常火，结合后台的微服务，可以把一个系统切分为一个个子模块。比如用户模块、权限模块、订单模块等，每一个模块可以单独开发、测试、部署，每个模块还可以使用不同的技术，最后通过主应用加载这些模块。

其实这样看起来，微前端有点类似ifram，或者直接一个超链接跳转就可以实现。确实，微前端类似这样的场景。但是一些场景下用户体验很差，比如每个应用的路由无法记录，应用之间的通信也不方便。

微前端每个模块都是一个子应用，主应用和子应用完全解耦，一个庞大的项目只是修改某一个很小的bug的时候，就不需要整改项目重新打包部署，只需要把项目拆分一个个子应用，然后修改打包部署子应用，主应用运行时动态加载，中间通过协议接入，子应用打包的时候通过导出方法供主应用调用去通信、加载。

早期的微前端解决方案是Single-SPA，核心是实现了路由劫持和应用加载，但是内部的样式和js没有做到隔离，出现冲突。而基于Single-SPA的qiankun，应该是目前落地微前端的主要选择，解决了Single-SPA的痛点。类似的还有Piral、Luigi等。Qiankun开箱即用，非常简单的实现了微前端。

如果使用Single-SPA，比如vue可以使用single-spa-vue，react可以使用single-spa-react。内部已经帮我们实现服务注册、事件监听、子父组件通信等功能，最后打包出一个个lib子应用类库供主应用加载。如果使用qiankun，直接自己暴露三个方法就可以。

目前已经越来越多企业开始使用微前端，但是使用微前端也是要结合项目衡量。当以前遗留下的项目技术栈不同、项目庞大，希望每个模块可以独立开发独立部署、有一些老项目很稳定了，不希望进行重构等，反正是要根据实际情况去分析是否利大于弊，才去选择落地微前端。

（完）