微前端：前端的微服務

作者：qaseven 2022-10-17 15:21:18

微服務是構建可以獨立工作的小型自治團隊的流行方式。不幸的是，就其本質而言，微服務只在后端工作。即使有最好的微服務架構，前端開發仍然需要高度的相互依賴，這會引入耦合和通信開銷，這會拖慢每個人的速度。

我們可以采用微服務架構模式并將其應用到前端嗎?

我們可以采用微服務架構模式并將其應用到前端嗎?事實證明我們可以。Netflix、Zalando和Capital One等公司已將這一模式推向前沿，為微前端奠定了基礎。本文將探討微前端、它們的優點和缺點，以及它們與傳統微服務的不同之處。

前端的微服務

當我們將微服務方法帶到前端時，我們就會得到微前端。換句話說，微前端由不同團隊擁有的組件組成，這些組件可以獨立部署。組裝這些組件以創建一致的用戶體驗。

從左到右，我們展示了 4 個場景。跨越所有場景，中間的水平線將前端與后端分開。

在左側，我們有一個跨越前端和后端(包括 UI)的單體。接下來，我們在后端有一個單體應用程序，在前端有一個 SPA 網頁(UI 與后端分離)。在第三個位置，我們在前端有相同的 SPA，但在后端將單體拆分為微服務。最后一個場景在后端使用微服務，在前端使用微前端。前端包括與其余部分隔離的不同組件或小部件。

單體可以以不同的方式分解。我們可以拆分前端和后端或在后端使用微服務。我們甚至可以將前端重新創建為由不同團隊管理的隔離組件的集合。

使用微前端，沒有一個團隊擁有整個 UI。相反，每個團隊都擁有一塊屏幕、頁面或內容。例如，一個團隊可能負責搜索框，而另一個團隊可能會根據用戶的口味對建議進行編碼。其他團隊可能會對音樂播放器進行編碼、管理播放列表或呈現計費頁面。我們增加了復雜性，但作為回報，團隊獲得了更多的自主權。

音樂流媒體網站的線框圖。總共有5個團隊：“主頁”本身的一個，播放列表的一個，推薦的一個，搜索框的一個，音樂播放器的一個。每個團隊都在主頁內分配了相應的小部件或組件。

前端功能由不同的團隊管理，獨立部署，并以透明的方式注入到最終用戶的主頁中。

微前端的好處和挑戰

微前端提供與微服務類似的好處。也就是說，我們可以通過將前端代碼分解成獨立的部分來擴大開發規模，由不同的團隊負責。與微服務一樣，每個功能都可以隨時自行發布，幾乎不需要協調。這導致更頻繁的更新。

垂直團隊

微前端可以創建垂直團隊，這意味著一個全棧開發團隊可以同時擁有后端和前端的功能。

垂直團隊處理給定功能或組件的所有功能和代碼。我們有 3 個團隊：建議、搜索和播放列表。每個團隊都獨立于其他團隊管理其微服務后端和微前端。

全棧垂直團隊負責功能或組件的前端和后端。

可連續部署的組件

微前端的每個部分都是一個可部署的單元。這允許團隊發布他們的更改，而無需等待發布火車或依賴其他團隊完成他們的工作。最終結果是前端可以每天更新幾次。

每個團隊都有一個單獨的源存儲庫、CI/CD 管道和生產服務，為微前端內容提供服務。

所有獨立微前端的組合在客戶端呈現一個前端。

每個團隊都可以擁有單獨的存儲庫、CI/CD 管道和服務機器。或者，我們可以在 monorepo 上托管所有內容，并擁有一個共享的 CI/CD 管道。

微前端設計的挑戰

微前端的主要挑戰是創建一個快速響應的客戶端。我們絕不能忽視這樣一個事實，即前端存在于內存、CPU 和網絡有限的環境中，否則我們就有可能導致 UI 緩慢。

簡潔的用戶界面對于產品的成功至關重要。最近的一項調查指出，“1 秒內加載的網站的轉化率是 5 秒內加載的網站的 3 倍”。用戶必須等待的每一秒，錢都會被扔出窗外。

除了微服務所面臨的所有挑戰之外，微前端設計還帶來了一些問題：

隔離：每個團隊的代碼最終都必須在同一個瀏覽器上共存。我們必須慎重隔離單獨的模塊以避免代碼或樣式沖突。
共享資源：為避免重復并保持前端精簡，組件應盡可能共享資產和庫，這可能會產生不良耦合。
可訪問性：嚴重依賴 JavaScript 來呈現頁面會對可訪問性產生負面影響。
樣式：當 UI 由各個團隊制作的組件組成時，保持一致的外觀更加復雜。小的風格不一致會讓人感到不和諧。
協調：有這么多活動部件，API 需要非常明確和穩定。團隊必須協調微前端中不同組件之間以及后端微服務之間的通信方式。

