前言
其实在小企业里，我对微前端的概念一直很模糊，接触不到，所以只是一种概念性的认知，在这里记录下最近看的一篇文章总结。
微前端架构：旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增加，从一个普通应用演变成一个巨石应用(Frontend Monolith)，随之而来的应用不可维护的问题。这类问题在企业级 Web 应用中尤为常见。
微前端要解决的问题
搞微前端目的就是要将产品原子化，由庞大的应用体系拆分为多个模块，再根据客户业务场景进行组合。每个功能模块能单独迭代，自由集成。
明确一点：
微前端不是框架，不是工具/库，而是一套架构体系，它包括若干库，工具，中心化的治理平台及相关配套设施
- 微前端包括3个部分：
- 微前端的基础设施，这是目前讨论最多的，一个微应用如何通过一个组件基座加载进来，脚手架工具，怎么单独构建和部署，怎么联调。
- 微前端配置中心：标准化的配置文件格式，支持灰度，回滚，红蓝，A/B等发布策略
- 微前端的可观察性工具：对于 任何分布式特点的架构，线上/线下治理都很重要。
具体要解决好的10个问题：
- 微应用的注册、异步加载和生命周期管理；
- 微应用之间、主从之间的消息机制；
- 微应用之间的安全隔离措施；
- 微应用的框架无关、版本无关；
- 微应用之间、主从之间的公共依赖的库、业务逻辑(utils)以及版本怎么管理；
- 微应用独立调试、和主应用联调的方式，快速定位报错（发射问题）；
- 微应用的发布流程；
- 微应用打包优化问题；
- 微应用专有云场景的出包方案；
- 渐进式升级：用微应用方案平滑重构老项目
基本原理
盗图如下：
传统项目管理工具通常是命令行工具，包括构建、发布、测试，会升级为项目工作台，通过 Web 界面管理项目。一个项目包括哪些微应用，版本，发布策略等在配置中心统一管理。一个大型应用被「碎片化」后，还要能做到「一目了然」。哪个模块报错，加载失败等异常发生第一时间反应在配置中心里
