微服務對前端的衝擊:微前端終於落地了 - thecamjackson
由於單體式前端架構在使用微服務經常會遇到部署問題。這篇文章總結了微前端(Micro Frontends)的好處,並就如何擴充套件他們進行了充分討論。
良好的前端發展很難。擴充套件前端開發以便讓許多團隊可以同時處理大型複雜產品甚至更難。在本文中,我們將描述最近將單體/整體的前端分解為許多更小,更易於管理的部分的趨勢,以及這種架構如何提高前端程式碼團隊的效率。除了討論各種好處和成本之外,我們還將介紹一些可用的實現選項,我們將深入探討演示該技術的完整示例應用程式。
近年來,微服務已經大受歡迎,許多組織使用這種架構風格來避免大型單體後端的限制。雖然已經有很多關於這種構建伺服器端軟體的文章,但許多公司仍在努力使用單體前端程式碼庫。
也許您想構建一個漸進式或響應式Web應用程式,但無法找到一個簡單的地方開始將這些功能整合到現有程式碼中。也許您想開始使用新的JavaScript語言功能(或者可以編譯為JavaScript的無數語言之一),但是您無法在現有的構建過程中使用必要的構建工具。或者您可能只是想擴充套件您的開發,以便多個團隊可以同時處理單個產品,但現有整體中的耦合和複雜性意味著每個人都踩到彼此的腳趾。這些都是真正的問題,這些問題都會對您有效地為客戶提供高質量體驗的能力產生負面影響。
最近,我們越來越關注複雜的現代Web開發所需的整體架構和組織結構。特別是,我們看到了將前端整體分解為更小,更簡單的塊的模式,這些塊可以獨立開發,測試和部署,同時仍然作為單一的內聚產品出現在客戶身上。我們將這種技術稱為 微前端,我們將其定義為:
“一種架構風格,可獨立交付的前端應用程式組成一個更大的單體/整體”
在2016年11月出版的ThoughtWorks技術雷達中,我們將微前端列為組織應評估的技術。我們後來將其提升為試用版,最後將其推廣到Adopt採用級別,這意味著我們認為這是一種經過驗證的方法,當您這樣做時應該使用它。
我們從微前端看到的一些主要好處是:
- 更小,更有凝聚力和可維護的程式碼庫
- 具有分離的自治團隊的更具可擴充套件性的組織
- 能夠以比以前更加增量的方式升級,更新甚至重寫部分前端
當然,在軟體架構方面沒有免費的午餐 - 一切都需要付出代價。一些微前端實現可能導致重複依賴,增加使用者必須下載的位元組數。此外,團隊自治的急劇增加可能會導致團隊工作方式的分散。儘管如此,我們認為可以管理這些風險,並且微前端的好處往往超過成本。
優點
1. 增量升級
對於許多組織來說,這是他們微觀前沿之旅的開始。舊的,大的,前端的巨石被昔日的技術堆疊或者在交付壓力下編寫的程式碼所阻礙,並且它已經到了完全重寫的深坑邊緣。為了避免 完全重寫的 危險,我們更傾向於 逐個扼殺舊的應用程式,同時繼續為我們的客戶提供新功能,而不受整體結構的影響。
這往往導致微前端架構。一旦一個團隊獲得了將功能一直帶到生產的經驗而對舊世界幾乎沒有任何修改,其他團隊也希望加入新世界。現有程式碼仍然需要維護,在某些情況下,繼續新增新功能可能是有意義的,但現在可以選擇。
最後的結論是,我們可以更自由地對產品的各個部分做出逐案決策,並對我們的架構,依賴關係和使用者體驗進行逐步升級。如果我們的主框架發生重大變化,每個微前端都可以在有意義的時候升級,而不是被迫停止世界並立即升級所有內容。如果我們想要嘗試新技術或新的互動模式,我們可以以比以前更孤立的方式進行實驗。
2. 簡單的解耦程式碼庫
根據定義,每個單獨的微前端的原始碼將遠小於單個單片前端的原始碼。這些較小的程式碼庫對於開發人員來說往往更簡單,更容易。特別是,我們避免了由於彼此之間不瞭解的元件之間的無意和不適當的耦合而產生的複雜性。通過在應用程式的有界上下文周圍繪製較粗的線條,我們會使這種意外耦合更加困難。
當然,單個高階架構決策(即“讓我們做微前端”)並不能代替好的老式清潔程式碼。例如,跨越有界上下文共享域模型變得更加困難,因此開發人員不太可能這樣做。同樣,微前端會促使您明確並慎重地瞭解資料和事件如何在應用程式的不同部分之間流動,這是我們應該做的事情!
2. 獨立部署
與微服務一樣,微前端的獨立可部署性是關鍵。這減少了任何給定部署的範圍,從而降低了相關風險。無論您的前端程式碼如何或在何處託管,每個微前端都應該有自己的持續交付管道,該管道可以構建,測試並將其一直部署到生產環境中。我們應該能夠在很少考慮其他程式碼庫或管道的當前狀態的情況下部署每個微前端。如果舊的整體塊是固定的,手動的,季度釋出週期,或者如果隔壁的團隊已將半完成或損壞的特徵推入其主分支中,則無關緊要。如果給定的微前端已準備好投入生產,它應該能夠這樣做:
3.自治團隊
將程式碼庫和釋出週期分離的更高階段的好處:團隊可以完全擁有為客戶提供價值所需的一切,從而使他們能夠快速有效地行動。為了實現這一目標,我們的團隊需要圍繞垂直業務功能組成,而不是圍繞技術功能。一種簡單的方法是根據終端使用者將看到的內容來分割產品,因此每個微前端都封裝了應用程式的單個頁面,並由一個團隊端到端擁有。這帶來了團隊更高的凝聚力,下圖每個應用程式應由一個團隊擁有:
總結
簡而言之,微前端都是將大而可怕的東西分成更小,更易於管理的部分,然後明確它們之間的依賴關係。我們的技術選擇,我們的程式碼庫,我們的團隊和我們的釋出流程都應該能夠彼此獨立地運營和開發,而不需要過多的協調。
相關文章
- 微前端如何落地?前端
- 後端有微服務,那前端呢?初探 微前端 的世界後端微服務前端
- 中臺微服務了,那前端呢?微服務前端
- 微前端 – 將微服務理念延伸到前端開發中前端微服務
- 微前端:DDD和微服務對客戶端開發的好處 - thenewstack前端微服務客戶端
- 網頁上的微服務—微前端架構實踐網頁微服務前端架構
- ABP微服務系列學習-對接前端介面微服務前端
- 基於Spring Cloud的微服務落地SpringCloud微服務
- 我終於知道公司前端為啥不加班了…前端
- 基於 iframe 的微前端框架 —— 擎天前端框架
- 教你玩轉微服務--基於DDD的微服務架構落地實踐之路微服務架構
- 微服務如何落地微服務
- 如何解構單體前端應用——前端應用的微服務式拆分前端微服務
- 微軟終於放棄了Electron了微軟
- 使用開源微前端框架 Luigi 建立一個基於微前端架構的工程前端框架UI架構
- 微服務前端開發框架React-Admin微服務前端框架React
- 關於前端主題切換的思考和現代前端樣式的解決方案落地前端
- 微前端(Micro Frontend ) 落地實施的一些具體例子前端
- 衝擊IPO,羅胖畫了一張終身教育大餅
- 從0實現一個前端微服務(上)前端微服務
- 前端微服務化解決方案1-介紹前端微服務
- 前端常用的終端命令前端
- 機器學習快速落地, Amazon SageMaker終於來了!機器學習
- 疊衣服、擦案板、衝果汁,能做家務的國產機器人終於要來了機器人
- 前端對接微信分享功能完全指南前端
- Go 對 Python 產生的衝擊GoPython
- 前端攻擊手段前端
- 基於 React & TypeScript & Webpack 的微前端應用模板ReactTypeScriptWeb前端
- 微前端microApp前端APP
- 隨行付微服務前端開發框架React Admin微服務前端框架React
- 如何應對AI帶來的衝擊AI
- 熱點微前端Microfrontend的討論:谷歌AdWords是真實的微前端前端谷歌
- 從0實現一個single-spa的前端微服務(中)前端微服務
- 從0實現一個single-spa的前端微服務(下)前端微服務
- 前端微服務化解決方案3 - 模組載入器前端微服務
- 個推前端微服務化:突破傳統SPA瓶頸前端微服務
- 前端微服務化解決方案2-使用必要性前端微服務
- 前端微服務化解決方案3-工程設計模式前端微服務設計模式