探索微前端的場景極限

點(diǎn)擊上方 前端Q，關(guān)注公眾號

回復(fù)加群，加入前端Q技術(shù)交流群

作者：kuitos

來源：https://www.zhihu.com/column/p/355419817

本文主要介紹總結(jié)了一些基于 qiankun 的微前端應(yīng)用場景與實踐

基礎(chǔ)場景

與路由綁定的方式渲染微應(yīng)用

通常情況下，我們接觸的最多的微前端的實踐，是以 URL/路由 為維度來劃分我們的微應(yīng)用，以 OneX 平臺（螞蟻金融云基于微前端架構(gòu)打造的統(tǒng)一接入平臺）為例：

接入這類平臺的微應(yīng)用，通常只需要提供自己的 entry html 地址，并為其分配一個路由規(guī)則即可。

這背后的實現(xiàn)則是基于 qiankun 的 registerMicroApps API，如：

import { registerMicroApps } from 'qiankun';

registerMicroApps([
  {
    name: 'app1', 
    container: '#container', 
    entry: '//micro-app.alipay.com/', 
    activeRule: '/app1' 
  }
])

路由與應(yīng)用綁定的方式簡單直觀，是微前端中最為常見的使用場景，通常我們會用這種方式將一堆獨(dú)立域名訪問的 MPA 應(yīng)用，整合成一個一體化的 SPA 應(yīng)用。

但這類場景也有自己的局限性：

1. 由于URL/路由的 唯一性/排他性 的特點(diǎn)，這種方式只適用單實例場景需求
2. 微應(yīng)用的調(diào)度都是由路由系統(tǒng)來自動處理的，雖然省事但是碰到更復(fù)雜的需求，如同一個路由下，根據(jù)不同的用戶權(quán)限展示不同的微應(yīng)用這類個性化訴求，需要寫一些中間層代碼來曲線救國
3. 應(yīng)用掛載的容器節(jié)點(diǎn)等需提前準(zhǔn)備好，不然碰到 動態(tài)/嵌套 路由這類情況，可能會因為路由 listener 監(jiān)聽觸發(fā)的時序不確定，導(dǎo)致微應(yīng)用無法完成掛載的問題

以組件的方式使用微應(yīng)用

qiankun 2.0 的發(fā)布帶來一個全新的 API loadMicroApp，通過這個 API 我們可以自己去控制一個微應(yīng)用加載/卸載，這個方式也是 qiankun 2.0 的重磅特性：

import { loadMicroApp } from 'qiankun';

// do something

const container = document.createElement('div');
const microApp = loadMicroApp({ name: 'app', container, entry: '//micro-app.alipay.com' });

// do something and then unmount app
microApp.unmout();

// do something and then remount app
microApp.mount();

開發(fā)者可以在脫離路由的限制下，以更自由的方式去渲染我們的微應(yīng)用?；?loadMicroApp API，我們只需要做一些簡單的封裝，即可以類似組件的開發(fā)體驗，完成微應(yīng)用的接入，以 React 為例：

第一步：封裝一個 MicroApp 組件：

import { loadMicroApp } from 'qiankun';
import React from 'react';

export default class MicroApp extends React.Component {

  containerRef = React.createRef();
  microApp = null;

  componentDidMount() {
    const { name, entry, ...props } = this.props;
    this.microApp = loadMicroApp(
      { name, entry, container: this.containerRef.current, props },
    );
  }

  componentWillUnmount() {
    this.microApp.unmount();
  }

  componentDidUpdate() {
    const { name, entry, ...props } = this.props;
    this.microApp.update(props);
  }

  render() {
    return <div ref={this.containerRef}></div>;
  }
}

第二步：通過 MicroApp 組件引入微應(yīng)用：

import MicroApp from './MicroApp';
import React from 'react';

class App extends React.Component {
    render() {
    return (
      {
        this.props.admin
          ? <MicroApp name="admin" entry="http://localhost:8080/" level={10} />
          : <MicroApp name="guest" entry="http://localhost:8081/" level={1} />
      }
    )
  }
}

如果你是 umi 應(yīng)用，那只需要直接使用插件封裝好的組件即可：

import { MicroApp } from 'umi';

