【譯】我不懂微前端（前端微服務）

原文

我不懂微前端

昨天，在和個人狗一塊兒散步回來以後，我在推特上看到了一些通知，人們艾特我，要求我分享對 Dan Abramov 關於微前端 的想法：

若是你關注了我，你就知道我對微前端很是熱衷，我和他們一塊兒工做了一段時間，而且也保持着開放的心態，分析不一樣的方式，來理解他們的利弊。

若是你沒有關注我，而是從技術角度對這個主題感到好奇，請查看個人 Medium 主頁，除此以外，還有許多其餘的關於微前端的資源，只需在 Medium 搜索或使用你最喜歡的搜索引擎就好。

我無法涵蓋 Twitter 中討論的全部主題，但讓咱們從頭開始，看看我是否能夠幫助添加一些 上下文（在本文中你會愈來愈多地聽到這個詞😁）微前端話題。

免責聲明

首先，我不是經過寫這篇文章來指責或攻擊任何人，甚至不是爲了在社交平臺上引戰，我尊重任何觀點，有時候我和其餘人有一樣的觀點，有時候也沒有，這種行爲帶來了創新和新想法，因此我徹底贊同它。

考慮到有些人是由丹開始的推文提到我名字的，因此我想分享個人想法，由於我真的相信咱們能夠真正討論微前端，爲每一個人提供我在每週收到的常見問題的好處。社交，我的電子郵件，演講後等等。

其餘人就上述推文與我取得了聯繫：我沒有直接回復推文，由於討論一個有趣的話題的話，像 280 個字符中的主題其實是限制性的，容易被誤解或省略一些重要的細節。

爲何是微前端而不是良好的組件模型？

組件絕對是有效的解決方案，許多公司天天都在使用它們，並取得巨大成功，但它們並非萬能的靈丹妙藥；項目，團隊，業務，更通常來講，它們的上下文必須適合，不然咱們就像試圖將一個正方形放入一個圓同樣，咱們並不老是能符合預期的。

探索新的可能性，挑戰咱們的信念和「標準的作事方式」，推進咱們的行業向前發展，鞏固現有標準或引入新標準。

讓咱們從這開始，微前端並無試圖取代組件，咱們有可能沒有適合全部項目的東西，好比組件，它就不是銀彈。

使用正確的工具來作正確的工做，這應該是咱們的目標。 請記住，開發軟件是經驗性的，而不是科學的。

我曾見過大型組織裏，有着可怕的代碼庫和一個實際成功的產品，我也看到過徹底相反的狀況，咱們不能只看到硬幣的一面。

到目前爲止，我只嘗試過大規模的微前端（大約200人 - 前端和後端工程師 - 在同一個項目上工做），結合微服務和團隊全部權，與咱們公司之前的模型相比，效果很是好。

他們能在較小的項目中工做嗎？理想狀況下能夠，但我想先嚐試一下。

在理論上，一切看起來都很好，當它進入到細節中時，你就會意識到侷限性並找到新的挑戰。若是您有任何經驗，我很樂意聽取您的意見！

關於微前端，有不一樣的風格，例如，咱們可使用 iframe 來組成最終的視圖，或者使用 Edge Side Include 或 Client Side Include，甚至使用預渲染策略，如 Open Components 或者 Interface Framework 並將結果緩存在 CDN 級別上。 另外一種方法是使用一個協調器(orchestrator)，它正在爲 SPA，單個 HTML 頁面或 SSR 應用程序提供服務，協調器能夠處於邊緣，起點或客戶端，協調器的一個例子能夠是Single-SPA。

這些方法代表咱們有兩種主要方法來肯定微前端的大小：

• 用戶界面的一部分，能夠對應一個組件，但沒必要與組件是 1對1 的映射關係
• 整個業務域，能夠對應 SPA，單個 HTML 頁面或 SSR 應用程序

它們有各自的利弊，我我的更喜歡後者，但它也不是防彈的，瞭解每種方法的侷限性，以及這些限制是否會影響最終項目結果很是重要。

微前端絕對是一種影響你所在組織的技術，它能夠提供團隊之間的隔離，避免過多的集中化，並使團隊可以採起 局部決策 。

這並不意味着這些團隊就沒法追求戰略或 API 約定達成一致意見，微前端使團隊可以採起能夠遵循的路徑，而無需與其餘團隊協調每一項技術決策，這些決策可能會影響代碼庫，但咱們容許它們快速失敗，獨立構建和部署，遵循組織定義的某些邊界（公司支持的語言，最佳實踐等）。

