微前端就是将前端应用分解成一些更小,更简单的,能够独立开发,测试,部署的小模块,而在用户看来仍然是一个整体的产品技术或者思想
主要特点是:
- - 耦合性低,更简单的代码库,让开发者编写更小,更简单,更容易的项目
- - 技术栈无关
- - 可以增量编译,支持渐进式重构,先让新旧代码并存,然后逐步转化旧代码
- - 每个子模块都具有独立开发,持续部署,独立运行,独立维护的能力
- - 单一职责,每个子项目只做和自己相关的业务工作,各子项目之间不存在依赖关系,保持隔离
优点
- - 兼容遗留系统
- - 与时俱进,不断引入优秀的新技术/新框架
- - 支持局部/增量升级, 避免每次发布都是全量来发布,牵一发而动全身,即使发布一个小模块,也可能导致项目垮掉
- - 代码简洁,解耦,更易维护
- - 子应用间可以自由拆分,组合
- - 与技术栈关联不大,各个子应用的开发团队可以采取熟悉的技术栈进行开发,降低开发时间和成本
- - 可以采用组件或者服务的方式进行团队间技术共享
- - 每个模块应用可以独立部署,独立运行,拥有故障隔离
缺点
- - 重复依赖: 由于应用独立开发,编译,会存在重复依赖的情况,导致不同应用重复下载相同依赖,额外增加流量和服务端压力
- - 团队之间容易分裂: 各团队只关注自己的业务或者平台功能,在面向用户的整体交付方面,会导致对用户的需求体现不敏感,响应不及时
- - 操作复杂: 开发体验不好,可能需要同时开启多个项目来获取完整的体验,跟踪和调试要跨全部系统
- - 性能处理的挑战性: 不同的实现方案,性能很难得到保障,例如 iframe方式,一个iframe等于打开1个新的网页，所有的JS/CSS全部加载1遍，内存会*2，无法释放
- - 拆分粒度越小,便意味着架构变得越复杂,维护成本高
- - 技术栈一旦多样化,就意味着技术栈混乱,系统变得更复杂,更难维护 - 管理版本复杂,依赖复杂
常见的微前端方案有哪些?
- 路由分发式: nginx代理转发,通过 路由在多个独立的前端应用之间跳转,一般是nginx之类的http服务器反向代理,或者框架自带路由解决
- iframe
- 前端微服务化
微前端架构有两种架构模式：
1.基座模式：通过⼀个主应⽤，来管理其它应⽤。设计难度⼩，⽅便实践，但是通⽤度低。
2.⾃组织模式：应⽤之间是平等的，不存在相互管理的模式。设计难度⼤，不⽅便实施，但是通⽤度⾼。
以上是学习微前端的笔记,后续会根据学习理解情况发各种方案的优缺点,和实际应用场景,应用拆分,qiankun.js学习与应用
