咱們如何構建微前端

咱們如何構建微前端

構建微前端，加快和擴大咱們的網站開發進程。

請在bit.dev查看咱們的微前端的運行狀況。

在比特，咱們爲超過10萬名使用組件的開發者構建工具。咱們的工具幫助開發者構建、重用和協做獨立的組件，以加快開發速度和提升應用質量。

從第一天起，咱們就開始狗尾續貂地開發本身的工具，同時讓組件驅動咱們的架構和開發流程。這樣作的一大優點就是能夠享受微前端的好處。

微前端是一種將單體前端代碼庫分割成更小、更易管理的碎片的方式。所以，前端團隊能夠享受到與微服務相似的好處：可維護的代碼庫、自主團隊、獨立發佈和增量升級。

微前端一般被認爲是由獨立的前端組成，它發生在_運行時，_在服務器或客戶端。

雖然運行時的集成有其好處（例如更小的有效載荷），但它們毫不是實現 "可獨立交付的前端應用組成"_的惟一方法（引用Cam Jackson）。

在咱們看來，這種構建和協做前端應用的新方式，是微前端的核心要素。

經過正確的組件模型和正確的工具，任何團隊均可以採用模塊化的方法來構建Web應用，並享受這些好處。

對咱們來講，在構建時組成前端應用，能夠帶來一箭雙鵰的效果--"傳統單體 "的安全性和健壯性，以及微型前端的簡單性和可擴展性。爲此，咱們使用了Bit--一個有助於使每一個組件徹底獨立的開源庫，以及咱們的雲平臺--它可讓團隊高效地協做和整合在一塊兒。

正確的模式，正確的工具

在本文中，我將展現咱們Bit公司是如何構建微前端的。我將解釋它是如何幫助咱們實現解耦代碼庫、徹底自主的團隊、獨立的增量升級和近100%的模塊化代碼重用等目標的。但願你能發現這些分享的知識對你有用。

首先，一個活生生的例子

若是你去Bit.dev的主頁，你會發現每次你把鼠標懸停在一個組件上時都會發生一些奇怪的事情。

鼠標進入一個組件後，高亮顯示就會打開，表示該組件的名稱、獨立版本以及發佈和暴露的範圍。當你滾動時，你會發現整個頁面是由不一樣團隊獨立構建、版本化和共享的組件組成的，在不一樣的代碼庫中，使用不一樣的構建流程，而且都集成在一塊兒，成爲一個具備凝聚力的產品。

你在那裏看到的，是咱們團隊如何使用React和Bit等現代組件驅動技術來構建微前端的真實演示。

在這個頁面上，你會看到兩套組件，由兩個團隊開發。一個是 "base-ui "組件集，由咱們的前端基礎設施團隊擁有。第二套是 "evangelist"，由咱們的營銷團隊擁有。

