前言——微前端的引出
我有开发一个较大的后台由若干个子系统组成的大系统，而这个大系统可能会有多个入口，且不同入口间代码需要有隔离需求（但是不强），同时这些若干个子系统会存在若干复用组件情况，甚至会出现某些页面存在 90% 以上相同的情况。
也就是说，我们需要解决在一个系统/多个系统 中整合若干个子系统的问题。
听上去是个适合 qiankun 的方案
从上面简单的描述看，微前端似乎是一个比较好的技术方向，我们可以把子系统拆分出来做成一个个独立的 App 然后通过某些微前端框架 —— 比如乾坤去做整合这个事情。
但是事实上，乾坤这一类的前端框架本质上没有解决任何业务服务上的事情，乾坤这些方案本质是一个 鸵鸟方案。
微前端方案的大前提
微前端本质上是为了解决 康威定律 在前端上的表现。
我们说的大白话一点就是：
发现了一个问题
模块的设计者需要互相之间频繁沟通。而跨部门交流比较难。
那么我们可以这么解决这个问题
不沟通就是最好的沟通
既然沟通是大问题，那么就减少沟通就好。
康威定律 原文提出的解决方案大致是这样的：
- 第一定律 组织沟通方式会通过系统设计表达出来
- 第二定律 时间再多一件事情也不可能做的完美，但总有时间做完一件事情
- 第三定律 线型系统和线型组织架构间有潜在的异质同态特性
- 第四定律 大的系统组织总是比小系统更倾向于分解
所以这里就出现了一个解决策略就是将 大的应用 拆分成 若干个子系统，让这些子系统直接交流，譬如后端的微服务就是这样去做的。
总结一下
微前端(微服务架构)关注的是 如何解决组织和团队间协作带来的工程问题，而不是单纯的某个技术问题。
微前端对项目的基本假设
对于愿意使用 微前端 方案的工程师，他们对于系统的观点本质上是 悲观的，所以在潜意识里，微前端的采纳者就不相信一个系统会永远健康的迭代下去，他们的想法可以用一句话概括：
孤立系统总是趋向于熵增，最终达到熵的最大状态，也就是系统的最混乱无序状态。 —— Rudolf Julius Emanuel Clausius
他们认为所有大型系统都逃不过 熵增定律，而正因为熵增永远是自然且轻松的，对抗熵增是需要持续不断的提供能源去治理，修正的。
基于此，微前端很多时候是「悲观主义工程师」在工程上的妥协，是一种防御性，有时候甚至是「掩耳盗铃」式的架构策略。所以在开头就提出了一点就是乾坤这些方案本质是一个鸵鸟方案。
当然虽然在理想情况下，对于一个追求完美的工程师而言所有的技术问题都应该是被正面修复、正确治理的。
软件工程学告诉我们去不遗余力的治理所有的技术难题是不现实的（成本问题），虽然微前端是一个鸵鸟方案，但是诚如乾坤作者所说的1。
kuitos（乾坤作者）
微前端倡导的不是消极的、投降主义的去回避系统中的历史遗留问题，而是告诉我们，很多时候我们可以通过分而治之的手段，让「上帝的归上帝，凯撒的归凯撒」。
所以微前端是有其意义的，但是微前端并不是所有人都需要的。
你到底需不需要微前端？
如果你的团队是一个整体，且对整个架构 有绝对的话语权，那么不要想，你不需要真正意义上的微前端。其他的可以考虑参考微前端作者文章中说的内容：https://juejin.cn/post/6989067239089668127
脚注
-
https://juejin.cn/post/6989067239089668127 作者本人的论述就非常好，从中能学习到很多 ↩
本文标题：微前端
永久链接：https://iceprosurface.com/code/micro-frontend/
作者授权：本文由 icepro 原创编译并授权刊载发布。
版权声明：本文使用「署名-非商业性使用-相同方式共享 4.0 国际」创作共享协议，转载或使用请遵守署名协议。