前端單頁應用微服務化解決方案1 - 思考

文章轉發自: alili.tech前端

近幾年,微服務架構在後端技術社區大紅大紫,它被認爲是IT軟件架構的將來技術方向.咱們如何借鑑後端微服務的思想來構建一個現代化前端應用? 在這裏我提供一個能夠在產品中真正能夠落地的前端微服務解決方案.git

微服務化後端先後端對比

後端微服務化的優點:

  1. 複雜度可控: 體積小、複雜度低,每一個微服務可由一個小規模開發團隊徹底掌控,易於保持高可維護性和開發效率。
  2. 獨立部署: 因爲微服務具有獨立的運行進程,因此每一個微服務也能夠獨立部署。
  3. 技術選型靈活: 微服務架構下,技術選型是去中心化的。每一個團隊能夠根據自身服務的需求和行業發展的現狀,自由選擇最適合的技術棧。
  4. 容錯: 當某一組建發生故障時,在單一進程的傳統架構下,故障頗有可能在進程內擴散,造成應用全局性的不可用。
  5. 擴展: 單塊架構應用也能夠實現橫向擴展,就是將整個應用完整的複製到不一樣的節點。

前端微服務化後的優點:

  1. 複雜度可控: 每個UI業務模塊由獨立的前端團隊開發,避免代碼巨無霸,保持開發時的高速編譯,保持較低的複雜度,便於維護與開發效率。
  2. 獨立部署: 每個模塊可單獨部署,顆粒度可小到單個組件的UI獨立部署,不對其餘模塊有任何影響。
  3. 技術選型靈活: 也是最具吸引力的,在同一項目下可使用現在市面上全部前端技術棧,也包括將來的前端技術棧。
  4. 容錯: 單個模塊發生錯誤,不影響全局。
  5. 擴展: 每個服務能夠獨立橫向擴展以知足業務伸縮性,與資源的沒必要要消耗;

咱們什麼時候須要前端微服務化?

  1. 項目技術棧過於老舊,相關技能的開發人員少,功能擴展吃力,重構成本高,維護成本高.
  2. 項目過於龐大,代碼編譯慢,開發體差,須要一種更高維度的解耦方案.
  3. 單一技術棧沒法知足你的業務需求

其中面臨的問題與挑戰

咱們即將面臨如下問題:github

  • 咱們如何實如今一個頁面裏渲染多種技術棧?
  • 不一樣技術棧的獨立模塊之間如何通信?
  • 如何經過路由渲染到正確的模塊?
  • 在不一樣技術棧之間的路由該如何正確觸發?
  • 項目代碼別切割以後,經過何種方式合併到一塊兒?
  • 咱們的每個模塊項目如何打包?
  • 前端微服務化後咱們該如何編寫咱們的代碼?
  • 獨立團隊之間該如何協做?

後續的文章我會一一解答以上問題,一塊兒挖掘前端微服務的潛力. 跳出概念,實實在在的落地到你的項目中. 未完待續 ...後端

相關文章

前端單頁應用微服務化解決方案1 - 思考架構

前端單頁應用微服務化解決方案2 - Single-SPAfrontend

前端單頁應用微服務化解決方案3 - 模塊加載器微服務

前端單頁應用微服務化解決方案4 - 消息總線3d

前端單頁應用微服務化解決方案5 - 路由分發cdn

前端單頁應用微服務化解決方案6 - 構建與部署blog

前端單頁應用微服務化解決方案7 - 靜態數據共享

前端單頁應用微服務化解決方案8 - 二次構建

Demo

前端微服務化 Micro Frontend Demo

微前端模塊加載器

微前端Base App示例源碼

微前端子項目示例源碼

相關文章
相關標籤/搜索