微前端 —— 理论篇

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 一、Angular 二、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