構建微前端的原則

有兩種互補的方法可以從單獨的微前端組件渲染統一的 UI：服務器端渲染和客戶端渲染。

服務器端渲染 (SSR)

服務器端渲染提供更快的性能和更易于訪問的內容。在服務器上渲染是快速提供內容的好選擇——尤其是在低功耗設備(如低端手機)上。當 JavaScript 被禁用時，它也是一種合適的后備模式。

服務器端渲染示意圖。網絡服務器輪詢各種微服務。他們用網絡服務器組裝并轉發給用戶瀏覽器的 HTML 片段進行回復。

網絡服務器從不同微服務提供的內容中組裝完整的頁面。這是第一個內容豐富的頁面。然后可以使用水合來添加更多動態內容。

我們有幾種執行 SSR 的方法：

服務器端包含(SSI)：是一種由網絡服務器執行的簡單腳本語言。該語言使用指令將 HTML 片段構建成一個完整的頁面。這些片段可能來自其他文件或程序的響應。所有主要的網絡服務器都支持 SSI，包括 Apache、Nginx 和 IIS。
iframes：古老的 iframe 功能允許我們在頁面上嵌入任意 HTML 內容。
Edge Side Includes (ESI)：一種更現代的 SSI 替代方案。ESI 可以處理變量，有條件，并支持更好的錯誤處理。緩存 HTTP 服務器(例如Varnish )支持 ESI 。

因此，例如，我們可以使用 SSI 從 HTML 渲染頁面：

<div>
<!--#include virtual="/hello-world" -->
</div>

該virtual關鍵字使網絡服務器從 URL 或 CGI 程序請求內容。在我們的例子中，我們需要設置網絡服務器以/hello-world使用合適的片段根據路徑響應請求：

<h1>Hello World!</h1>

SSR 在許多 Web 框架中用于渲染第一個屏幕。此外，還有一些有趣的特定于 SSR 的實用程序，例如compoxure、nodei和Tail。

客戶端渲染 (CSR)

客戶端渲染通過從微服務獲取數據并操作 DOM 在用戶瀏覽器中構建頁面。大多數 Web 框架使用某種形式的 CSR 來改善用戶體驗。

客戶端渲染示意圖。用戶的瀏覽器從 CDN 下載頁面源。

在加載時，頁面從不同的微服務端點加載數據并動態呈現視圖。

CSR 使用端點提供的數據在用戶瀏覽器上動態呈現頁面。

我們編寫松散耦合組件的主要工具是自定義元素。自定義元素是 HTML 標準的一部分。它們允許我們創建新的 HTML 標記并將邏輯和行為附加到它們。

使用 JavaScript 從頁面動態裝載和卸載自定義元素：

// hello-world-component.js
class HelloWorld extends HTMLElement {
connectedCallback() {
this.innerHTML = `<h1>Hello world</h1>`;
}
}
customElements.define('hello-world', HelloWorld);

定義后，我們可以像使用任何其他 HTML 標記一樣使用新元素：

<hello-world></hello-world>

在示例中，整個頁面將包含一個用于獲取 JavaScript 組件的腳本標記：

<!doctype html>
<head>
<meta charset="utf-8">
<title>Microservice Example</title>
</head>
<body>
<script src="./hello-world-component.js" async></script>
<hello-world></hello-world>
</body>

雖然大多數前端框架都可用于微前端，但有些框架是專門為它們設計的：

Piral：實現稱為pilets的獨立組件。Pilets 是捆綁內容和行為的模塊。
Ragu：框架的框架。它允許我們將編寫在任何框架中的代碼作為小部件嵌入。
單一 SPA：一個元框架，用于將 UI 拼湊在一起，使用 React、Angular 和 Ember 等前端框架的任意組合。
Frint：另一個用于構建基于組件的應用程序的模塊化框架。與 React、Vue 和 Preact 集成。
Module Federation：一個 WebPack 插件，通過捆綁單獨的構建來創建單頁應用程序 (SPA)。這些構建可以獨立于每個構建

結論

切換到微前端架構可以給我們的開發團隊更多的自主權，從而加速開發。但是，適用于微服務的相同警告也適用于微前端。我們需要經過驗證的設計，這意味著微前端不適合新建項目。

新項目最好采用傳統模式，例如由單個團隊管理的單頁應用程序 (SPA)。只有前端經受住了時間的考驗，我們才能將微前端視為前進的方向。

責任編輯：華軒來源：今日頭條

微服務開發前端