前言

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

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

你將收獲

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

正文

在總結微前端架構之前,讓我們來先看看微服務是什么。

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

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

傳統的web軟件開發架構往往如下圖所示:

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

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

由上圖可以發現微服務給我們帶來的好處:

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

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

2、微前端架構概念及方案

（1）理解微前端架構

上面簡單介紹了一下微服務架構,接下來我們進入主題,來聊聊微前端. 微前端和微服務實現的目的類似,都是將應用由單一的單體應用轉變為多個小型子應用,差別就在于:

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

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

Michael Geers 大佬發表了一些對微前端的一些思考,內容大致總結一下就是:

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

正如下面的例子所示:

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

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

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

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

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

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

（2）微前端架構實現的方案

上面內容我們大致了解了一下微前端的概念和作用,接下來筆者總結一下曾經經歷過的微前端實現方案。

基于MPA + iframe + requirejs實現的微前端架構

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

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

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