我我的在不一樣的組織中工做過，新的加入者會提供關於如何更改「核心庫」但一般用於政治的好的看法，由於這些改變不會當即帶來好處，這些建議在積壓的內部停留在等待狀態中。

將團隊決策權下放多是公司能夠作的最好的事情之一，由於這個團隊與產品團隊和業務專家共同生活，天天都在說同一種語言，他們處於博弈的領先地位，集中化反而輸了上下文，提供的一些約束有時候也是沒必要要的。

當公司可以在特定業務領域內提供一些技術界限時，團隊能夠以最佳方式表達本身，可能會犯一些錯誤，可是恢復速度很是快，由於要改變的工做範圍小於完整的應用程序。

理解上下文

丹在他的例子中是正確的，但他沒有考慮談話的背景，他試圖推廣一個必須適用於全部事情的解決方案，但實際狀況並不是如此。

任何決策的背景，最重要的事情，是去理解一個由我的貢獻者，團隊或組織進行的技術實現。

在過去的十年中，我看到許多項目以相似的方式，相同的架構，類似的模式編寫......可是在旅途中遇到了不一樣的結果和不一樣的挑戰，正如我以前所說，軟件開發是經驗性的，而不是科學的。

如今，咱們能夠更好地瞭解咱們可使用哪些方法成功交付項目，咱們再也不使用適合全部項目的框架或架構，咱們正在嘗試使用正確的工具來完成正確的工做。

若是一個項目應該使用高度共享的組件，項目從而成功，那就絕對沒問題，可能項目的最終結果，環境，所涉及的參與者以及爲交付項目而創建的過程使共享組件庫成爲了合適的解決方案。

與此同時，其餘情境可能須要不一樣的方法，在盒子外思考，由於傳統方法沒法提供可預測的結果。

背景是關鍵，理解業務，咱們運營的環境，咱們所瞄準的結果都與咱們的背景相關聯。

所以，擁有一個組件庫來抽象數百個（若是不是數千個）組件的功能，就像擁有多個 SPA 同樣，代碼被複制而不是包含在庫或其中的許多中。

上下文迫使咱們作出有時不是其餘人指望的決定，咱們過去已經學到了許多規則/指導，例如 DRY（不要重複本身）或 DIE（複製是邪惡的），這些是徹底適用的，但不是咱們須要尊重的教條，無論是什麼緣由。由於有時咱們有充分理由那樣作。

不要誤解個人意思，我不是在提倡複製大量代碼是一種最佳實踐，但有時候這是一種必要的惡行，它能夠更快地向前推動。

代碼重複可使咱們的團隊更加自主，由於他們不會共享因爲抽象而變得更加複雜的代碼，而且他們不依賴於外部團隊。

與往常同樣，咱們在複製代碼時須要深思熟慮，抽象代碼和複製哪一個更合理，上下文驅使咱們作出決定。

抽象一般比代碼重複更昂貴，若是你大規模地應用錯誤的抽象，咱們就會生成複雜的代碼，致使團隊成員產生挫敗感，轉而致使更糟糕的行爲，例如忽略集中式方法，轉而採用更小的「適合目標「 的方法，由團隊在其本身的代碼庫中實現的方法，其結果是對總體解決方案的控制較少。

因此，是的，讓咱們避免代碼重複，但要在你的決策中保持平衡，由於若是你在應用程序的正確部分解決這些問題，你會感到驚訝。

多個技術棧

我徹底贊成 Federico 的觀點，咱們可以選擇的想要的任何技術，它們均可能成爲災難的源泉......那若是咱們只使用最好的部分呢？

微前端並無強加不一樣的技術堆棧，事實上它們支持這種方法，並不意味着咱們須要遵循它。

就像在微服務世界中同樣，咱們在同一系統中最終不會有20種不一樣的語言，由於它們中的每一種都是執拗己見的，而且在系統內部帶來了本身的願景，維護不一樣的生態系統是很是昂貴的，而且可能會形成混亂，從而不會提供太多的好處。

可是權衡可能會有所幫助，咱們能夠從中選擇有限的語言或框架列表，那些真正起做用的部分。

猛不及防，咱們並無與一個技術棧緊密耦合，咱們能夠重構支持前一個堆棧的舊項目，以及一個緩慢但穩定地進入生產環境而不須要大爆炸版本的新項目（參考扼殺模式），咱們能夠在生產環境中使用相同的庫或框架的不一樣版本而不影響整個應用程序，咱們能夠嘗試新的框架或方法，觀測到實際的性能在運行，咱們能夠僱用最好的來自多個社區的人等等許多其餘的優點。

