跳至主要內容

微前端实践梳理

Cap原创大约 4 分钟

使用微前端的背景

随着公司业务发展，对患者也好，对医院也好，运营层面需要越来越多的手段去展开工作。对应的就是需要越来越多的管理后台去承载这些工作。

问题一

每一个业务后台需要一个账号，对使用者来说增加的就是人力成本和管理成本；对研发来说，增加的就是研发成本。

问题二

除了基于一条业务线去划分一个管理后台，会造成管理后台数量的增多。一些小的运营模块也需要有一两个页面去承载，比如活动/财务/售后，如果不断将这些小模块集成到已有的管理后台工程中，可预见的就是不断臃肿的巨石应用的应运而生。

基于以上两个问题的背景，拆分应用，独立部署，最小化开发，是我们期望解决的方向，微前端作为一种行业的解决方案，也就自然而然的被我们提上日程。

微前端选型

纵览微前端的实现方案，可以归纳为以下几种

  1. single-spaopen in new window
  2. 阿里qiankunopen in new window
  3. 腾讯wujieopen in new window
  4. 京东micro-appopen in new window
  5. 字节Garfishopen in new window
  6. 根据公司自身情况，自己设计的微前端方案（微前端在美团外卖的实践open in new window）
  7. 模块联邦的形式（定制化）

选择那种，无非就是根据我们当前情况，做出最优解。

第一步

首先，基于人力成本和技术积累的角度来说，排除舍弃了定制化的方向。如果采用6，7的这种方案，好处不用说，完全贴合当前前端架构，但短期内无法解决的问题就是：

  1. 我们的前端人力不太够，不能在这方面投入更多的精力

  2. 我们前端团队的技能积累还支撑不了，遇到卡点问题的快速解决能力

第二步

接下来我们就是看一些框架的选择。主要是从以下几个维度去打分

  1. 接入学习成本

    接入学习成本，决定了我们会在这个事情上的投入产出时间。这点需要我们去看官方文档

  2. 对当前我们已有前端工程的友好度

    对已有工程的友好度，决定了我们的兼容成本和能否解决我们的问题，这点需要我们剖析当前架构和了解框架的实现原理

  3. 社区的活跃度

    社区的活跃度，决定了我们遇到问题时的解决手段是否多

基于以上三个大点的结论，基本能引导我们该使用那种框架。
最后我们选择了micro-app

  1. 组件形式接入，心智负担小
  2. 基于类webcomponents+iframe实现
  3. 社区活跃

微前端架构设计

选定框架后，要做的就是落地到我们的业务形态中。不同的公司实际情况肯定不一致，我们根据以下几点去思考方案，基本能覆盖成功落地的点。

代码仓库的管理

这里我们需要考虑的是如何管理各个父子应用,有以下几种途径

  1. Submodules
  2. monorepo
  3. 维持现状，独立工程

本地开发调试

这里我们需要考虑，开发人员如何快速便捷的本地开发调试

部署方案

这里我们需要考虑，如何接入CICD，保证父子应用的更新

监控方案

这里我们需要考虑，如何快速定位问题

落地过程中遇到的问题

主要是一些兼容隔离的问题，例如

  1. 样式没有做到全隔离
  2. 富文本编辑器的问题

目前还存在的问题

  1. 本地开发调试还需要进一步优化，降低心智负担。