微前端的核心价值

[kuitos]

整理自 11.20 晚阿里云微前端线下沙龙

整个会议下来，我只对一个话题有兴趣，就是 #大果 提出的灵魂拷问：

如果是 widget 级别，那么微前端跟业务组件的区别在哪里？微前端到底是因何而生？

圆桌环节简单发表了一下自己的观点，这里再文字补充一下。

先抛观点：

我认为微前端的核心价值在于 "技术栈无关"，这才是它诞生的理由，或者说这才是能说服我采用微前端方案的理由。

为什么"技术栈无关"这么重要？

我抛两个场景，大家思考一下：

1. 你新入职一家公司，老板扔给你一个 5 年陈的项目，需要你在这个项目上持续迭代加功能。
2. 你们起了一个新项目，老板看惯了前端的风起云涌技术更迭，只给了架构上的一个要求："如何确保这套技术方案在 3~5 年内还葆有生命力，不会在 3、5 年后变成又一个遗产项目？"

第一个场景我们初步一想，可以啊，我只需要把新功能用 react/vue 开发，反正他们都只是 ui library，给我一个dom 节点我想怎么渲染怎么渲染。但是你有没有考虑过这只是浮在表层的视图实现，沉在底下的工程设施呢？我要怎么把这个用 react 写的组件打出一个包，并且集成到原来的用 es5 写的代码里面？或者我怎么让 webpack 跟 之前的 grunt 能和谐共存一起友好的产出一个符合预期的 bundle？

第二个场景，你如何确保技术栈在 3~5 年都葆有生命力？别说跨框架了，就算都是 react，15 跟 16 都是不兼容的，hooks 还不能用于 class component 呢我说什么了？还有打包方案，现在还好都默认 webpack，那 webpack 版本升级呢，每次都跟进吗？别忘了还有 babel、less、typescript 诸如此类呢？别说 3 年，有几个人敢保证自己的项目一年后把所有依赖包升级到最新还能跑起来？

为什么举这两个场景呢，因为我们去统计一下业界关于”微前端“发过声的公司，会发现 adopt 微前端的公司，基本上都是做 ToB 软件服务的，没有哪家 ToC 公司会有微前端的诉求（有也是内部的中后台系统），为什么会这样？很简单，因为很少有 ToC 软件活得过 3 年以上的。而对于 ToB 应用而言，3~5 年太常见了好吗！去看看阿里云最早的那些产品的控制台，去看看那些电信软件、银行软件，哪个不是 10 年+ 的寿命？企业软件的升级有多痛这个我就不多说了。所以大部分企业应用都会有一个核心的诉求，就是如何确保我的遗产代码能平滑的迁移，以及如何确保我在若干年后还能用上时下热门的技术栈？

不论是 qiankun/OneX(蚂蚁基于qiankun打造的云应用接入平台) 最开始诞生的初衷，还是后续在于社区的交流过程中都发现，如何给遗产项目续命，才是我们对微前端最开始的诉求。阿里的同学们可能感受不深，毕竟那些一年挣不了几百万，没什么价值的项目要么是自己死掉了，要么是扔给外包团队维护了，但是要知道，对很多做 ToB 领域的中小企业而言，这样的系统可能是他们安身立命之本，不是能说扔就扔的，他们承担不了那么高的试错成本。

我认可的解决思路应该是，撒旦的归撒旦，耶稣的归耶稣。

我们只需要在主系统构造一个足够轻量的基座，然后让各子应用按照共同的协议去实现即可。这个协议可以包括，主应用应该如何加载子应用，以及子应用如何被主应用感知、调度，应用之间如何通信等。这个协议不应该包括，子应用要如何确保隔离性、安全性，也就是子应用除了实现一些较为简单的协议之外，跟开发一个正常的 spa 应用应该没有任何差别，包括不应该有 开发、构建、发布 等流程上的侵入。只要子应用实现了这几个协议，其他的东西怎么玩，我们都不需要关心或干预。

这样的话，其实整个系统就变成了一个真正的、基于运行时的插件平台了。

有一个非常合适的例子，我们通常是怎么看待可视化搭建平台的？我想大部分 pro code 玩家都是不太敢轻易尝试这个方式去开发自己的核心产品的，原因是什么呢？很简单，不可控。我的产品的上限由平台决定而不是我自己的 coding 能力决定，这就很要命了。尤其是一些核心模块，后面我想做一些个性性的改造可能都支持不了。但是如果有了微前端机制呢，只需要搭建平台去实现相关的协议，平台产出的页面就能很轻易的被集成到我们自己的应用里了。我们开发时可以选择需要强控制的页面自己写，边缘页面用可视化生成即可，完全没有任何心理负担。

为什么我认为"技术栈无关"才是微前端的初衷？

我们听到了很多不同团队的分享中，关于微前端带来的各种业务提升、产品提升的价值。比如产品的自由组合能力，比如以 widget 这种可视化方式直接输出产品的能力等等，将这些价值视作微前端诞生的理由。