當咱們具備使用多個技術棧的能力時，有一些準則確實有助於從中得到巨大的好處，只有當存在混亂而不是共同的目標時，缺點或災難才成爲現實。

注意代碼包的大小

我對 Dan Shappir 很是敬重，去年我在 Fluent 會議期間參加了在聖何塞舉辦的研討會。

他提供了大量關於如何優化咱們的 Web 應用程序的好看法，絕對是性能優化的大師。

我認爲 Dan 在這裏分享的評論確實依賴於（再次強調）上下文，例如，使用微前端並在多個 SPA 中切分應用程序，只容許下載部分應用程序，從應用程序代碼庫中拆分庫，容許咱們若是用戶須要快速往返(roundtrips)，增長服務供應商文件的 CDN 上的 TTL，瀏覽器也加強了直接從磁盤提供文件的緩存策略，而不是執行屢次往返。

最後，服務端的 workers 能夠經過針對依賴關係的緩存策略來緩解此問題，若是它對用例是明智的。

如今，沒法避免的是，若是咱們將依賴關係打包得很糟糕，這會影響加載時間，但它不會影響微前端，它會影響 SPA。

可能與微前端同樣，你也能夠共享依賴關係（看看Single-SPA）或者你說不的話，在後一種狀況下，取決於你的應用程序使用方式，例如，若是咱們能瞭解用戶在咱們的應用程序中的行爲，咱們能夠將應用程序「切片」到咱們的用戶正在消費微前端內部的「旅程」，並在另外一個內部開始新的旅程。

咱們能夠發現的是，咱們的用戶來到咱們的平臺執行一次旅程，在這種狀況下，他們將只下載微前端中所需的依賴項和代碼，而不是整個應用程序中使用的全部依賴項。

同理，用戶能夠在咱們的應用程序中隨機導航，這樣的話他將屢次下載一些依賴項，但在這種狀況下，這取決於團隊如何減輕他的旅程並改善性能以提供更好的體驗。

帕累托法則 (80/20 規則) ：「......對於許多事件，大約 80％ 的影響來自 20％ 的緣由」。

使用微前端的 API 管理多是具備挑戰性的，但不比與其餘架構協同工做重要，在咱們的案例中，咱們正在從服務字典中移動，咱們列出了全部可用的 API 到專用於每一個微前端的列表，它須要一點點更多的工做，但它優化了服務器和客戶端之間共享的有效負載，只顯示對該微前端感興趣的 API。 顯然，並不老是可讓 API 只與一個微前端相關，在這種狀況下，咱們須要在團隊之間擁有外部依賴關係和溝通，但與平常工做相比，它很是有限。

我想在此強調的是，微前端並不完美，但良好的實踐組合可使咱們的項目以高標準交付：正確的工做，正確的工具，還記得嗎？

總結

我真的相信，正確的工做使用正確的工具是必不可少的，總體，微服務，組件，庫，微前端是表達本身的工具和技術，咱們的意圖只是「解決方案」的一方面（技術側），另外一方面顯然是使用這些技術和工具產生的業務影響。

微前端能夠真正幫助組織更快地行動，在業務領域內進行創新並隔離故障，同時我不反對任何形式或形狀的總體應用程序，我不（徹底）反對集中化，儘管我常常看到任何類型的庫都過於優化而沒有真正關注業務的發展方向，但卻增長了必定程度的無心義抽象，從而下降了開發人員的工做效率，而不是加速它。

因爲團隊不能過多地影響另外一個團隊的工做，所以集中化一般會致使團隊失望，由於外部依賴很難解決。

我知道有一些方法能夠經過內部開源緩解這個問題，我也不能提供太多關於這種方法的看法，可是從我瞭解到的幾個談話和我有的聊天，對於在公司中使用內部採購的一些工程師而言，若是你有不一樣代碼庫的共同責任，這絕對是一個很好的方法，若是你有這方面的經驗，請隨時評論這篇文章。

採起平衡決策是成功的祕訣。

最後，請記住 背景是理解決策的關鍵。 建築師常常編寫ADR（架構決策記錄）。這些文件正在幫助公司中的任意員工理解爲何作出描述上下文，可用選項，所選擇的選項以及最終由此決定產生的後果的決策。

我常常看到人們判斷其餘公司或同事的決定，而不理解作出決定的背景，實際上，背景對決策自己更爲重要，由於儘管它聽起來很可怕或徹底不合適，但實際上可能有是該特定背景的最佳（或惟一）選項。

像往常同樣，我願意討論，我相信人們會不一樣意這篇文章中分享的一些觀點，但這就是分享咱們的經驗和信念的所有意義！ 🤓