背景

📢 博客首發 : SugarTurboS Blog

團隊的專案 A 經歷兩年需求的洗禮，一些問題也隨之暴露出來：

• 專案參考的npm包很多，業務代碼也很多，有著向巨石應用發展的趨勢，巨石應用的一些典型問題如下：構建效率低下、dev-server 占用記憶體大甚至記憶體泄露、維護成本急劇增加，
• 專案主框架升級成本高，要兼容舊代碼，
• 專案里的某些業務幾乎不再迭代，但每個版本依然會被打包構建，每次構建的npm包版本可能不同，導致一些隱藏未知錯誤，
• 該專案之前是由兩個不同的專案合并而來，代碼風格上存在兩種方式，解決類似問題時引入的技術方案也是不一樣，導致后期維護成本高，同樣對于新人來說閱讀性差，

解決之路

為什么用微前端

對于微前端跟 iframe 的方案區別，為什么用微前端這個問題，這里不再累贅，qiankun里面有一篇文章已經說得非常不錯，有興趣可以去看看，
why not iframe

為什么我們選擇qiankun

• qiankun的接入對專案改動小，成本低，
• 社區活躍，作者對于 issue 回復快，
• star 數相對較多
• 阿里自家專案有在使用，穩定性 ok，即生產可用（這一點其實是官方上說的，實際我們也不肯定，就我們使用感覺，穩定性還是有一定保障的），

重構之路

這個的坑不是指qiankun的坑，當然，qiankun這個框架還是有一些坑在的，這里主要的指在專案重構的時候，遇到的一些坑及我們的解決方案，以供大家參考，

兩個 React 的坑

專案之前的結構，所有的包都安裝在根目錄的node_modules，專案里所有內容都指向一個React，而用qiankun重構后，我們定義每個子專案為一個相對獨立的專案（有獨立的package.json檔案，獨立包管理），但子專案之前又會有一些公共的組件，我們把它放在以子專案同級的 common 檔案夾，如下圖，

這時候就遇到一個問題：子專案參考自己package.json目錄下的node_modules里面的React，而 common 參考根目錄的package.json目錄下node_modules里面的React，當子專案參考 common 封裝的React 組件，子專案跑的時候會報同時引入了兩個React，導致報錯，

一開始，我們想到的方案是這樣的，把全部包安裝在根目錄的node_modules，但是，這個方案最大問題是所有子專案必須用同一版本React、后期React想升級，必須所有子專案做兼容，但是有些子專案被劃分出來就是為了不再跟隨升級迭代，這就矛盾了，

后來，我們換了一個方案，我們在打包的時候，預先把 common 目錄 copy 一份到子專案，這樣就能保住都是參考一個React，在開發的時候，額外啟動一個監聽服務 watch common 目錄，監聽到檔案變化的時候自動 copy 檔案到子專案，子專案的 common 目錄進行權限控制，只能進行讀寫操作，無其他操作執行權限，所有參考 common 通過@common 映射，這樣給到開發時，common 內容的更改只需要在根目錄 common 修改，子專案通過@common 參考不需要關注真實的 common 與子專案的目錄結構關系，

babel 配置讀取不到的坑

重構前，我們們只有一個 babel 配置，重構后，我們們的目錄結構是典型的 monorepo 結構，我們們只有子專案有 .babelrc.json 檔案，導致 common 往上查找找不到配置報錯 (ps:我們們專案是使用babel7構建)

一開始，是沿用babel6時候的方式，使用.babelrc.json檔案，根目錄及子專案分別有一個.babelrc.json檔案，這樣的最大缺點是兩個.babelrc.json檔案配置幾乎相同，后期維護改配置需要修改兩個檔案，

然后改用子專案 .babelrc.json 通過 extends 配置復用根目錄的.babelrc.json配置，

后面發現，由于 babel 配置有一些是需要配置路徑，而json只能配置相對路徑，于是改用js格式配置，

