来源：Alibaba F2E公众号
作者：有知
去年看到社区里一些关于微前端的讨论时，就想写篇文章梳理一下自己的观点，后来因为种种原因搁置了（主要是懒）。今天在微信群中看到又有不少人谈起微前端，虽遗憾错过了讨论，但也勾起了自己的表达欲。所以这里整理了一些文字，记录下自己的观点。
先说两个观点。
1. 微前端是「康威定律」在前端架构上的映射
设计系统的架构受制于产生这些设计的组织的沟通结构。 — M.Conway
康威定律几乎就是微前端（准确来说是微服务架构）的理论基础了。它指出了组织架构越庞大，其系统间沟通成本越高的问题。而解决这一问题的有效手段就是，将大的系统拆分成一个个微小的，可以独立自治的子系统。一旦系统的依赖限制在了内部，功能上更加内聚，对外部的依赖变少，那么就能显著的减少跨系统之间的沟通成本了。
简单来说，康威定律的指导思想就是：既然沟通是大问题，那么就不要沟通就好了[doge.jpg]。
所以本质上，微前端(微服务架构)关注的是如何解决组织和团队间协作带来的工程问题，而不是单纯的某个技术问题。
群里飞叔只说对了一半，实际上当时我是有各个前端应用的主控权的。但主要问题出在这些系统都是 4年+、代码 20W行+ 的长尾应用，而产品还在持续的集成迭代，我既没精力去给他们做技术栈升级，也没动力(兴趣)去跟一个个前应用 owner 沟通了解一些技术细节。
这可间接的引出我的第二个观点。
2. 微前端的假设是，所有大型系统都逃不过熵增定律
这个假设指的是，所有大型系统都将从有序变为无序，他们背后的 codebase 的归宿都将是「屎山」。
如果不是，那一定是因为这个系统使用的技术栈更新的不够快，参与系统开发的工程师不够多，产品迭代的时间不够长。
在潜意识里，微前端的采纳者就不相信一个系统会永远健康的迭代下去。因为熵增永远是自然且轻松的，而对抗熵增，则必须有足够的外力介入、足够的成本投入才行。
这也是为什么，qiankun 的很大一批用户，都是因为要在一批长尾应用上迭代新功能，最后实在搞不动，才会尝试用微前端的方案来解决了。
基于此，微前端很多时候是「悲观主义工程师」在工程上的妥协，是一种防御性，有时候甚至是「掩耳盗铃」式的架构策略。
当然在理想状态下，对于一个有追求的工程师而言，所有的技术问题都应该是被正面修复、正确治理的，而不是起手就来一个 workaround。但同时所有的软件工程原则也都会告诉我们，不遗余力、不计成本的去优化、解决一个技术问题是不可取的，尤其是在这个问题的投入产出比不高的情况下。
微前端倡导的不是消极的、投降主义的去回避系统中的历史遗留问题，而是告诉我们，很多时候我们可以通过分而治之的手段，让「上帝的归上帝，凯撒的归凯撒」。
满足以下几点，你可能就不需要微前端
基于以上两个观点，我们可以概括出，存在以下场景时，你可能就不需要微前端：
- 你/你的团队 具备系统内所有架构组件的话语权
简单来说就是，系统里的所有组件都是由一个小的团队开发的。
- 你/你的团队 有足够动力去治理、改造这个系统中的所有组件
直接改造存量系统的收益大于新老系统混杂带来的问题。
- 系统及组织架构上，各部件之间本身就是强耦合、自洽、不可分离的
系统本身就是一个最小单元的「架构量子」，拆分的成本高于治理的成本。
极高的产品体验要求，对任何产品交互上的不一致零容忍
不允许交互上不一致的情况出现，这基本上从产品上否决了渐进式升级的技术策略
满足以下几点，你才确实可能需要微前端
1.系统本身是需要集成和被集成的 一般有两种情况：
- 旧的系统不能下，新的需求还在来。没有一家商业公司会同意工程师以单纯的技术升级的理由，直接下线一个有着一定用户的存量系统的。而你大概又不能简单通过 iframe 这种「靠谱的」手段完成新功能的接入，因为产品说需要「弹个框弹到中间」
- 你的系统需要有一套支持动态插拔的机制。这个机制可以是一套精心设计的插件体系，但一旦出现接入应用或被接入应用年代够久远、改造成本过高的场景，可能后面还是会过渡到各种微前端的玩法。
2.系统中的部件具备足够清晰的服务边界
通过微前端手段划分服务边界，将复杂度隔离在不同的系统单元中，从而避免因熵增速度不一致带来的代码腐化的传染，以及研发节奏差异带来的工程协同上的问题。
还是那个老生常谈的理念，没有银弹，架构本身就是各种 trade–off。
大部分时候，一个「流行」的东西，你都无法阻止不需要它的人去使用它。