function MyComponent() {
  return (
    <div>
      <MicroApp name="qiankun" age={1.5} stars={8700} />
    </div>
  )
}

這類方式適用于一些可共用的、帶業(yè)務(wù)邏輯的服務(wù)型組件（類似于我們以前常說的端對端組件）：比如帶聊天交互的客服機(jī)器人、帶引導(dǎo)功能的 intro 服務(wù)等。

如螞蟻 sofa 產(chǎn)品控制臺中的這個使用入門微應(yīng)用：

右側(cè)呼出的窗口即為一個獨(dú)立開發(fā)、獨(dú)立發(fā)布的微應(yīng)用

通過組件的這種方式，我們可以完全自主的控制微應(yīng)用的渲染，并與之做一些復(fù)雜的交互。不論是在開發(fā)者的編碼心智，還是用戶的體驗上，都跟使用一個普通的業(yè)務(wù)組件無異。

組件的方式非常靈活，幾乎解決了所有路由綁定方式渲染微應(yīng)用的問題，但也有自己的一些局限：比如我們會要求這類微應(yīng)用必須是不帶路由系統(tǒng)的 widget 類型，不然也會出現(xiàn)多實例時路由沖突的問題。

嵌套渲染場景

有一些更復(fù)雜的場景中，我們可能需要使用到「套娃」的方式集成我們的若干微應(yīng)用。

比如我們要在應(yīng)用 A 下集成應(yīng)用 B 的商品列表頁，然后在應(yīng)用 B 的商品列表頁呼出應(yīng)用 C 的買家詳情頁，所有應(yīng)用的喚起都以 彈層/抽屜 這種不刷新的交互來完成。

在有了上面兩個場景的實踐經(jīng)驗后，我們很容易得出這樣的組合邏輯：

在應(yīng)用 A 中通過調(diào)用 loadMicroApp(B) 的方式喚起微應(yīng)用 B，然后在微應(yīng)用 B 中通過 loadMicroApp(C) 的方式喚起微應(yīng)用 C，通過這樣的調(diào)用鏈路即可很完美的完成產(chǎn)品上的訴求。

但是現(xiàn)實情況往往沒有那么簡單，前面提到過，若想要 loadMicroApp API 能符合預(yù)期的運(yùn)行，我們需要確保被加載的微應(yīng)用是不含自己的路由系統(tǒng)，否則會出現(xiàn)多個應(yīng)用間路由系統(tǒng)互相 搶占/沖突 的情況。

而現(xiàn)實情況是，我們大部分需要復(fù)用的頁面/組件，都會是某個站點(diǎn)的局部路由頁，很少有人會專門起一個倉庫，用來專門把這個頁面抽取成一個微應(yīng)用，比如上面提到的買家詳情頁。

這種場景下，我們其實只需要確保微應(yīng)用的路由系統(tǒng)不會干擾到全局的 URL 系統(tǒng)即可。幸運(yùn)的是 react-router 的 memory history 模式很好的解決了這一問題。如果你是一個 umi 應(yīng)用，只需要直接使用我們封裝好的組件即可完成 memory history 的運(yùn)行時切換：

import { MicroAppWithMemoHistory } from 'umi';

<Drawer>
  <MicroAppWithMemoHistory name="buyer" url='/buyers/123' />
</Drawer>

交互效果可以參考：

圖中 app1/app2 均是子應(yīng)用，但是在 app1 中可以再通過抽屜呼出 app2，同時瀏覽器地址欄也不會被 app2 的路由干擾。

關(guān)于嵌套渲染相關(guān)的詳細(xì)介紹，可以看這篇《基于微前端的大型中臺項目融合方案》

極限渲染場景

如果你覺得嵌套微應(yīng)用就是我們場景的天花板了，那未免有點(diǎn)小看群眾們的想象力了。

在我們內(nèi)部的一個設(shè)計工程化平臺里，我們通過 qiankun 成功的把一個微應(yīng)用的 20+ 路由頁同時渲染到了一個 url 下：

上圖中右側(cè)列表中每一個 demo 都是通過 qiankun 渲染的一個獨(dú)立微應(yīng)用實例，而這里面每一個微應(yīng)用實例，實際對應(yīng)是同一個 react 應(yīng)用的不同路由頁。

