探索微前端的场景极限，95页初级前端模块笔记分享

最新推荐文章于 2024-11-01 13:37:40 发布

2401_84093054

最新推荐文章于 2024-11-01 13:37:40 发布

阅读量962

点赞数 25

分类专栏：程序员文章标签：前端笔记

本文链接：https://blog.csdn.net/2401_84093054/article/details/137419095

版权

程序员专栏收录该内容

278 篇文章 0 订阅

订阅专栏

}

第二步：通过 MicroApp 组件引入微应用：

import MicroApp from ‘./MicroApp’;

import React from ‘react’;

class App extends React.Component {

render() {

return (

{

this.props.admin

}

)

}

如果你是 umi 应用，那只需要直接使用插件封装好的组件即可：

import { MicroApp } from ‘umi’;

function MyComponent() {

return (

)

}

这类方式适用于一些可共用的、带业务逻辑的服务型组件（类似于我们以前常说的端对端组件）：比如带聊天交互的客服机器人、带引导功能的 intro 服务等。

如蚂蚁 sofa 产品控制台中的这个使用入门微应用：

通过组件的这种方式，我们可以完全自主的控制微应用的渲染，并与之做一些复杂的交互。不论是在开发者的编码心智，还是用户的体验上，都跟使用一个普通的业务组件无异。

组件的方式非常灵活，几乎解决了所有路由绑定方式渲染微应用的问题，但也有自己的一些局限：比如我们会要求这类微应用必须是不带路由系统的 widget 类型，不然也会出现多实例时路由冲突的问题。

嵌套渲染场景

有一些更复杂的场景中，我们可能需要使用到「套娃」的方式集成我们的若干微应用。

比如我们要在应用 A 下集成应用 B 的商品列表页，然后在应用 B 的商品列表页呼出应用 C 的买家详情页，所有应用的唤起都以弹层/抽屉这种不刷新的交互来完成。

在有了上面两个场景的实践经验后，我们很容易得出这样的组合逻辑：

在应用 A 中通过调用 loadMicroApp(B) 的方式唤起微应用 B，然后在微应用 B 中通过_loadMicroApp(C)_ 的方式唤起微应用 C，通过这样的调用链路即可很完美的完成产品上的诉求。

但是现实情况往往没有那么简单，前面提到过，若想要 loadMicroApp API 能符合预期的运行，我们需要确保被加载的微应用是不含自己的路由系统，否则会出现多个应用间路由系统互相抢占/冲突的情况。

而现实情况是，我们大部分需要复用的页面/组件，都会是某个站点的局部路由页，很少有人会专门起一个仓库，用来专门把这个页面抽取成一个微应用，比如上面提到的买家详情页。

这种场景下，我们其实只需要确保微应用的路由系统不会干扰到全局的 URL 系统即可。幸运的是 react-router 的 memory history 模式很好的解决了这一问题。如果你是一个 umi 应用，只需要直接使用我们封装好的组件即可完成 memory history 的运行时切换：

import { MicroAppWithMemoHistory } from ‘umi’;

交互效果可以参考：

关于嵌套渲染相关的详细介绍，可以看这篇《基于微前端的大型中台项目融合方案》

极限渲染场景

如果你觉得嵌套微应用就是我们场景的天花板了，那未免有点小看群众们的想象力了。

在我们内部的一个设计工程化平台里，我们通过 qiankun 成功的把一个微应用的 20+ 路由页同时渲染到了一个 url 下：4

上图中右侧列表中每一个 demo 都是通过 qiankun 渲染的一个独立微应用实例，而这里面每一个微应用实例，实际对应是同一个 react 应用的不同路由页。

不同于前面几个场景，将同一个应用的不同页面，同时渲染到主应用的不同 UI 容器中这个需求下，有几个比较特殊的问题需要去考虑：

是否需要特殊的微应用生产方式
多路由系统共存带来的冲突/抢占问题
不同微应用间的样式隔离
如何优化渲染性能：既然每一个微应用实例实际对应的是同一个应用，那我们如何尽可能多的复用一些运行时或者沙箱，从而降低这么多微应用同时渲染代理的运行时开销

篇幅考虑，针对这类场景优化的技术细节不在这里介绍了，后面会单独写一篇来介绍

解决了这些问题后，我们只需要在我们的项目中这么去使用就可以了：

// MicroAppWithMemoHistory 是基于 memory history 封装的微应用加载器

import { MicroAppWithMemoHistory } from ‘umi’;

function Home {

return (

{ /* 将同一个应用的不同路由页同时渲染出来 */ }

)

}

工程上的想象空间

微前端架构除了其带来的巨石应用解构、技术栈无关等工程能力外，也为我们对一些已有的工程问题带来了新的解题思路，比如：

npm 包分发业务组件背后的工程问题

在以前，我们经常通过发布 npm 包的方式复用/共享我们的业务组件，但这种方式存在几个明显的问题：

npm 包的更新下发需要依赖产品重新部署才会生效
时间一长就容易出现依赖产品版本割裂导致的体验不一致
无法灰度
技术栈耦合

说白了就是 npm 包这种静态的共享方式，丧失了动态下发代码的能力，导致了其过慢的工程响应速度，这在现在云服务流行的时代就会显得格外扎眼。而微前端这种纯动态的服务依赖方式，恰好能方便的解决上面的问题：被依赖的微应用更新后的产物，在产品刷新后即可动态的获取到，如果我们在微应用加载器中再辅以灰度逻辑，那么动态更新带来的变更风险也能得到有效的控制。

新的 UI 共享模式

在以前，如果我们希望复用一个站点的局部 UI，几乎只有这样一条路径：从业务系统中抽取出一个组件 -> 发布 npm 包 -> 调用方使用 npm 包。

且不说前面提到的 npm 自身的问题，单单是从一个已有的业务系统中抽取出一个 UI 组件这个事情，都可能够我们喝一壶的了。我们不仅要在物理层面，将这部分代码抽取成若干个单独的文件，同时还要考虑如何跟已有的系统做上下文解耦，这类工作出现在一个越是年代久远的项目上，实施起来就越是困难，做过这类事情的同学应该都会深有体会。

不同于组件库的研发流程，微前端的场景下，大部分时候我们不会为了去复用一个 UI，而去专门写一个微应用出来。通常我们期望的是，从一个已有系统中，直接选取我们需要复用的部分，嵌入到我们自己的容器里进行渲染。

基于上面提到过的微应用多实例的渲染方案，我们可以考虑将需要复用的组件，以路由 URL 作为 ID 的方式导出。比如我们有这样一个 A 应用有一个这样的页面：

function OnePage() {

return (

)

}

我们有另外一个应用，希望单独复用 A 应用的用户列表部分的交互跟 UI，那我们只需要多加一条路由规则：

…

依赖方只需要配合 memory history 并指定 url 为 /userList 即可完成渲染（参考上面嵌套渲染章节）。