微前端是一個可以追溯到多年前的新趨勢。隨着新方法的出現以及各種挑戰被克服，它們正在慢慢地進入主流。但遺憾的是，許多非常明顯的認識誤區，讓許多人很難理解微前端到底是什么。
簡而言之，微前端就是將微服務的一些好處引入前端。除此之外，我們不應該忘記，微服務也不是什么“銀彈”。
提示：要在微前端或任何其他項目之間共享 React/Angular/Vue 組件，可以使用像 Bit 這樣的工具。它允許你從任何代碼庫中“harvest”組件，並將它們共享到 bit.dev 的一個集合中。它讓團隊可以在任何存儲庫中使用你的組件。使用它可以優化協作、加速開發和保持 UI 一致性。
示例：在 bit.dev 中查找共享 React 組件
認識誤區
我想列一下在過去幾個月中，我最常聽到的關於微前端的誤解。先從從一個明顯的例子開始。
微前端需要 JavaScript
目前，許多微前端解決方案都是 JavaScript 框架。這怎么可能錯呢？JavaScript 不再是可選的。每個人都想要高度交互的體驗，而 JS 在提供這些體驗中發揮着至關重要的作用。
除了加載速度快、可訪問 Web 應用的優點外，還有其他因素應該考慮。因此，許多 JavaScript 框架都提供了 isomorphic 渲染能力。最終，這讓它們不僅能夠在客戶端進行拼接（stitch），還能在服務器上准備好一切。如果有性能要求（如第一次有意義渲染的初始時間），這個選項聽起來很不錯。
請記住，isomorphic 渲染有其自身的挑戰。
然而，即使一個 JavaScript 解決方案沒有提供 isomorphic 呈現，這也沒什么問題。如果不想在構建微前端時使用 JavaScript，我們當然可以這樣做。有許多模式，其中很多根本不需要 JavaScript。
考慮一種“比較舊的”模式：使用<frameset>。我聽見你笑了？好吧，有一些現如今人們試圖做的分割，它以前就支持了（下文有更詳細的討論）。一個頁面（可能由另一個服務渲染）負責菜單，而另一個頁面負責標題。
復制代碼
<frameset cols="25%,*,25%"> <frame src="menu.html"> <frame src="content.html"> <frame src="sidebar.html"></frameset>如今，我們使用更靈活（且仍然受到活躍支持）的<iframe>元素。它們提供了一些很好的特性——最重要的是使得不同的微前端相互隔離，但仍然可以通過postMessage進行通信。
微前端只在客戶端有效
在 JavaScript 認識誤區之后，這是下一個層次。當然，在客戶端有多種技術可以實現微前端，實際上，我們甚至不需要<iframe>或任何類似的技術。
微前端可以像服務器端“includes”一樣簡單。有了諸如 Edge Side Includes 之類的高級技術，這將變得更加強大。如果我們排除了在微前端功能中實現的微前端場景，那么即使是簡單的鏈接也可以很好的工作。最終，微前端解決方案也能像小而獨立的服務器端渲染器一樣簡單。每個渲染器可能只有一個頁面那么小。
下圖展示了在反向代理中發生的更高級的拼接：
通過反向代理實現服務器端拼接
當然，可能 JavaScript 有許多優點，但它仍然高度依賴於你試圖通過微前端解決的問題。根據你的需要，服務器端解決方案可能仍然是最好的（或者至少是更好的）選擇。
你應該使用多個框架
在幾乎每一個關於微前端的教程中，不同的部分不僅由不同的團隊開發，而且使用了不同的技術。這是假的。
適當的微前端方法可能使用不同的技術，但是，這不應該是目標。我們做微服務也不只是為了在后端拼湊技術。如果我們使用多種技術，那只是因為我們獲得了一個特定的好處。
我們的目標應該始終是某種統一性。最好的方法是考慮一個新項目：我們會怎么做？如果答案是“使用單一框架”，那么我們就走上正軌了。
長遠來看，有很多原因可以解釋為什么應用程序中會出現多個框架。可能是遺留的，可能為了方便，也可能是一個概念驗證。無論是什么原因：能夠處理這種場景還是不錯的，但它絕不應該是開始就希望達到的狀態。
不管你的微前端框架多高效——使用多個框架總是要付出不可忽視的代價。不僅初始渲染會花費更長的時間，而且內存消耗也會朝着錯誤的方向發展。不能使用方便模型（例如，針對某個框架的模式庫）。需要更多的重復。最終，程序的 Bug 數量、不一致行為和可感知的響應性都會受到影響。
按技術組件划分
一般來說，這沒有多大意義。我還沒見過微服務后端的數據處理在一個服務中而 API 在另一個服務中。通常，服務由多個層組成。雖然某些技術內容（如日志記錄）肯定會引入到公共服務中，但有時也會使用諸如 Sidecar 之類的技術。此外，還需要通用服務編程技術。
對於微前端，情況也是如此。為什么一個微前端只能做菜單？每個微前端都有相應的菜單嗎？拆分應該根據業務需求來做，而不是技術決策。如果你讀過一些關於領域驅動設計的書，你就會知道它是關於定義這些領域的——而這個定義與任何技術要求無關。
考慮以下划分：
按布局分解成微前端
這些都是技術組件，和微前端無關。在一個真實的微前端應用程序中，屏幕可能看起來是這樣的。
按領域分解成微前端
的確，這里的拼接要復雜得多，但這是一個可靠的微前端應用程序應該為你提供的！
不應該共享任何東西
不。你應該共享那些值得共享的東西。你絕對不應該共享所有東西（見下一條）。但要做到始終如一，你至少需要共享一套原則。至於是通過共享庫、共享 URL，或者只是在構建或設計應用程序時使用的文檔，那就不重要了。
對於微服務，“無共享”架構如下圖所示：
微服務的“無共享”架構
在瀏覽器中，這將導致使用<iframe>，因為目前沒有其他方法可以防止資源泄漏。使用影子 DOM，則 CSS 可能會被隔離，但腳本層面仍然能訪問所有內容。
即使想遵循無共享的架構，我們也會遇到麻煩。
當然，共享的程度越深（例如，使用一個通過應用 shell 追加到 DOM 的共享庫），就越會出問題。另一方面，共享程度越淺（例如，只是一個指定基本設計元素的文檔），就會出現更多的不一致性。
應該共享一切
絕對不是。如果這樣想，那么單體更有意義。就性能而言，這可能已經是一個問題了。什么可以延遲加載？我們能去掉一些東西嗎？但真正的問題是依賴管理。什么都不能更新，因為它可能會破壞某個東西。
共享部件的好處是一致性保證。
現在，如果我們共享所有的東西，我們就是用復雜性來換一致性。這種一致性是不可維護的，因為復雜性會在每個角落引入 Bug。
問題的根源在於“依賴地獄”。下圖很好地說明了這一點。
簡而言之，如果一切都相互依賴，那么我們就會有依賴問題。僅僅更新一個方框就會影響整個系統。一致嗎？確實。簡單的？絕不。
微前端只是 Web 端的
為什么只是 Web？誠然，到目前為止，我們接觸到的主要是 Web，但其概念和想法可以應用於任何類型的應用程序（移動應用、客戶端應用……甚至是 CLI 工具）。在我看來，微前端只是“插件架構”的一個花哨叫法。不過，插件接口如何設計，以及運行使用插件的應用程序需要具備什么條件，這就是另外一回事了。
下圖顯示了一個非常通用的插件架構，來自 Omar Elgabry ：
通用插件架構
該架構並沒有在哪里運行的概念。它既可以在手機上運行，也能在 Windows 上運行，甚至還能在服務器上運行。
微前端需要大型團隊
為什么？如果解決方案超級復雜，那么我肯定會找一個簡單的。有些問題需要復雜的解決方案，但好的解決方案通常是簡單的。
根據場景的不同，它甚至可能不需要一個分布式團隊。擁有分布式團隊是采用微前端的首要原因之一，但這不是唯一原因。另一個很好的理由是特性的粒度。
如果從業務的角度來看微前端，那么你就會發現，擁有啟用和關閉特定特性的能力是很有意義的。針對不同的市場，使用不同的微前端。回到一個簡單的權限模式，這是有意義的。不需要編寫代碼來根據特定條件打開或關閉某些東西。所有這些都留給公共層，可以根據（可能是動態的）條件激活或停用。
這樣，不能（或不應該）使用的代碼也不會被交付。雖然這不應該是一個保護層，但它肯定是一個便捷（和性能）層。用戶不會感到困惑，因為他們看到的是他們能做的。他們看不到沒有交付的功能，所以沒有字節浪費在不可用的代碼上。
微前端無法調試
對於任何類型的實現（或供討論的底層架構），開發經驗都可能遭到削弱。應對這種情況的唯一方法是開發人員優先。實現中的第一原則應該是：使調試和開發成為可能。采用標准的工具。
有些微前端框架根本不接受這一點。有些需要在線連接、專用環境、多重服務……這不應該是標准，也絕不是常態。
微服務需要微前端（或反過來）
解耦的模塊化后端可能為解耦前端打下了一個很好的基礎，但通常情況下，情況並非如此。后端單體，前端模塊化，也是完全可行的，例如，為簡化個性化可能就要結合授權、權限和市場。
實際上，同樣，微服務后端並不能證明適合將類似的模式應用於前端。許多微服務后端都是由單用途的應用程序操作的，它們的功能沒有增加，只是外觀發生了改變。
微前端需要單存儲庫
我已經讀到過好幾次，要創建一個微前端解決方案，就需要利用單存儲庫，最好使用像 Lerna 這樣的工具。我不認可這一點。當然，單存儲庫有一些優點，但也有明顯的缺點。
雖然有一些微前端框架需要聯合 CI/CD 構建，但大多數都不需要。聯合 CI/CD 構建通常會導致單存儲庫，因為其設置要簡單得多。但對我來說，這是單體重新打包。如果你在單存儲庫上進行聯合構建，那么你就失去了讓微前端富有吸引力的兩個非常重要的優點：
- 獨立部署
- 獨立開發
不管怎樣，如果你看到微前端解決方案需要單存儲庫：那樣做就行。一個精心設計的單體系統可能會更好，它不會有分布式系統的所有問題。
結論
微前端技術並不適合所有人。我不認為微前端是未來的發展趨勢，但我也相信它們在未來會發揮重要作用。
轉自https://www.toutiao.com/i6882230526820745739/?timestamp=1602548270&app=news_article&group_id=6882230526820745739&use_new_style=1&req_id=202010130817500100140540150A3EE695
喜歡這篇文章？歡迎打賞~~