我們們專案參考的一些 npm 包沒有轉es6，我們們只能用 webpack 對這些包額外 babel 轉化一下，但是發現專案的 babel 配置對 npm 包并不生效，后來發現是因為 babel7 之后，.babelrc 不會對 node_modules 包起作用，必須改用babel.config.js代替，

以上就是我們最終關于babel的配置，

【記得 babel-loader 時要配置引數 rootMode 為 upward，表示允許 babel 往上查找babel.config.js檔案】，同樣子專案要配置 extends 引數指向最外層的 babel 檔案路徑，

關于babel6.x與babel7的區別，babel對于monorepo專案的配置，官網上面這篇文章寫的是最詳細的，

通信

qiankun 只給我們們提供了一個 initGlobalState(初始化一個全域state)、onGlobalStateChange(監聽變化)、setGlobalState(更新state)的全域狀態管理，并不跟React的狀態管理器做關聯，我們們要做的是把全域state與子應用redux做一個雙向系結，

// 這里面state與globalState要進行深比較，如果是淺比較，會導致程式陷入死回圈，
const [state, setState] = useState({}) // 這里用state代替redux，做一個簡單演示，
let globalState = null
// 監聽globalState值變化，如果有變化則更新state
actions.onGlobalStateChange((newGlobalState) => {
  globalState = newGlobalState
  const diffState = getDiffState(globalState, state)
  if (diffState) setState(diffState)
})

// 監聽state值變化，如果有變化則更新globalState
useEffect(() => {
  const diffState = getDiffState(state, globalState)
  if (diffState) actions.setGlobalState(diffState)
}, [state])

異步加載

由于我們們專案之前是使用 webpack 的 import 實異步加載，在使用qiankun重構后，發現以下問題：

當前處于子應用 A，切換子應用 B，在異步 js 還在加載程序中，快速切換回應用 A，待子應用 B 的異步 js 加載完畢后，我們們切換回子應用 B，發現子應用那個異步 js 加載的內容為空，

導致該問題原因是 A->B->A 程序后，子應用 B 的沙箱被移除了，異步 js 缺少執行環境，導致異步 js 執行的(window.webpackJsonp...)已經找不到，

目前沒有找到有效的解決辦法，這可能是框架的一個隱藏坑，已提issue，期望大佬們能協助解決，我們現在想到的可行方案是改用loadMicroApp手動加載子應用，

瀏覽器的 fetch 差異

在專案送測程序中，測驗發現在某些瀏覽器（目前知道的是搜狗瀏覽器某個版本）會有兼容性問題，后來追查發現，有些瀏覽器的 fetch 默認 credentials 不是 same-origin，導致一些 cookie 的 header 資訊沒被帶上，后臺權限認證一直不過，

解決方法就是呼叫 qiankun 的 start 是重寫fetch，設定 credentials=same-origin，保證瀏覽器的兼容性，

start({
  fetch(...args) {
    const config = {
      credentials: 'same-origin',
    }
    if (!args[1]) args[1] = {}
    args[1] = {
      ...args[1],
      ...config,
    }
    return fetch(...args)
  },
})

總結

其實整體來說，接入qiankun成本還是比較低的，遇到的問題大多不是qiankun直接導致，而是用qiankun重構后，專案結構發生變化帶來的一些問題，

優化開發體驗篇

專案重構后，因為整體結構的變化，出現的一些性能及開發體驗的問題，這里主要說影響比較大的兩點，

記憶體占用嚴重，子應用無法熱更新

1、有同事發現，專案用qiankun重構后，在本地開發程序中，如果chrome tool長期打開，隨著頁面重繪次數越多，chrome的記憶體占用會越來越嚴重，理論上來說，就算程式有記憶體泄露啥的，重繪頁面也會釋放掉才對，為啥記憶體卻是越來越大呢？后來發現，只要不打開chrome tool，記憶體是正常的，重繪記憶體就會降下來的，而且，我們們使用未重構的分支驗證，也是不會記憶體越來越大的，如圖：

2、子應用內容變更，是無法熱更新的，一開始以為是webpack的配置沒有配對導致的，后來發現并不是webpack，而是qiankun使用的single-spa框架的問題，詳細可見issue，里面作者也提供了一個方案，就是允許你重新加載子應用，但是這樣就違背了熱更新的更新區域的思想，而且，加載子應用跟重繪并沒有太大差別了，開發體驗太差，

