【CSDN 編者按】只聽(tīng)過(guò)“微服務(wù)”，“微前端”又是什么硬核技術(shù)？

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

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

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

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

為什么需要微前端？

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

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

• 聚合前端應(yīng)用。微服務(wù)架構(gòu)，可以解耦后端服務(wù)間依賴(lài)。而微前端，則關(guān)注于聚合前端應(yīng)用。

• 熱鬧驅(qū)動(dòng)開(kāi)發(fā)。新的技術(shù)，既然很熱鬧，那么就學(xué)吧。

微前端的實(shí)現(xiàn)，意味著對(duì)前端應(yīng)用的拆分。拆分應(yīng)用的目的，并不只是為了架構(gòu)上好看，還為了提升開(kāi)發(fā)效率。

為此，微前端帶來(lái)這么一系列的好處：

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

2. 單一職責(zé)。每個(gè)前端應(yīng)用可以只關(guān)注于自己所需要完成的功能。

3. 技術(shù)棧無(wú)關(guān)。你可以使用 Angular 的同時(shí)，又可以使用 React 和 Vue。

除此，它也有一系列的缺點(diǎn)：

• 應(yīng)用的拆分基礎(chǔ)依賴(lài)于基礎(chǔ)設(shè)施的構(gòu)建，一旦大量應(yīng)用依賴(lài)于同一基礎(chǔ)設(shè)施，那么維護(hù)變成了一個(gè)挑戰(zhàn)。

• 拆分的粒度越小，便意味著架構(gòu)變得復(fù)雜、維護(hù)成本變高。

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

畢竟沒(méi)有銀彈。

如何設(shè)計(jì)微前端架構(gòu)？

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

架構(gòu)模式

微前端應(yīng)用間的關(guān)系來(lái)看，分為兩種：基座模式（管理式）、自組織式。分別也對(duì)應(yīng)了兩者不同的架構(gòu)模式：

• 基座模式。通過(guò)一個(gè)主應(yīng)用，來(lái)管理其它應(yīng)用。設(shè)計(jì)難度小，方便實(shí)踐，但是通用度低。

• 自組織模式。應(yīng)用之間是平等的，不存在相互管理的模式。設(shè)計(jì)難度大，不方便實(shí)施，但是通用度高。

就當(dāng)前而言，基座模式實(shí)施起來(lái)比較方便，方案上便也是蠻多的。

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

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

• 應(yīng)用注冊(cè)。即提供新的微前端應(yīng)用，向應(yīng)用注冊(cè)表注冊(cè)的功能。

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

• 訪問(wèn)權(quán)限等相關(guān)配置。

應(yīng)用在部署的時(shí)候，便可以在注冊(cè)表服務(wù)中注冊(cè)。如果是基于注冊(cè)表來(lái)管理應(yīng)用，那么使用基座模式來(lái)開(kāi)發(fā)比較方便。

設(shè)計(jì)理念

在筆者實(shí)踐微前端的過(guò)程中，發(fā)現(xiàn)了以下幾點(diǎn)是我們?cè)谠O(shè)計(jì)的過(guò)程中，需要關(guān)注的內(nèi)容：

• 中心化：應(yīng)用注冊(cè)表。這個(gè)應(yīng)用注冊(cè)表?yè)碛忻總€(gè)應(yīng)用及對(duì)應(yīng)的入口。在前端領(lǐng)域里，入口的直接表現(xiàn)形式可以是路由，又或者對(duì)應(yīng)的應(yīng)用映射。

• 標(biāo)識(shí)化應(yīng)用。我們需要一個(gè)標(biāo)識(shí)符來(lái)標(biāo)識(shí)不同的應(yīng)用，以便于在安裝、卸載的時(shí)候，能尋找到指定的應(yīng)用。一個(gè)簡(jiǎn)單的模式，就是通過(guò)康威定律來(lái)命名應(yīng)用。

• 應(yīng)用生命周期管理。

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

生命周期

前端微架構(gòu)與后端微架構(gòu)的最大不同之處，也在于此——生命周期。微前端應(yīng)用作為一個(gè)客戶(hù)端應(yīng)用，每個(gè)應(yīng)用都擁有自己的生命周期：

• Load，決定加載哪個(gè)應(yīng)用，并綁定生命周期

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

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

• Unload，刪除應(yīng)用的生命周期

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

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

如何拆分？

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

技術(shù)方式

從技術(shù)實(shí)踐上，微前端架構(gòu)可以采用以下的幾種方式進(jìn)行：

• 路由分發(fā)式。通過(guò) HTTP 服務(wù)器的反向代理功能，來(lái)將請(qǐng)求路由到對(duì)應(yīng)的應(yīng)用上。

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

• 微應(yīng)用。通過(guò)軟件工程的方式，在部署構(gòu)建環(huán)境中，組合多個(gè)獨(dú)立應(yīng)用成一個(gè)單體應(yīng)用。

• 微件化。開(kāi)發(fā)一個(gè)新的構(gòu)建系統(tǒng)，將部分業(yè)務(wù)功能構(gòu)建成一個(gè)獨(dú)立的 chunk 代碼，使用時(shí)只需要遠(yuǎn)程加載即可。

