前言

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

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

你將收獲

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

正文

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

正如下面的例子所示:

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

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

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

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

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

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

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

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

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

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

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

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