不同于前面幾個場景，將同一個應(yīng)用的不同頁面，同時渲染到主應(yīng)用的不同 UI 容器中這個需求下，有幾個比較特殊的問題需要去考慮：

1. 是否需要特殊的微應(yīng)用生產(chǎn)方式
2. 多路由系統(tǒng)共存帶來的 沖突/搶占 問題
3. 不同微應(yīng)用間的樣式隔離
4. 如何優(yōu)化渲染性能：既然每一個微應(yīng)用實例實際對應(yīng)的是同一個應(yīng)用，那我們?nèi)绾伪M可能多的復(fù)用一些運(yùn)行時或者沙箱，從而降低這么多微應(yīng)用同時渲染代理的運(yùn)行時開銷

篇幅考慮，針對這類場景優(yōu)化的技術(shù)細(xì)節(jié)不在這里介紹了，后面會單獨(dú)寫一篇來介紹

解決了這些問題后，我們只需要在我們的項目中這么去使用就可以了：

// MicroAppWithMemoHistory 是基于 memory history 封裝的微應(yīng)用加載器
import { MicroAppWithMemoHistory } from 'umi';

function Home {
  return (
    <div>
      { /* 將同一個應(yīng)用的不同路由頁同時渲染出來 */ }
      <MicroAppWithMemoHistory name="demo" url="/demo1" />
      <MicroAppWithMemoHistory name="demo" url="/demo2" />
      <MicroAppWithMemoHistory name="demo" url="/demo3" />
      <MicroAppWithMemoHistory name="demo" url="/demo4" />
      <MicroAppWithMemoHistory name="demo" url="/demo5" />
      <MicroAppWithMemoHistory name="demo" url="/demo6" />
    </div>
  )
}

更多的想象空間

工程上的想象空間

微前端架構(gòu)除了其帶來的巨石應(yīng)用解構(gòu)、技術(shù)棧無關(guān)等工程能力外，也為我們對一些已有的工程問題帶來了新的解題思路，比如：

npm 包分發(fā)業(yè)務(wù)組件背后的工程問題

在以前，我們經(jīng)常通過發(fā)布 npm 包的方式復(fù)用/共享我們的業(yè)務(wù)組件，但這種方式存在幾個明顯的問題：

1. npm 包的更新下發(fā)需要依賴產(chǎn)品重新部署才會生效
2. 時間一長就容易出現(xiàn)依賴產(chǎn)品版本割裂導(dǎo)致的體驗不一致
3. 無法灰度
4. 技術(shù)棧耦合

說白了就是 npm 包這種靜態(tài)的共享方式，喪失了動態(tài)下發(fā)代碼的能力，導(dǎo)致了其過慢的工程響應(yīng)速度，這在現(xiàn)在云服務(wù)流行的時代就會顯得格外扎眼。而微前端這種純動態(tài)的服務(wù)依賴方式，恰好能方便的解決上面的問題：被依賴的微應(yīng)用更新后的產(chǎn)物，在產(chǎn)品刷新后即可動態(tài)的獲取到，如果我們在微應(yīng)用加載器中再輔以灰度邏輯，那么動態(tài)更新帶來的變更風(fēng)險也能得到有效的控制。

新的 UI 共享模式

在以前，如果我們希望復(fù)用一個站點(diǎn)的局部 UI，幾乎只有這樣一條路徑：從業(yè)務(wù)系統(tǒng)中抽取出一個組件 -> 發(fā)布 npm 包 -> 調(diào)用方使用 npm 包。

且不說前面提到的 npm 自身的問題，單單是從一個已有的業(yè)務(wù)系統(tǒng)中抽取出一個 UI 組件這個事情，都可能夠我們喝一壺的了。我們不僅要在物理層面，將這部分代碼抽取成若干個單獨(dú)的文件，同時還要考慮如何跟已有的系統(tǒng)做上下文解耦，這類工作出現(xiàn)在一個越是年代久遠(yuǎn)的項目上，實施起來就越是困難，做過這類事情的同學(xué)應(yīng)該都會深有體會。

不同于組件庫的研發(fā)流程，微前端的場景下，大部分時候我們不會為了去復(fù)用一個 UI，而去專門寫一個微應(yīng)用出來。通常我們期望的是，從一個已有系統(tǒng)中，直接選取我們需要復(fù)用的部分，嵌入到我們自己的容器里進(jìn)行渲染。

