微前端接入笔记

为什么要去掉 iframe

iframe 不利于我们进行组件的通信，其原生带来的割裂感，使我们无法复用组件和 css 样式。qiankun 使用的是沙箱的机制，通过劫持路由, 配合 webpack 构建出相同的资源访问形式，进行切换不同路由找到相应的页面，在进行加载。

为什么选择了 qiankun

  • single-spa single-spa 是一个用于前端微服务化的 JavaScript 前端解决方案 (本身没有处理样式隔离， js 执行隔离) 实现了路由劫持和应用加载。也是比较早的作出微前端的框架，下面的几个框架也是借鉴了不少内容。 通过主项目提供注册逻辑、子应用提供三个协议接入方法和打包格式 single-spa 只是实现了加载器、路由托管。沙箱隔离并没有实现。因此它只支持单应用的场景。

  • qiankun 这个框架是阿里出品的，也是比较早的微前端处理方式。总结来说它有以下特点：

简单——任意 js 框架均可使用。微应用接入像使用接入一个 iframe 系统一样简单，但实际不是 iframe。 完备——几乎包含所有构建微前端系统时所需要的基本能力，如 样式隔离、js 沙箱、预加载等。 生产可用——已在蚂蚁内外经受过足够大量的线上系统的考验及打磨，健壮性值得信赖。

qiankun 方案 qiankun 方案是基于 single-spa 的微前端方案。 特点

html entry 的方式引入子应用，相比 js entry 极大的降低了应用改造的成本； 完备的沙箱方案，js 沙箱做了 SnapshotSandbox、LegacySandbox、ProxySandbox 三套渐进增强方案，css 沙箱做了 strictStyleIsolation、experimentalStyleIsolation 两套适用不同场景的方案； 做了静态资源预加载能力；

不足

适配成本比较高，工程化、生命周期、静态资源路径、路由等都要做一系列的适配工作； css 沙箱采用严格隔离会有各种问题，js 沙箱在某些场景下执行性能下降严重； 无法同时激活多个子应用，也不支持子应用保活； 无法支持 vite 等 esmodule 脚本运行；

EMP 方案 EMP 方案是基于 webpack 5 module federation 的微前端方案。 特点

webpack 联邦编译可以保证所有子应用依赖解耦； 应用间去中心化的调用、共享模块； 模块远程 ts 支持；

不足

对 webpack 强依赖，老旧项目不友好； 没有有效的 css 沙箱和 js 沙箱，需要靠用户自觉； 子应用保活、多应用激活无法实现； 主、子应用的路由可能发生冲突； EMP 方案是基于 webpack 5 module federation 的微前端方案。

技术细节

好处： 1.应用自治 只需要遵循统一的接口规范或者框架，以便系统集成到一起。 2.单一职责 每个前端应用可以只关注于自己所需要完成的功能 3.技术栈无关 缺点： 1. 应用的拆分基础依赖于基础设施的构建，一旦大量应用依赖于同一基础设施，那么维护变成了一个挑战。 2. 拆分的粒度越小，意味着架构变得复杂、维护成本变高

遇到最难的问题

qiankun 是通过 fetch 去获取子应用注册时配置的静态资源 url，所有静态资源必须是支持跨域的，那就得设置运行源

http {
  server {
    listen 80;
    add_header Access-Control-Allow-Origin *;
    add_header Access-Control-Allow-Headers DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization;
    add_header Access-Control-Allow-Methods GET,POST,OPTIONS;
    if ($request_method = 'OPTIONS') {
      return 204;
    }
    location / {
      root /data/www/html;
      index index.html index.htm;
    }
  }
}

  • Access-Control-Allow-Origin：跨域在服务端是不允许的。只能通过给 Nginx 配置

  • Access-Control-Allow-Origin *后，才能使服务器能接受所有的请求源（Origin）

  • Access-Control-Allow-Headers: 设置支持的 Content-Type

样式隔离

start 方法有个属性 sandbox。该值默认为 true

为 true，可以隔离子页面的样式，但是*、html、body 等公共的样式还是会影响到主应用

可以配置为 { strictStyleIsolation: true } 表示开启严格的样式隔离模式。 这种模式下 qiankun 会为每个微应用的容器包裹上一个 shadow dom 节点，从而确保微应用的样式不会对全局造成影响。

function render(props = {}) {
  const { container } = props;
  new Vue({
    router,
    render: (h) => h(App),
  }).$mount(container ? container.querySelector("#app") : "#app");
}
// ...
// 生命周期 - 挂载后
export async function mount(props) {
  // ...
  // 渲染
  render(props);
}
// ...
// 本地调试
if (!window.__POWERED_BY_QIANKUN__) {
  render();
}

保障原来的应用运行正常，但能集成到基座 portal 中

使用这个全局变量来区分当前是否运行在 qiankun 的主应用中

window._POWERED_BY_QIANKUN

独立运行：window.POWERED_BY_QIANKUN为 false，执行 mount 创建 vue 对象 运行在 qiankun: window.POWERED_BY_QIANKUN为 true，则不执行 mount

history 路由模式，需要如何配置 nginx，才能正常访问

通过 nginx 配置加入 try_files，history 模式同样会有一个问题，就是当页面刷新时，如果没有合适的配置，会出现 404 错误，针对这种请看，需要额外在 nginx 配置，对于找不到 url 的，将首页 html 返回

nginx配置问题

  • try_files：用来解决 nginx 找不到 client 客户端所需要的资源时访问 404 的问题

  • proxy_pass：主要是用来配置接口网关反向代理，可以使得父子应用下访问的 api 是一致的，防止接口跨域问题

微前端方案种类

基座模式：通过搭建基座、配置中心来管理子应用。如基于 SIngle Spa 的偏通用的乾坤方案，也有基于本身团队业务量身定制的方案。 自组织模式： 通过约定进行互调，但会遇到处理第三方依赖等问题。 去中心模式： 脱离基座模式，每个应用之间都可以彼此分享资源。如基于 Webpack 5 Module Federation 实现的 EMP 微前端方案，可以实现多个应用彼此共享资源分享。

微前端按技术来拆分

按技术拆分

路由分发式。通过 HTTP 服务器的反向代理功能，来将请求路由到对应的应用上。 前端微服务化。在不同的框架之上设计通讯、加载机制，以在一个页面内加载对应的应用。 微应用。通过软件工程的方式，在部署构建环境中，组合多个独立应用成一个单体应用。 微件化。开发一个新的构建系统，将部分业务功能构建成一个独立的 chunk 代码，使用时只需要远程加载即可。 前端容器化。通过将 iFrame 作为容器，来容纳其它前端应用。 应用组件化。借助于 Web Components 技术，来构建跨框架的前端应用。

上一页2020.11.25下一页面试的基本原则

最后更新于

这有帮助吗？