你可能并不需要微前端-技术圈

这个图特别形象

经作者 kuitos 授权，本文转自 https://zhuanlan.zhihu.com/p/391248835

去年看到社区里一些关于微前端的讨论时，就想写篇文章梳理一下自己的观点，后来因为种种原因搁置了（主要是懒）。今天在微信群中看到又有不少人谈起微前端，虽遗憾错过了讨论，但也勾起了自己的表达欲。所以这里整理了一些文字，记录下自己的观点。

先说两个观点。

1. 微前端是「康威定律」在前端架构上的映射

设计系统的架构受制于产生这些设计的组织的沟通结构。— M.Conway

康威定律几乎就是微前端（准确来说是微服务架构）的理论基础了。它指出了组织架构越庞大，其系统间沟通成本越高的问题。而解决这一问题的有效手段就是，将大的系统拆分成一个个微小的，可以独立自治的子系统。一旦系统的依赖限制在了内部，功能上更加内聚，对外部的依赖变少，那么就能显著的减少跨系统之间的沟通成本了。

简单来说，康威定律的指导思想就是：既然沟通是大问题，那么就不要沟通就好了[doge.jpg]。

所以本质上，微前端(微服务架构)关注的是如何解决组织和团队间协作带来的工程问题，而不是单纯的某个技术问题。

群里飞叔 @徐飞只说对了一半，实际上当时我是有各个前端应用的主控权的。但主要问题出在这些系统都是 4年+、代码 20W行+ 的长尾应用，而产品还在持续的集成迭代，我既没精力去给他们做技术栈升级，也没动力(兴趣)去跟一个个前应用 owner 沟通了解一些技术细节。

这可间接的引出我的第二个观点。

这个假设指的是，所有大型系统都将从有序变为无序，他们背后的 codebase 的归宿都将是「屎山」。

如果不是，那一定是因为这个系统使用的技术栈更新的不够快，参与系统开发的工程师不够多，产品迭代的时间不够长。

在潜意识里，微前端的采纳者就不相信一个系统会永远健康的迭代下去。因为熵增永远是自然且轻松的，而对抗熵增，则必须有足够的外力介入、足够的成本投入才行。

这也是为什么，qiankun 的很大一批用户，都是因为要在一批长尾应用上迭代新功能，最后实在搞不动，才会尝试用微前端的方案来解决了。

基于此，微前端很多时候是「悲观主义工程师」在工程上的妥协，是一种防御性，有时候甚至是「掩耳盗铃」式的架构策略。

当然在理想状态下，对于一个有追求的工程师而言，所有的技术问题都应该是被正面修复、正确治理的，而不是起手就来一个 workaround。但同时所有的软件工程原则也都会告诉我们，不遗余力、不计成本的去优化、解决一个技术问题是不可取的，尤其是在这个问题的投入产出比不高的情况下。

微前端倡导的不是消极的、投降主义的去回避系统中的历史遗留问题，而是告诉我们，很多时候我们可以通过分而治之的手段，让「上帝的归上帝，凯撒的归凯撒」。

基于以上两个观点，我们可以概括出，存在以下场景时，你可能就不需要微前端：

系统本身是需要集成和被集成的一般有两种情况：
旧的系统不能下，新的需求还在来。没有一家商业公司会同意工程师以单纯的技术升级的理由，直接下线一个有着一定用户的存量系统的。而你大概又不能简单通过 iframe 这种「靠谱的」手段完成新功能的接入，因为产品说需要「弹个框弹到中间」
你的系统需要有一套支持动态插拔的机制。这个机制可以是一套精心设计的插件体系，但一旦出现接入应用或被接入应用年代够久远、改造成本过高的场景，可能后面还是会过渡到各种微前端的玩法。
系统中的部件具备足够清晰的服务边界通过微前端手段划分服务边界，将复杂度隔离在不同的系统单元中，从而避免因熵增速度不一致带来的代码腐化的传染，以及研发节奏差异带来的工程协同上的问题。

还是那个老生常谈的理念，没有银弹，架构本身就是各种 trade–off。

大部分时候，一个「流行」的东西，你都无法阻止不需要它的人去使用它。