作者 | Phodal

責編 | 伍杏玲

【CSDN 編者按】只聽過「微服務」，「微前端」又是什麼硬核技術？

它正是借鑒微服務的概念來應用在前端上，將一個巨大的前端工程拆分成一個的小工程，這些小工程具備獨立的開發和運行能力，而整個系統就由這些小工程協同合作。

這個理念很好，可在實際開發中，又該如何落地？如何拆分呢？涉及何種技術？在本文中，作者將從淺入深，逐步為大家講解。

隨著 Martin Fowler 博客上，那篇 Cam Jackson 寫的微前端的文章發布，到處都在討論 Microfrontend。作為一個微前端 「專家」，我也分享一下：如何去落地微前端。

微前端是一種類似於微服務的架構，它將微服務的理念應用於瀏覽器端，即將單頁面前端應用由單一的單體應用轉變為多個小型前端應用聚合為一的應用。各個前端應用還可以獨立開發、獨立部署。同時，它們也可以在共享組件的同時進行並行開發——這些組件可以通過 NPM 或者 Git Tag、Git Submodule 來管理。

微前端不是銀彈，它和微服務一樣會帶來大量的挑戰。

• 遺留系統遷移。解決遺留系統，才是人們採用微前端方案最重要的原因。

• 聚合前端應用。微服務架構，可以解耦後端服務間依賴。而微前端，則關注於聚合前端應用。

• 熱鬧驅動開發。新的技術，既然很熱鬧，那麼就學吧。

微前端的實現，意味著對前端應用的拆分。拆分應用的目的，並不只是為了架構上好看，還為了提升開發效率。

為此，微前端帶來這麼一系列的好處：

1. 應用自治。只需要遵循統一的介面規範或者框架，以便於系統集成到一起，相互之間是不存在依賴關係的。

2. 單一職責。每個前端應用可以只關注於自己所需要完成的功能。

3. 技術棧無關。你可以使用 Angular 的同時，又可以使用 React 和 Vue。

除此，它也有一系列的缺點：

• 應用的拆分基礎依賴於基礎設施的構建，一旦大量應用依賴於同一基礎設施，那麼維護變成了一個挑戰。

• 拆分的粒度越小，便意味著架構變得複雜、維護成本變高。

• 技術棧一旦多樣化，便意味著技術棧混亂。

畢竟沒有銀彈。

就當前而言，要設計出一個微前端應用不是一件容易的事——還沒有最佳實踐。在不同的落地案例里，使用的都是不同的方案。出現這種情況的主要原因是，每個項目所面臨的情況、所使用的技術都不盡相同。為此，我們需要了解一些基礎的微前端模式。

微前端應用間的關係來看，分為兩種：基座模式（管理式）、自組織式。分別也對應了兩者不同的架構模式：

• 基座模式。通過一個主應用，來管理其它應用。設計難度小，方便實踐，但是通用度低。

• 自組織模式。應用之間是平等的，不存在相互管理的模式。設計難度大，不方便實施，但是通用度高。

就當前而言，基座模式實施起來比較方便，方案上便也是蠻多的。

而不論種方式，都需要提供一個查找應用的機制，在微前端中稱為服務的註冊表模式。和微服務架構相似，不論是哪種微前端方式，也都需要有一個應用註冊表的服務，它可以是一個固定值的配置文件，如 JSON 文件，又或者是一個可動態更新的配置，又或者是一種動態的服務。它主要做這麼一些內容：

• 應用發現。讓主應用可以尋找到其它應用。

• 應用註冊。即提供新的微前端應用，嚮應用註冊表註冊的功能。

• 第三方應用註冊。即讓第三方應用，可以接入到系統中。

• 訪問許可權等相關配置。

應用在部署的時候，便可以在註冊表服務中註冊。如果是基於註冊表來管理應用，那麼使用基座模式來開發比較方便。

在筆者實踐微前端的過程中，發現了以下幾點是我們在設計的過程中，需要關注的內容：

