微前端 —— 理論篇

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