微前端
微前端是一种架构。主要讨论如何将网站或 Web 应用视为由独立团队拥有的功能组合。
简单讲，就是研究巨石应用的组织形态的拆分 以及 轻小应用在业务形态上的聚合。
需要明确的是，微前端不是一门具体的技术，而是整合了技术、策略和方法，可能会以脚手架、配套工具和规范约束等等成体系的形式综合呈现，是一种宏观上的架构。这种架构目前有多种方案，各有利弊。
拆分
为什么要拆分
开发效率。
- 应用自治
- 单一职责
- 技术栈无关（次要）
来源于软件功能的最大难题，即"扩展"。 软件开发的历程大抵会经历三个阶段
- 迅速出第一版交予市场验证
- 根据市场反馈快速迭代，系统复杂度不断增加
- 代码逐渐老化，复杂性不断增加，项目开始停滞不前。
软件功能的最大难题，就是扩展。当软件功能越来越多，需求变更频繁，开发效率越来越低，维护成本越来越高，软件的架构也越来越难以维护。
那为什么开发效率越来越低？
代码复杂度 随着代码量的增长，单个开发者想要理解整个代码库，变得越来越困难。如果团队超过五个人，每个人负责一个功能，那么单个人几乎不可能追踪系统的所有工作进度。 从而不敢轻易修改代码，过时的代码开始累积，技术债务就这样出现了。后面接手的新人，更难于重构那些遗留下来的代码。长此以往，开发变得越来越不愉快和令人无法满意。
团队原因 随着团队成员的增加，交流成本开始指数式上升。如果整个团队有 n 个程序员，为了了解其他人的工作，你需要跟 n - 1 个人逐一交流（口头或者书面），那么整个团队的交流路径总数就是 n * (n - 1) / 2。 交流成本的增长速度是人员增长速度的平方，团队人数越多，协同的难度就越大。
解决方法：
代码解耦 代码层面的解决方法是，将软件解耦，拆分成组件或者模块，防止各个部分紧密地耦合在一起。每个组件和模块，都可以独立开发，通过公开的接口被其它部分调用。
团队解耦 团队层面的解决方法是，将软件拆分成多个团队负责，每个团队负责一个组件或者模块，团队之间通过定义好的接口进行通信。
代码拆分：拆分的边界识别
- DDD
- 减少功能重叠
- 减少跨上下文通信
- 按照业务领域拆分
- 垂直拆分
- 混合拆分
团队拆分：团队组成
- 平台团队
- 业务团队
- 敏捷开发
- DevOps 文化
拆分的成本
拆分的收益
聚合
为什么要聚合
天下大势，分久必合，合久必分。软件架构亦然。就像数据库分库分表一样，当一个组织过于庞大，就进一步将它细化。当软件开始细化、系统变得多样，用户又会开始厌倦一家公司的应用软件分散在多个不同的应用上。应用的获客成本越来越高，应用又需再次聚合。
架构模式
- 基座模式
- 自组织模式。
聚合要素
各框架的聚合方案
- single-spa
主应用力求足够简单，只负责子应用的调度，业务逻辑都由子应用来承担。
总结来说，single-spa 的核心就是定义了一套协议。通过这套协议，主应用可以方便的知道在什么情况下激活哪个子应用。而这套协议主要包含两个部分：主应用的配置信息和子应用的生命周期函数。
- 实现一套生命周期，在 load 时加载子 app，由开发者自己玩，别的生命周期里要干嘛的，还是由开发者造的子应用自己玩
- 监听 url 的变化，url 变化时，会使得某个子 app 变成 active 状态，然后走整套生命周期
single-spa 到底是个什么鬼single-spa 技术分析
- 乾坤 qiankun 提供的注册子应用 APIregisterMicroApps 中，请求的子应用资源是 html 文件，即子应用打包后的入口页面
- wujie
- micro-app
- garfish