微前端快速選型指南

在之前那篇《實施前端微服務化的六七種方式》中，介紹了在實施微前端的過程中，我們採用的一些不同方案的架構方案。在這篇文章中，我將總結如何依據不同的情況來選擇合適的方案。

快速選型指南圖

我還是直接先給結論：

關鍵點的相關解釋如下：

框架限制

。在後臺微服務系統裡，人們使用其它語言的庫來開發新的服務，如用於人工智慧的 Python。但是在前端，幾乎不存在這種可能性。所以當我們的前端框架只有一個時，我們在採用微前端的技術時，可選範圍就更大了。而遺憾的是，多陣列織需要相容遺留系統。

IE 問題

。不論是在幾年前，還是在今年，我們實施微前端最先考慮的就是對於 IE 的支援。在我遇到的專案上，基本上都需要支援 IE，因此在技術選型上就受限一定的限制。而在我們那些不需要支援 IE 的專案上，他們就可以使用 WebComponents 技術來構建微前端應用。

依賴獨立

。即各個微前端應用的依賴是要統一管理，還是要在各個應該中自己管理。統一管理可以解決重複載入依賴的問題，獨立管理會帶來額外的流量開銷和等待時間。

微前端方案的對比：簡要對比

如果你對上述的幾個方面，仍然不是很熟悉的話，請閱讀《

實施前端微服務化的六七種方式

》。

同樣的，一些複雜概念的解釋如下：

應用微服務化

，即每個前端應用一個獨立的服務化前端應用，並配套一套統一的應用管理和啟動機制，諸如微前端框架 Single-SPA 或者 mooa 。

微件化

，即透過對構建系統的 hack，使不同的前端應用可以使用同一套依賴。它在

應用微服務化

的基本上，改進了重複載入依賴檔案的問題。

微應用化

，又可以稱之為

組合式整合

，即透過軟體工程的方式，在開發環境對單體應用進行拆分，在構建環境將應用組合在一起構建成一個應用。詳細的細節，可以期待後面的文章《

一個單體前端應用的拆解與微服務化

》

微前端方案的對比：複雜方式

之前看到一篇微服務相關的 文章，介紹了不同微服務的區別，其採用了一種比較有意思的對比方式特別詳細，這裡就使用同樣的方式來展示：

那麼，對於下表而言，表中的 a~j 分別表示上面的幾種不同的架構考慮因素。

（PS：考慮到 Web Components 幾個單詞的長度，暫時將它簡稱為 WC~~）

圖中的 O 表示支援，空白表示不支援，- 表示不受影響。

再結合之前的選型指南：

（PS：本圖採用 Keynote 繪製）

你是否找到你想到的架構了？

出自《微前端的那些事兒》