微前端架构思考：量化技术选型方案
一、背景
本文将讨论与明确如何度量前端领域中后台系统的微前端方案，目的在于对于长期迭代的项目在治理时，提供一种可量化的评估方式，得出系统是否需要采用微前端架构。并尝试回答以下问题：
- 系统是否需要引入微前端架构
- 系统是否需要进行拆分，以什么样的粒度拆分合理？
二、问题分析
2.1 概念
问题讨论之前首先进行概念拉齐
| 名词 | 说明 |
|---|---|
| SPA | Single Page Application, 单页面应用。由前端控制页面路由跳转与页面数据更新。 |
| MPA | Multi Page Applicaiton, 多页面应用。路由跳转时会跳转至另一个Web应用。 |
| Monorepo | 仓库组织形式，应用相关代码维护在一个共同的仓库，方便协作。 |
| Polyrepo | 仓库组织形式，应用相关代码维护在不同的仓库，彼此隔离。 |
| 微前端 | 一种架构模式，支持独立开发应用，在运行时组合，增强用户体验。 |
2.2 微前端定义
微前端是一种软件架构模式，在开发周期（开发、部署、运行、维护）中，不同的子应用互相独立，只有在运行时自动组装成一个完整的应用，从来带来较好的用户体验。
](url)
微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。
2.3 微前端要素识别
在前端领域，需要通过微前端构建解决问题的场景可以归为两类
- 现存多个子应用，需要进行融合。一般见于平台搭建、跨团队协作场景。
- 某个SPA应用发展为巨石应用，需进行治理，可采用微前端方案进行子应用拆分。
针对巨石应用拆分场景，通过对现有微前端技术选型方案的分析，可识别出微前端架构决策相关的要素如下表。
2.3 模型定义
将上述要素进行扩展，根据经验值设定决策选项与建议分数与权重，可以得到下表。
则模型的定义为：各权限点加权求和。
- 评分在50分以下，建议采用SPA架构；
- 50 ~ 80 分，可结合实际场景调研微前端架构，进一步分析收益；
- 80分以上，建议重点关注微前端架构，选取合适的微前端架构方案进行研发提效。
三、场景讨论
以某个在迭代的一个项目X为例，该项目在进行技术选型时，经过了几次技术决策，演进到了微前端 + polyRepo架构，应用之间的依赖通过npm包进行分享，此架构为后期维护带来了较高成本。
用上述评分模型对该项目的历史状况和现状进行分析后，得分为55，可得出结论，该系统目前并不完全适用于微前端场景。
基于该系统目前的开发、协作与维护情况，推演半年~1年后的得分约为70，可以评估系统采用演进路线1进行架构调整和演进，保留系统扩展性。
四、规划与展望
[模型优化] 目前该决策模型仅从经验值给出系统采用微前端建议指数(0~ 100)，还需大量的样本工程进行输入，对权重和计算方式进行持续优化。
[工程化] 可以通过合适的方式进行工程实现，如工具或插件快速对工程进行评估并给出合理建议，可以对系统进行更高效的决策和评估。
[架构建议] 根据该度量方案，若项目建议采用微前端方案，关于进一步的微前端框架选型、系统以什么样的粒度拆分合理等方案待进一步探索。
目前社区内部对微前端的讨论较多，在该网站上microfrontend.dev/ 有较为详尽的说明，也有评分和微前端架构选型方案可供大家参考，欢迎一起学习交流。
