关于微前端的一些思考和总结
April 29, 2020
前言
微前端是最近几年在理论层面比较流行的一种说法, 意图将微服务的一套实践搬到前端来, 也是各个大公司在项目管理实践中总结出的方法论.
目的
微前端主要是应对大型项目在开发过程中所遇到的一些问题的一种方法论, 企图在前端中引入和微服务相似的架构, 来达到页面各个部分的开发, 技术栈, 迭代, 测试, 发布等各个环节的分离, 页面各个部分只通过暴露的接口来进行通信, 可以让前端项目以更小的划分来进行开发, 并且相互之间不会有任何影响.
挑战
在微前端的实践路上也有很多前所唯有的挑战, 和后端微服务不一样, 微服务在架构上是有现实映射支持的, 在前端浏览器, 则可能没有对应的映射, 实践的路上也是困难重重. 在这些问题可以划分几个更具体的问题: 代码分离和聚合, 公共资源共享, 独立样式, 应用间通信, 测试等.
在这里我列出几种方案, 以及他们的优缺点和解释这些方案是如何解决以上这些问题的. 不过同样地, 没有银弹.
iFrame.
iframe 作为一种成熟的标签在前端的很多地方, 及很早就开始应用. 传统而言, iframe 作为优秀的沙盒方案, 可以有效隔离全局变量, 样式, 路由等. 他可以很直观地分割一个页面中的两个应用, 完全可以独自架构, 测试, 上线. 但是同样地, 这个方案也有他致命的确定. iframe 运行在新的浏览器进程中致使他在很多方面都丧失灵活性. 例如应用之间的通信会变成进程间的通信, 这种消耗在某些情况下是不可以接受的.
具象问题
在架构微前端时虽然没办法测试方案是否完备, 但是如果你的微前端架构方案能回答出以下问题, 则方案相对健壮.
- 能否通过一个 url 链接, 从 app 的外部链接定位到当前页面的状态?
- 各个应用是否使用同一份格式化样式代码?