qiankun 传统项目配置_前端微服务

见内容

解决的问题

常见讨论

观点：微前端的核心价值在于 “技术栈无关”

微前端的公司，基本上都是做 ToB 软件服务的，没有哪家 ToC 公司会有微前端的诉求，因为很少有 ToC 软件活得过 3 年以上的，如何给遗产项目续命，才是我们对微前端最开始的诉求。

微前端首先解决的，是如何解构巨石应用，解构之后还需要再重组，重组的过程中我们就会碰到各种 隔离性、依赖去重、通信、应用编排 等问题。

1

2玉伯：

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

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

能力

我们希望，按照用户和使用场景将多个系统汇总成一个或者几个综合的系统.

将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。由此带来的变化是，这些前端应用可以独立运行、独立开发、独立部署。以及，它们应该可以在共享组件的同时进行并行开发——这些组件可以通过 NPM 或者 Git Tag、Git Submodule 来管理。

技术特点：

技术栈无关 主框架不限制接入应用的技术栈，子应用具备完全自主权

独立开发、独立部署 子应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新

独立运行时 每个子应用之间状态隔离，运行时状态不共享

实现方案

将应用内的组件调用变成了更细粒度的应用间组件调用

原有：将路由分发到应用的组件执行

现有：路由来找到对应的应用，再由应用分发到对应的组件上

常见实现方案使用 HTTP 服务器的路由来重定向多个应用

在不同的框架之上设计通讯、加载机制，诸如 Mooa 和 Single-SPA

iFrame。使用 iFrame 及自定义消息传递机制

使用纯 Web Components 构建应用

结合 Web Components 构建

iframe

优点

比较容易实现

缺点

子项目需要改造，需要提供一组不带导航的功能

iframe嵌入的显示区大小不容易控制，存在一定局限性

URL的记录完全无效，页面刷新不能够被记忆，刷新会返回首页

iframe功能之间的跳转是无效的

iframe的样式显示、兼容性等都具有局限性

实现方式

在采用 iframe 的时候，我们需要做这么两件事：

设计管理应用机制

设计应用通讯机制

加载机制。在什么情况下，我们会去加载、卸载这些应用；在这个过程中，采用怎样的动画过渡，让用户看起来更加自然。

通过 iframeEl.contentWindow 去获取 iFrame 元素的 Window 对象是一个更简化的做法。随后，就需要定义一套通讯规范：事件名采用什么格式、什么时候开始监听事件等等。

纯 Web Components 技术构建

同一时刻可展示多个子应用。通常使用 Web Components 方案来做子应用封装，子应用更像是一个业务组件而不是应用。

暂时技术不成熟，兼容性不高

MPA + 路由分发

优点：

框架无关；2.

独立开发、部署、运行；

应用之间 100% 隔离。

缺点：

应用之间的彻底割裂导致复用困难。(比如，每个应用左侧和顶部都带有导航，那么, 当我要把该应用在其他系统中复用时，需要对该子应用的导航做较为复杂的改动) ；

每个独立的 SPA 应用加载时间较长，容易出现白屏，影响用户体验；

后续如果要做同屏多应用，不便于扩展。

基座式 SPA，主从应用设计

主应用捕获全局的路由事件，基于判断当前路由需要加载哪个子应用，然后 load 它。

路由这里有点不同，在类 Single-SPA 方案中，子应用在加载后，一般会由子应用去接管系统路由。而在基座式的方式中，子应用一般会把自己的路由注册到主应用中，并不接管系统路由。子应用更像是主应用的一个“路由模块”。

缺点：

首先基座就决定了它是框架强相关的，哪怕是基座的版本升级迭代，也会非常容易造成子应用 break change。

传统 SPA + 组件化(比如 Web Components) + 私有 npm 源

使用 npm 包的方案缺陷：需要不断地在