你可能并不需要微前端
這個(gè)圖特別形象
經(jīng)作者 kuitos 授權(quán)，本文轉(zhuǎn)自 https://zhuanlan.zhihu.com/p/391248835
去年看到社區(qū)里一些關(guān)于微前端的討論時(shí)，就想寫篇文章梳理一下自己的觀點(diǎn)，后來因?yàn)榉N種原因擱置了（主要是懶）。今天在微信群中看到又有不少人談起微前端，雖遺憾錯(cuò)過了討論，但也勾起了自己的表達(dá)欲。所以這里整理了一些文字，記錄下自己的觀點(diǎn)。
先說兩個(gè)觀點(diǎn)。
1. 微前端是「康威定律」在前端架構(gòu)上的映射
設(shè)計(jì)系統(tǒng)的架構(gòu)受制于產(chǎn)生這些設(shè)計(jì)的組織的溝通結(jié)構(gòu)。— M.Conway
康威定律幾乎就是微前端（準(zhǔn)確來說是微服務(wù)架構(gòu)）的理論基礎(chǔ)了。它指出了組織架構(gòu)越龐大，其系統(tǒng)間溝通成本越高的問題。而解決這一問題的有效手段就是，將大的系統(tǒng)拆分成一個(gè)個(gè)微小的，可以獨(dú)立自治的子系統(tǒng)。一旦系統(tǒng)的依賴限制在了內(nèi)部，功能上更加內(nèi)聚，對(duì)外部的依賴變少，那么就能顯著的減少跨系統(tǒng)之間的溝通成本了。
簡(jiǎn)單來說，康威定律的指導(dǎo)思想就是：既然溝通是大問題，那么就不要溝通就好了[doge.jpg]。
所以本質(zhì)上，微前端(微服務(wù)架構(gòu))關(guān)注的是如何解決組織和團(tuán)隊(duì)間協(xié)作帶來的工程問題，而不是單純的某個(gè)技術(shù)問題。
群里飛叔 @徐飛 只說對(duì)了一半，實(shí)際上當(dāng)時(shí)我是有各個(gè)前端應(yīng)用的主控權(quán)的。但主要問題出在這些系統(tǒng)都是 4年+、代碼 20W行+ 的長(zhǎng)尾應(yīng)用，而產(chǎn)品還在持續(xù)的集成迭代，我既沒精力去給他們做技術(shù)棧升級(jí)，也沒動(dòng)力(興趣)去跟一個(gè)個(gè)前應(yīng)用 owner 溝通了解一些技術(shù)細(xì)節(jié)。
這可間接的引出我的第二個(gè)觀點(diǎn)。
2. 微前端的假設(shè)是，所有大型系統(tǒng)都逃不過熵增定律
這個(gè)假設(shè)指的是，所有大型系統(tǒng)都將從有序變?yōu)闊o(wú)序，他們背后的 codebase 的歸宿都將是「屎山」。
如果不是，那一定是因?yàn)檫@個(gè)系統(tǒng)使用的技術(shù)棧更新的不夠快，參與系統(tǒng)開發(fā)的工程師不夠多，產(chǎn)品迭代的時(shí)間不夠長(zhǎng)。
在潛意識(shí)里，微前端的采納者就不相信一個(gè)系統(tǒng)會(huì)永遠(yuǎn)健康的迭代下去。因?yàn)殪卦鲇肋h(yuǎn)是自然且輕松的，而對(duì)抗熵增，則必須有足夠的外力介入、足夠的成本投入才行。
這也是為什么，qiankun 的很大一批用戶，都是因?yàn)橐谝慌L(zhǎng)尾應(yīng)用上迭代新功能，最后實(shí)在搞不動(dòng)，才會(huì)嘗試用微前端的方案來解決了。
基于此，微前端很多時(shí)候是「悲觀主義工程師」在工程上的妥協(xié)，是一種防御性，有時(shí)候甚至是「掩耳盜鈴」式的架構(gòu)策略。
當(dāng)然在理想狀態(tài)下，對(duì)于一個(gè)有追求的工程師而言，所有的技術(shù)問題都應(yīng)該是被正面修復(fù)、正確治理的，而不是起手就來一個(gè) workaround。但同時(shí)所有的軟件工程原則也都會(huì)告訴我們，不遺余力、不計(jì)成本的去優(yōu)化、解決一個(gè)技術(shù)問題是不可取的，尤其是在這個(gè)問題的投入產(chǎn)出比不高的情況下。
微前端倡導(dǎo)的不是消極的、投降主義的去回避系統(tǒng)中的歷史遺留問題，而是告訴我們，很多時(shí)候我們可以通過分而治之的手段，讓「上帝的歸上帝，凱撒的歸凱撒」。
滿足以下幾點(diǎn)，你可能就不需要微前端
基于以上兩個(gè)觀點(diǎn)，我們可以概括出，存在以下場(chǎng)景時(shí)，你可能就不需要微前端：
你/你的團(tuán)隊(duì) 具備系統(tǒng)內(nèi)所有架構(gòu)組件的話語(yǔ)權(quán) 簡(jiǎn)單來說就是，系統(tǒng)里的所有組件都是由一個(gè)小的團(tuán)隊(duì)開發(fā)的。
你/你的團(tuán)隊(duì) 有足夠動(dòng)力去治理、改造這個(gè)系統(tǒng)中的所有組件 直接改造存量系統(tǒng)的收益大于新老系統(tǒng)混雜帶來的問題。
系統(tǒng)及組織架構(gòu)上，各部件之間本身就是強(qiáng)耦合、自洽、不可分離的 系統(tǒng)本身就是一個(gè)最小單元的「架構(gòu)量子」，拆分的成本高于治理的成本。
極高的產(chǎn)品體驗(yàn)要求，對(duì)任何產(chǎn)品交互上的不一致零容忍 不允許交互上不一致的情況出現(xiàn)，這基本上從產(chǎn)品上否決了漸進(jìn)式升級(jí)的技術(shù)策略
滿足以下幾點(diǎn)，你才確實(shí)可能需要微前端
系統(tǒng)本身是需要集成和被集成的 一般有兩種情況：
舊的系統(tǒng)不能下，新的需求還在來。 沒有一家商業(yè)公司會(huì)同意工程師以單純的技術(shù)升級(jí)的理由，直接下線一個(gè)有著一定用戶的存量系統(tǒng)的。而你大概又不能簡(jiǎn)單通過 iframe 這種「靠譜的」手段完成新功能的接入，因?yàn)楫a(chǎn)品說需要「彈個(gè)框彈到中間」
你的系統(tǒng)需要有一套支持動(dòng)態(tài)插拔的機(jī)制。 這個(gè)機(jī)制可以是一套精心設(shè)計(jì)的插件體系，但一旦出現(xiàn)接入應(yīng)用或被接入應(yīng)用年代夠久遠(yuǎn)、改造成本過高的場(chǎng)景，可能后面還是會(huì)過渡到各種微前端的玩法。
系統(tǒng)中的部件具備足夠清晰的服務(wù)邊界 通過微前端手段劃分服務(wù)邊界，將復(fù)雜度隔離在不同的系統(tǒng)單元中，從而避免因熵增速度不一致帶來的代碼腐化的傳染，以及研發(fā)節(jié)奏差異帶來的工程協(xié)同上的問題。
還是那個(gè)老生常談的理念，沒有銀彈，架構(gòu)本身就是各種 trade–off。
大部分時(shí)候，一個(gè)「流行」的東西，你都無(wú)法阻止不需要它的人去使用它。