來看下知名團(tuán)隊(duì) Vercel 是如何使用【微前端】的吧！

作者：Vercel 官方團(tuán)隊(duì) 2024-10-30 12:26:44

隨著迭代速度的加快，我們正在全力推動整個平臺的微前端發(fā)展，重點(diǎn)優(yōu)化路由、簡化預(yù)覽工作流程，并提升硬導(dǎo)航性能。同時，我們正致力于增強(qiáng)儀表板體驗(yàn)并解決工作流程中的挑戰(zhàn)，以全面提升微前端開發(fā)的效率。

Vercel 是一個專為前端開發(fā)者提供一體化平臺，簡化 Web 應(yīng)用程序的構(gòu)建和部署流程的公司。

除此之外，Vercel 團(tuán)隊(duì)還開源了很多知名前端框架，比如：Next.js。所以這是一個典型的由眾多技術(shù)大佬組成的團(tuán)隊(duì)。

差點(diǎn)跑偏了，咱們回到今天內(nèi)容的主題！

在上周，Vercel 團(tuán)隊(duì)公布了他們內(nèi)部的【微前端設(shè)計方案】，所以咱們今天就來看看，這種頭部技術(shù)團(tuán)隊(duì)，如何構(gòu)建微前端方案的！

Vercel 如何采用微前端

官方團(tuán)隊(duì)原文：https://vercel.com/blog/how-vercel-adopted-microfrontends

Vercel 的主網(wǎng)站曾是一體化的 Next.js 大型應(yīng)用，既服務(wù)于普通訪客，也涵蓋登錄用戶的儀表板。然而，隨著 Vercel 的快速擴(kuò)展，這種架構(gòu)逐漸暴露出效率瓶頸：構(gòu)建時間延長、依賴管理復(fù)雜化、工作流程頻繁卡頓。哪怕是微小的變更，都需要重新構(gòu)建整個應(yīng)用，延緩了獨(dú)立開發(fā)的進(jìn)度，也影響了 CI 管道的運(yùn)行效率。

于是，我們意識到：是時候進(jìn)行架構(gòu)變革了。

我們重新設(shè)計了架構(gòu)，轉(zhuǎn)向垂直微前端，從而簡化了開發(fā)體驗(yàn)，縮短了預(yù)覽構(gòu)建時間和本地開發(fā)編譯時間——提升超過 40%。通過刪除非必要的微前端代碼，我們不僅減少了依賴的體積，還大幅降低了頁面加載時間，從而優(yōu)化了用戶性能。此舉使得核心 Web 指標(biāo)，如最大內(nèi)容繪制 (LCP) 和下一次繪制交互 (INP) 等都有了顯著提升。

在 Vercel 對微前端支持的基礎(chǔ)上，這一重大調(diào)整極大地改善了開發(fā)人員體驗(yàn) (DX)，同時也為進(jìn)一步優(yōu)化提供了清晰的方向。通過此次內(nèi)部大規(guī)模遷移測試，我們?yōu)槠脚_開發(fā)找到了更高效的流程。這篇博客不僅記錄了我們的轉(zhuǎn)型歷程，也展示了我們?yōu)殚_發(fā)者簡化流程、加速構(gòu)建的實(shí)踐。今后，我們將持續(xù)提升單個應(yīng)用程序的構(gòu)建速度，在保障用戶性能的前提下，實(shí)現(xiàn)更優(yōu)越的開發(fā)體驗(yàn) (DX)。

接下來，讓我們深入探討這次轉(zhuǎn)型的具體方法。

利用 Turbo

我們的第一步是著力改善本地編譯、構(gòu)建時間和 CI 工作流程。借助 Turborepo 支持的 Vercel monorepo，我們能夠利用 Vercel Remote Cache 等功能，在 CI 管道中智能執(zhí)行受影響的任務(wù)，大幅度減少了冗余操作。同時，我們引入了 Turbopack，極大提升了本地開發(fā)的速度。

然而，在推進(jìn)這些優(yōu)化的過程中，我們意識到：單一應(yīng)用模式對當(dāng)前的 Vercel.com 已不再必要。通過應(yīng)用內(nèi)邏輯拆分，我們能夠避免構(gòu)建和編譯中的無效工作，為開發(fā)人員帶來更顯著的速度提升。

水平和垂直微前端的選擇

為了進(jìn)一步提升效率，我們引入了微前端架構(gòu)，將大型應(yīng)用分解為更小、更獨(dú)立的單元，支持跨產(chǎn)品領(lǐng)域和工程團(tuán)隊(duì)的并行開發(fā)。微前端架構(gòu)的主要分割策略包括：

垂直微前端：按路徑拆分，即每個頁面由單個應(yīng)用管理。這種方式清晰而高效，適合具有獨(dú)立頁面邏輯的場景，確保每個頁面的開發(fā)與構(gòu)建相對獨(dú)立。
水平微前端：按功能拆分，多個應(yīng)用同時在一個頁面上運(yùn)行。這種方式更適合需要在單頁內(nèi)加載不同功能模塊的復(fù)雜應(yīng)用場景。

圖片

微前端的兩種常見方法：單個頁面內(nèi)的多個微前端（水平分割）或使用單個微前端管理整個頁面（垂直分割）。

每種微前端方法各有優(yōu)缺點(diǎn)，根據(jù)具體用例都能帶來實(shí)質(zhì)性好處。正如 Luca Mezzalira 在其微前端專著中所述，垂直和水平分割的選擇應(yīng)依據(jù)項(xiàng)目需求權(quán)衡。

