雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
導讀：如果盤點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中，力求使該平台成為基于微前端的中背景系統一站式搭建解決方案的最佳實踐。
【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/live立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-05-28
本文作者：滴滴技術
本文來自：“
掘金”，了解相關資訊可以關注“掘金”