本文將分享我和我的團隊在使用微前端時學到的重要經驗。在兩年的時間里，我們發現了這種架構的許多問題，也犯了同樣多的錯誤。所以，現在分享出來，以幫助你解決或避免它們。

讓我們首先回顧一下什么是微前端架構，然后深入了解它們的陷阱以及如何避免每一個陷阱。

微前端簡述

Martin Fowler將微前端開發方法定義為：

一種架構風格，獨立交付的前端應用程序被組成一個更大的整體。

當應用于Web開發時，它意味著有許多獨立的小型前端應用程序是同一個網站或Web應用程序的一部分。正如這里已經提到的，我的團隊已經成功地使用了這種方法。特別是我們有機會利用它的所有優點，如可擴展性、技術獨立性和可維護性。另一方面，從長遠來看，我們注意到一些嚴重的問題。所以，我們決定放棄這種架構方式，轉而回到更傳統的單體架構。

這意味著，我們不僅學到了微前端的優點，也學到了它們的主要缺點。現在讓我們深入了解它們，看看我們應該如何避免或解決它們。

1. 冗余的依賴關系

根據定義，每個微前端應用程序都是獨立于其他應用程序的。換句話說，一個微型前端架構涉及到一個以上的前端應用程序，它們也應該能夠在沒有其他應用程序的情況下工作。為了實現這一點，它們中的每一個都有自己的依賴關系。所以，從整體上看，你會失去使用包管理器的好處。事實上，你的整個應用程序很可能由許多版本的相同庫組成，分散在各個微前端。

這無疑是一個問題，因為它使你的網絡應用不必要地比它的單體對應物大。這就落在了終端用戶身上，他們被迫下載更多的數據。此外，這還會影響到渲染時間，從而影響到Google Web Vitals 的得分，也影響到你的網站的SEO。

如何解決這個問題

一個可能的解決方案包括三個步驟。首先，確定所有微前端的通用庫集。第二，創建一個包含所有共享庫的微前端。然后，更新你的微前端，使他們的構建包從這個共享項目中導入所需的庫。

正如 Martin Fowler的原始博文中所描述的那樣，這個想法來自于應用程序之間的共享依賴關系，這帶來了許多障礙，不能被認為是一項容易完成的任務。因此，在你試圖實現這一目標時，請記住這一點。

2. 沖突和重疊的風格

同樣，技術和團隊的獨立性很好，但它也會帶來一些問題。這在處理風格問題時尤其如此。事實上，從業務角度來看，每個微型前端都不能有自己的風格。這是因為你肯定不希望你的應用程序看起來由許多補丁組成。所有的東西都應該看起來一致，無論是在風格、用戶界面還是用戶體驗方面。

另一個由多個前端作為同一應用程序的一部分而產生的問題是，你可能最終會出現無意的CSS規則覆蓋。在處理微型前端時，CSS方面的非預期的重疊是很常見的，而且你可能在部署你的應用程序后才發現它們。原因是每個團隊通常只在自己的應用程序上工作，而在部署前沒有看到全貌。

這些問題會對你的品牌聲譽產生負面影響。而且，終端用戶將為這些不一致的地方付出代價，特別是在用戶界面方面。

如何解決這個問題

當涉及到 UI 和 UX 時，唯一可能的解決方案是確保每個團隊相互交談并考慮到相同的結果。此外，在上述共享微前端項目中添加樣式組件可能會有所幫助。然而，這將使每個微前端應用程序都依賴于它，并因此破壞了底層的獨立性。但至少它會避免你的應用程序作為一個整體看起來是異構的。

如果你想避免 CSS 重疊，一個解決方案是在前端容器中添加一個 ID <div>。然后，配置 webpack 以在每個 CSS 規則之前插入此 ID。否則，您可以決定采用 CSS 方法，例如 BEM（Block-Element-Modifier）。這鼓勵你將網站視為可重用組件塊的集合，其類名在你的項目中應該是唯一的。

