來源：Alibaba F2E公衆号
作者：有知
去年看到社群裡一些關于微前端的讨論時，就想寫篇文章梳理一下自己的觀點，後來因為種種原因擱置了（主要是懶）。今天在微信群中看到又有不少人談起微前端，雖遺憾錯過了讨論，但也勾起了自己的表達欲。是以這裡整理了一些文字，記錄下自己的觀點。
先說兩個觀點。
1. 微前端是「康威定律」在前端架構上的映射
設計系統的架構受制于産生這些設計的組織的溝通結構。 — M.Conway
康威定律幾乎就是微前端（準确來說是微服務架構）的理論基礎了。它指出了組織架構越龐大，其系統間溝通成本越高的問題。而解決這一問題的有效手段就是，将大的系統拆分成一個個微小的，可以獨立自治的子系統。一旦系統的依賴限制在了内部，功能上更加内聚，對外部的依賴變少，那麼就能顯著的減少跨系統之間的溝通成本了。
簡單來說，康威定律的指導思想就是：既然溝通是大問題，那麼就不要溝通就好了[doge.jpg]。
是以本質上，微前端(微服務架構)關注的是如何解決組織和團隊間協作帶來的工程問題，而不是單純的某個技術問題。
群裡飛叔隻說對了一半，實際上當時我是有各個前端應用的主要權的。但主要問題出在這些系統都是 4年+、代碼 20W行+ 的長尾應用，而産品還在持續的內建疊代，我既沒精力去給他們做技術棧更新，也沒動力(興趣)去跟一個個前應用 owner 溝通了解一些技術細節。
這可間接的引出我的第二個觀點。
2. 微前端的假設是，所有大型系統都逃不過熵增定律
這個假設指的是，所有大型系統都将從有序變為無序，他們背後的 codebase 的歸宿都将是「屎山」。
如果不是，那一定是因為這個系統使用的技術棧更新的不夠快，參與系統開發的工程師不夠多，産品疊代的時間不夠長。
在潛意識裡，微前端的采納者就不相信一個系統會永遠健康的疊代下去。因為熵增永遠是自然且輕松的，而對抗熵增，則必須有足夠的外力介入、足夠的成本投入才行。
這也是為什麼，qiankun 的很大一批使用者，都是因為要在一批長尾應用上疊代新功能，最後實在搞不動，才會嘗試用微前端的方案來解決了。
基于此，微前端很多時候是「悲觀主義工程師」在工程上的妥協，是一種防禦性，有時候甚至是「掩耳盜鈴」式的架構政策。
當然在理想狀态下，對于一個有追求的工程師而言，所有的技術問題都應該是被正面修複、正确治理的，而不是起手就來一個 workaround。但同時所有的軟體工程原則也都會告訴我們，不遺餘力、不計成本的去優化、解決一個技術問題是不可取的，尤其是在這個問題的投入産出比不高的情況下。
微前端倡導的不是消極的、投降主義的去回避系統中的曆史遺留問題，而是告訴我們，很多時候我們可以通過分而治之的手段，讓「上帝的歸上帝，凱撒的歸凱撒」。
滿足以下幾點，你可能就不需要微前端
基于以上兩個觀點，我們可以概括出，存在以下場景時，你可能就不需要微前端：
- 你/你的團隊 具備系統内所有架構元件的話語權
簡單來說就是，系統裡的所有元件都是由一個小的團隊開發的。
- 你/你的團隊 有足夠動力去治理、改造這個系統中的所有元件
直接改造存量系統的收益大于新老系統混雜帶來的問題。
- 系統及組織架構上，各部件之間本身就是強耦合、自洽、不可分離的
系統本身就是一個最小單元的「架構量子」，拆分的成本高于治理的成本。
極高的産品體驗要求，對任何産品互動上的不一緻零容忍
不允許互動上不一緻的情況出現，這基本上從産品上否決了漸進式更新的技術政策
滿足以下幾點，你才确實可能需要微前端
1.系統本身是需要內建和被內建的 一般有兩種情況：
- 舊的系統不能下，新的需求還在來。沒有一家商業公司會同意工程師以單純的技術更新的理由，直接下線一個有着一定使用者的存量系統的。而你大概又不能簡單通過 iframe 這種「靠譜的」手段完成新功能的接入，因為産品說需要「彈個框彈到中間」
- 你的系統需要有一套支援動态插拔的機制。這個機制可以是一套精心設計的插件體系，但一旦出現接入應用或被接入應用年代夠久遠、改造成本過高的場景，可能後面還是會過渡到各種微前端的玩法。
2.系統中的部件具備足夠清晰的服務邊界
通過微前端手段劃分服務邊界，将複雜度隔離在不同的系統單元中，進而避免因熵增速度不一緻帶來的代碼腐化的傳染，以及研發節奏差異帶來的工程協同上的問題。
還是那個老生常談的理念，沒有銀彈，架構本身就是各種 trade–off。
大部分時候，一個「流行」的東西，你都無法阻止不需要它的人去使用它。