這兩套組件整合在一塊兒，能夠快速組成你所看到的主頁，以及其餘頁面，如【企業頁面】(https://bit.dev/enterprise)或【支持頁面】(https://bit.dev/support-plans)，甚至能夠組成更多的應用。

[

](https://bit.dev/support-plans)

如今咱們能夠很是快速地編寫更多的頁面

若是你點擊組件的範圍，你就能親眼看到咱們的代碼庫架構和組織結構。

[

](https://bit.dev/enterprise)

建立一個新的網站須要幾個小時而不是幾周的時間

組件的一個範圍叫作"base-ui"。這是Bit.dev最基本的組件設計系統，它包含了諸如 "段落 "等基本元素。它由前端基礎設施團隊擁有，並在其本身的解耦代碼庫中開發。全部這些組件都在Bit.dev上發佈和共享。在那裏，它們能夠很容易地被任何其餘須要它們的團隊發現並集成到新項目中。並且，團隊建設的base-ui能夠不斷增發更新到特定組件。

[

](https://bit.dev/bit/base-ui)

base-ui.Bit.dev的基本組件設計系統。Bit.dev的基本組件設計系統

第二個範圍叫作"**營銷s://bit.dev/bit/evangelist)"。這是咱們具體的面向營銷的組件系統，用於在咱們的應用中構建營銷頁面。它由營銷團隊自主擁有，並在[解耦代碼庫中開發。全部這些組件都在Bit.dev上發佈和共享，並由營銷團隊維護。

[

](https://bit.dev/bit/evangelist)

佈道者。Bit.dev的營銷組件系統

在這個例子中，營銷團隊與構建Bit.dev網絡平臺的團隊是脫鉤的。這個團隊在不一樣的代碼庫中工做，經過本身的解耦構建管道發佈變化，並能不斷提供增量升級。

每一個團隊都在本身的較小的、解耦的代碼庫中構建本身的組件，並靈活地按功能等劃分垂直全部權。他們使用Bit來獨立地對每一個組件進行版本、構建、測試、打包和發佈。他們使用bit.dev平臺來託管並向其餘團隊公開組件，這樣他們就能夠進行整合和協做。

Bit的每一個團隊都享有相似的工做流程。全部的團隊都在一塊兒工做，互相分享和集成組件，而不會踩到對方的腳趾。在咱們的代碼庫中編寫的組件中，有接近100%的組件是共享和重用的，不只包括前端組件，還包括咱們系統的許多其餘方面，如 "搜索 "功能、"遊樂場 "功能，甚至某些全棧功能，包括前端和後端功能。咱們發現這頗有價值。

咱們爲本身和其餘團隊採起的KPI和基準測試顯示，在採用這種組件驅動的設計時，發生了各類積極的事情。例如，發佈的數量能夠增長30倍(!)，花在集成上的時間減小了50%以上，新功能的組成變成了幾小時或幾天的事情，甚至新開發人員的入職也能夠變成簡單的幾小時而不是幾周的事情。你能夠在【HeavyBit JAMStack播客】(https://www.heavybit.com/libr...，親耳聽到更多關於這種變化，以及它對一個快速成長的創業公司的做用。

那麼，微前端究竟是什麼？

近年來，微服務容許後端架構經過鬆散耦合的代碼庫進行擴展，每一個代碼庫負責本身的業務邏輯，並暴露出一個API，每一個代碼庫均可以獨立部署，而且每一個代碼庫都由不一樣的團隊擁有和維護。

[

](https://martinfowler.com/arti...

Source: This wonderful article by Cam Jackson

這種模式提供了巨大的優點，有助於加速、擴展和提升開發過程的效率。

微前端的理念是將一樣的優點帶到現代開發工做流程中。它意味着將單體項目分解成更小、更易管理的碎片，這些碎片由各自的團隊獨立開發和擁有，並具備同時構建和出貨的能力。

這個概念能夠提供巨大的優點，好比簡單的、解耦的代碼庫、自主的團隊、獨立的發佈和增量的升級。大大加快了開發進程，擴大了規模，提升了效率。

那爲何如今能夠，之前就不行呢？

直到最近，大多數網絡應用仍然是做爲單一的單體項目來構建的。GatsbyJS的創始人Kyle Mathews說得很好，他說：_"今天的網站仍然是用20年前的方式來製做的，用繁瑣的單體方法來構建網站、存儲數據和交付內容。是時候用一種新的方式來構建網絡了"_。

然而今天，組件是現代網絡的標準基元。只是如今，這些模塊化和可重用的部件才達到了真正的能力，成爲咱們網絡應用的構件，實現了傳統單體的模塊化分解。如今，爲了挖掘這個機會，須要一個共享的基礎架構，以促進團隊共同構建Web應用的模塊化組件驅動設計。

這就是像Bit這樣的新工具的做用，提供必要的工具集，以便在架構和組織層面採用和享受組件驅動開發，並實現這些潛在的好處。

Bit可讓開發人員將獨立組件的開發、重用和發佈解耦，從而能夠高效地開發、重用和集成這些組件以組成不一樣的應用程序。這使得Bit成爲一個強大的工具，不只適用於設計系統和共享組件，並且適用於構建微前端。

在Bit，咱們從第一天開始就一直與微前端合做。這也是咱們設計和測試咱們本身的工具的方式，以便它們可以幫助其餘團隊更好地構建組件。今天，咱們的工具幫助超過10萬名開發者享受到了相似的好處。

在這篇文章中，我將分享咱們本身的團隊是如何用組件構建微前端的。我將展現並解釋咱們是如何將Web開發分割成解耦的、可維護的代碼庫，如何讓新功能和新技術易於替換或集成，如何讓團隊自由地獨立構建並向生產發佈變動而不至於絆住對方的腳步，如何實現高達100%的組件複用，如何構建既可擴展的架構和組織結構，又能隨着咱們的發展而順利成長。

Our shared component infrastructure

[

](https://bit.dev/)

固然，不一樣的團隊使用不一樣的堆棧和工具來構建他們的技術。

對於咱們網絡平臺和網站的開發，咱們選擇了React。隨着Hooks和Context-API等功能的發佈，React成爲了咱們從更小的、獨立的、可重用的碎片開發現代應用的絕佳選擇。

對於支持組件驅動的微前端的shard基礎設施，咱們使用了Bit的開源工具和雲平臺。

除了平常的狗糧化產品，Bit還爲咱們提供了一些採用咱們微前端架構的必要功能。

1. 咱們的OSS工具](https://github.com/teambit/bi...，模塊化的工做空間能夠幫助咱們用獨立的組件進行構建。組件能夠獨立開發、渲染、構建、測試、版本、發佈，甚至能夠經過CI，而不須要耦合到任何具體的項目中。

此外，Bit還提供了兩個關鍵特性。首先，它提供了對全部組件的依賴關係圖的通用控制。它自動解析每一個組件的依賴關係，只要任何依賴關係發生變化，它就會讓你準確地知道應該改變什麼。其次，它提供了0配置的可重用和可定製的開發環境，所以組件能夠經過本身的構建管道與任何更大的項目分離，這些變化能夠在整個組件的依賴圖中構建。

這聽起來好像不少，事實也是如此，但Bit實際上讓構建獨立的組件變得很是簡單，這些組件能夠自行開發和發佈。

2. 咱們的雲平臺爲團隊(包括咱們本身)提供了一個協做中心，在這裏，每一個人均可以發佈組件，輕鬆地記錄它們(比特將這一過程自動化)，發現和安裝它們。這讓咱們的團隊能夠共享和重用咱們構建的接近100%的組件。

爲了確保每一個前端都能得到本身獨立的快速構建流程，Bit還提供了獨特的CI/CD流程，它是**100%組件驅動的，這意味着不一樣的團隊能夠安全地集成變動，而無需等待、爭奪主控權或破壞任何東西。開發人員能夠在全部受影響的應用程序中持續、安全地傳播對組件的變動。

與其在一個構建過程當中構建全部團隊都必須經歷的單體項目，組件驅動的CI將構建過程分割開來，使其只運行在實際發生變化的組件上，並將變化無限地傳播到其依賴圖上，以構建每個受影響的組件，在每個應用程序的每個頁面上。

這讓咱們能夠將不一樣團隊的發佈管道從彼此之間解放出來，這樣每一個團隊就能夠獨立地、持續地發佈變動和更新到生產中。這也意味着大約50倍的構建速度，由於並非全部的東西都會被構建。並且，咱們能夠將問題和錯誤精確到具體的組件。

成功的變動能夠自動轉化爲拉取請求，並自動發送給全部相關項目，這樣他們的維護者就能夠安全地採用這些變動，並確保他們的應用程序始終保持最新版本。Bit.dev還爲咱們提供了不一樣項目中全部組件的概覽，這樣咱們就能夠準確地監控和規範誰在什麼版本中使用哪一個組件。

咱們的流程

康威法則](https://en.wikipedia.org/wiki...，軟件架構和組織結構之間有很強的關聯性。在構建微前端時，這是很是正確的，由於主要目標是讓組織更有效率。解耦代碼庫，實現集成，或者分割發佈管道，都是構建更好的軟件以及自主敏捷團隊的方法。

Autonomous teams

一個小團隊被受權作決定，並不懈地朝着目標前進，會比一個大團隊更快地提供結果和洞察力。畢竟，有誰比擁有產品的團隊更瞭解產品的用戶和問題呢？

因爲咱們的組件驅動架構的靈活性，咱們可以分配團隊的全部權，並以一種更加動態、垂直和上下文相關的方式。咱們沒有讓bit.dev的 "前端團隊 "和 "營銷網站團隊 "一塊兒在一個單體應用上工做，而是在各個方面將這些團隊徹底分開。

首先，有幾個開發人員被認爲是 "前端基礎設施團隊"，他們直接彙報維護bit.dev平臺的一套基本組件。在這個團隊中，還有一名設計師、一名產品經理和一些利益相關者。他們獨立於其餘使用這些功能的團隊構建、發佈和更新功能。

"組件搜索 "團隊，負責bit.dev上的複雜搜索功能，由幾個開發人員（包括前臺和後臺）、一個NLP研究員和一個產品經理組成。它將組件暴露出來，供其餘團隊集成到他們的產品中。

"組件發現 "團隊包括幾名開發人員、一名兼職設計師和一名兼職產品經理，以構建一套用於記錄、可視化和交互的組件，這些組件在bit.dev平臺上共享。事實上，因爲比特的緣故，不管是在比特的本地開發工做區，仍是在雲平臺上，一樣的文檔組件都是由這個團隊構建的。

又有幾個開發人員被分配到營銷團隊，與幾個營銷人員和一個設計師一塊兒構建營銷的一套組件，這些組件被用來組成咱們的營銷網站，以及一些更多的應用。

客戶成功團隊，有本身的開發人員，構建和維護本身的一套組件，這些組件實現了整個Bit.dev平臺上使用的不一樣的用戶交互，甚至在咱們構建的其餘網站和應用中也使用。

這樣的例子不勝枚舉，而每一個功能都成爲一個團隊自主負責構建和運維的組件，供其餘團隊也整合和使用。

簡單的、解耦的代碼庫

解耦代碼庫使功能更容易開發、測試、維護、替換或升級。咱們但願可以不斷增長新的技術和功能。

咱們的每一個團隊都在一個徹底不一樣的、解耦的代碼庫中工做。它開發、測試和維護本身的功能，而沒有與其餘團隊在comlex單體中工做的限制和痛苦。

每一個功能或產品的源代碼天然要比整個應用的源代碼小得多，也簡單得多，這使得eah代碼庫更容易開發、測試和維護，而沒有在一個單體內部共同工做的限制和痛苦。

若是你回顧一下bit.dev主頁上的 "base-ui "和 "evangelist "例子，你會發現每一套組件都是在不一樣的代碼庫中開發的。這兩套組件都是相互解耦的，並被集成在一塊兒以建立不一樣的頁面、功能和應用程序。

因爲全部的代碼庫都是相互解耦的，並且每個代碼庫都是由大部分甚至是徹底由組件組成的，所以，逐步重構咱們的應用程序的部分也變得容易得多（不少），這樣咱們就能夠快速而安全地添加或替換技術。

隨着時間的推移，必須明肯定義哪些代碼屬於每一個代碼庫，是一個很好的方法，能夠更好地理解咱們正在構建的架構，以及每一個部分在其中的做用。

獨立的釋放管道

咱們可以將不一樣團隊的發佈流水線相互拆分、解耦，讓每一個團隊都能獨立構建併發布多個應用的變動，而不須要等待版本臃腫或爭奪主分支。

如上所述，經過Bit和Bit.dev，咱們可以爲每一個團隊的組件集指定一個自定義但標準化的構建管道。所以，儘管是單獨構建，但全部組件均可以經過相同的任務和工具。

而後，Bit.dev（Beta版）上的（速度快50倍）組件驅動的CI流程會在每個頁面和每個應用中映射和構建改變全部依賴組件的傳播依賴圖。

用簡單的話說，每一個團隊均可以對任何組件進行更改，獨立構建這些更改，並瞭解它是否以及如何在全部相關應用中破壞其餘組件和其餘團隊。

若是一切順利，這些變動會自動轉化爲Pull-Request，發送到全部相關項目，這樣它們的全部者就能夠更新他們的組件。他們甚至能夠經過Slack得到通知和提醒。在Bit.dev的 "項目 "功能中（咱們團隊的另外一個項目），咱們能夠查看和監控誰採用了哪一個PR，在哪裏。

所以，咱們不須要再去搞繁瑣的iframes，也不須要再去尋找其餘的解決方案，而是依靠構建時的集成，不將咱們的發佈流程耦合在一塊兒。目前，這對咱們來講效果很是好，咱們的組件驅動的CI將在幾周內推出Beta版，因此當它出來時，也能夠隨時試駕。在將來，咱們確實有一個計劃，要一路走下去，實現組件驅動的應用部署。

無限的組件複用和協做

[

](https://bit.dev/)

咱們將全部的組件發佈到Bit.dev.上，在那裏，咱們全部的團隊都會以有趣和有效的方式相互分享、發現、協做和重用組件。在那裏，咱們全部的團隊都能以有趣而有效的方式相互分享、發現、協做和重用組件。

新增的功能，如可視化組件文檔、智能組件搜索，甚至是實時模擬，都有助於讓咱們全部的組件都能被發現，這樣咱們就不須要維護任何額外的文檔網站、註冊表或工具。

這種協做系統使開發人員更容易分享代碼、提出反饋意見，並確保一致性。咱們特別喜歡這樣的事實：它能夠幫助新加入團隊的開發人員縮短學習曲線，由於他們能夠找到並開始使用現有的組件，這樣他們就能夠當即開始構建。

對咱們來講，這也是改善開發人員和其餘利益相關者之間合做的有用方法，好比咱們的設計師和產品，他們如今能夠看到咱們全部的組件。

結論

有人說微前端無非是一種 "好的組件模式"。對於咱們來講，它是一個好的組件模式，同時也是一個更好的方式來創建咱們本身的團隊，改善咱們的工做方式，構建更好的模塊化軟件，並更快、更頻繁地交付。

對於大型組織來講，獨立的團隊交付是他們構建和發佈成功的Web應用程序的能力的真正遊戲改變者。標準化組件開發，並容許團隊相互分享和協做的能力也是如此。

對於小團隊來講，採用靈活和可擴展的架構將提升他們的發展能力，快速添加新功能，招收新員工，專一於核心技術和創新，而不是專一於不那麼重要的事情。

但願你能在組件驅動的微前端的理念中找到對你有用的東西，謝謝你的閱讀!