一、背景

商家后臺前端代碼目前代碼量達到十萬級，每個迭代團隊需要在同一倉庫中迭代幾十個需求，在日漸龐大的巨石應用下如此活躍的迭代，開發(fā)效率與構建效率上給我們帶來了一些挑戰(zhàn)，我們需要優(yōu)化以下幾點：

1. 代碼構建體量大，隨著時間推移，構建速度的優(yōu)化空間較少。
2. 巨石應用下各個業(yè)務模塊沒有做物理拆分，管理與維護難度提升。
3. 應用粒度較粗，在發(fā)布節(jié)點上需要對應用做進一步拆分以優(yōu)化發(fā)布粒度。
4. 巨石應用下，組件與業(yè)務的關系需要梳理，避免出現(xiàn)重復開發(fā)的情況。

微前端是目前解決應用拆分的主要解決方案，但是由于其隔離性的機制使得各個子應用間完全隔離，使得用戶在開發(fā)子應用時無法訪問其他子應用頁面，這對于各子應用存在關聯(lián)關系需要同時訪問開發(fā)的場景開發(fā)效率較低，并且目前市面上已經(jīng)完全封裝的主流微前端框架對我們來說是黑盒，無法做到高度自定義，無法滿足特定拆分需求，因此我們決定采用模塊聯(lián)邦與大倉模式結合的方式解決以上問題。

二、目標

提升構建與維護效率

將巨石應用進行拆分，獨立開發(fā)與部署、提升構建部署效率與代碼維護效率。

雖是單個子應用開發(fā)，但可全量訪問巨石應用模塊

由于商家內部各應用間在業(yè)務上存在上下游的關系，我們在開發(fā)D子應用時，需要在其上游的C、B子應用中進行相關配置，它們之間是強綁定的關系，結論就是：需要在本地開發(fā)時，能夠同時使用其他子應用的頁面模塊的功能。

三、技術方案

以上提到的提升構建與維護效率，目前微前端與MF方案都是支持的，關鍵點在于如何在本地開發(fā)能夠訪問到平臺的全量功能。本地代碼已經(jīng)有了，啟動本地進程即可，那么，其他子應用如何訪問?

微應用代理

如果是從本地再啟動其他應用，這其實就背離了應用拆分的初衷，同時也降低了本地開發(fā)的效率，同時隨著子應用越來越多，本地進程也會越來越多，這可能會大大影響本地開發(fā)效率。看來本地啟動行不通，那么從哪里訪問呢?對了，線上不是可以訪問到其他模塊嗎?但是怎么將本地開發(fā)與線上的模塊結合呢?由于目前商家后臺使用了MF方式在路由層或vue文件內遠程引入MF模塊，那么是否可以通過MF模塊轉發(fā)的方式將遠程組件代理至本地組件呢?

以上的組件代理插件實質上是用于做MF組件加載管理的chrome插件，可以控制基座應用加載的模塊是線上的還是本地。

代理方案如下

• 用戶首次進入線上測試環(huán)境，會加載遠程應用入口文件，代理插件會將入口文件根據(jù)用戶配置轉發(fā)至對應的本地地址。
• 進入路由訪問，由于上一步對遠程應用入口做了代理，加載的模塊被代理至本地，這樣用戶就可以在線上訪問到本地頁面，實現(xiàn)本地開發(fā)。
• 在線上基座應用與本地應用間建立websocket鏈接，本地應用代碼更改后通知線上基座應用刷新頁面。

下面是具體實現(xiàn)：

generateRedirectUrl = (details: UrlDetailsType) => {
    if (details.url.includes(MICRO_ONLINE_LOAD_PATH)) {
      const redirectUrl = this.generateDefaultProxyUrl({ originUrl: details.url })
      if (redirectUrl) {
        console.log('觸發(fā)代理', `${details.url}代理至${redirectUrl}`)
        this.checkMicroAppStatus({ originUrl: details.url, redirectUrl })

        return {
          redirectUrl,
        }
      }
    }
    if (details.url.includes('t1-dev.dewu.net:98')) {
      console.log("details.url.includes('t1-dev.dewu.net:98')", details.url);
      const redirectUrl = this.generateOnlineUrlByLocal({ originUrl: details.url })
      if (redirectUrl) {
        console.log('觸發(fā)代理', `${details.url}代理至${redirectUrl}`)
        this.checkMicroAppStatus({ originUrl: details.url, redirectUrl })
        return {
          redirectUrl,
        }
      }
    }
  }

• 文件內容代理為本地文件后，此時對應的模塊加載path還是會加載線上路由，這里同樣需要做內容代理。
• 由于是基于線上測試環(huán)境開發(fā)，本地開發(fā)的頁面不僅需要在線上展示，并且本地代碼更新后需要觸發(fā)線上頁面更新，這是必不可少的步驟，我們基于websocket將本地與線上進行連接。
• 不同子應用動態(tài)設置socketUrl與PingUrl。

function getHost() {
  if (process.env.SOCKET_SERVER) {
    return new URL(process.env.SOCKET_SERVER);
  }
  return location;
}
function getSocketUrl() {
  let h = getHost();
  let host = h.host;
  host = `localhost:${PORT}`;
  const isHttps = h.protocol === 'https:';
  return `ws://${host}`;
}
function getPingUrl() {
  const h = getHost();
  return `${h.protocol}//${h.host}/__umi_ping`;
}

• 建立websocket連接，并定時觸發(fā)連接檢測。