垂直分割提供了良好的內(nèi)聚力，但在切換不同微前端應(yīng)用時可能帶來導(dǎo)航挑戰(zhàn)。雖然預(yù)取技術(shù)和 Chromium 的推測 API 可以緩解這一問題，但它們往往會增加資源使用，并受限于瀏覽器支持。

相比之下，水平分割在同一頁面上運(yùn)行多個微前端模塊，使得測試、發(fā)布、監(jiān)控和調(diào)試更復(fù)雜，增加了運(yùn)維管理難度。

我們最終選擇了垂直微前端，將應(yīng)用拆分為用戶少訪問的邏輯部分，以減少構(gòu)建時間和依賴復(fù)雜度，同時保留了單一存儲庫的統(tǒng)一性。早期測試結(jié)果顯示，這種方法將構(gòu)建時間縮短了 50%，并在開發(fā)與生產(chǎn)中簡化了模塊所有權(quán)，使開發(fā)人員能夠享受到單一應(yīng)用的流暢體驗(yàn)。

我們的遷移路徑

接下來，我們將單體前端應(yīng)用遷移到更小的垂直應(yīng)用中，以確保開發(fā)和用戶體驗(yàn)不受影響。具體來說，我們將應(yīng)用劃分為三個核心區(qū)域：

營銷
文檔
登錄儀表板

這些區(qū)域在功能和用戶界面上各自獨(dú)立，用戶不常在它們之間切換，因此非常適合分離。

圖片

用戶在單個微前端內(nèi)體驗(yàn)軟導(dǎo)航，在微前端之間移動時體驗(yàn)硬導(dǎo)航

借助 Next.js 的 Multi-Zones 功能，我們可以無縫支持垂直微前端架構(gòu)。為了控制遷移風(fēng)險，我們選擇增量遷移，創(chuàng)建全新的應(yīng)用而非分叉原始代碼庫。雖然分叉看似簡單，但它會帶來復(fù)雜的同步和一致性問題，尤其是在共享頁眉、頁腳和設(shè)計系統(tǒng)等組件時，需要在多個存儲庫中維護(hù)。

繼續(xù)使用 monorepo 并將代碼集中到 packages 中，使得共享組件能夠保持一致，同時可以靈活劃分關(guān)鍵區(qū)域。我們采用了 Turborepo 和 Dependency Cruiser 等工具，以便簡化分區(qū)和依賴管理過程。

圖片

Vercel 的 monorepo 采用“apps”文件夾中的獨(dú)立微前端結(jié)構(gòu)，同時提升共享包以實(shí)現(xiàn)所有應(yīng)用程序的無縫訪問。

通過功能標(biāo)記，我們逐步將流量從單體前端應(yīng)用轉(zhuǎn)移至新的微前端應(yīng)用，從而在刪除舊代碼前驗(yàn)證性能改進(jìn)并將風(fēng)險降至最低。一旦新頁面穩(wěn)定運(yùn)行一周且無錯誤，我們便從現(xiàn)有應(yīng)用中移除舊代碼，從而逐步減少依賴并縮短構(gòu)建時間。

圖片

在增量遷移期間，頁面同時存在于原始前端整體和新的微前端中。功能標(biāo)志控制路由，直到微前端版本完全上線。

借助 monorepo 設(shè)置和垂直分區(qū)方法，我們得以快速行動，保持一致性并縮短構(gòu)建時間，同時讓整個開發(fā)過程始終清晰、簡單。

吸取的教訓(xùn)和管理權(quán)衡

在成功實(shí)現(xiàn) Vercel.com 的微前端架構(gòu)后，我們將同樣的方法擴(kuò)展到其他項(xiàng)目，例如 2024 年 Next.js Conf 頁面。此頁面作為獨(dú)立于 nextjs.org 的應(yīng)用運(yùn)行，得益于新架構(gòu)，不同的區(qū)域可以獨(dú)立提取為單獨(dú)的應(yīng)用程序，從而加快開發(fā)周期。Next.js Conf 團(tuán)隊(duì)和 Next.js 開發(fā)團(tuán)隊(duì)可以快速、獨(dú)立地迭代更新。

然而，遷移過程中仍然面臨挑戰(zhàn)。為確保性能不受影響，我們采用了 Speed Insights 等工具來實(shí)時監(jiān)控用戶體驗(yàn)，并使用 Vercel Toolbar 跟蹤布局轉(zhuǎn)換和交互時間警報，確保頁面響應(yīng)性達(dá)標(biāo)。

我們也意識到在本地和預(yù)覽版環(huán)境中測試微前端相當(dāng)困難。例如，草稿模式等功能不穩(wěn)定，而性能瓶頸（如硬導(dǎo)航）更是常見問題。為了解決這些問題，我們應(yīng)用了預(yù)取和預(yù)渲染策略，借助 Chromium 的推測規(guī)則優(yōu)化用戶體驗(yàn)。

平衡性能與資源使用的策略

為降低硬導(dǎo)航的延遲，我們首先加載初始頁面資源（JavaScript 和 CSS），在鏈接可見時提前填充瀏覽器緩存。這樣用戶導(dǎo)航時，資源可以立即從緩存中加載，減少等待時間。但頁面仍需渲染并獲取其他資源（如 HTML）來完成加載。

我們更進(jìn)一步，在用戶交互（例如點(diǎn)擊鏈接）時預(yù)渲染頁面，使頁面在后臺完成渲染和網(wǎng)絡(luò)請求處理。這樣當(dāng)用戶到達(dá)頁面時，體驗(yàn)更接近即時加載。通過在適當(dāng)時機(jī)執(zhí)行預(yù)取和預(yù)渲染，我們在性能與資源使用之間取得了平衡，避免設(shè)備過載，同時提供了流暢的用戶體驗(yàn)。

圖片