從微前端聊聊架構演進

時間 2020-02-04

原文原文鏈接

就目前來看，微前端已經不是一個新話題了。隨着愈來愈多的公司的深刻研究，當前也提出了不少的解決方案。不過本文不是想要來介紹微前端，更想介紹項目如何一步步到達微前端架構的實際需求。html

固然，也不排除有些項目在初期就須要微前端這樣的架構，不過我一直相信，任何架構模式都是根據實際需求來構建的。爲何不少大公司投入那麼多的精力去作這樣一件事，更多的也是由於他們真正須要這樣一種架構，甚至達到了不用會影響業務開發的可能。不過對於大部分企業，不太須要關注這一點。前端

事實上，不管是什麼架構形式,都是爲了項目可以更快的進行開發。因此不可貴出，ETC 原則 (Easier To Change ，易於修改) 貫穿始終。vue

對於 ToC 端應用而言，可能生存期只有 2，3 年就會結束或者重寫。可是對於 ToB 端應用基本上是公司不關門以前都會持續開發和使用下去。固然不少 ToC 端應用提供的更可能是服務而不是業務，他們更多的關注重點放在服務上而並不是業務範疇。react

單項目應用

對於後端開發而言，都是由單體應用開始的，可是對於前端開發，所謂單體應用的說法並不合適，因此我在這裏把它叫作單項目應用。webpack

對於一個剛剛開始的創業公司，是沒有足夠的人力儲備以及代碼實踐。此時咱們要作的就是利用腳手架開啓項目進行開發。咱們須要作的是作好代碼規範，把代碼寫好。更多的考慮前端組件化與服務分離。git

依賴注入

若是不考慮項目中基於業務的各類依賴庫以及其中的設計模式，那麼依賴注入必然是打造一個易於修改與擴展的項目不可或缺的設計模式。控制反轉和依賴注入能夠參考控制反轉和依賴注入的理解(通俗易懂)。程序員

但很惋惜，在衆多的前端框架中僅僅只有 Angular 內置該功能，且僅有 Angular 有服務類(獨立文件)的概念(不一樣框架關注點不一樣)。能夠經過 Angular 中的依賴注入進行學習。事實上，在開發較爲複雜的業務時，對拉取以及處理數據的代碼做爲獨立文件是不錯的處理方式。這樣其實也符合 react 和 vue 只作界面渲染層的需求，把功能服務提取出來，這樣界面端框架切換就不太會影響服務的提供，就像公司在今年年中計劃升級 vue3 這類的大的框架接口改動，出錯的可能也會減小。github

以小程序請求服務爲依賴諸如的例子，開始時候咱們注入了本身開發的請求類服務。後面發現了能夠自帶登錄管理的網絡請求組件 weRequest (若是你有此需求，也能夠看看我以前寫的從 weRequest登錄態管理來聊聊業務代碼這篇博客)。此時，咱們要替換以前的請求服務，只須要對 weRequest 再包裝一層，提供與以前服務相等的接口就不須要大幅度修改與業務相關的代碼，這樣修改基本上也不會出現 bug。諸如此類還有緩存服務等，只要接口不變，究竟存儲在 sessionStorage 仍是內存,又或者 LRU (Least recently used) 仍是 LFU (Least frequently used),這隻取決於服務是如何提供的。web

我的認爲若是想要開發一個持續迭代的應用，必定要在 ETC 上下足了功夫。創業公司更是如此。不然，若是在開發中須要增長一個新的需求或者修改當前需求，卻發現當前的服務難以使用乃至於須要重寫整個服務，這個在業務開發中是沒法接受的。同時，初創公司的需求修改是最爲常見的。不過，過分設計也是程序員的通病。小程序

多項目分離

隨着項目的慢慢變大，雖然咱們能夠依靠 Webpack 按需加載，但項目的編譯與構建時間卻不斷增加。同時遇到某一個局部 bug 也須要全量編譯與發佈。項目在開發階段遇到了巨大的阻力。

組件與服務提取

分離出不易變化的共通代碼，獨立做爲項目發佈與部署是可行的方法。就像咱們會使用 Webpack externals 來導入外部依賴同樣，咱們把項目中不易變化的代碼分離出去。就像咱們會使用開源庫來協助開發同樣，不可避免的會由於自身需求與開源庫不相符合，同時又由於業務需求沒那麼通用因此不適合提煉出來，只能本身修改。包括不少的服務以及組件。我這裏叫作業務型組件。由於這一類基於業務從基礎組件中開發出來，但在穩定後改動性也不大。

