微前端-理论篇

1. 微前端

        基于 spa 类的单页应用，随着企业工程项目的体积越来越大，开发的功能越来越多，页面也越来越多，项目随之也变得越来越臃肿，维护起来十分困难，往往改一个 logo，或者改一个小样式，都要将项目全部重新打包一遍，维护困难，部署也困难。
        因此前端在借鉴后端的微服务架构模式后，衍生了微前端架构，将一个功能繁多的单页应用转换为多个小型单页应用的组合，这些小型应用往往具有 独立开发、独立运行、独立部署 的特点。它们通常与 技术栈无关，不同的应用可以用 react 开发，也可以用 vue 开发，但是它们始终能组成一个完整的应用。

2. 可实现方式

        以下是基于我已经实现的方式介绍的（毕竟没亲手操作过，啥也吹不出来啊）

1. iframe（难度：1）
2. single-spa（难度：4）

3. iframe

         iframe 实现的方式很简单，这里就简单阐述一下。通常是一个 portal 项目作为各个小型应用项目的入口，此 portal 项目包含业务菜单，权限控制等，而各个小型应用项目独立开发，打包并部署到各自服务器上面，在 portal 项目中，通过将需要展示的小型应用的 url 赋值给 iframe 的 url，将其内嵌在 portal 项目中即可，十分简单。
         优点：实现简单
         缺点：iframe 与主页面共享连接池；由于 iframe 与主页面的静态资源文件无法共享，所以相同的依赖在各个项目中独自打包，导致用户需要加载很多重复的依赖，例如 react.js、vue.js 等，这是影响性能的主要原因；还有一个就是用户缩放等操作，iframe 内部的样式无法同时适配。

4. single-spa

官网链接

         single-spa 在官网中被自称为一个 元框架，可以实现在一个页面将多个不同的框架整合，甚至在切换的时候都不需要刷新页面（支持 React、Vue、Angular 1、Angular 2、Ember 等等）
         官网中的例子是所有项目都在同一个仓储中的，这显然违背了我们的初衷，我们需要每一个小应用都有自己独立的仓储，好在官网中也推荐了一个 System 框架的案例，实现了各个小应用的独立仓储。

        * 现在开始从头搭建我们的微前端架构 *。我们要实现的应用是一个主菜单，五个小页面，每个菜单对应一个页面。有一个 menu 应用，里面包含了菜单的跳转；一个 react 应用，其中包含 3 个页面；一个 vue 应用，包含两个页面。
        项目架构：

        其中 menu 是主菜单应用；portal 是应用注册、路由分发等服务和共同依赖包 (react、react-dom 等) 的抽离；project1 是 react 应用，包含 3 个子页面；project2 是 vue 应用，包含 2 个子页面。

        由于有些项目的搭建过程太过繁琐，我将分为三篇文章分别介绍 portal 项目的搭建、project1 与 menu 项目的搭建、project2 项目的搭建。

        项目源码

        微前端 —— portal 项目
        微前端 —— menu&&project1（React）
        微前端 —— project2 项目（VUE