• 中心化：應用註冊表。這個應用註冊表擁有每個應用及對應的入口。在前端領域裡，入口的直接表現形式可以是路由，又或者對應的應用映射。

• 標識化應用。我們需要一個標識符來標識不同的應用，以便於在安裝、卸載的時候，能尋找到指定的應用。一個簡單的模式，就是通過康威定律來命名應用。

• 應用生命周期管理。

• 高內聚，低耦合。

生命周期

前端微架構與後端微架構的最大不同之處，也在於此——生命周期。微前端應用作為一個客戶端應用，每個應用都擁有自己的生命周期：

• Load，決定載入哪個應用，並綁定生命周期

• bootstrap，獲取靜態資源

• Mount，安裝應用，如創建 DOM 節點

• Unload，刪除應用的生命周期

• Unmount，卸載應用，如刪除 DOM 節點、取消事件綁定

這部分的內容事實上，也就是微前端的一個難點所在，如何以合適的方式來載入應用——畢竟每個前端框架都各自不同，其所需要的載入方式也是不同的。當我們決定支持多個框架的時候，便需要在這一部分進入更細緻的研究。

隨後，我們要面臨的一個挑戰是：如何去拆分應用。

從技術實踐上，微前端架構可以採用以下的幾種方式進行：

• 路由分髮式。通過 HTTP 伺服器的反向代理功能，來將請求路由到對應的應用上。

• 前端微服務化。在不同的框架之上設計通訊、載入機制，以在一個頁面內載入對應的應用。

• 微應用。通過軟體工程的方式，在部署構建環境中，組合多個獨立應用成一個單體應用。

• 微件化。開發一個新的構建系統，將部分業務功能構建成一個獨立的 chunk 代碼，使用時只需要遠程載入即可。

• 前端容器化。通過將 iFrame 作為容器，來容納其它前端應用。

• 應用組件化。藉助於 Web Components 技術，來構建跨框架的前端應用。

實施的方式雖然多，但是都是依據場景而採用的。有些場景下，可能沒有合適的方式；有些場景下，則可以同時使用多種方案。

路由分髮式微前端，即通過路由將不同的業務分發到不同的、獨立前端應用上。其通常可以通過 HTTP 伺服器的反向代理來實現，又或者是應用框架自帶的路由來解決。如下圖所示：

路由分髮式

就當前而言，路由分髮式的架構應該是採用最多、最容易的 「微前端」 方案。

前端微服務化，是微服務架構在前端的實施，每個前端應用都是完全獨立（技術棧、開發、部署、構建獨立）、自主運行的，最後通過模塊化的方式組合出完整的前端應用。其架構如下圖所示：

前端微服務化

採用這種方式意味著，一個頁面上同時存在二個及以上的前端應用在運行。而路由分髮式方案，則是一個頁面只有唯一一個應用。

微應用化，即在開發時，應用都是以單一、微小應用的形式存在，而在運行時，則通過構建系統合併這些應用，組合成一個新的應用。其架構如下圖所示：

微應用化

微應用化更多的是以軟體工程的方式，來完成前端應用的開發，因此又可以稱之為組合式集成。對於一個大型的前端應用來說，採用的架構方式，往往會是通過業務作為主目錄，而後在業務目錄中放置相關的組件，同時擁有一些通用的共享模板。

微件（widget），指的是一段可以直接嵌入在應用上運行的代碼，它由開發人員預先編譯好，在載入時不需要再做任何修改或者編譯。而微前端下的微件化則指的是，每個業務團隊編寫自己的業務代碼，並將編譯好的代碼部署（上傳或者放置）到指定的伺服器上，在運行時，我們只需要載入相應的業務模塊即可。對應的，在更新代碼的時候，我們只需要更新對應的模塊即可。下圖便是微件化的架構示意圖：

微件化

在非單面應用時代，要實現微件化方案，是一件特別容易的事。從遠程載入來對應的 JavaScript 代碼，在瀏覽器上執行，生成對應的組件嵌入到頁面的相應部分。對於業務組件也是類似的，提前編寫好我們的業務組件，當需要對應的組件時再響應、執行。