但我对此一直保持的观点是，微前端首先解决的，是如何解构巨石应用，从而解决巨石应用随着技术更迭、产品升级、人员流动带来的工程上的问题。解构之后还需要再重组，重组的过程中我们就会碰到各种 隔离性、依赖去重、通信、应用编排 等问题。在解决了这些问题之后，才是产品的自由组合、widget 输出等能力。同时由于有了前者能力的铺垫和加持，这些产品上的价值提升也就变得很自然和容易。

不论是 OneX 还是阿里云的同学，都在反复强调微前端带来的业务价值及产品价值，比如产品的组合能力，widget 的产品输出能力（这些能力在我们的产品域确实很重要也很有价值，但并不是所有的控制台产品都一定需要的能力）。从分享中我们也能看到，云产品对于微前端的诉求是基本相同的，包括背后的 管控、编码 能力等。但我们需要清楚一件事，并不是只有云产品才需要微前端，也并不是所有采用微前端方案的公司都是做云产品的。

大果提的问题非常我认为有探讨价值：「widget 级别的微前端应用跟业务组件有什么区别？」

我的观点：有没有区别在于你的实现是不是技术栈无关。

以大果提到的淘宝吊顶 js 为例（这是一个非常贴切的举例，蚂蚁也有类似的 js 组件），它具备独立发布、固定地址自动升级等特点，我猜也不会限制调用方的技术栈，调用方使用时跟用一个普通的 library 一样，区别在于普通的 library 是通过 npm 包引入，但是这个 library 我们是通过 script 标签引入的。

但是考察是否技术栈无关不能简单看这些 api 设计，还要看是否存在一些隐性耦合。

比如是否要求调用方的 react 版本、是否要求调用方必须提前构造好一些上下文环境才能完成调用。

如果这些回答都是否，那么我认为这也是一种微前端的实现方式。

克军提到：

如果微前端只存在工程上的价值是不值得大张旗鼓去做的。

微前端的初衷应该还是来解决工程问题的，带来的产品价值在不同的领域可大可小。 比如在阿里云这种典型的云产品控制台的场景下，它带来的产品价值就会很可观。因为阿里云作为提供 IAAS 服务的云平台，它需要的就是平台、产品的被集成能力，在这种场景下，微前端能力能非常好的契合这个诉求。但需要强调的是，并不是所有采用微前端的客户，都是阿里云这种 IAAS 平台产品。很多中小型控制台大多没有产品自由组合能力的诉求。产品能力只能算是微前端的能力的一种延伸。

玉伯提到：

今天看各 BU 的业务问题，微前端的前提，还是得有主体应用，然后才有微组件或微应用，解决的是可控体系下的前端协同开发问题（含空间分离带来的协作和时间延续带来的升级维护）

总结的很精确。「空间分离带来的协作问题」是在一个规模可观的应用的场景下会明显出现的问题，而「时间延续带来的升级维护」几乎是所有年龄超过 3 年的 web 应用都会存在的问题。

微前端方案正确的架构姿势

既然「技术栈无关」是微前端的核心价值，那么整个架构方案的实现上，都应该秉持这一原则，任何违背这一原则的做法都应该被摒弃。

「技术栈无关」是架构上的准绳，具体到实现时，对应的就是：应用之间不应该有任何直接或间接的技术栈、依赖、以及实现上的耦合。

比如我们不能要求子应用、主应用必须使用某一版本的技术栈实现。

比如在通信机制的设计与选择上，尽量基于浏览器原生的 CustomEvent api，而不是自己搞的 pub/sub。

比如子应用是否具备不依赖宿主环境独立运行的能力，衡量标准是是否能一行代码不改，或者只改很少的配置，就能达成这一目标。

所以我认为正确的微前端方案的目标应该是：方案上跟使用 iframe 做微前端一样简单，同时又解决了 iframe 带来的各种体验上的问题。

理想状态下，以此为目标的微前端应用，是自动具备流通能力的，且这个流通能力不会因为主应用的实现升级而丧失（也就是说在 19 年能接入主应用的微前端应用，到了 2025 年也应该能正常接入正常运行，并同样保有在不同主应用间流通的能力）。

qiankun 正是以此为准则设计的。

如果说阿里的企业使命是：「让天下没有难做的生意」。

那么微前端的使命我认为是：「让天下没有短命的控制台」。

事实上如果所有的 web 技术栈能做到统一，所有 library 的升级都能做到向下兼容，我们确实就不需要微前端了。 —— 鲁迅

[afeiship]

我没说过..
—— 鲁迅

[zhoupengqiang]

赞成，不是技术栈无关的微前端方案，我都不考虑。

[zlq4863947]

鲁迅还说过技术方面的名言啊，学习了

[Pines-Cheng]

基于阿里云平台和体量来搞，想象空间很大。

[gavinwyf]

正在调研微服务解决方案，价值观上很有启发，感谢！