前言
世界上本没有痛，刺挠的人多了，痒也挠成了痛
------ 鲁迅
今天挑战一个有点争议的话题，微前端到底是真能解决行业痛点还是只是无病呻吟KPI产物？？
本文并非讲解社区对于微前端框架的技术实现，而是将以较流行的阿里的qiankun（乾坤）框架为例，讨论微前端概念的由来、实际的价值和存在的意义。
本文主要文字论述，尝试分析微前端发展的底层逻辑。
注：本文内容带有大量主观偏见，旨在更深入讨论，并无恶意，切勿人身攻击！！
什么是微前端
微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。
微前端是一种架构理念
就是将一个复杂的大应用拆分成多个子应用，降低应用间的耦合，子应用可以由不同团队，独立开发、独立交付、独立部署、独立运行，并且我们可以将这些独立的子应用组合到主应用中，保持一个应用的使用体验
以乾坤框架为例，设计上推崇以下核心价值：
- 技术栈无关
- 独立开发、独立部署
- 增量升级
- 独立运行时
为什么需要微前端
要想了解微前端真正的价值，我们必须清楚到底为什么需要它。虽然很多文章有陈列它的诸多优点，但其核心诉求还是为了提供让新老项目更容易兼容的一种方式，让我们可以没有包袱的使用最新的技术，开发独立的模块，嵌入到原有系统中，来达到让系统摆脱技术栈的束缚，渐进式的迭代升级。
一个新技术的出现，要么是为了创造价值，要么是为了解决难点，微前端毫无疑问属于后者。
在乾坤 框架的官网也给出了具体的解释，这基本代表了业内公认的对于微前端要解决的核心痛点。
微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用(Frontend Monolith)后，随之而来的应用不可维护的问题。这类问题在企业级 Web 应用中尤其常见。
什么是巨石应用
对于巨石应用很多人应该都会很有共鸣，毕竟大C端项目不常有，但企业内部各种中后台web应用比比皆是，每个前端都曾开发过，这种架构简单、功能单一、重要性低、使用频率也不高，但是就有一点，能活。人走它还在，bug传三代。
漫长的生命周期，让一个小微应用滚成了巨石应用，从微不足道到出现让厉害的工程师们都会头疼的各种难题：
- 代码量庞大，业务模块复杂
- 引用混乱，代码耦合
- 技术过时，维护成本高
- 技术栈升级成本巨大，ROI低风险高
- 技术债、线上遗留bug、架构问题积重难返
- 开发体验差
- 构建部署慢
多数情况下，由于ROI太低，工程师很难选择彻底重构代码，而只能不停打补丁在祖传代码上继续耕耘，所以当微前端 概念出现时，引起了非常广泛的共鸣，如果它能解决这个问题，那它将是成为众多在屎山勤恳耕耘的工程师的 "救世主"。
那它真的能解决这个痛点吗？要想得到答案首先要关注的不是乾坤的文档里的各种功能实现，而是先思考：
-
到底是什么让一个小微应用变成了巨石应用？
-
能不能避免巨石应用的出现？
熵增定律
在阿里乾坤团队中关于微前端的这篇文章： 《你可能并不需要微前端》 ，其中有一点分析的很透彻，它提到随着时间的推移，所有系统都逃不过熵增定律，并且他倡导不要"消极"的回避，而是主动的"治理"。
所谓熵增定律简单说就是万事万物随着时间的无限拉长，终将从有序变成无序，在一个封闭系统里，没有外力做功，其混乱度（熵）会不断增大。
这里有2个关键词：
- 封闭系统：我们开发的系统就是封闭系统，只受代码影响
- 无外力做功：可以理解系统正常的需求迭代，功能更替。而我们在原有的系统上不断的修缮，矫正，封装，重构就是外力。
所以如果没有这些外力做功，那我们系统无论最初设计的多么精妙，最终都会变成垃圾，事实上即使加以外力，也仅仅只会延缓这一过程。
为什么要专门来讲下熵增定律呢，因为对于小微应用如何变成巨石应用的原因，我个人无法总结，它什么时候形成，为何而形成，这个原因由于业务场景的不同而太过于复杂，可能是：
- 技术架构不够完善
- 开发规范够不明确
- 项目技术过时淘汰
- 开发方式的变革更新
- 产品迭代方向与预期不符
- 开发人员水平参差不齐
- 团队成员更替
- 线上积累bug未解决
- 等等等等。。。。。
但无论因为什么，面对这些代码，最终摆在工程师面前的难题都是：难以维护。
人都善变的，因为时间让我们变的复杂。而代码变的难以维护，也往往不是某一个问题导致，而是因为它经历了各种时期各种复杂的问题总和后的结果。那为什么会有这么多无法预测、没有解决的问题呢？
终极答案就是：时间太长。
那我要灵魂拷问：谁可以对抗时间？靠一个技术框架，行吗？
以前我们用原生，后来用vue和react构建，现在再加入一个乾坤，你要知道无论是react还是乾坤这些都将是你技术架构中的一部分，我们的技术架构是基于当前的时间节点，根据过去的历史经验总结而成的，试想，你能用现在的经验去对抗未来未知的变化吗？我觉得这是痴人说梦。
那为什么很多人觉得，这个乾坤用了后，就是解决了目前巨石应用带来的各种问题，没错但是它只能解决过去已发生的问题，它存在巨大的时间局限性，人也一样，我们只能基于当前的认知去思考未来。
我们只能基于现有的前端开发模式、框架、工具链、npm、webpack、语言特性、浏览器特性去设计技术架构，那么未来随着时间推移，当其中某个技术有重大升级的时候，那乾坤也将成为屎山代码中的一部分，没什么特殊的。毕竟工程化才出现几年，以前用jq开发设计出来的各种最佳实践，现在不也都弃之如敝了么。
不只是是乾坤，其实整个微前端的概念本身很大一部分都是伪需求，为了解决现有技术架构时间延续问题，引入了新的技术架构，而新的技术架构也难逃时间的侵蚀，那引入它到底有什么意义呢？
这其中存在一个悖论：你需要设计一个完美的系统来对抗熵增，而世界上不存在完美的系统。
世界上不存在完美的系统
世界上没有完美的系统，在时间面前，任何精美的设计都会变的漏洞百出，所以我们需要对该系统不停的加以外力，不停的修缮、矫正、补充以延续它的生命，但即使如此它也终会走到生命的尽头，到那时，我们只能推到重来，新技术加上新的最佳实践再诞生一个崭新的有活力的产品。
但好在，大部分系统生存周期都远不会这么漫长，在此之前就早早下线了。
这是自然发展的规律，而我们要找寻一个成本很低的方法，去对抗一个时间带来的巨大的不确定的熵增，这本身就是太过理想化的行为，它并不以人的意志为转移，在此面前无论你是所谓"消极的，投降主义"，还是积极的抵抗，我认为对现实结果都不会有太大改变（我希望你能理解我表达的是那些真正的我们无法预知和控制的"变数"，而不是可预测或已存在的具体问题，而造成巨石应用的根本原因往往是那些无法预知的变数）。
彻底解决它唯一的办法就是：付出同等的代价 ；而放在巨石应用中这个代价就是：重构。
否则即使你引入一个微前端框架，解决了目前的问题，再过五年十年它仍然会再次成为一个巨石应用。
本节我想说的是：微前端无法解决最根本的痛点，它的底层逻辑是不通的
微前端框架的实际价值
微前端的框架既然无法解决漫长生命周期为之带来的巨石应用问题，那他的地位将急剧下降，从最初备受吹捧的行业最佳实践，变成一个充满局限性的某些业务场景下的某些具体问题的解决方案。
这才是它应有的地位，我甚至觉得其实都没必要写一个类似乾坤的具体框架出来，原因有：
- 这个问题的解决方案肯定会带有浓厚的业务特点，很难将功能抽象出来，抽象出来也很难复用。
- 这其实并不是成本很高的事，设计一个简单的兼容方案就能解决大多数业务问题。
- 并不是很需要那么多复杂的功能，例如沙箱隔离、应用组合、应用通信、生命周期、优化缓存、依赖共享等。
在我看来这个有点太把简单的问题复杂化了，或者说纯用技术思维去思考解决一切问题，如果只是为了做技术实验是值得鼓励的，但如果要放在具体业务问题中，我个人是非常不推荐的。而且即使接入成本再低，也会增加不小的心智负担。
事实上在我看来这些框架在绝大多数业务场景下，都没有最简单的 ifame 好用。
如果你是一个技术负责人，那我真心建议你，扪心自问，你的业务问题真的需要接入这样的一个框架才能解决现有问题么？ 直接针对你们业务目前的技术特点在工具链、在编译时、在运行时在各个环节，甚至自己用iframe直接去操作，想怎么写怎么写，不舒服么。
当然如果你的业务场景与阿里云平台的业务特点完全一样，那也是可以用的，毕竟乾坤就是从该业务中孵化出来的。
总结
- 世界不存在完美的系统
- 微前端的架构无法也不可能解决最核心的痛点
- 不能解决核心痛点的微前端框架，价值会大大缩水，远不及人们的期望
- 目前现存微前端框架无法成为行业最佳实践，只能作为解决很小的一部分具体业务问题的解决方案
- 微前端的架构理念，值得我们学习，运用到自己的架构中
- 在大多数业务场景中，你其实都没必要真的接入微前端框架，请慎重
总之，拿乾坤框架举例，我很难评判它的出现是不是KPI的产物，但我认为它的实际价值要远远小于社区对它的关注，其开源作者在文章中说："大部分时候，一个「流行」的东西，你都无法阻止不需要它的人去使用它。"，我深以为然。
原创声明
原创文章，转载请注明作者和文章原链接 阿祖zu