淺談微前端在滴滴車服中的應用實踐

導讀：若是盤點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 一、Angular 二、Ember 等等，若是想要簡單的將工程微應用化，能夠考慮使用這個框架。

固然，沒有銀彈可言，微前端並非萬金油，不管是哪種實現方式，咱們在考慮採用微前端架構以前，除了考慮它帶來的好處，還要考量存在的大量風險和技術挑戰，例如：

• 使用以後如何區分開發環境和線上環境
• 如何隔離 JS，避免 CSS 衝突
• 應用間共享公共資源的機制
• 第三方模塊重疊
• 處理數據獲取並考慮用戶的初始化加載狀態
• 權限如何接入
• 如何減小初始 Loading 時間
• 如何有效測試

因此，微前端與微服務同樣，要真正進入實踐，還須要作好一系列的技術儲備。目前小桔車服結合實際業務形態，構建出一套全鏈路的的產品接入平臺，解決了上述微前端中的技術卡點，爲中後臺體系建設提供了一套通用的解決方案。

4. 微前端在車服中的實踐

先介紹下背景，車服租車業務線有很是高的業務複雜度，並經歷了屢次商業模式探索整合優化。在業務不斷探索調整的過程當中，租車商用和MIS系統造成了多個系統分治的局面，同時林林總總的諸如採購、營銷、企業車隊等獨立系統也都因業務側的訴求紛紛進行了新建，且有更多的新的獨立系統在業務側籌劃構建的路上，這極大加重了開發和維護這些中後臺系統的成本。

爲此，團隊決定以整合當前集團和車服環境內LASS能力爲基點，提供一套微前端的架構體系，從頁面資源到微應用再到系統級的搭建和管理的統一能力，即Midway平臺。

如上，Midway平臺以微前端架構思想爲基礎，採用基座模式，提供一個主應用即基座做爲系統的統一入口，管理子應用的生命週期以及應用間的通訊，提供核心部分的業務功能如用戶登陸、統一鑑權、導航菜單、路由管理等功能，並將對應的請求指向對應的服務，子應用則是具體負責子模塊的業務實現，無視技術棧，由各個團隊獨立開發部署。

Midway 底層以single-spa爲基礎，隔離子應用間的樣式與做用域，經過應用註冊、鉤子引用等方法，對接入的應用進行完整的生命週期控制，同時提供了應用通信、公共資源加載、應用按需加載、應用預加載、日誌監控等多種底層功能，下面撿重點介紹一下：

應用註冊

Midway 調用 single-spa 的 registerApplication方法註冊微應用，支持傳入異步函數 loadApp（返回 Promise 便可）及非函數類型值。若是是非函數類型，它會主動轉換，在鉤子返回先後及返回的鉤子作了一些功能建設：

1. 新增 beforeUnmount、 afterUnmount、 beforeMount、 afterMount、 beforeLoad 鉤子，方便在應用mount及load先後作一些處理工做。
2. 根據單頁面構架器（飛馬）獲取靜態資源，爲飛馬頁面entry.js添加鉤子及相關配置等。
3. 根據應用註冊時傳入的entry類型，分析處理獲取當前應用的 html、scripts、styles、id（飛馬頁面） 等信息。
4. 根據 entry 配置，異步拉取相關靜態資源，最終返回用來渲染的模板代碼 template和 execScripts，用來執行 entry.js 獲取鉤子的方法。
5. 爲當前應用建立沙箱環境（proxy），並在沙箱環境下執行 execScripts獲取 entry.js 的鉤子函數，最後 loadApp返回加工後的鉤子函數。

應用預加載

應用的預加載方案咱們以前討論了很多時間，考慮到之後管理的微應用規模及性能影響，咱們決定採用預加載配置方案。須要手動配置哪些應用須要提早加載靜態資源，主要咱們來詳細說說背後的處理及思考：

1. 過濾已經 mount 過的應用，已經 mount 過的應用資源確定加載過了，因此不須要預加載了。
2. 註冊的微應用中的第一個應用 mount 後，纔會對配置的其它預加載應用作預加載，single-spa 作了一些自定義事件，其中有一個就是在第一個微應用 mount 後觸發的事件 single-spa:first-mount。所以，咱們監聽此事件，當第一個微應用 mount 後，咱們就能夠開始預加載任務了。
3. 利用 window.requestIdleCallback API 在瀏覽器空閒時間預加載應用資源, 在 mobile 設備和弱網環境下，咱們不會開啓預加載任務。在不支持 window.requestIdleCallbackAPI 的瀏覽器裏，咱們使用 setTimeout 來模擬。

JS沙箱

「沙箱」這個詞聽起來高大上，可是其實咱們很早就已經接觸過了。具體的概念及細節這裏再也不贅述，你們能夠自行搜索。簡單的說，當你要解析或執行不可信的 js 的時候，當你要隔離被執行代碼的執行環境的時候，當你要對執行代碼中可訪問對象進行限制的時候，沙箱就派上用場了。

樣式隔離

劫持 HTMLHeadElement.prototype.appendChild 方法，接管 appendChild，在應用 mount、unmount 時作樣式快照生成與恢復操做。後續考慮使用 shadow dom 方案作樣式隔離，更完全安全。

資源緩存

本地緩存資源，能有效減小資源請求加載的時間，加快應用渲染，減小頁面空白時間。對比過瀏覽支持的各類本地數據存儲方案，最終選擇 IndexedDB 來作存儲靜態資源解決方案，爲何選擇它，這裏就不作過多贅述了。詳細處理有如下幾點：

1. 使用 Dexie.js 來管理 IndexedDB 數據庫
2. 設置緩存週期爲 7 天，過時資源會被清理
3. 核心 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 發佈