系统的组织在不断变化的同时，其设计和架构也在不断地调整。
如同数据库的分库分表一样，既然一个组织的部门已经过于庞大，就进一步将它细化。
软件的不同部分又被拆分到不同的部门之下。
随着不同部门的业务发展，技术栈越来越难统一，出现了多样化。
在走向多样化后，用户越来越厌倦一家公司的应用软件分散在多个不同应用上。
应用的获客成本越来越高，应用又一次走向聚合。
在分离了前后端之后，拆分降低了系统的复杂度，并进一步提高了软件的开发效率。
随着业务不断扩张，需求也不断扩张，应用又开始变得臃肿。
既然应用变大了，我们就继续往下拆分，拆分成更小的单位。
-----摘选自《前端架构 从入门到微前端》
“任何物体在没有接受外界能量的条件下，总是朝着熵增（无序）的方向变化。”
分库分表，前后端分离，聚合，拆分到粒度更小的单位等软件架构解决方案，解决的核心问题是，熵减。
应用臃肿，管理成本增加，获客成本增加，组织臃肿等表现形式，表现形式的本质是，熵增。
总的来说，“微前端”这个名词，以及它所带来的一系列策略。都是为了解决软件和组织在某一阶段的，熵增的问题。
一、微前端架构
特点
- 应用自治
- 单一职责
- 技术栈无关
为什么需要
- 遗留系统迁移
- 后端解耦，前端聚合
- 热闹驱动开发
技术拆分方式
- 路由分发式
- 前端微服务化。不同框架之上设计通信和加载机制，以在一个页面内加载对应应用。
- 微应用。软件工程方式，在部署构建环境中，把多个独立的应用组合成一个单体应用。
- 微件化。开发一个新的构建系统，将部分业务功能构建成一个独立的chunk代码，使用时只需远程加载。
- 前端容器化。将iframe作为容器来容纳其他前端应用。
- 应用组件化内。借助Web Components技术，来构建跨框架的前端应用。
说明：
①微件（Widget），flutter框架作为移动端的解决方案，就是微件化的实践之一。
②Web component技术的推广受限于浏览器的支持程度。
微前端架构设计
- 组件与模式库
- 应用通信机制
- 数据共享机制
- 专用的构建系统（可选）
架构模式
- 基座模式
- 自组织模式
设计理念
- 中心化：应用注册表
- 标识化应用
- 应用生命周期管理（微前端框架Single-SPA的基本生命周期，load->bootstrap->mount->unload->unmount）
- 高内聚，低耦合
微架构
- 后端拆分。微服务。
- App拆分。App存在多种容器，有插件化、组件化、小程序等不同的方案。
- 前端拆分。前端微服务、微应用化、微件化等。（前端走向微前端架构的原因，除了庞大的单体应用，还有一部分是要聚合旧的遗留系统）
二、实战篇-前端微服务化
缘起：
- 注册表。应用可以自动加载、运行，并能够与应用注册表进行联系
- 完全隔离。每个应用的开发是完全隔离的，开发时互不影响。它可以接入某个框架，以更好地支持构建
适用性：
- 应用地挂载DOM节点
- 应用的服务地址
- 应用的唯一标识符
- 应用的名称
- 应用所需要加载的脚本文件
设计方案：
- 通用型微前端方案 Single-SPA
- 定制型微前端方案 Mooa
说明：
①Single-SPA官网https://single-spa.js.org/docs/examples/
②Single-SPA参考GitHub-https://github.com/single-spa/single-spa