什么是微前端？
微前端（Micro-Frontends）是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用还可以独立运行、独立开发、独立部署。微前端不是单纯的前端框架或者工具，而是一套架构体系
可以由多个团队独立开发的现代web应用程序的技术、策略和方案。
可以跟微服务这么对比着去理解：
| 微服务 | 微前端 | 一个微服务就是由一组接口构成，接口地址一般是 URL。当微服务收到一个接口的请求时，会进行路由找到相应的逻辑，输出响应内容。 | 一个微前端则是由一组页面构成，页面地址也是 URL。当微前端收到一个页面 URL 的请求时，会进行路由找到相应的组件，渲染页面内容。 | 后端微服务会有一个网关，作为单一入口接收所有的客户端接口请求，根据接口 URL 与服务的匹配关系，路由到对应的服务。 | 微前端则会有一个加载器，作为单一入口接收所有页面 URL 的访问，根据页面 URL 与微前端的匹配关系，选择加载对应的微前端，由该微前端进行进行路由响应 URL。 |
|---|
微前端的价值
微前端架构具备以下几个核心价值：
技术栈无关：主框架不限制接入应用的技术栈，子应用具备完全自主权
独立开发、独立部署：子应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
独立运行时：每个子应用之间状态隔离，运行时状态不共享
微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用( Frontend Monolith )后，随之而来的应用不可维护的问题。这类问题在企业级 Web 应用中尤其常见。
实现微前端有哪些方案
- iframe
Web Components
ESM
single-spa、qiankun
EMP
- 各解决方案的利弊：
-
iframe可以直接加载其他应用，但无法做到单页导致许多功能无法正常在主应用中展示。
-
web Components
- 技术栈无关：Web Components是浏览器原生组件，那即是在任何框架中都可以使用。
- 独立开发：使用Web Components开发的应用无需与其他应用间产生任何关联。
- 应用间隔离： Shadow DOM的特性，各个引入的微应用间可以达到相互隔离的效果。
-
ESM
- 无技术栈限制：ESM加载的只是js内容，无论哪个框架，最终都要编译成js，因此，无论哪种框架，ESM都能加载。
- 应用单独开发： ESM只是js的一种规范，不会影响应用的开发模式。
- 多应用整合： 只要将微应用以ESM的方式暴露出来，就能正常加载。
- 远程加载模块: ESM能够直接请求cdn资源，这是它与生俱来的能力。
-
single-spa、qiankun基本上可以称为单页版的iframe，具有沙箱隔离及资源预加载的特点，几乎无可挑剔。但可能存在以下几点不足：
- 对于React 深度定制项目来说，无法做到状态管理很好的传递
- 对于非标准的AMD、UMD、SystemJS 等加载方式的库会存在依赖问题(需要针对性改造)
- 多框架实现体积过大以及存在一定的调试成本
-
EMP作为最年轻微前端解决方案，也是吸收了许多web优秀特性才诞生的，它在实现微前端的基础上，扩充了跨应用状态共享、跨框架组件调用、远程拉取ts声明文件、动态更新微应用等能力。同时，细心的小伙伴应该已经发现，EMP能做到第三方依赖的共享，使代码尽可能地重复利用，减少加载的内容。
以下表格为各解决方案的总结:
| 方案 | 描述 | 缺点 | iframe | 天生隔离样式与脚本、多页 | 不是单页应用，会导致浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用 弹框类的功能无法应用到整个大应用中，只能在对应的窗口内展示 由于可能应用间不是在相同的域内，主应用的 cookie 要透传到根域名都不同的子应中才能实现免登录效果 每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程，占用大量资源的同时也在极大地消耗资源 iframe的特性导致搜索引擎无法获取到其中的内容，进而无法实现应用的seo 常见问题FAQ
如需帝国cms功能定制以及二次开发请联系我们联系作者
请选择支付方式×
×
|
|---|
发表评论
还没有评论，快来抢沙发吧！