企業項目微前端改造——qiankun框架

講述以前在一家公司，經歷了一次巨石項目的微前端改造(本篇幾乎不涉及開發代碼)。代碼又是由第三方公司外包，後續公司拿來本身開發維護，因爲公司業務發展迅猛，前期並無合理規劃前端架構，在開發一年後決定技術改造，提出微前端的方式進行改造，同時提供一套兜底方案。這就面臨着，一邊是疊加的業務模塊，一邊是技術改造，兩條腿同時走路的問題就在於，資源不夠。

背景

1. 運營平臺業務模塊多達100+，近乎於巨石項目
2. 代碼的打包發版時間過長
3. 多人協做開發，test環境頻繁發版，形成環境不穩定
4. 共用模塊頻繁衝突，util模塊冗餘

基於上述4點，進行項目改造

預研

1. 拆服務——對於運營平臺各個模塊進行領域劃分
2. 方案一：iframe 做爲沙盒容器承載着各個服務
3. 方案二：拆服務，以一個服務做爲主入口，關聯其餘服務(子入口)

這裏作個小結
- 兩套方法的思想實際上是差很少的，大容器套小容器，關鍵是容器直接的通訊、用戶鑑權
- 微前端是個微服務的思想，若是從0-1作微前端是容易的，技改爲微前端，存在必定挑戰

複製代碼

後續預研中，大佬提出使用qiankun框架，這個框架說是大廠作背書，應該不會有太多問題，(那會兒，qiankun剛開源沒多久)。後面就是在已有項目中demo、申請服務資源、登錄權限。

qiankun 摘要

yarn add qiankun # or npm i qiankun -S

import { loadMicroApp } from 'qiankun';
// 加載微應用
loadMicroApp({
  name: 'reactApp',
  entry: '//localhost:7100',
  container: '#container',
  props: {
    slogan: 'Hello Qiankun',
  },
});
// https://qiankun.umijs.org/zh
複製代碼

qiankun框架中，提供了父、子服務的概念，它爲咱們實現的是父、子之間的通訊，登錄權限、用戶狀態、解決緩存

巨石項目須要處理的問題

1. 本地權限的拆分
2. node中間層(用於前端鑑權)交由後端負責
3. 限制發版次數
4. 共用模塊拆分

總結

- 對巨石項目的拆解，套用qiankun框架，最後失敗
- 在已經拆分的服務的基礎上，採用兜底方案處理
- 失敗的緣由，qiankun社區還沒有豐富，平臺自身業務發展迅速，徹底的qiankun化改造，跟不上預期效果
- 探索qiankun的過程當中，一部分拆解也在兜底方案中得以應用，也是有必定成果
- 微前端，是一種前端分發的理念。
- 以前，遇到的項目，也是微前端思想，採用的是咱們的兜底策略，只是人家把公共組件使用npm分發的方式
複製代碼