基于上面提到過的微應(yīng)用多實例的渲染方案，我們可以考慮將需要復(fù)用的組件，以路由 URL 作為 ID 的方式導(dǎo)出。比如我們有這樣一個 A 應(yīng)用有一個這樣的頁面：

function OnePage() {
  return (
    <div>
      <SearchForm/>
      <UserList/>
    </div>
  )
}

我們有另外一個應(yīng)用，希望單獨(dú)復(fù)用 A 應(yīng)用的用戶列表部分的交互跟 UI，那我們只需要多加一條路由規(guī)則：

<Switch>
  ...
  <Route path="/userList" memory={true}>
    <UserList/>
  </Route>
</Switch>

依賴方只需要配合 memory history 并指定 url 為 /userList 即可完成渲染（參考上面嵌套渲染章節(jié)）。

站點(diǎn)即配置

當(dāng)我們將所有可以共享的服務(wù)單元變成一個個獨(dú)立的微應(yīng)用之后，我們便可以通過配置的方式描述我們的站點(diǎn)了，類似：

{
  layout: 'admin-pro',
  apps: [
    { name: 'abc', props: {} },
    { name: 'bcd', props: {} },
    { name: 'cde', props: {} },
  ]
}

其中 layout 可以是一個帶基礎(chǔ)交互框架、用戶鑒權(quán)等公共能力的微應(yīng)用，也可以是一組微應(yīng)用的集合（類似 babel 中的 preset 插件），而 apps 則是一組需要在當(dāng)前站點(diǎn)渲染出來的業(yè)務(wù)微應(yīng)用。

這種方式非常適用于，當(dāng)我們要在一個業(yè)務(wù)域下開發(fā)多個細(xì)分服務(wù)站點(diǎn)時，通過這種配置的方式，配合一個運(yùn)行時的微應(yīng)用編排引擎，快速的生成一系列視覺一致、交互統(tǒng)一的業(yè)務(wù)站點(diǎn)出來。

產(chǎn)品上的想象空間

在有了上面那些場景背后的技術(shù)支撐后，在產(chǎn)品上，我們就已經(jīng)多出很多想象空間了。

但我們還可以想的更極限一點(diǎn)：

比如我們知道微信有一個公眾號浮窗的功能，包括安卓系統(tǒng)常見的小窗模式，解決的就是空間獨(dú)占、以及跨空間時的交互問題。

安卓常見的小窗模式

那我們在中后臺也可以參考類似的設(shè)計，將不同空間的關(guān)聯(lián)性操作以這種非獨(dú)占的形態(tài)聚合到一起，從而降低流程上的斷層感，提升產(chǎn)品體驗。

demo.jpg

（這里本有一張螞蟻內(nèi)部系統(tǒng)的交互示意圖，因涉及保密信息無法公開，有興趣的同學(xué)可以選擇加入我們后做進(jìn)一步的交流分享 ）

寫在最后

微前端提供的這些漸進(jìn)式更新、動態(tài)組合、 服務(wù)拓展的能力，相信大家通過我們介紹的這些常見場景，以及一些極致條件下的解決方案中能窺其一二。

但需要強(qiáng)調(diào)的是，任何技術(shù)架構(gòu)都不可能是銀彈，我們不必對微前端過于神化/劣化。本篇僅希望在分享了我們在微前端領(lǐng)域的一系列探索之后，能給其他開發(fā)者帶來一些新的選擇和啟發(fā)，從而為其工程及產(chǎn)品上帶來更多的可能性

聲明：文章著作權(quán)歸作者所有，如有侵權(quán)，請聯(lián)系小編刪除。

往期推薦

大廠面試過程復(fù)盤(微信/阿里/頭條,附答案篇)

面試題：說說事件循環(huán)機(jī)制(滿分答案來了)

專心工作只想搞錢的前端女程序員的2020

最后

• 歡迎加我微信，拉你進(jìn)技術(shù)群，長期交流學(xué)習(xí)...
  

• 歡迎關(guān)注「前端Q」,認(rèn)真學(xué)前端，做個專業(yè)的技術(shù)人...

點(diǎn)個在看支持我吧