一、前端架构的前世今生
初始：无架构，前端代码内嵌到后端应用中
MVC:
前后端分离：
- 将前端代码从后端环境中提炼出来（ajax促进了前端分离架构的发展）多页面架构
缺点：前端缺乏独立部署能力，整体流程依赖后端环境
NodeJs 的广泛使用促进了前端技术的飞速发展
- 各种打包、构建工具应运而生。
- 诞生了多元化前端开发方式，使得前端开发可以脱离整体后端环境
单页面架构
- 打包：gulp,rollup,webpack,vite......
- 框架：vue/react/angular/......
- ui库：antd/iview/elementui/mintui
优势：
- 切换页面无刷新浏览器，用户体验好
- 组件化开发方式，极大提升了代码复用率 劣势：
- 不利于SEO,首次渲染会出现较长时间的白屏（可解决）
大前端时代：
- 后端框架：express,koa
- 包管理工具：npm,yarn
- node版本管理工具：nvm 总结：
- 过于灵活的实现也导致了前端应用拆分过多，维护困难。
- 往往一个功能或需求会跨两三个项目进行开发。
微前端新型架构
- 技术栈无关
- 主框架不限制接入应用的技术栈，微应用具备完全自主权
- 独立开发、独立部署 微前端架构-天下大势合久必分分久必合
- 增量升级
- 微前端是一种非常好的实施渐进式重构的手段和策略
- 微应用仓库独立，前后端可独立开发，主框架自动完成同步更新
- 独立运行时
- 每个微应用之间状态隔离 运行时状态不共享
微前端劣势：
- 接入难度高
- 应用场景-移动端少，管理端多
- 在一个系统内微前端是应用间的架构方案
- 在多个应用之间，微前端则是一种系统间等架构方案 3.微前端是将多个前端应用以某种形式结合在一起进行应用。
解决的问题：
- 解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变为一个巨石应用后，随之而来的应用不可维护的问题。
实现的形式：
- 单实例：即同一时刻，只有一个子应用被展示，子应用具备一个完整的应用生命周期。
- 多实例：通常基于url的变化来做子应用的切换。 多实例：同一时刻可展示多个子应用。 通常使用Web Components方案来做子应用封装，子应用更像是一个业务组件而不是应用。
二、微前端方案对比
微前端框架对比：
