微前端相关

[Pines-Cheng]

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

微前端的核心价值在于 "技术栈无关"，这才是它诞生的理由。

而对于 ToB 应用而言，3~5 年太常见了好吗！去看看阿里云最早的那些产品的控制台，去看看那些电信软件、银行软件，哪个不是 10 年+ 的寿命？企业软件的升级有多痛这个我就不多说了。所以大部分企业应用都会有一个核心的诉求，就是如何确保我的遗产代码能平滑的迁移，以及如何确保我在若干年后还能用上时下热门的技术栈？

对很多做 ToB 领域的中小企业而言，这样的系统可能是他们安身立命之本，不是能说扔就扔的，他们承担不了那么高的试错成本。

我们只需要在主系统构造一个足够轻量的基座，然后让各子应用按照共同的协议去实现即可。这个协议可以包括，主应用应该如何加载子应用，以及子应用如何被主应用感知、调度，应用之间如何通信等。

这个协议不应该包括，子应用要如何确保隔离性、安全性，也就是子应用除了实现一些较为简单的协议之外，跟开发一个正常的 spa 应用应该没有任何差别，包括不应该有 开发、构建、发布 等流程上的侵入。只要子应用实现了这几个协议，其他的东西怎么玩，我们都不需要关心或干预。

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

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

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

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

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

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

玉伯提到：

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

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

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

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

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

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

参考

• qiankun
• 微前端的核心价值
• 可能是你见过最完善的微前端解决方案
• 架构设计：微前端架构