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

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

微前端簡述

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

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

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

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

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

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

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

如何解決這個問題

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

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

2. 沖突和重疊的風(fēng)格

同樣，技術(shù)和團(tuán)隊(duì)的獨(dú)立性很好，但它也會帶來一些問題。這在處理風(fēng)格問題時尤其如此。事實(shí)上，從業(yè)務(wù)角度來看，每個微型前端都不能有自己的風(fēng)格。這是因?yàn)槟憧隙ú幌Ｍ愕膽?yīng)用程序看起來由許多補(bǔ)丁組成。所有的東西都應(yīng)該看起來一致，無論是在風(fēng)格、用戶界面還是用戶體驗(yàn)方面。

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

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

如何解決這個問題

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

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

3. 性能不佳

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

另外，請記住，當(dāng)測試你的微型前端與其他人隔離時，你可能不會注意到這一點(diǎn)。當(dāng)一個框架的多個實(shí)例同時運(yùn)行時，問題就開始了。這是因?yàn)椋绻鼈兪仟?dú)立運(yùn)行的，它們就不必像部署時那樣分享底層機(jī)器的資源。

如何解決這個問題

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

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

4. 前端之間的通信

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

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

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

如何解決這個問題

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

5. 團(tuán)隊(duì)之間的溝通問題

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

如何解決這個問題

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

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

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

總結(jié)

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

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

原文標(biāo)題：??5 Pitfalls of Using Micro Frontends and How to Avoid Them??

作者：Antonello Zanini