3. 性能不佳

在同一個頁面上運行一個以上的JavaScript前端應用程序，會因此而降低整個應用程序的速度。這是因為每個框架實例都需要CPU、內存和網絡帶寬方面的資源。

另外，請記住，當測試你的微型前端與其他人隔離時，你可能不會注意到這一點。當一個框架的多個實例同時運行時，問題就開始了。這是因為，如果它們是獨立運行的，它們就不必像部署時那樣分享底層機器的資源。

如何解決這個問題

解決這個問題的一個想法是，加強團隊溝通，避免做同樣的調用和闡述。然后，將他們的結果存儲在每個微前端都能訪問的地方，或者讓他們在執行繁重的操作之前進行溝通，以驗證之前是否已經檢索或生成過相同的數據。

另外，當涉及到性能時，你必須用所有的微前端來測試應用程序，而不要僅僅依靠對每個微前端的測試。

4. 前端之間的通信

最初，你不需要讓你的微型前端進行通信，除非在極少數情況下。這可能會愚弄你，讓你以為會一直這樣。另外，雖然微前端的架構模式是關于獨立性的，但這是與通信相對的。

當應用程序作為一個整體增長時，使你的微前端能夠毫不費力地相互溝通可能會成為一個優先事項。最重要的是，如果你想不斷地重復同樣的操作，特別是在它們不是空閑的情況下。

另外，如上所述，為了實現更高的性能，溝通是必要的。例如，你不希望你的應用程序為了檢索相同的數據而兩次調用相同的API，并不必要地拖慢你的服務器。

如何解決這個問題

解決方案是基于存儲在cookie或localStorage中的共享狀態，或基于自定義定義的事件，實現一個自定義的信息傳遞層。正如你所想象的，實現這一點是有成本的，而且很快就會變得復雜和麻煩，難以處理。另外，要考慮到通信會引入開銷。所以，你必須確定你所構建的東西會帶來真正的好處，并且不會使你的應用程序變得更加緩慢。

5. 團隊之間的溝通問題

大型團隊的溝通可能是一個問題，但最糟糕的莫過于幾個團隊之間的溝通。這是因為有多個團隊在不同的代碼庫上工作意味著尋找可重用的功能、函數和實用程序變得更加困難。這在代碼的可發現性方面是很糟糕的，因此也是可重用的。換句話說，你可能會很容易地在不同的微觀前臺出現相同組件的重復實現。

如何解決這個問題

解決方案是在一開始就支持團隊之間的溝通邏輯。如上所述，這涉及到為所采用的每種技術擁有一個具有可重復使用資源的項目。但是，有這樣一個項目而不保持更新，會使它變得毫無用處。

因此，你必須允許每個團隊向其添加組件和庫。此外，擁有一個專門的團隊可以使整個過程更容易。事實上，對于一個獨立和孤立的團隊來說，可能不容易理解哪些元素將被一個以上的微型前端所共享。

此外，不要把技術獨立看成是幾個孤立的團隊。恰恰相反，讓團隊之間互相交流，并讓自己保持最新的狀態，對項目的成功至關重要。因此，在采用微型前端架構時，培養一種溝通文化必須是關鍵因素之一。

總結

在這篇文章中，我們看了微前端架構方法的五個最大的陷阱，并以我的團隊兩年來每天與之打交道時積累的經驗為依據。盡管微前端方法讓開發者把一個前端應用分成更小的獨立部分，但這并不意味著每個團隊也應該是孤立的。相反，分享解決方案、組件、資源和知識是成功的關鍵。

不幸的是，我們作為一個團隊并不了解這一點。因此，我們被迫放棄了我們的微型前端之旅。但我們從這次冒險中學到了很多東西，我希望分享導致我們失敗的主要原因以及如何避免或抵消它們是有用的。

原文標題：??5 Pitfalls of Using Micro Frontends and How to Avoid Them??

作者：Antonello Zanini