从零实现一个微前端框架，前端项目的掌握能力。
微前端框架，包括应用开发，框架开发，后端服务，微前端发布平台。
微前端主要应用场景：PC端中后台
vue.jpg

微前端架构

  • 主应用，路由分发
    • 统一调度和管理子应用
    • 注册子应用，获取数据，例如菜单数据
  • 子应用
  • 后端服务和应用如何发布？
    • Node BFF；例如 midwayjs
  • 发布平台
    • cdn版本控制

微前端好处

  1. 技术栈无关，主框架不限制接入应用的技术栈
  2. 独立开发，独立部署
    1. BFF层提供微前端管理的能力，配置化的接入微前端体系
    2. 对接成本，学习成本
  3. 支持增量发布，渐进式重构
    1. 更多的应用场景，软件系统可以分成独立的部分，精心分解的领域
  4. 每个子应用可以独立运行，集成支持应用之间的隔离
  5. 研发体验一致
    1. UI 样式风格统一
    2. 开发模式复用，例如：apm 埋点，问题排查，前端监控上报
    3. 子项目相似的代码，相似的风格对后面 codereview 和维护会更方便
    4. 组件库的复用
      1. 基础组件，业务组件，工具函数可被复用

跨团队维护场景

跨团队维护场景，比如一个系统分多个子系统
每个子系统由不同的团队维护，可能跨部门团队、外包，甚至 ISV，技术栈上可以要求一致，
但发布节奏会不同，并且跨团队的沟通成本高，所以技术闭环是比较好的方式，每个子应用保留自己的测试、CI、构建、部署等流程。

每个子功能是一个文件，格式可以是 umd 或 amd，然后按需加载子功能的文件实现。这一类，可以归为运行时的插件系统。

微前端缺点

  1. 前端项目拆分太多，不好维护
  2. 一个功能拆分太细，导致跨越多个项目进行开发
  3. CSS样式冲突
  4. 集成难度高

首次加载

  1. 注册子应用
  2. 公共事件管理
  3. 异常捕获
  4. 全局状态管理

路由更新，子应用是否匹配当前的路由

  1. MATCH 路由匹配
    1. 加载子应用，卸载上一个子应用
    2. 执行，解析子应用
    3. 渲染子应用
  2. NoMatch
    1. return

主应用

  1. nav导航菜单
  2. header头部信息
  3. 面包屑导航
  4. 定制化主题

各个子项目之间是解耦的，独立开发和部署，相互没有影响；

微前端架构

  1. 应用之间的通信
  2. 子应用的注册
  3. 公共的样式，状态管理
  4. 沙箱隔离

  5. 异常的捕获

  6. 主应用控制路由匹配，和子应用加载

    1. 共享依赖加载
  7. 子应用做功能，并接入主应用，试下联动控制

image.png

main主应用

https://juejin.cn/post/6943763969576271879

  1. 注册子应用
  2. 加载，渲染子应用
    1. 将子应用渲染在固定的容器里面
    2. 异常的捕获和报错处理
  3. 路由更新匹配 rules，active
  4. 获取数据，鉴权处理
    1. 加载全局依赖
  5. 父子应用通信机制

如果不做按需加载，需要在主应用把所有子应用的 JS 和 CSS 都引入，
不仅是性能上的问题，JS 沙箱的方案会更加复杂，
CSS 隔离可能只能通过约定和 css modules 的方式实现，而无法处理通用的场景

子应用

  • 渲染页面
  • 监听通信，主应用传递的数据

服务端发布

  • eggjs跨域代理
  • 登录鉴权

SSO登录