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

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

微前端簡述

Martin Fowler將微前端開發(fā)方法定義為：

一種架構(gòu)風格，獨立交付的前端應(yīng)用程序被組成一個更大的整體。

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

這意味著，我們不僅學到了微前端的優(yōu)點，也學到了它們的主要缺點。現(xiàn)在讓我們深入了解它們，看看我們應(yīng)該如何避免或解決它們。

1. 冗余的依賴關(guān)系

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

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

如何解決這個問題

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

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

2. 沖突和重疊的風格

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

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

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

如何解決這個問題

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

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

3. 性能不佳

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

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

如何解決這個問題

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

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

4. 前端之間的通信

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

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

另外，如上所述，為了實現(xiàn)更高的性能，溝通是必要的。例如，你不希望你的應(yīng)用程序為了檢索相同的數(shù)據(jù)而兩次調(diào)用相同的API，并不必要地拖慢你的服務(wù)器。

如何解決這個問題

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

5. 團隊之間的溝通問題

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

如何解決這個問題

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

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

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

總結(jié)

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

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

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

作者：Antonello Zanini