去年看到社區(qū)里一些關(guān)于微前端的討論時，就想寫篇文章梳理一下自己的觀點，后來因為種種原因擱置了（主要是懶）。今天在微信群中看到又有不少人談起微前端，雖遺憾錯過了討論，但也勾起了自己的表達欲。所以這里整理了一些文字，記錄下自己的觀點。

作者：kuitos 

微前端框架 qiankun 作者

https://zhuanlan.zhihu.com/p/391248835

大廠技術(shù)  高級前端  Node進階

點擊上方 程序員成長指北，關(guān)注公眾號

回復(fù)1，加入高級Node交流群

先說兩個觀點。

1. 微前端是「康威定律」在前端架構(gòu)上的映射

設(shè)計系統(tǒng)的架構(gòu)受制于產(chǎn)生這些設(shè)計的組織的溝通結(jié)構(gòu)。— M.Conway

康威定律^[1]幾乎就是微前端（準確來說是微服務(wù)架構(gòu)）的理論基礎(chǔ)了。它指出了組織架構(gòu)越龐大，其系統(tǒng)間溝通成本越高的問題。而解決這一問題的有效手段就是，將大的系統(tǒng)拆分成一個個微小的，可以獨立自治的子系統(tǒng)。一旦系統(tǒng)的依賴限制在了內(nèi)部，功能上更加內(nèi)聚，對外部的依賴變少，那么就能顯著的減少跨系統(tǒng)之間的溝通成本了。

簡單來說，康威定律的指導(dǎo)思想就是：既然溝通是大問題，那么就不要溝通就好了[doge.jpg]。

所以本質(zhì)上，微前端(微服務(wù)架構(gòu))關(guān)注的是如何解決組織和團隊間協(xié)作帶來的工程問題，而不是單純的某個技術(shù)問題。

群里飛叔@徐飛^[2]只說對了一半，實際上當時我是有各個前端應(yīng)用的主控權(quán)的。但主要問題出在這些系統(tǒng)都是 4年+、代碼 20W行+ 的長尾應(yīng)用，而產(chǎn)品還在持續(xù)的集成迭代，我既沒精力去給他們做技術(shù)棧升級，也沒動力(興趣)去跟一個個前應(yīng)用 owner 溝通了解一些技術(shù)細節(jié)。

這可間接的引出我的第二個觀點。

2. 微前端的假設(shè)是，所有大型系統(tǒng)都逃不過熵增定律

這個假設(shè)指的是，所有大型系統(tǒng)都將從有序變?yōu)闊o序，他們背后的 codebase 的歸宿都將是「屎山」。

如果不是，那一定是因為這個系統(tǒng)使用的技術(shù)棧更新的不夠快，參與系統(tǒng)開發(fā)的工程師不夠多，產(chǎn)品迭代的時間不夠長。

在潛意識里，微前端的采納者就不相信一個系統(tǒng)會永遠健康的迭代下去。因為熵增永遠是自然且輕松的，而對抗熵增，則必須有足夠的外力介入、足夠的成本投入才行。

這也是為什么，qiankun 的很大一批用戶，都是因為要在一批長尾應(yīng)用上迭代新功能，最后實在搞不動，才會嘗試用微前端的方案來解決了。

基于此，微前端很多時候是「悲觀主義工程師」在工程上的妥協(xié)，是一種防御性，有時候甚至是「掩耳盜鈴」式的架構(gòu)策略。

當然在理想狀態(tài)下，對于一個有追求的工程師而言，所有的技術(shù)問題都應(yīng)該是被正面修復(fù)、正確治理的，而不是起手就來一個 workaround。但同時所有的軟件工程原則也都會告訴我們，不遺余力、不計成本的去優(yōu)化、解決一個技術(shù)問題是不可取的，尤其是在這個問題的投入產(chǎn)出比不高的情況下。

微前端倡導(dǎo)的不是消極的、投降主義的去回避系統(tǒng)中的歷史遺留問題，而是告訴我們，很多時候我們可以通過分而治之的手段，讓「上帝的歸上帝，凱撒的歸凱撒」。

滿足以下幾點，你可能就不需要微前端

基于以上兩個觀點，我們可以概括出，存在以下場景時，你可能就不需要微前端：

1. 你/你的團隊 具備系統(tǒng)內(nèi)所有架構(gòu)組件的話語權(quán)
   簡單來說就是，系統(tǒng)里的所有組件都是由一個小的團隊開發(fā)的。
2. 你/你的團隊 有足夠動力去治理、改造這個系統(tǒng)中的所有組件
   直接改造存量系統(tǒng)的收益大于新老系統(tǒng)混雜帶來的問題。
3. 系統(tǒng)及組織架構(gòu)上，各部件之間本身就是強耦合、自洽、不可分離的
   系統(tǒng)本身就是一個最小單元的「架構(gòu)量子」，拆分的成本高于治理的成本。
4. 極高的產(chǎn)品體驗要求，對任何產(chǎn)品交互上的不一致零容忍
   不允許交互上不一致的情況出現(xiàn)，這基本上從產(chǎn)品上否決了漸進式升級的技術(shù)策略

滿足以下幾點，你才確實可能需要微前端

1. 系統(tǒng)本身是需要集成和被集成的 一般有兩種情況：

2. 舊的系統(tǒng)不能下，新的需求還在來。
   沒有一家商業(yè)公司會同意工程師以單純的技術(shù)升級的理由，直接下線一個有著一定用戶的存量系統(tǒng)的。而你大概又不能簡單通過 iframe 這種「靠譜的」手段完成新功能的接入，因為產(chǎn)品說需要「彈個框彈到中間」

3. 你的系統(tǒng)需要有一套支持動態(tài)插拔的機制。
   這個機制可以是一套精心設(shè)計的插件體系，但一旦出現(xiàn)接入應(yīng)用或被接入應(yīng)用年代夠久遠、改造成本過高的場景，可能后面還是會過渡到各種微前端的玩法。

4. 系統(tǒng)中的部件具備足夠清晰的服務(wù)邊界
   通過微前端手段劃分服務(wù)邊界，將復(fù)雜度隔離在不同的系統(tǒng)單元中，從而避免因熵增速度不一致帶來的代碼腐化的傳染，以及研發(fā)節(jié)奏差異帶來的工程協(xié)同上的問題。

還是那個老生常談的理念，沒有銀彈，架構(gòu)本身就是各種 trade–off。

大部分時候，一個「流行」的東西，你都無法阻止不需要它的人去使用它。

參考資料