微前端（2）基于实际业务的思考-previous

本篇是实际业务的思考，previous 代表选型前期，基于目前的框架使用和业务发展的预测，可能后期会推翻，暂时先做一个记录。

当前业务

用户管理系统（UMS）：用户管理、系统管理、菜单管理、权限管理、监控日志
产品追溯系统（PTS）：产品生命周期追溯、客户管理、产品管理
订单管理系统（OMS）：订单管理、对接出入库明细
出入库管理系统（WMS）：仓库管理、产品入库管理
质量管理系统（QDS）：竞品管理、产品对比、属性管理、运行环境管理、产品数据管理、标准体系、问题清单

当前框架

基于 Vue3 + Vite (库使用 Element Plus + Pinia) ，除 UMS 外基本样式统一（Navbar、Sidebar），组件基本保持一致。

主要痛点

  1. 目前不同项目采用手动替换文件，需要统一样式、共享组件、共享通用方法；
  2. 运行时构建时间过长；(初步估计为编译/转化文件过多导致)
  3. 基于 chrome ，暂时未使用 polyfill 之类的通用浏览器支持；
  4. PLCS 用户登录后，直接输入其他子系统 URL ，无法触发首次登录修改密码。（操作概率非常非常小）
  5. 子系统之间不方便横跳，因为子系统通过动态菜单获取本系统权限，无法得知其他系统权限，UMS 首页也仅可获知是否有子系统进入权限，无法细节到具体菜单权限。(来自用户需求，可通过教育用户解决)

思考

若使用微前端，需要对以下部分做一个抽离：

  1. src/assets 中公用images（logo, 404, icon）、公用css（ common, element-variables, transition, index部分）
  2. src/components 中 公用组件（Breadcrumb, Hamburger, File…）这部分内容应该是各个系统沉淀的，在业务发展过程中根据设计要求改写的组件，复用到其他系统
  3. config/axios 这部分待考量，因为涉及到实际业务改写。
  4. hooks/ 这部分还没有完善
  5. store/ 虽然代码差不多，感觉还是各个系统独立维护
  6. types/ 这里是自动导入的，不确定
  7. utils/ 部分公用工具逻辑需要
  8. views/layout 公用样式需要

公用部分应该在一个服务器的存储空间里，前端保持维护，运维定期备份。

需要实现（基于现有基础）

  1. UMS 负责整体布局、Navbar（导航可以在 Navbar 最左侧），登录页面等通用页面
  2. UMS 负责子应用的注册引入和管理
  3. 使用 common 公用方法库
  4. 使用 components 共用组件库

问题

  1. 分开打包时关于组件、样式的引用怎么写？项目中没找到报错？
  2. 先设计子系统和 UMS 通信，再考虑子系统之间通信？
  3. “UMS 作为基座，负责加载公用逻辑，其他子系统共享。”这样不就是 monorepo 形式？不方便让其他系统单独开发了。

10.8更新

若只把 UMS 作为一个框架，不考虑组件复用、样式复用问题，应该也可行。
UMS 顶部导航作为消息共享区域，用户信息、子系统访问权限、消息推送（若有）、文档等其他功能。
子系统只需要专注于主体部分，可能涉及子系统之间跳转（例如：根据订单号跳转到订单管理系统，前提是有权限）。

10.23更新

当前测试 ice 框架可实现最基本需求，若进一步修改，涉及以下部分：
UMS：

  1. Navbar 中根据 URL 替换标题、图标（子系统的 Navbar 都需要在 UMS 中写一份）
  2. 判断是 UMS 本系统，渲染其他功能入口（首页、控制台、消息管理、操作日志、个人中心、修改密码）
  3. 设置共享状态（token、userInfo、sysAccess）
    子系统：
  4. 判断在当前系统中，渲染 Navbar（SimpleLayout/OtherLayout）
  5. 获取共享状态
    优化项：预加载
    需要保证：
  6. 单独系统按照之前模式可以正常运行
  7. 改造后不会引入新 bug
  8. 就只有最初简单的改造成本，后续开发成本不会增加
  9. 系统运行效率有一定提升（加分项）