• 前端容器化。通過(guò)將 iFrame 作為容器，來(lái)容納其它前端應(yīng)用。

• 應(yīng)用組件化。借助于 Web Components 技術(shù)，來(lái)構(gòu)建跨框架的前端應(yīng)用。

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

路由分發(fā)式

路由分發(fā)式微前端，即通過(guò)路由將不同的業(yè)務(wù)分發(fā)到不同的、獨(dú)立前端應(yīng)用上。其通?？梢酝ㄟ^(guò) HTTP 服務(wù)器的反向代理來(lái)實(shí)現(xiàn)，又或者是應(yīng)用框架自帶的路由來(lái)解決。如下圖所示：

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

前端微服務(wù)化

前端微服務(wù)化，是微服務(wù)架構(gòu)在前端的實(shí)施，每個(gè)前端應(yīng)用都是完全獨(dú)立（技術(shù)棧、開(kāi)發(fā)、部署、構(gòu)建獨(dú)立）、自主運(yùn)行的，最后通過(guò)模塊化的方式組合出完整的前端應(yīng)用。其架構(gòu)如下圖所示：

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

組合式集成：微應(yīng)用化

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

微應(yīng)用化更多的是以軟件工程的方式，來(lái)完成前端應(yīng)用的開(kāi)發(fā)，因此又可以稱(chēng)之為組合式集成。對(duì)于一個(gè)大型的前端應(yīng)用來(lái)說(shuō)，采用的架構(gòu)方式，往往會(huì)是通過(guò)業(yè)務(wù)作為主目錄，而后在業(yè)務(wù)目錄中放置相關(guān)的組件，同時(shí)擁有一些通用的共享模板。

微件化

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

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

前端容器化

前端容器：iframe

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

結(jié)合 Web Components 構(gòu)建

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

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

業(yè)務(wù)拆分

與微服務(wù)類(lèi)似，要?jiǎng)澐植煌那岸诉吔?，不是一件容易的事。就?dāng)前而言，以下幾種方式是常見(jiàn)的劃分微前端的方式：

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

• 按照權(quán)限拆分。

• 按照變更的頻率拆分。

• 按照組織結(jié)構(gòu)拆分。利用康威定律來(lái)進(jìn)一步拆分前端應(yīng)用。

• 跟隨后端微服務(wù)劃分。實(shí)踐證明， DDD 與事件風(fēng)暴是一種頗為有效的后端微前端拆分模式，對(duì)于前端來(lái)說(shuō)，它也頗有有效——直接跟蹤后端服務(wù)。

每個(gè)項(xiàng)目都有自己特殊的背景，切分微前端的方式便不一樣。即使項(xiàng)目的類(lèi)型相似，也存在一些細(xì)微的差異。

微前端之外

如果微前端對(duì)于你們來(lái)說(shuō)困境重重，還有一些不錯(cuò)的架構(gòu)模式可以采用。

應(yīng)用微化架構(gòu)

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

• 構(gòu)建時(shí)拆分架構(gòu)。

• 代碼刪除架構(gòu)。以刪代碼的方式，來(lái)形成每個(gè)前端應(yīng)用。

• 微前端準(zhǔn)備式架構(gòu)。即，隨時(shí)可以拆分為多個(gè)前端應(yīng)用。

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

即：微應(yīng)用化，是一個(gè)隨時(shí)可合并式架構(gòu)。而應(yīng)用微化，則是一個(gè)隨時(shí)可拆分式架構(gòu)。

它不僅僅是一個(gè)適合于前端的架構(gòu)模式，也是一適用于后端的架構(gòu)模式。

整潔前端架構(gòu)

Clean Architecture 是由 Robert C. Martin 在 2012 年提出的架構(gòu)模式。它具有這么一些特點(diǎn)：框架無(wú)關(guān)性、可被測(cè)試、UI 無(wú)關(guān)性、數(shù)據(jù)庫(kù)無(wú)關(guān)性、外部機(jī)構(gòu)（agency）無(wú)關(guān)性。

對(duì)于前端架構(gòu)來(lái)說(shuō)，Clean Architecure 實(shí)際上是：Clean Architecture + MVP + 組件化。如下圖所示：

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

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

沒(méi)有銀彈。不得不提及的是，對(duì)于小規(guī)模的團(tuán)隊(duì)來(lái)說(shuō)，它帶來(lái)的弊端可能會(huì)遠(yuǎn)遠(yuǎn)大于好處——帶來(lái)大量冗余的代碼。盡管通過(guò) Angular Schematics 可以通過(guò)參數(shù)來(lái)生成代碼，但是這種分層架構(gòu)地于簡(jiǎn)單的應(yīng)用來(lái)說(shuō)，還是過(guò)于復(fù)雜、難以上手。對(duì)于不寫(xiě)測(cè)試的項(xiàng)目來(lái)說(shuō) ，usecase 也不能帶來(lái)它們所承諾的好處。

結(jié)論

微前端不是銀彈，當(dāng)前也沒(méi)有最佳實(shí)踐，但是這是一個(gè)非常好的學(xué)習(xí)機(jī)會(huì)。

節(jié)選自《前端架構(gòu)：從入門(mén)到微前端》