微前端

[MrZWH]

微前端概念解读

https://micro-frontends.org

微前端开发的特性

• 技术无关：各个开发团队都可以自行选择技术栈，不受同一项目中其他团队影响
• 业务独立：各个交付产物都可以被独立使用，避免和其他交付产物耦合
• 样式隔离：各个交付产物中的样式不会污染到其他组件
• 原生支持：各个交付产物都有自由使用浏览器原生API，而非要求使用封装后的API

微服务平台和微前端对比

	微服务	微前端	备注
服务	独立服务，比如交易服务	应用或者模块，比如导航	服务是不会相互影响的
服务治理	服务注册/发现/依赖管理/跟踪/降级/限流/日志/监控/运维等	应用的发现/路由/监控/降级/运行/注销/聚合 等	需要一个/多个系统统一处理一些上层的事情
服务通信	HTTP/RPC/中间件	eventBus/sharedWorker/BroadcastChannel/LocalStorge

应用场景

常见的实现方案

拆分和聚合

常见的方式

• 大仓库拆分独立的模块，统一构建
• 大仓库通过 monorepo methodology 做成npm包，集成主项目
• 大仓库拆分子仓库，构建应用出独立的服务/应用
• 大仓库拆分多仓库，构建后集成到主应用

常见的技术方案

• 通过 IFrame 方式进行聚合
• 使用 WebComponent 构建应用
• 在不同的框架之上设计通讯、加载机制，注入 Single-SPA

iframe 现存的问题

• 不可控制：iframe嵌入的显示区大小不容易控制，存在一定局限性（目前来说不算问题）
• bfcache！：URL 的记录完全无效，页面刷新不能够被记忆，刷新会返回首页，iframe功能之间跳转也无效（目前来说不算问题）
• 兼容性坑：iframe的样式显示，兼容性等都具有局限性
• 性能开销：iframe 阻塞 onload、占用连接池、多层嵌套页面崩溃

iframe 的优势

• 改造成本低，可以快速上线
• 沙盒模型，各个模块天然隔离，不需要考虑样式污染，应用之间的相互影响

webcomponents

single-SPA

微前端解决了什么问题

• 解决应用越来越大，维护成本高的问题

主要体现在

• 代码复杂度不可控，多人协作带来的困难
• 模块容易相互影响，一个模块出错，往往导致另外模块出错
• 项目扩展性差，不利于横向扩展
• 无法独立部署，为什么需要独立部署
• 技术选型受限，真的必要吗？