寫在前面：本文節選自ThoughtWorks 黃峰達《前端架構：從入門到微前端》一書。這是一本圍繞前端架構的實施手冊，從基礎的架構規範，到如何設計前端架構，再到採用微前端架構拆分複雜的前端應用。通過系統地介紹前端架構世界的方方面面，來幫助前端工程師更好地進行系統設計。
微前端如何落地？
在過去的幾個星期裡，隨著 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
iframe 作為一個非常 “古老” 的，人人都覺得普通的技術，卻一直很管用。它能有效地將另一個網頁/單頁面應用嵌入到當前頁面中，兩個頁面間的 CSS 和 JavaScript 是相互隔離的——除去 iframe 父子通訊部分的程式碼，它們之間的程式碼是完全不相互干擾的。iframe 便相當於是建立了一個全新的獨立的宿主環境，類似於沙箱隔離，它意味著前端應用之間可以相互獨立執行。
結合 Web Components 構建
Web Components 是一套不同的技術，允許開發者建立可重用的定製元素（它們的功能封裝在程式碼之外），並且在 web 應用中使用它們。
目前困擾 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 作為示例：
這種架構模式特別適合於：組織內即寫前端又同後端的團隊。它易於對映前後端 API，且可以使用 usecase 作為防腐層。
沒有銀彈。不得不提及的是，對於小規模的團隊來說，它帶來的弊端可能會遠遠大於好處——帶來大量冗餘的程式碼。儘管通過 Angular Schematics 可以通過引數來生成程式碼，但是這種分層架構地於簡單的應用來說，還是過於複雜、難以上手。對於不寫測試的專案來說 ，usecase 也不能帶來它們所承諾的好處。
結論
微前端不是銀彈，當前也沒有最佳實踐，但是這是一個非常好的學習機會。
文/ThoughtWorks黃峰達
更多精彩洞見，請關注微信公眾號：ThoughtWorks洞見