【CSDN 編者按】只聽過“微服務”，“微前端”又是什么硬核技術？

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

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

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

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

為什么需要微前端？

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

• 遺留系統(tǒng)遷移。解決遺留系統(tǒng)，才是人們采用微前端方案最重要的原因。

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

• 熱鬧驅動開發(fā)。新的技術，既然很熱鬧，那么就學吧。

微前端的實現(xiàn)，意味著對前端應用的拆分。拆分應用的目的，并不只是為了架構上好看，還為了提升開發(fā)效率。

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

1. 應用自治。只需要遵循統(tǒng)一的接口規(guī)范或者框架，以便于系統(tǒng)集成到一起，相互之間是不存在依賴關系的。

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

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

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

• 應用的拆分基礎依賴于基礎設施的構建，一旦大量應用依賴于同一基礎設施，那么維護變成了一個挑戰(zhàn)。

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

• 技術棧一旦多樣化，便意味著技術?；靵y。

畢竟沒有銀彈。

如何設計微前端架構？

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

架構模式

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

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

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

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

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

• 應用發(fā)現(xiàn)。讓主應用可以尋找到其它應用。

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

• 第三方應用注冊。即讓第三方應用，可以接入到系統(tǒng)中。

• 訪問權限等相關配置。

應用在部署的時候，便可以在注冊表服務中注冊。如果是基于注冊表來管理應用，那么使用基座模式來開發(fā)比較方便。

設計理念

在筆者實踐微前端的過程中，發(fā)現(xiàn)了以下幾點是我們在設計的過程中，需要關注的內(nèi)容：

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

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

• 應用生命周期管理。

• 高內(nèi)聚，低耦合。

生命周期

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

• Load，決定加載哪個應用，并綁定生命周期

• bootstrap，獲取靜態(tài)資源

• Mount，安裝應用，如創(chuàng)建 DOM 節(jié)點

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

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

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

如何拆分？

隨后，我們要面臨的一個挑戰(zhàn)是：如何去拆分應用。

技術方式

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

• 路由分發(fā)式。通過 HTTP 服務器的反向代理功能，來將請求路由到對應的應用上。

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

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

• 微件化。開發(fā)一個新的構建系統(tǒng)，將部分業(yè)務功能構建成一個獨立的 chunk 代碼，使用時只需要遠程加載即可。

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

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

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

路由分發(fā)式

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

就當前而言，路由分發(fā)式的架構應該是采用最多、最容易的 “微前端” 方案。

前端微服務化

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

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

組合式集成：微應用化

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

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

微件化

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

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

前端容器化

前端容器：iframe

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

結合 Web Components 構建

Web Components 是一套不同的技術，允許開發(fā)者創(chuàng)建可重用的定制元素（它們的功能封裝在代碼之外），并且在 Web 應用中使用它們。

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

業(yè)務拆分

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

• 按照業(yè)務拆分。

• 按照權限拆分。

• 按照變更的頻率拆分。

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

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

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

微前端之外

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

應用微化架構

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

• 構建時拆分架構。

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

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

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

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

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

整潔前端架構

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

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

考慮到應用的規(guī)模，這里以 Angular + TypeScript 作為示例：

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

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

結論

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

節(jié)選自《前端架構：從入門到微前端》