本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

比較微型前端與替代架構

如同所有架構策略，採用微型前端的決策必須根據組織原則引導的評估條件。微型前端具有優點和缺點。如果您的組織決定使用微型前端，您必須制定策略來解決分散式系統的挑戰

選擇應用程式架構時，微型前端最熱門的替代方案是單體、n 層應用程式和微型服務，以及單頁應用程式 (SPA) 前端。這些都是有效的方法，而且每個方法都有優點和缺點。

單體

不需要頻繁變更的小型應用程式可以非常快速地以整體形式交付。即使在預期顯著成長的情況下，整體是自然的第一步。稍後，整體結構可以淘汰或重構為更靈活的結構。透過從整體開始，您的組織可以進入市場、取得客戶意見回饋，並更快地改善產品。

不過，如果未仔細維護或程式碼庫隨時間增加大小，單體應用程式通常會降級。當多個團隊對相同的程式碼庫做出重大貢獻時，他們很少對其維護和操作做出貢獻。這會導致責任的不平衡，這會影響速度並導致效率低下。同時，隨著程式碼基礎的演進，整體模組之間的意外耦合會導致意外的副作用。這些副作用可能會導致故障和中斷。

N 層應用程式

具有相對靜態演進步調的更複雜應用程式可以建置為三層架構 （呈現、應用程式、資料），在前端和後端之間具有 REST 或 GraphQL 層。這更具彈性，不同層的團隊可以在某種程度上獨立開發。n 層應用程式的缺點是更難部署功能。前端和後端會透過 API 合約解耦，因此必須一起部署突破性的變更，或必須對 API 進行版本控制。

考慮以下常見案例：如果發佈新功能需要變更資料結構描述，產品擁有者可能需要幾天的時間才能與前端團隊商定一組功能。然後，前端團隊會要求後端團隊開發和發行其端的功能。後端團隊將與資料擁有者合作，以釋出資料庫結構描述更新。接下來，後端團隊將發佈 API 的新版本，以便前端團隊可以開發和發佈其變更。在此案例中，傳播所有生產變更可能需要數週甚至數個月的時間，因為每個團隊都有自己的待處理項目、優先順序，以及開發、測試和發佈變更的機制。

微服務

在微服務架構中，後端會分解為小型服務，每個服務都會解決受限環境中的特定商業問題。透過公開明確定義的界面合約，每個微服務也會與其他 服務強烈分離。

值得一提的是，邊界內容和界面合約也應該存在於精心打造的單體和 n 層架構中。不過，在微服務架構中，通訊會透過網路進行，通常是 HTTP 通訊協定，而 服務具有專用的執行期基礎設施。這支援每個後端服務的獨立開發、交付和操作。

選擇符合您需求的方法

單體和 n 層架構將多個網域問題組合成一個技術成品。這使得相依性和內部資料流程等層面更容易管理，但它使新功能的交付更加困難。為了維持一致的程式碼基底，團隊通常會花時間進行重構和解耦，因為他們必須處理大型程式碼基底。

幾個團隊開發的應用程式可能不需要移動到微型前端所帶來的額外複雜性。如果團隊未支付高耦合和長前置時間來發佈變更的懲罰，則尤其如此。

總而言之，更複雜和分散式架構通常是複雜且快速移動應用程式的最佳選擇。對於中小型應用程式，分散式架構不一定優於單體架構，尤其是在應用程式不會在短時間內大幅演進的情況下。