iframe 作為一個非常 「古老」 的，人人都覺得普通的技術，卻一直很管用。它能有效地將另一個網頁/單頁面應用嵌入到當前頁面中，兩個頁面間的 CSS 和 JavaScript 是相互隔離的——除去 iframe 父子通信部分的代碼，它們之間的代碼是完全不相互干擾的。iframe 便相當於是創建了一個全新的獨立的宿主環境，類似於沙箱隔離，它意味著前端應用之間可以相互獨立運行。

結合 Web Components 構建

Web Components 是一套不同的技術，允許開發者創建可重用的定製元素（它們的功能封裝在代碼之外），並且在 Web 應用中使用它們。

WC 容器化

目前困擾 Web Components 技術推廣的主要因素，在於瀏覽器的支持程度。在 Chrome 和 Opera 瀏覽器上，對於 Web Components 支持良好，而對於 Safari、IE、Firefox 瀏覽器的支持程度，並沒有那麼理想。

與微服務類似，要劃分不同的前端邊界，不是一件容易的事。就當前而言，以下幾種方式是常見的劃分微前端的方式：

• 按照業務拆分。

• 按照許可權拆分。

• 按照變更的頻率拆分。

• 按照組織結構拆分。利用康威定律來進一步拆分前端應用。

• 跟隨後端微服務劃分。實踐證明， DDD 與事件風暴是一種頗為有效的後端微前端拆分模式，對於前端來說，它也頗有有效——直接跟蹤後端服務。

每個項目都有自己特殊的背景，切分微前端的方式便不一樣。即使項目的類型相似，也存在一些細微的差異。

如果微前端對於你們來說困境重重，還有一些不錯的架構模式可以採用。

應用微化架構，是一種開發時整體，構建時拆分，運行時分離的前端架構模式。即應用微化架構從一份代碼中，構建出適用於不同環境的多套目標代碼。實現上它是一種：

• 構建時拆分架構。

• 代碼刪除架構。以刪代碼的方式，來形成每個前端應用。

• 微前端準備式架構。即，隨時可以拆分為多個前端應用。

由於它與微應用化的相似性，我們將它與微應用化做一個對比。它與微應用化不同的是，應用微化是在構建時對應用進行拆分，而非在本地模式下對應用拆分。相似的是，它也是基於構建系統的應用拆分方式。

可拆分式微前端

即：微應用化，是一個隨時可合併式架構。而應用微化，則是一個隨時可拆分式架構。

它不僅僅是一個適合於前端的架構模式，也是一適用於後端的架構模式。

Clean Architecture 是由 Robert C. Martin 在 2012 年提出的架構模式。它具有這麼一些特點：框架無關性、可被測試、UI 無關性、資料庫無關性、外部機構（agency）無關性。

對於前端架構來說，Clean Architecure 實際上是：Clean Architecture + MVP + 組件化。如下圖所示：

考慮到應用的規模，這裡以 Angular + TypeScript 作為示例：

Clean Frontend

這種架構模式特別適合於：組織內即寫前端又同後端的團隊。它易於映射前後端 API，且可以使用 UseCase 作為防腐層。

沒有銀彈。不得不提及的是，對於小規模的團隊來說，它帶來的弊端可能會遠遠大於好處——帶來大量冗餘的代碼。儘管通過 Angular Schematics 可以通過參數來生成代碼，但是這種分層架構地於簡單的應用來說，還是過於複雜、難以上手。對於不寫測試的項目來說 ，usecase 也不能帶來它們所承諾的好處。

微前端不是銀彈，當前也沒有最佳實踐，但是這是一個非常好的學習機會。

節選自《前端架構：從入門到微前端》

作者簡介：黃峰達（Phodal），ThoughtWorks Senior Consultant，CSDN 博客專家。長期活躍於 GitHub、CSDN，專註於物聯網和前端領域。出版著作《自己動手設計物聯網》，以及《Growth：全棧增長工程師指南》等六本電子書，並譯有《物聯網實戰指南》。

本文系作者投稿，版權歸作者所有。

【END】

推 薦

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！