let pingTimer = null;
let isFirstCompilation = true;
let mostRecentCompilationHash = null;
let hasCompileErrors = false;
let hadRuntimeError = false;
const pingUrl = getPingUrl();
if (!window[`${APP_NAME}UmiEntry`]) {
  const socket = new WebSocket(getSocketUrl(), 'webpack-hmr');
  socket.addEventListener('message', ({ data }) =>
    __awaiter(void 0, void 0, void 0, function* () {
      data = JSON.parse(data);
      if (data.type === 'connected') {
        console.log(`[webpack] connected.`);
        // proxy(nginx, docker) hmr ws maybe caused timeout,
        // so send ping package let ws keep alive.
        pingTimer = setInterval(() => socket.send('ping'), 30000);
      } else {
        handleMessage(data).catch(console.error);
      }
    }),
  );
}

• 本地需求開發(fā)共享部署態(tài)代碼的store與路由跳轉。
• 需求開發(fā)完成后進行單個應用部署，由于是本地代理，不影響測試訪問。

基于模塊聯(lián)邦

前面的代理機制依賴于MF的遠程加載，模塊聯(lián)邦加載機制可參考「掘金」平臺中題目為“最詳細的Module Federation的實現(xiàn)原理講解” 這篇文章。基于模塊聯(lián)邦的微前端落地方案可以參考之前的一篇文章 基于Module Federation的模塊化跨棧方案探索。

本地與部署態(tài)基座應用通過MF方案加載子應用，同時部署態(tài)新增動態(tài)加載保證遠程組件的實時性，在加載入口文件處進行監(jiān)控告警。

基座應用為部署態(tài)，在進行MF加載時，通過chrome插件動態(tài)控制加載子文件路徑，開發(fā)態(tài)子應用共享部署態(tài)代碼的store，路由注冊等基礎配置。

加載態(tài)依賴chrome插件做動態(tài)代理，實現(xiàn)本地與其他測試環(huán)境構建代碼的動態(tài)切換，同時子應用與部署態(tài)代碼建立websocket代碼更新鏈接，在子應用更新代碼時，實時刷新線上頁面。同時支持端口的動態(tài)配置，一鍵關閉。

效果

以上介紹加載鏈路保證了構建部署提速與功能的完整，較好的解決了應用拆分功能不完備問題。本次架構優(yōu)化將構建由15s減少至2.0s。業(yè)務需求部署速度由8min減少至2min。

四、應用拆分

大倉模式

應用拆分只是目的，要實現(xiàn)這個目標不僅僅要做拆分，對于商家后臺來說各個應用間的復用同等重要，由于是業(yè)務解耦，這意味著各應用間存在更多可復用的功能與模塊。

同時不僅是商家后臺的部分模塊也會在交易后臺使用，既要保證應用業(yè)務的解耦，同時要保證組件充分復用，大倉模式是目前最合適的方案。

大倉模塊化共享

由于商家后臺各個子應用由于同屬商家整條業(yè)務鏈路，存在眾多可共用的組件和模塊，而npm發(fā)布模式本身給業(yè)務組件與業(yè)務項目帶來了一定隔離性，同時因為各子應用業(yè)務上存在關聯(lián)，很多大型模塊需要被多個子應用引入，而這些大型模塊的迭代通常比較頻繁，同時需要對業(yè)務請求進行封裝。這里我們使用了基于大倉模式的源碼引入以達到代碼共用的目的。組件開發(fā)鏈路如下：

這里體現(xiàn)的是源碼引入的方式，在構建態(tài)進行通用模塊的打包構建，這一點目前能跑通的背景是商家后臺本身是一個完整的應用，現(xiàn)有的模式同樣是一個組件被多個模塊所使用，同時測試階段也是全量回歸。以下是大倉組件基礎鏈路：

1. 組件構建發(fā)布使用標準的cli規(guī)范。
2. 在提交MR節(jié)點與發(fā)布節(jié)點新增自動化卡口。
3. 通過依賴分析自動化檢測單測運行范圍。
4. 組件發(fā)布時發(fā)布通知，提醒組件使用者，并運行業(yè)務單測。

之后會對該部分做詳細介紹。

五、總結與思考

單應用構建->單頁面構建?

以上主要講述了MF方案如何將本地結合線上開發(fā)，這里僅對微應用級別做了解耦，基于MF的模塊化實現(xiàn)，由于remoteMicro實質上是創(chuàng)建了一個引用路徑到require函數(shù)的映射然后代理至本地，那么對于不同模塊，在能力上是具備模塊化代理的能力的，基于目前MF按需構建(僅構建暴露出去的組件模塊)的規(guī)則，我們可以對某個模塊的映射對象里的xxx.async.js做代理。這樣就可以實現(xiàn)頁面粒度的按需構建，在部署構建提速上有很大潛力。

本篇文章主要介紹了如何對商家巨石應用做拆分，包括拆分方案的介紹，如何同時保證單個構建與功能完整性，并且針對微應用代理加載進行了進一步探索，接著介紹了大倉模式下需要遵循的規(guī)范以及未來的規(guī)劃。大倉模式目前在前端平臺已經(jīng)持續(xù)不斷地完善，將來應該會針對此模式做更詳細的介紹，在拆分這件事情上，對于構建本身或許能被更加細粒度化，構建文件的代理本質上減少了代碼的構建量，目前是通過人為控制的方式，此次驗證了模塊聯(lián)邦支持可代理與動態(tài)更改expose。基于這兩個特性，是否能將構建做到更加局部化，這可能會成為構建優(yōu)化的方向。應用拆分一方面提升了開發(fā)人員的開發(fā)與部署效率，同時也對業(yè)務迭代流程做了業(yè)務解耦，明確了責任邊界，更有利于后臺應用的開發(fā)需求管理，降低需求代碼維護成本。