固然，這裏的話，能夠採用的是單項目多程序包，相似於 lerna 這種模式，也能夠採用多項目模式。固然，對於目前初創公司而言，不太可能有幾個產品同時在開發，因此可能相似 lerna 解決方案會更好。可是若是能夠提取幾個產品的共通服務，卻是能夠做爲公司的基礎庫來維護。由於不太容易改變，因此讓兩個開發人員在有需求的時候去維護也綽綽有餘，畢竟不像開源項目那樣，須要服務的是各類各樣的公司，千奇百怪的需求。固然，提煉出來的業務必定要很是基礎。由於比不提取共同代碼更難接受的就是一有需求就要改動依賴庫的代碼。與業務緊密相關的組件或者服務仍是放在主項目中，以便於修改。

widget 開發

微件（Web Widget)，中文可譯做：小部件、小工具、微件、掛件等，是一小塊能夠在任意一個基於HTML的網頁上執行代碼構成的小部件，它的表現形式多是視頻、地圖、新聞或小遊戲等等。咱們在 ToC 應用常常會使用，例如在網頁中插入百度地圖，或者百度商橋(在線客服網頁插件)等網頁 wediget。

在持續工做與開發的過程當中，咱們有一些業務是與當前業務關係不是那麼大，例如登錄業務，不少時候，登錄是獨立於咱們當前業務以外的業務。例如像阿里不少登錄都會有釘釘登錄，支付寶登錄等模式，把整個登錄界面做爲單獨的項目而後用 iframe 進行登錄業務開發。若是作的好的話，咱們多個產品就可使用同一個登錄項目。這個對於小公司能夠節省很多開發時間。

咱們在開發中遇到的報表等無強業務相關的代碼均可以提出來做爲單獨項目進行開發。若是有需求的狀況下，也能夠開發瀏覽器插件來輔助業務開發。

多頁面業務拆分

伴隨着代碼的進一步擴展，咱們開始基於不一樣的業務來拆分咱們的項目。固然，事實上基於業務的多頁面拆分並不意味真正的須要多個項目。在當前人手不夠的狀況下，不拆分爲多個項目更好。固然此時各個單頁面須要都須要加載共同的控制檯頭部(參考阿里雲控制檯)。固然，事實上，在單項目應用時期，咱們就能夠按照多頁面拆分。可是當前若是沒有作過上述幾個操做，項目的編譯和構建在開發中將會是一個災難。同時，咱們若是能夠按照單頁面拆分整個項目，就能夠減小全局狀態，減小各個業務間的全局狀態也在必定程度上規避 bug。

能夠看到，到達這一步，初創公司從零開發的產品可能已經開發了 2-3 年。若是當前的公司沒有特別大的資金介入，可能在將來的幾年內仍是以這種形態進行開發。

微前端

Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently. -- Micro Frontends

上面是微前端的定義，首先第一個關鍵詞就是多團隊，多團隊表明涉及的業務和人員有必定的基數，若是人員團隊不夠多，實在不必上微前端。同時，微前端不會限制技術棧。某些特定場景下可能特定的技術棧有更好的生態。

固然，我認爲微前端的最大的做用就是在遺留系統中作增量升級。面對已經上線幾年的老項目，咱們不可能一步到位就升級現有系統的技術棧。微前端是我已知實現漸進式重構的最好方案。

上述基於業務拆分雖然也能夠解決狀態隔離和獨立開發部署等功能，可是因爲須要加載同一個控制檯頭部，因此不能簡單的作到各業務技術棧無關(能夠作，可是目前須要雙方協同)。不過我的目前也遇不到此類需求。

簡而言之，微前端就是將大而恐怖的東西切成更小，更易於管理的部分，而後明確地代表它們之間的依賴性。各自團隊的技術選擇，代碼庫，發佈流程都應該可以彼此獨立地運行和擴展。無需過多的協調，讓各個團隊之間高內聚而低耦合。更自由靈活的使用 ETC 原則。

由於公司目前在創業階段，沒有微前端的需求。因此對微前端更多的是概念解讀，而並不是落地實踐。固然，對於需求微服務的團隊來講，實際上想要落地，仍是須要作很是多的工做的，我的也沒有什麼技術實踐和經驗，就再也不繼續再寫下去了。關於業界實踐，你們能夠看一看D2 中關於微前端專場的資料 d2forum 14th 與視頻，也能夠關注 qiankun 和 alibabacloud-console-os。後面我也會多研究這兩個開源庫來提高本身。