[譯] 微前端

• 原文地址：Micro Frontends

• 原文做者：Cam Jackson

• 譯文出自：掘金翻譯計劃

• 本文永久連接：github.com/xitu/gold-m…

• 譯者：Jenniferyingni

• 校對者：Stevens1995, Baddyo

作好前端開發不是件容易的事情，而比這更難的是擴展前端開發規模以便於多個團隊能夠同時開發一個大型且複雜的產品。本文將描述一種趨勢，能夠將大型的前端項目分解成許多個小而易於管理的部分，也將討論這種體系結構如何提升前端代碼團隊工做的有效性和效率。除了討論各類好處和代價以外，咱們還將介紹一些可用的實現方案和深刻探討一個應用該技術的完整示例應用程序。

近年來，微服務 已經大受歡迎，許多組織使用這種架構風格來避免大型單體（monolithic）後端的侷限性。關於如何在服務器端軟件中也採用相似風格，雖然如今已經有許多相關的文章，可是許多公司仍然仍是在單體前端代碼庫中掙扎。

也許您想構建一個漸進式或響應式 Web 應用程序，但沒法找到一個方法將這些特性整合到現有代碼中。也許您想要使用 JavaScript 的新特性（或者是其餘的能夠編譯成 JavaScript 的語言），但沒法在項目已有的構建流程中加入新增的構建工具。又或者您可能只是想擴展您的開發規模，以便多個團隊能夠同時處理一個項目，但現有單體架構中的耦合和複雜性意味着每一個人負責的代碼都會有不可避免的重合。這些都是真實存在的問題，這些問題都會對您有效地爲客戶提供高質量服務的能力產生負面影響。

最近，咱們愈來愈關注複雜的現代 Web 開發所需的總體架構和組織結構。值得一提的是，咱們看到了一種將前端總體分解爲小而簡單的塊的模式。這些塊能夠獨立開發、測試和部署，同時仍然聚合爲一個產品出如今客戶面前。 咱們將這種技術稱爲微前端，咱們將其定義爲：

一種將多個可獨立交付的小型前端應用聚合爲一個總體的架構風格

在 2016 年 11 月發表的 ThoughtWorks 技術雷達期刊中，咱們將微前端歸爲了評估等級。後來又將其提高到了試驗等級，最終列爲了採納等級，這意味着，咱們將微前端視爲一種通過驗證的方法，應該在合適的情境中採用它。

圖 1：微前端在技術雷達中屢次被說起。

採用微前端的幾個主要優勢是：

• 體積小、易拼合且易於維護的代碼庫

• 更具擴展性的互相解耦且獨立的團隊

• 和之前相比能採用增量的方式，更易於對前端的某些部分進行升級、更新甚至重寫

以上列出的優勢與微服務的優勢相同，這並不是巧合。

固然了，「天底下沒有免費的午飯」，這句話在軟件架構中一樣適用，有些微前端實現可能致使依賴項的重複，增長了用戶所需下載依賴的體積。除此以外，團隊獨立性的急劇增長會形成團隊風格的差別。儘管如此，咱們認爲這些是可控的風險，而且使用微前端所帶來的好處要遠遠多於付出的代價。

優勢

咱們會着重關注微前端的新屬性以及它們帶來的好處，而不是使用具體的技術或者實現細節來定義微前端。

增量升級

對於許多團隊來講，這是他們開始微前端之旅的初始緣由。那種陳舊而龐大的前端單體模式，被過期的技術棧或趕工完成的代碼質量死死拖住後腿，其程度之嚴重，已經到了讓人看了就禁不住想推翻重寫的地步。爲了不徹底重寫的風險 ，咱們更加傾向於將舊的應用程序逐步地翻新，與此同時不受影響地繼續爲咱們的客戶提供新功能。

這每每就須要用到微前端架構。一旦有團隊能作到持續地增長新功能而且對原有的總體幾乎不作修改，其它的團隊也會爭相效仿。已有的代碼依舊須要維護，有些狀況下繼續爲其增長新功能也是有必要的，可是如今微前端提供了可選項。

微前端能使咱們更加自由地對產品的各個部分作出獨立的決策，使咱們的架構、依賴以及用戶體驗都可以增量升級。若是主框架中有一個非兼容性的重要更新，每一個微前端能夠選擇在合適的時候更新，而不是被迫停止當前的開發並當即更新。若是咱們想要嘗試新的技術，或者是新的交互模式，對總體的影響也會更小。

簡單、解耦的代碼庫

每一個單獨的微前端項目的源代碼庫會遠遠小於一個單體前端項目的源代碼庫。這些小的代碼庫將會更易於開發。更值得一提的是，咱們避免了不相關聯的組件之間無心形成的不適當的耦合。經過加強應用程序的邊界來減小這種意外耦合的狀況的出現。

固然了，一個獨立的、高級的架構方式（例如微前端），不是用來取代規範整潔的優秀老代碼的。咱們不是想要逃避代碼優化和代碼質量提高。相反，咱們加大作出錯誤決策的難度，增長正確決策的可能性，從而使咱們進入成功的陷阱。例如，咱們將跨邊界共享域模型變得很困難，因此開發者不太可能這樣作。一樣，微前端會促使您明確並慎重地瞭解數據和事件如何在應用程序的不一樣部分之間傳遞，這本是咱們早就應該開始作的事情！

獨立部署

與微服務同樣，微前端的獨立可部署性是關鍵。它減小了部署的範圍，從而下降了相關風險。不管您的前端代碼在何處託管，每一個微前端都應該有本身的連續交付通道，該通道能夠構建、測試並將其一直部署到生產環境中。咱們應當可以在不考慮其餘代碼庫或者是通道的狀況下來部署每一個微服務。作到即便原來的單體項目是固定的按照季度手動發佈版本，或者其餘團隊提交了未完成的或者是有問題的代碼到他們的主分支上，也不會對當前項目產生影響。若是一個微前端項目已準備好投入生產，它應該具有這種能力，而決定權就在構建而且維護它的團隊手中。

圖 2 : 每一個微前端都獨立的部署到生產環境上

自主的團隊

將咱們的代碼庫和發佈週期分離的更高階的好處，是使咱們擁有了徹底獨立的團隊，能夠參與到本身產品的構思、生產及後續的過程。每一個團隊都擁有爲客戶提供價值所需的所有資源，這就使得他們能夠快速且有效地行動。爲了達到這個目的，咱們的團隊須要根據業務功能縱向地劃分，而不是根據技術種類。一種簡單的方法是根據最終用戶將看到的內容來分割產品，所以每一個微前端都封裝了應用程序的單個頁面，並由一個團隊全權負責。與根據技術種類或「橫向」關注點（如樣式、表單或驗證）來組成團隊相比，這會使得團隊工做更有凝聚力。

圖 3：每一個應用都由一個團隊負責

總結

簡而言之，微前端都是將巨大的東西分紅更小、更易於管理的小部分，而後明確它們之間的依賴關係。咱們的技術選擇、代碼庫、團隊以及發佈流程都應該可以彼此獨立地運行和開發，不須要過多的協調。

咱們將分期發表這篇文章。後續的文章將介紹用於實現這些功能的替代集成方法、如何處理諸如樣式和應用間通訊這類實現問題，咱們也將討論一些缺點，還有介紹詳細的示例實現。

想知道咱們什麼時候發佈後續部分，請訂閱 RSS 源、Cam 的 twitter、或者 Martin 的 twitter。

重要修改

2019 年 6 月 10 日：發佈第一期文章，探討了微前端的優勢

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。