在前后端分之后，拆分降低了系统的复杂度，并进一步提高了软件的开发效率，随着业务的不断扩张，需求也不断扩张，应用又开始变得臃肿，所以我们会考虑往下拆分，拆分为更小的单位。
什么是微前端架构？它是如何形成的，以及有什么优缺点？
微前端是类似于微服务的架构，它将微服务的理念应用于浏览器端，将单页面前端应用由单一应用转变为多个小型前端应用聚合为一的应用，各个前端独立部署，独立开发，同时可以通过npm 或者 submodule来管理
9.1应用自治
将多个应用组件交给多个团队进行开发，遵循统一的接口规范或框架，便于系统集成在一起，因此相互之间没有依赖关系，可使用不同的前端框架，都不会受影响
9.2 单一职责
微前端要满足单一职责性，然后前端面向最终客户，需要保证用户体验的连续性，所以面临挑战时，需要考虑其他的方式
9.2 技术栈无关
前端可以通过多种JavaScript开发出自身业务需要的应用，没有限定只能使用一个框架
其他好处：
遗留系统迁移，
后端解耦，前端聚合，
热闹驱动开发：可能某个框架很火，但是用了后发现不适合，做迁移更换，不会影响整个项目的运行
如何设计一个微前端架构的系统？
从技术实践上，微前端架构可以采用以下几种方式进行：
1. 路由分发式：通过http服务器的反向代理功能，将请求路由到对应的应用上
它看起来像一个完整的整体。但它们并非是一个整体，每当用户从A应用转的时候，往往需要刷新一下页面、重新加载资源文件。这个架构中，我们只需要关注应用间的数据传递方式。通过缓存的方式共享数据，缺少了应用状态的处理，需要用户重新登录，体验很不好
2. 前端微服务化：在不同框架之上设计通讯和加载机制，以在一个页面内加载对应的应用
采用这种方式意味着，一个页面上同时存在两个及以上的前端应用在运行。而路由分式方案则是，一个页面只有唯一一个应用。 当我们单击指向某个应用的路由时，会加载、运行对应的应用。而原有的一个或多个应用，仍然可以在页面上保持运行的状态。同时，这些应用可以使用不同的技术栈来开如页面上可以同时运行React、Angular和Vue框架开发的应用。 因此我们需要做到两点： 第一点：在页面合适的地方引入或者创建dom 第二点：用户操作时，加载对应的应用（触发对应的启动，并能卸载应用）
3. 微应用：通过软件工程的方式，部署构建环境中，把多个独立的应用组合成一个单体应用
开发时应用都是单一、微小应用的形式存在，而运行时，则通过构建系统合并这些应用，组合成一个新的应用
4. 微件化： 开发一个新的构建系统，将部分业务功能构建成一个独立的chunk代码，使用时远程加载即可
每个业务团队编写自己的业务代码，并将编译好的代码部署（上传或放置）到指定的服务器上，在运行时，只需要加载相应的业务代码即可
(1) 持有一个完整的框架运行时及编译环境。这用于保证微件能正常使用，即可调用架API等。
(2) 性能受影响。应用由提前编译变成运行时才编译，会造成一些性能方面的影响-具体视组件的大小而定。
(3) 提前规划依赖。如果一个新的微件想使用新的依赖，需要从上游编译引入。此外，我们还需要一个支持上述功能的构建系统，它用于构建一个独立的微件模块微件的形式如下:
分包构建出来的独立代码，如 webpack 构建出来的 chunk 文件。
使用DSL的方式编写出来的组件。为了实现这种方式，我们需要对前端应用的构建系统进行修改，如 webpack，使持构建出单个的代码段。这种方式的实施成本比微应用化成本高。
5. 前端容器化：将iframe技术作为容器来容纳其他前端应用
他能有效的将一个网页、单页面应用嵌入到当前应用中，两个页面间的css和JavaScript相互隔离的--除去iframe父子通信部分的代码，相当于创建了一个独立的宿主环境，类似于沙箱隔离，意味着前端应用之间可以相互独立运行，如果采用这种方式，那就不要做 seo的支持以及设计相应的应用管理机制
6. 应用组件化，借助于web component技术，构建跨框架的前端应用
web Components 是一不同的技术，允许开发者创建可重用的定制元素(它们%能封装在代码之外)，并且在 Web 应用中使用它们。
真正在项目上使用 Web Components 技术，离现在的我们还有些距离，可是结合Components 来构建前端应用，是一种面向未来演进的架构。或者说在未来，可以采用种方式来构建应用。比如 Angular 框架，已经可以将当前应用构建成一个 Web Compo组件，并在其他支持引入 Web Components 组件的框架中使用，如 React。我们还可以使WebComponents 构建出组件，再在其他框架中引入。
为此，我们只需要在页面中通过 Web Components引入业务模块即可，其使用方式似于微件化的方案
目前困扰 Web Components 术推广的主要因素在于浏览器的支持程度。在 Chrom和Opera 浏览器上，对 Web Components 支持良好，而对 Safari、IE、Firefox 浏览器的持程度，并不是很理想。有些不兼容的技术，可以引入 polyfill 来解决
如何合理的拆分微前端应用？
1.按照业务拆分。
2.按照权限拆分。
3.按照变更的频率拆分。
4.按照组织结构拆分。
5.按照后端微服务拆分。
微前端架构设计
- 构建基础设施：组件与模式库，应用通信机制，数据共享机制，专业的构建系统
- 提取组件与模式库: 样式，业务组件及共享库
- 应用通信机制： 同级通信，父子通信【postmessage】
- 数据管理【url参数传递，localstorage, 客户端存储indexDB，webSQL, 服务器存储客户端状态】
- 专用的构建系统
微前端架构模式
1.基座模式
通过一个应用来管理其他应用，设计难度小，方便实践，通用低
这个主应用，既可以只带有单纯的基座功能，也可以带有业务功能。它所处理的功能指的是核心部分的业务功能，如:
a. 用户的登录、注册管理。 b. 系统的统一鉴权管理。 c. 导航菜单管理。 d. 路由管理。
2.自组织模式
应用之间是平等的，不存在相互管理的模式，设计难度大，不方便实施，通用度高
微前端设计理念
-
中心化：应用注册表
-
标识化应用
-
生命周期 【single-spa框架】
-
高聚合，低耦合
