前言

最近幾年微前端一直是前端界的熱門議題, 它類似于微服務架構(gòu), 主要面向于瀏覽器端，能將一個復雜而龐大的單體應用拆分為多個功能模塊清晰且獨立的子應用,且共同服于務同一個主應用。各個子應用可以獨立運行、獨立開發(fā)和獨立部署。

微前端架構(gòu)概念的誕生及應用對于提供復雜應用服務的企業(yè)來說顯然是一種機遇, 同樣也是一種挑戰(zhàn).本文主要就微前端架構(gòu)的概念和實現(xiàn)方案做一個總結(jié)和復盤,并且通過一個實際案例來實踐微前端架構(gòu),希望能對同樣有此需求的朋友們提供一些幫助和思路。

你將收獲

• 什么是微服務以及微服務能給企業(yè)帶來什么。
• 微前端架構(gòu)概念及方案。
• umi下的微前端架構(gòu)方案實戰(zhàn)。
• 一個程序員的技術復盤與展望。

正文

在總結(jié)微前端架構(gòu)之前,讓我們來先看看微服務是什么。

1、什么是微服務以及微服務能給企業(yè)帶來什么

微服務是一種用于構(gòu)建應用的架構(gòu)方案。微服務架構(gòu)有別于更為傳統(tǒng)的單體式方案，可將應用拆分成多個核心功能。每個功能都被稱為一項服務，可以單獨構(gòu)建和部署，這意味著各項服務在工作（和出現(xiàn)故障）時不會相互影響。

傳統(tǒng)的web軟件開發(fā)架構(gòu)往往如下圖所示:

雖然我們在傳統(tǒng)應用中可以采用模塊化來拆分業(yè)務邏輯和開發(fā)方式,但最終它們會打包并部署為單體式應用。這種架構(gòu)往往更適合中小型項目, 開發(fā)簡單直接,更適合集中化管理應用.但往往也會存在很多缺點,比如可擴展性不足,相同或者相似業(yè)務復用困難,部署時間長, 業(yè)務復雜之后很難維護等問題。

對于復雜系統(tǒng)和業(yè)務來說,我們一般會采用微服務架構(gòu)。其思路是將一個完整的應用分解為小的、互相連接的微服務,每個服務完成特定的功能, 并且某些特定的服務還能為其他服務提供API接口。

由上圖可以發(fā)現(xiàn)微服務給我們帶來的好處:

• 將一個龐大的單體拆解成多個子服務,大大降低了開發(fā)復雜度。
• 任務邊界劃分明確, 每個子服務之間單獨開發(fā), 不同服務之間可并行由不同的開發(fā)人員開發(fā),提高開發(fā)效率。
• 更細粒度的加強了模塊化進程, 可維護性和可讀性更高。
• 團隊之間只要制定好API約定, 那么不同成員或者團隊可以采用不同的技術開發(fā)服務。
• 可用共享服務, 使得不同子服務可組合實現(xiàn)更復雜的功能。
• 每個微服務可獨立部署發(fā)布,使得自動化CI(持續(xù)集成)/CD(持續(xù)交付)成為可能。

但微服務并不是任何場景下都是合適的, 微服務的目標是充分分解應用程序，以促進敏捷開發(fā)和持續(xù)集成部署。在部署微服務時我們需要做好適當?shù)倪吔鐒澐?并處理不同微服務之間的并發(fā)問題,這些都是對整個項目帶來的挑戰(zhàn),需要更加專業(yè)的技術成員來把控.目前市面上也有很多開源的微服務框架比如Dubbo, Spring Cloud等,筆者之前公司采用的Spring Cloud就是一個很好的微服務架構(gòu)方案。

2、微前端架構(gòu)概念及方案

（1）理解微前端架構(gòu)

上面簡單介紹了一下微服務架構(gòu),接下來我們進入主題,來聊聊微前端. 微前端和微服務實現(xiàn)的目的類似,都是將應用由單一的單體應用轉(zhuǎn)變?yōu)槎鄠€小型子應用,差別就在于:

• 微前端應用于瀏覽器端,主要是對web應用進行拆解,最后將不同子系統(tǒng)(模塊)聚合成一個完整的應用。
• 微前端主要目的是聚合,即將不同子系統(tǒng)聚合成一個大系統(tǒng),而微服務架構(gòu)目前更多是解耦,即解耦不同服務間的依賴。

我們先來看看微前端的一些思考者.

Michael Geers 大佬發(fā)表了一些對微前端的一些思考,內(nèi)容大致總結(jié)一下就是:

“ 微前端 ”是將微服務的概念擴展到前端領域。為了構(gòu)建一個功能強大的瀏覽器應用程序（也稱為單頁應用程序），當前普遍的趨勢是將其建立在微服務架構(gòu)之上。但是隨著時間的流逝，通常由獨立團隊開發(fā)的前端層會不斷增長，并且變得更加難以維護。Micro Frontends背后的想法是將Web應用程序視為由獨立團隊擁有的功能的組合。每個團隊都有自己關心和專長的不同業(yè)務或任務領域。每個團隊可以跨職能，并且從數(shù)據(jù)庫到用戶界面，端到端地開發(fā)其功能。

正如下面的例子所示:

當我們的系統(tǒng)中有多個不同的子模塊,并且子模塊之間有相對獨立且完整的功能體系時, 一旦子模塊變得越來越多, 那么整個應用將變得非常龐大且臃腫,開發(fā)和維護成本大大提高.如果在這種場景下我們采用SPA模式開發(fā),那么項目后期將變得不可想象,頁面首次加載將變得非常慢(筆者曾經(jīng)就經(jīng)歷過,開發(fā)一個復雜系統(tǒng)頁面首次加載花了20多秒,所以不得不采用MPA來處理); 但是我們采用MPA(多頁應用)模式,雖然解決了應用臃腫的問題, 但仍然存在很多有待處理問題,比如模塊切換需要重新刷新頁面, 公共組件無法共享,子模塊直接,父子模塊之間的通信問題,開發(fā)部署繁瑣等.這寫都是傳統(tǒng)開發(fā)模式會遇到的問題。

試想一下,如果面對以上問題, 如果有一種架構(gòu)模式, 可以讓我們在主應用中共享公共組件和狀態(tài)(但是要保證子應用運行時內(nèi)部的狀態(tài)隔離), 并且不同子模塊之間可以單獨開發(fā)部署, 模塊間切換不刷新頁面, 并且模塊之間,父子應用之間可以通過某種簡單的方式實現(xiàn)通信,這樣是不是就完美了?不錯, 這也許就是微前端要解決的問題。

往往企業(yè)的中后臺系統(tǒng)更加適合使用微前端架構(gòu),因為B端大部分都是業(yè)務驅(qū)動,而往往這些業(yè)務之間會非常復雜, 比如Saas, Paas等系統(tǒng).像類似于云平臺,CRM,ERP系統(tǒng)往往是微前端架構(gòu)的拯救對象。

筆者曾經(jīng)接手的ERP系統(tǒng),由于開發(fā)時間比較早,往往有很多遺留的歷史包袱,比如新老技術棧的糅合, 前端業(yè)務代碼龐大而毫無違和感,為了對其繼續(xù)迭代開發(fā), 重構(gòu)是必經(jīng)之路,微前端另一個重要的作用筆者認為就是解放.解放不可挽回的痛??.

筆者之前在寫從0到1教你搭建前端團隊的組件系統(tǒng)（高級進階必備）這篇文章時簡單提了一下微前端的一些知識,這里先回放一張筆者之前做的簡陋的圖,方便大家理解微前端架構(gòu)。

但我們所看到的不是事實的全部,在文章后面筆者會總結(jié)一張更全面的圖,來整理微前端的一些實踐應用。

（2）微前端架構(gòu)實現(xiàn)的方案

上面內(nèi)容我們大致了解了一下微前端的概念和作用,接下來筆者總結(jié)一下曾經(jīng)經(jīng)歷過的微前端實現(xiàn)方案。

基于MPA + iframe + requirejs實現(xiàn)的微前端架構(gòu)

這是筆者接手最早的一個項目,主要是服務于企業(yè)內(nèi)部的ERP系統(tǒng),當時采用的技術棧主要是jquery+layui+requirejs,記得還是筆者剛畢業(yè)時參與的項目.主要是利用AMD模塊化機制來復用代碼,當時項目代碼及其龐大復雜,大致架構(gòu)如下:

傳統(tǒng)實現(xiàn)方式一般是通多多頁面的方式來對應用解耦,并采用模塊化加載機制來導入可復用組件.系統(tǒng)間通型采用storage+window.opener+iframe.比如我們一個大系統(tǒng)的首頁可能會有來自不同子系統(tǒng)的頁面,已iframe的方式嵌入.不同子系統(tǒng)間由不同的人維護,雖然做到了微前端的模式,但是還是有很多缺點。

改架構(gòu)的一般分工是架構(gòu)組主要負責制定架構(gòu)標準和規(guī)范，維護公共模塊（類似于現(xiàn)在的組件，當時由于采用jquery生態(tài)，可以簡單的說成公共UI插件的維護）；業(yè)務組主要負責編寫業(yè)務代碼，實現(xiàn)某個系統(tǒng)的具體交互和功能。