導讀：如果盤點2019年最火的前端技術，那么微前端肯定占有一席之地。但是大部分人對於微前端這個架構新貴的了解還是處於懵懵懂懂的狀態，本文將會詳細介紹微前端的前生今世，帶大家了解微前端架構是如何一步步從實際需求中演化而來，以及小桔車服基於微前端所提煉的一套中后台體系建設實踐。
1. 什么是微前端
微前端這個概念最初是對應於微服務這個概念提出的，微服務的核心思想就是將一個大的單體應用基於業務能力拆分為一組小的服務，每個服務都是獨立的進程且能獨立部署，無需統一的技術棧進行集中化管理，只需要進行輕量級的通信就可以完成業務訴求。微前端就是這樣一種類似於微服務的架構模式，它將微服務的核心思想應用於瀏覽器端，即將單個復雜（大規模）的前端應用轉換成多個小型前端應用，每個小型前端應用都與技術棧無關，可以獨立開發、獨立部署，當然拆分還需要一套成熟的通信機制串聯起所有的應用，既能保證應用自治又能保證應用聯系，以更好的協同度共同提升開發效率。
總結來說，微前端就是在前端一體化的大背景下，利用技術手段達到業務層應用聚合、技術層應用自治的工程架構方案，實現一個功能豐富且強大的前端應用。
2. 為什么需要微前端
是不是還是感覺有些朦朦朧朧，沒關系，基於任何技術都需要依托於業務的原則，我們舉一個淺顯易懂的例子來幫助你理解一下前端為什么需要微前端架構：
在很多年前，小紅和小蘭決定創業，開一家網上商城，兩個人一拍即合，快速設計出原型1.0版本，使用最原始的Jquery以及Html產出了一套面向用戶展現的購物網站以及面向運營展現的管理后台：
為了方便理解，我們先不管前台的購物系統，只專注后台管理系統，因為項目前期只需要滿足最基本的購物需求，所以當時所有的管理需求都集中在一個管理系統，代碼收攏在一個倉庫，具體架構如下：
小紅和小蘭迅速將1.0版本的網上商城推向市場，由於搶占了先機，大家很喜歡這種足不出門就可以購物的感覺，兩人迅速賺到了一筆錢。
后來隨着業務越做越大，商品管理逐漸分成了精選商品管理和普通商品管理，庫存管理分成了合作商庫存和自營庫存，訂單管理和用戶管理也愈發的龐大，成了這個樣子：
可以明顯看出，隨着業務的繁雜，每個模塊的管理變的愈發臃腫，所有團隊都在一個系統中維護不同的功能變的越來越麻煩，因此小紅和小蘭決定了上線2.0版本，將整個后台管理系統解耦拆分，由不同的團隊維護不同的模塊，A團隊只負責商品管理這塊，B團隊只負責庫存管理這塊，其余模塊也類似，這樣大家各自部署，各自開發，互不干涉。
在2.0模式下，當業務越做越大，小紅和小蘭決定再成立營銷和渠道兩個團隊，分別開展一些營銷活動和渠道活動時，后台管理系統也需要增加一個渠道管理和營銷管理模塊，沿用上面解耦的邏輯，這倆團隊再新建一個渠道系統和營銷系統分別管理，大家各自產出自己的代碼，各自維護各自的系統，擴展性大大增強。
同時隨着前端技術的發展，Jquery以及Html的框架逐步落后， Angular、 React、Vue等單頁面應用異軍突起成為主力，各個團隊都逐漸開始重構各自的系統，商品管理系統用了React框架，訂單管理系統用了Vue框架等等，大家各自朝着自己感興趣的框架上發力，各自為政的狀態讓大家都互不干擾，這樣做就滿足了最開始代碼解耦的需求。
2.0模式的一切看起來都挺完美，但是真的很完美么，很快問題就出來了：
首先，苦了真正使用后台系統的運營同學和產品同學，這些同學想要使用后台系統的各種功能，日常操作就變成了不斷的切換、切換、再切換系統。例如他們想要上架一個新的商品，需要先去商品管理系統配置一系列信息，再去庫存管理系統查詢相應的商品庫存，最后再去營銷系統配置這個商品的營銷活動，整個過程需要不斷的切換系統，運營效率大大降低。
然后，開發效率也大大降低，比如所有的系統都是基於同一套登錄權限模塊，但由於部署在不同的域名環境，每個系統都重復開發一遍，類似的網關模塊、日志模塊等等也是如此。而且不同系統之間存在大量的耦合功能，單獨的代碼環境並不能復用一些其他系統已有的代碼，就會造成各種重復造輪子的行為。
有什么樣的方式既可以讓各個系統既能單獨開發部署，各自選擇技術棧，又能緊密聯系聚合成一個系統供運營同學和產品同學使用呢，微前端的架構思想應運而生。
微前端的核心思想就是將一個完整的前端應用分解成一些更小的、微粒化的、能夠獨立開發測試部署的子應用，子應用之間通過弱通信機制互相聯系，在用戶看來仍然是內聚的單個產品。
那么整個電子商城的后台管理系統可以使用微前端的思想重新架構一番，也就是3.0模式：
這樣，從產品維度來看，所有的系統都內聚在一個基系統中，用戶只需要一次登錄就可以不刷新的切換各個系統，所有功能都內聚在一起，有效提高了運營效率；從技術維度來看，各個系統並不需要進行技術棧的重構，依然可以沿用原有技術棧，每個團隊依然各自維護各自的代碼庫，獨立部署獨立上線，且可以共用一些通用的能力如登錄、鑒權、打點、日志分析等，即保證了遺留系統的遷移，又聚合了前端應用，完美解決應用臃腫情況下如何各自治理的問題。
相信通過上面例子，在一個虛擬電子商務后台系統架構的逐漸演化中，你應該了解了前端為什么需要微前端架構，總結來說，微前端具備下面優勢：
- 靈活聚合業務成系統：產品功能耦合，面向用戶時多個不同的業務功能耦合成一個業務系統。
- 兼容多技術棧：無論技術棧是Vue，還是React，或者Angular，都可以完美的在一個系統中運行。
- 獨立開發部署：子應用之間倉庫獨立，可以各自開發，部署后容器層會完成自動的同步更新。
- 依賴資源復用：抽離不同應用中所依賴的公共資源，一次性加載多方復用，從而提升性能。
3. 微前端的技術選型
前面介紹了為什么需要微前端架構，那么接下來介紹一下技術選型，首先需要明確一個概念，微前端是一種架構思想，並不具體指某個技術，它是當前端業務在發展到一定規模之后，一種用來分解復雜度的架構模式，具體可以考慮以下幾種選型：
路由式分發
這是最古老的微前端技術實現方式之一，也是最容易的實現方式，通過HTTP的反向代理功能，經過路由判斷將請求轉發到響應的服務上去，優點就是幾乎不需要做任何改造，配置一下nginx服務即可，缺點也很明顯，完全沒有性能優化，切換系統仍需刷新頁面重新加載資源文件，只是從表層將不同應用拼湊到一起。
iframe容器
這是最古老的微前端技術實現方式之二，雖然簡單但是確實有效，iframe一直是瀏覽器規范之一，除了某些化石級別的版本，幾乎所有的瀏覽器都可以完全兼容。Iframe的頁面與父頁面分開，完全不受父頁面css或者全局的javascript 影響，在一定程度上類似於“沙箱隔離”，但一個系統如果加載過多的iframe體驗會很不友好，重復加載相同的依賴，影響網頁加載速度。
微件式服務
微件化是指某個應用由開發人員提前將完整的、閉環的所有功能提前編譯好，其他應用可以直接嵌入到網頁中而不需要做任何的修改或者編譯就可以直接運行展示。早期很多應用的引入都是這樣做的，將本身應用封裝成sdk包，使用者遠程加載javascipt代碼就能生成對應的組件嵌入到頁面，后續隨着npm的流行，逐漸發展成將應用以NPM包的形式發布源碼，這樣做的優勢是發布靈活單獨部署打包，缺點就是如果引入多個應用微件，可能存在互相干擾的問題，且應用間通信困難，對遺留應用需要做過多改造。
Web Components
Web Components是一個Web組件標准，它提供了瀏覽器底層的支持，不依賴各種框架的支持和webpack的編譯，讓人們也可以使用組件。Web Components通過一種標准化的非侵入的方式封裝一個組件，每個組件能組織好它自身的HTML、CSS、JavaScript，並且不會干擾頁面上的其他代碼。使用方式與frame比較類似，組件擁有自己獨立的 Scripts 和 Styles，以及對應的用於單獨部署組件的域名，內部資源高內聚，作用域獨立，加載由自身控制。看上去Web Components確實是一種比較好的微前端架構選型，但遺憾的是目前瀏覽器的支持程度尚不完善，在Safari、ie和火狐上支持並不理想，如果不考慮多瀏覽器的兼容，Web Components是一個不錯的選擇。
自制框架的微應用式服務
微應用式服務是指系統在開始都是以單一微小應用的形式存在，只有當運行時才由系統框架將這些應用加載合並，組合成一個完整系統。無論是基於虛擬樹的react和vue框架，還是基於Web Components的Angular框架，所有框架的原型都離不開在html里加載元素，那么，我們只需要提前將單個系統打包編譯成一個微應用，在頁面合適的地方引入或者創建 DOM，這樣當用戶操作時觸發應用的啟動，並能在用戶切換時卸載應用，所以這個微應用式服務的核心在於加載器的設計，既能實時加載切換不同應用，又能有效隔離應用防止互相干擾。Single-SPA是現在較為成熟的一個開源框架，可以實現在一個頁面將多個不同的框架整合，甚至在切換的時候都不需要刷新頁面，已支持 React、Vue、Angular 1、Angular 2、Ember 等等，如果想要簡單的將工程微應用化，可以考慮使用這個框架。
當然，沒有銀彈可言，微前端並不是萬金油，無論是哪一種實現方式，我們在考慮采用微前端架構之前，除了考慮它帶來的好處，還要考量存在的大量風險和技術挑戰，例如：
- 使用之后如何區分開發環境和線上環境
- 如何隔離 JS，避免 CSS 沖突
- 應用間共享公共資源的機制
- 第三方模塊重疊
- 處理數據獲取並考慮用戶的初始化加載狀態
- 權限如何接入
- 如何減少初始 Loading 時間
- 如何有效測試
所以，微前端與微服務一樣，要真正進入實踐，還需要做好一系列的技術儲備。目前小桔車服結合實際業務形態，構建出一套全鏈路的的產品接入平台，解決了上述微前端中的技術卡點，為中后台體系建設提供了一套通用的解決方案。
4. 微前端在車服中的實踐
先介紹下背景，車服租車業務線有非常高的業務復雜度，並經歷了多次商業模式探索整合優化。在業務不斷探索調整的過程中，租車商用和MIS系統形成了多個系統分治的局面，同時林林總總的諸如采購、營銷、企業車隊等獨立系統也都因業務側的訴求紛紛進行了新建，且有更多的新的獨立系統在業務側籌划構建的路上，這極大加劇了開發和維護這些中后台系統的成本。
為此，團隊決定以整合當前集團和車服環境內LASS能力為基點，提供一套微前端的架構體系，從頁面資源到微應用再到系統級的搭建和管理的統一能力，即Midway平台。
如上，Midway平台以微前端架構思想為基礎，采用基座模式，提供一個主應用即基座作為系統的統一入口，管理子應用的生命周期以及應用間的通信，提供核心部分的業務功能如用戶登錄、統一鑒權、導航菜單、路由管理等功能，並將對應的請求指向對應的服務，子應用則是具體負責子模塊的業務實現，無視技術棧，由各個團隊獨立開發部署。
Midway 底層以single-spa為基礎，隔離子應用間的樣式與作用域，通過應用注冊、鈎子引用等方法，對接入的應用進行完整的生命周期控制，同時提供了應用通訊、公共資源加載、應用按需加載、應用預加載、日志監控等多種底層功能，下面撿重點介紹一下：
應用注冊
Midway 調用 single-spa 的 registerApplication方法注冊微應用，支持傳入異步函數 loadApp（返回 Promise 即可）及非函數類型值。如果是非函數類型，它會主動轉換，在鈎子返回前后及返回的鈎子做了一些功能建設：
- 新增 beforeUnmount、 afterUnmount、 beforeMount、 afterMount、 beforeLoad 鈎子，方便在應用mount及load前后做一些處理工作。
- 根據單頁面構架器（飛馬）獲取靜態資源，為飛馬頁面entry.js添加鈎子及相關配置等。
- 根據應用注冊時傳入的entry類型，分析處理獲取當前應用的 html、scripts、styles、id（飛馬頁面） 等信息。
- 根據 entry 配置，異步拉取相關靜態資源，最終返回用來渲染的模板代碼 template和 execScripts，用來執行 entry.js 獲取鈎子的方法。
- 為當前應用創建沙箱環境（proxy），並在沙箱環境下執行 execScripts獲取 entry.js 的鈎子函數，最后 loadApp返回加工后的鈎子函數。
應用預加載
應用的預加載方案我們之前討論了不少時間，考慮到以后管理的微應用規模及性能影響，我們決定采用預加載配置方案。需要手動配置哪些應用需要提前加載靜態資源，主要我們來詳細說說背后的處理及思考：
- 過濾已經 mount 過的應用，已經 mount 過的應用資源肯定加載過了，所以不需要預加載了。
- 注冊的微應用中的第一個應用 mount 后，才會對配置的其它預加載應用做預加載，single-spa 做了一些自定義事件，其中有一個就是在第一個微應用 mount 后觸發的事件 single-spa:first-mount。因此，我們監聽此事件，當第一個微應用 mount 后，我們就可以開始預加載任務了。
- 利用 window.requestIdleCallback API 在瀏覽器空閑時間預加載應用資源, 在 mobile 設備和弱網環境下，我們不會開啟預加載任務。在不支持 window.requestIdleCallbackAPI 的瀏覽器里，我們使用 setTimeout 來模擬。
JS沙箱
“沙箱”這個詞聽起來高大上，但是其實我們很早就已經接觸過了。具體的概念及細節這里不再贅述，大家可以自行搜索。簡單的說，當你要解析或執行不可信的 js 的時候，當你要隔離被執行代碼的執行環境的時候，當你要對執行代碼中可訪問對象進行限制的時候，沙箱就派上用場了。
樣式隔離
劫持 HTMLHeadElement.prototype.appendChild 方法，接管 appendChild，在應用 mount、unmount 時做樣式快照生成與恢復操作。后續考慮使用 shadow dom 方案做樣式隔離，更徹底安全。
資源緩存
本地緩存資源，能有效減少資源請求加載的時間，加快應用渲染，減少頁面空白時間。對比過瀏覽支持的各種本地數據存儲方案，最終選擇 IndexedDB 來做存儲靜態資源解決方案，為什么選擇它，這里就不做過多贅述了。詳細處理有以下幾點：
- 使用 Dexie.js 來管理 IndexedDB 數據庫
- 設置緩存周期為 7 天，過期資源會被清理
- 核心 API 有 cacheAssets、 getCacheAssets、 clearExpiredAssets
5. 總結
總結來說，Midway 整體設計理念以高內聚、低耦合為標准，秉承微前端的理念，實現了一套前台渲染、后台管理的平台化服務體系，用戶不必再去關注應用聚合時的技術細節，開箱即可用。
目前，租車業務線的多系統分治的情況已開始使用Midway平台着手治理，各問題域模塊也在相繼按照微應用的粒度進行拆分以實現多系統間復用，同時新立系統也已有多個接入，極大降低了系統搭建的門檻和業務模塊開發的重復性。我們未來圍繞Midway微前端核心能力建設的同時，將持續把工程化、安全監控、性能體驗、數據可視化等方向的能力逐步融入到Midway中，力求使該平台成為基於微前端的中后台系統一站式搭建解決方案的最佳實踐。
團隊招聘
滴滴出行旗下的小桔車服終端技術團隊是一個年輕有擔當、充滿活力，追求技術極致，致力於打造現象級長短租一站式租車平台，並以技術手段賦能小桔能源、小桔養車等多條業務線的大終端技術團隊。涉及的前端技術棧有 vue，react，nodejs，flutter，微信小程序等。目前在杭州和北京長期都有大量崗位，包括部分實習崗位。
長期招聘崗位：
- 前端工程師
- 客戶端工程師(Android/iOS)
- AIoT硬件工程師(車聯方向優先)
- 2021屆畢業生(畢業時間:20.11~21.10)實習生
歡迎投遞簡歷至：diditech@didiglobal.com
郵件主題請命名為「姓名+應聘部門+應聘方向」
我們會認真對待每一份投遞，給予最快的處理速度！
作者簡介
碩士畢業於北京郵電大學，2019年加入滴滴，喜歡小寵物，衷於技術。目前在車服終端技術負責租車相關工作，力爭做一名有理想、愛生活的程序猿。
**歡迎關注滴滴技術公眾號！
本文由博客群發一文多發等運營工具平台 OpenWrite 發布