我們們討論發現，沒有什么方案可以解決這個問題，只有一個規避的方案，就是我們們平時開發的時候，使用子應用路由進行開發，這樣就可以規避這兩個略為蛋疼的問題，當然，在一些場景下，如果主應用做一些權限的東西，單獨跑子應用必須重寫一套權限，我們目前做法是把這種模塊掛公共目錄里，后面還要繼續探索有沒有更好的方案，大家如果有更好的解決方案歡迎留言，

monorepo 專案的開發命令管理

專案組的小伙伴吐槽說，我們們之前開發只需要npm run dev一個命令列就可以搞定，qiankun重構后，每個子應用啟動一個服務，qiankun還要一個服務，如果要全套跑起來，我們需要打開多個命令列視窗分別運行，這樣太麻煩了，針對這個問題，自然是引入npm-run-all解決這個問題，一開始我們也是這樣做的，但是后面發現，實際開發程序中，有的時候小 A 只要開發子應用 A，小 B 只需要開發子應用 B，每個人都全部啟動，既浪費記憶體資源，也不優雅，那么，要怎么樣隨心所欲一行命令開啟你想要的服務呢？
我們們最后是使用npm-run-all的 Node API，自主處理命令列，然后使用它提供的 API 動態啟動想要的服務，如npm start main A，會啟動 qiankun 所在的服務及 A 微服務，

// package.json
"scripts": {
  'start': 'node start.js',
  "start:main": "cd client/main && npm run dev",
  "start:A": "cd client/A && npm run dev",
  "start:B": "cd client/B && npm run dev",
  "start:C": "cd client/C && npm run dev",
}

// start.js
const runAll = require('npm-run-all')

function getApps() {
  // 查找命令列所帶的引數，如果沒有帶引數，然后啟動Main及A服務
  let apps = process.argv.filter((arg) =>
    ['Main', 'A', 'B', 'C'].some((name) => name === arg)
  )
  if (apps.length <= 0) apps = ['Main', 'A']
  return apps
}

function getTasks() {
  let apps = getApps()
  let tasks = apps.map((app) => `start:${app}`)
  return tasks
}

runAll(getTasks(), {
  parallel: true,
  // stdout: writable,
  // stderr: errWritable,
  // printLabel: true,
})
  .then((results) => {
    console.log('done!', results)
  })
  .catch((err) => {
    console.log('failed!', err)
  })

公共包

重構后，我們發現有些包子應用都有使用，比如React、antd…，如果每個子應用都安裝依賴一個antd，那就很浪費資源加載，也會影響用戶首屏等待時間，qiankun沒有提供這方面的方案，我們最后是使用dll方式，先把這些公共包提前打包后，在dll到各個子專案，dll的方式也是有一些不足的，因為dll無法按需加載，只能參考整個包，同樣，dll需要提前加載，如果dll打包的東西不是使用很頻繁或首屏使用的，會特別浪費，所以我們一般只有滿足以下條件才會考慮dll:

• 1、多個專案使用
• 2、專案使用的頻率高
• 3、這個npm包幾乎大部分功能都需要使用

結尾

最后說說我們的想法，專案是否需要引入 qiankun，我們覺得關鍵還是要清楚引入 qiankun 后的收益及成本，拿我們們這個專案來說，因為可預見后面業務越來越大的時候，它肯定會變成巨石應用，qiankun 的接入在當前來看可能成本高于收益，但從長遠來說，收益是絕對高于成本的，所以我們們把它引到專案中去了，

最后，由于篇幅有限，很多細節的東西沒有在這里展現，如果有興趣的，歡迎私下交流，

未經授權，禁止轉載～

更多文章

• SugarTurboS Blog
• Redux原始碼解讀與編程藝術
• 淺談前端設計模式
• 你還在為專案里的重復請求發愁嗎?
• 協同編輯場景的基礎分析及方案設計