前端微服务
背景
2016年由ThoughtWorks提出微前端的概念，将后端微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。
H5前端所承载的业务主要是拉新，保持用户粘性，保持项目生态的完整性以及数据展示，管理系统。
所以对应到产品就是活动页面（拉新，保持用户粘性），各家小程序（保持项目生态的完整性），pc后台管理系统（数据展示，管理系统）
如何把微服务架构思路加入到我们现有框架中。
框架目的
- 独立开发、独立测试、独立发布、独立部署，提高了开发效率。 （业务解耦）
- 统一的样式、统一的公共组件，项目的粒度易控制
- 资源按需加载，提取公共库
待解决问题
1、开发流程构建问题
- 需要提供一套应用注册机制，完成应用的无缝整合
- 需要支持构建时集成应用和应用独立发布部署
2、部署过程问题
前端微服务的技术探索
- 原始的iframe
- 代码合并 + 理由webpack 打包合并微服务
- single-vue-spa
原始 iframe
1、优点：
项目改造成本低，兼容性高
三大框架项目可以任意组合，非常高效
2、缺点：
iframe 由于是整个嵌入的html，交互会有问题（比如一些alert弹窗等）
事件传递会有困难
3、针对问题的解决方案：
postMessage：
可以解决页面交互 事件传参 的问题
Emitter：
事件中心，处理交互
代码合在一起
即所有模块可以根据目录去区分，但是所有代码都是合在一起的，可以通过 webpack 打包工具等操作实现微服务，这也是微服务的一种
1、特点：
代码合并一起
资源调用，通过路由切换的方法控制各个模块的微服务加载
2、实现：
自己写框架实现路由合并
代码分开开发，组合式集成
代码分开开发，各个系统 独立开发、独立运行和独立部署 ，当然这样也是成本更高的
独立开发和独立运行：
单个模块微服务是可以独立开发和运行的，这样轻量级代码，便于我们的运行和开发流畅度
常见技术方案就是：
将各个模块独立打包 chunk，在调用的时候进行加载即可
成本高的原因（规范）：
- 依赖需要统一：一旦项目分开开发，依赖版本不同必然会照成不可预知的问题，所以统一依赖非常重要
- 路由问题：组件式集成核心就是理由路由进行框架之间的切换加载，那么路由管理和规范是重中之重
- 全局组件的问题：全局组件可能会造成不可预知的错误，所以组件分装要注意
- 全局方法的问题，大家都喜欢在Vue.prototype下挂载方法，使用微服务，必然需要添加规范，防止覆盖和冲突
公用代码的问题：
比如 vue，vuex，vuerouter，element-ui 等，如果每个项目都打包，明显代码冗余，加载缓慢，我们想要的是一次加载，处处使用
强大的构建系统：
构建系统是发布的保证
可能需要的资源：
- 编写框架，动态管理我们各个模块的App
- 构建发布系统，编写脚本
- 第三方CDN，便于依赖统一以及代码大小优化
- 后端运维的支持
- 测试的支持，技术框架探索，测试工程量非常大，当然Bu可能会很多
组合式集成
独立开发、独立运行和独立部署
框架 VueAppMicro
利用我们编写的框架去动态管理路由和store
root模块：
也可以认为是导航模块，这个模块是 base ，一般他用到导航跳转到各个子系统
首屏加载模块：
default模块
default 因为是动态加载的，default可以认为是默认就需要加载的
active 模块（current）
当前活跃模块
框架大致功能模块
模块列表
index.js
- 入口
- 单利模式（挂载到 window，只要有一个创建，其余微服务均使用这个）
app
- 管理 application
- 注册app
- 删除app
- 查询app
- app 状态变更
router
- 路由管理
- 添加删除路由
lifecycle
- 生命周期管理
- start
- navigationTo
- mount
- unmount
enit
- 事件中心，用作微服务交互的
html
- 获取 link src 数据
- 获取html资源
开发技术栈
rollup.js
- 框架打包工具
ES6
- class
类单利模式
- 因为不同框架都需要注册 MicServer，但是其中的 apps 只需要一个
系统架构
app
- 模块注册
- 模块的增删改查
router
- 路由的增删改查
- 状态查询
lifecycle
- 挂载和卸载
html
- html处理，包含js和css合并到我们的index.html
Emit
- 事件中心，事件的传递和交互
- 在我们 main 元素中挂载不同的Vue，进行操作
