微前端 —— 理论篇

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