摘要

作者：京东科技 陈云飞在以往的业务场景中，用户进入五花八门的菜单体系中，往往会产生迷茫情绪，难以理解平台名称及具体作用，导致数据开发与管理学习成本较高，降低工作效率。为此我们整合从数据接入，数据开发，数据管理的全链路流程，期望让用户体验一站式数据开发与管理的便捷性；并提供不同业务场景，方便根据业务场景进行进一步数据开发与管理工作，为数据应用平台打下夯实规范的数据基础，方便用户在数据平台里，对于数据开发和数据应用进行便捷性的切换，因此我们设计目前的门户基座，可以快速浏览各个平台，同时串联数据开发与管理的工作，减少用户的试错成本，提升工作效率。

作者：京东科技 陈云飞

一，需求背景

1 业务背景

在以往的业务场景中，用户进入五花八门的菜单体系中，往往会产生迷茫情绪，难以理解平台名称及具体作用，导致数据开发与管理学习成本较高，降低工作效率。为此我们整合从数据接入，数据开发，数据管理的全链路流程，期望让用户体验一站式数据开发与管理的便捷性；并提供不同业务场景，方便根据业务场景进行进一步数据开发与管理工作，为数据应用平台打下夯实规范的数据基础，方便用户在数据平台里，对于数据开发和数据应用进行便捷性的切换，因此我们设计目前的门户基座，可以快速浏览各个平台，同时串联数据开发与管理的工作，减少用户的试错成本，提升工作效率。

2 标品需求

基座子-项目交互简图如图1；

1，基座的业务页面比较简单，主要包含：顶部边栏、左侧边栏、公共子菜单、顶级平台菜单；

2，点击左上角图标，显示顶级平台菜单，点击平台，在基座左侧边栏动态显示平台一级菜单；

3，点击基座左侧边栏，在公共子菜单，动态显示一级菜单下边的二级、三级菜单；

4，点击基座左侧边栏或者公共子菜单，需要基座调度，在子项目区域正确加载子项目及子项目页面；

图 1

数据中台新门户基座要接入老数据平台一、老数据平台二等 多平台的前端项目，并且原有前端子项目在门户基座呈现任意子项目、任意子项目页面 任意混搭的需求；新门户要接入的项目关系详情如图2；

图 2

3 数据中台融合；

数据中台融合指的是京东体系内，其他对外独立交付的数据中台，比如京东工业、京东城市等项目；数据中台商业化的子项目不仅在新门户容器内，也可以按需打包进其他数据中台容器；下面简称 数据中台融合；

二，微前端技术调研

原有数据中台接入子应用的方式有多种：iframe 嵌套、@weus 微应用、链接跳转等；

1 iframe 存在问题：

• url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。

• UI 不同步，DOM 结构不共享。想象一下屏幕右下角 1/4 的 iframe 里来一个带遮罩层的弹框，同时我们要求这个弹框要浏览器居中显示，还要浏览器 resize 时自动居中..

• 全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果。

• 慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程。

2 weus 存在问题：

•weus 是京东内部研发已经不再维护了，如果有新的问题需要自己解决，对微前端有新需求也需要自己去实现；

•weus 没有严格的 css 沙箱、js 沙箱，而在我们的需求中，沙箱机制是刚需，我们要接入的子项目在 window 上挂在哪些变量，无法通过规范做到强有力的制约（因为要接入的项目是已经写完了）

•weus 在微前端功能实现，没有qiankun 丰富健全，比如全局状态管理、虽然 weus 实现了子应用的预加载，但是比较机械，是把所有注册的子应用都缓存，实际可能不需要，qiankun 就比较灵活可以根据需要手动缓存等；

3 链接跳转

链接跳转，指的是点击一个菜单，跳转到另一个页面。这种方式不符合 “一站式 ”大数据平台产品定位；

4 最终结论

通过几种实现方式的对比，最终决定以 qiankun 微前端为基础，结合我们的实际业务场景，通过权限菜单树 和 子项目关联来实现基座对子项目的调度，具体方案请参照 三，基座技术方案详细描述；

三，技术方案详细描述；

1 名词解释

跨子项目跳转

指的是子项目没通过基座自行跳转，基座此时需要根据 url 匹配正确的基座显示；

触发节点

点击菜单，菜单对应的节点即为触发节点，跨子项目跳转（刷新页面）没有触发节点，以跳转后url 对应的页面节点为触发节点；

页面节点

权限菜单树中，挂载了子项目页面的节点

门户节点

狭义指的是，当前页面节点对应的公共子菜单父级节点；广义指的是通过页面节点向父系节点查询，最终确认公共子菜单、基座边栏的显示，并通过页面节点确定菜单高亮等行为；

第一子系节点

指的是在由触发节点查页面节点时，只关注子节点中的第一个，如果当前节点的第一个节点不是页面节点，继续在孙子节点的第一个，直到节点类型为页面节点为止；

调度引擎

指的是在基座中，对权限树数据处理，接收基座业务层调度，通过对权限树遍历、查询操作对业务层输出运算结果的一个抽象分层；

2 整体流程图

如图3 为基座技术方案的整体流程图，下面详细介绍

图 3

3 技术方案-分步描述

第 1 步，配置权限菜单树，关联子项目页面

•如图 3 所示，首先会在权限中心配置权限菜单树，权限菜单树有很多级，比如一级平台，二级平台，二级平台一级菜单，二级菜单等，三级菜单等；

•然后需要在菜单树上，挂在子项目的页面，子项目页面的一些权限按钮等；

•最后权限中心对不同的用户赋予权限菜单树的子集；

第 2 步，基座菜单树数据处理；

•基座从接口拿到权限菜单树关联页面数据后，触发调度引擎初始化、并把基座的业务更新函数传给调度引擎；

•基座获取到菜单树以后，广度优先算法（如图4）遍历整个树结构，并建立节点间父子关联关系。根据节点是否挂载了子项目页面定义前端节点类型 ；最终形成图 5 的数据；

•在树遍历过程中，会统一在基座左侧边栏这一层级的节点，做一个门户节点的标记；

图4

•如图 5 所示，前端调度关系中，把权限菜单树分成 两种节点类型，挂载了子项目页面的节点，定义为页面节点。另一种没挂载子项目页面的节点，定义为分组节点；在基座调度中，不关心权限按钮节点，在数据处理中，页面节点就是整个权限菜单树的叶子节点；

图 5

第 3 步，点击基座边栏或公共子菜单

•点击基座边栏，触发点击菜单流程，点击的节点即为 “触发节点”；

•由触发节点，向第一子系节点查页面节点，查页面节点同时，会同时匹配门户节点；

•没有匹配到门户节点，由触发节点向父系节点匹配门户节点；

第 4 步，刷新页面或跨子项目跳转

•这时没有直接的触发节点，只能通过 url 上的标识和菜单树上的页面节点进行匹配

•匹配到页面节点以后，由页面节点向父系节点查门户节点；

第 5 步，通过门户节点输出 “运算结果”

•这里的运算结果主要包含：基座左侧边栏、公共子菜单菜单树列表、菜单高亮、产品平台名称等一系列基座需要正确显示所需要的数据；

•基座调度引擎，根据触发调度的类型；如果是点击菜单触发会执行 切换页面操作，刷新和跨子项目跳转则不需要触发；

第 6 步，基座业务层执行运算结果；

•基座调度引擎，在接收基座业务层调度指令后，通过对图 5 权限树的遍历、查询操作，最终获取运算结果；

• 调用基座业务层的更新函数，执行运算结果，到此基座调度流程结束；

四，基座-子项目结构通信图

1 基座分为业务层、调度引擎两部分；

•基座业务层主要包含：左侧边栏、顶部边栏、顶级平台菜单等 UI显示；

•基座调度层，以 qiankun 微前端为基础，丰富扩展了权限树数据处理、调度运算、双向通信、子项目分组分步预加载策略等；

2 基座子项目通信和路由调度

•基座在执行主题切换时候，通过 qiankun 的 setGlobalState 通知子项目；子项目在绑定项目空间等特定需求时，通过调度引擎封装的 eventCenter 和基座反向通信；

•跨子项目跳转，子项目会自行触发 pushState，点击基座菜单跳转流程，由调度引擎触发 pushState 触达

• qiankun 的 pushSate 劫持策略，触发 popstate 子项目页面因此触发更新；

图 6

3 路由劫持策略原理

基座调度引擎通过监听 popstate 来获取刷新、跨子项目跳转的指令，从而触发调度流程；以下为原理解析：

•以 Vue 为例，Vue 通过 主动触发 pushState、replaceState 或者监听 popstate 变化触发页面发生变化；

•但是跨子项目跳转，执行 pushState 并没有触发 popState 基座调度引擎又怎么能监听到呢？

•通过阅读 qiankun 中依赖的库 single-spa 的源码，navigation 模块劫持了 pushstate 方法，只要触发 pushstate，就会触发 popstate 事件，关键代码如下所示：

function patchedUpdateState(updateState, methodName) {   return function () {     const urlBefore = window.location.href;     const result = updateState.apply(this, arguments);     const urlAfter = window.location.href;       if (!urlRerouteOnly || urlBefore !== urlAfter) {       if (isStarted()) {         window.dispatchEvent(           createPopStateEvent(window.history.state, methodName)         );       } else {         reroute([]);       }     }     return result;   }; } window.history.pushState = patchedUpdateState(    window.history.pushState,    "pushState" );  

五，基于 qiankun 功能扩展：

1 沙箱隔离

js 沙箱利用 qiankun 沙箱机制；

css 沙箱，qiankun 的 css 沙箱不健全；我们接入的又是老项目，目前的策略是 ：

•基座通过特殊命名空间 .susceptor、element-ui 通过 .spr 跟子项目隔离；

•子项目通过特殊命名空间，例如 .datacenter-xxx 跟基座隔离

•子项目对 .el- 不执行隔离，目的是为了统一控制布局、主题，同时做性能优化；

2 通信机制

基座和子项目，属于典型的主从结构，采用单向数据流通信；为了满足特殊场景子项目跟基座通信需求，在 qiankun 的通信基础上，封装了 eventCenter 仅用于 子项目 跟基座通信；

•基座 -> 子项目，通过qiankun 的 onGlobalStateChange 通信

•子项目 -> 基座，通过 subActions 封装的 eventCenter 通信

3 分组、分步、动态预加载机制

目前标品基座已经加载了 30多个前端子项目，这么多前端子项目在首个子项目挂载后执行预加载，有可能会阻塞正常页面访问；

分组指的是，通过产品划定的平台，只有切换到当前平台才会加载到当前平台的子项目；

分步指的是，当前平台子项目过多时，一次预加载少量子项目，分多次预加载；

动态指的是，基座在首个子项目挂载后，会检测网速，只有网速良好时才会执行预加载；

4 跨子项目跳转

跨子项目跳转的背景在于 BDP 一站式开发与管理平台，是一个大产品，数据规划、数据集成 等是其中的模块；模块之间存在一些跳转，对于前端就是跨子项目跳转；

我们目前的跨子项目跳转，由 subActions 封装，抹平了标品基座 和 数据中台融合容器的区别；

基座跳转逻辑如下：

crossAppJump: ({ subApp='', path= '', paramsStr='', target= ''})=> {       let jumpUrl = `/susceptor/${subApp}${path}`       if(paramsStr){         jumpUrl = `${jumpUrl}${paramsStr}`       }       if(target === '_blank'){         window.open(`${location.origin}${jumpUrl}`)       } else {         window.history.pushState({ portalPushState: true }, null, jumpUrl);       }   },  

数据中台融合跳转逻辑如下：

 crossAppJump: ({ subApp='', path= '', paramsStr='', target= ''})=> {       let jumpUrl = `/${subApp}${path}`       window.__datafuse_jssdk__.crossAppJumpFnGetter({         path: jumpUrl,         paramsStr,         target       })(); }  

5，接口访问及登录鉴权；

由于微前端的技术形态，子项目在基座中加载实质是基座容器的 一段 html，所有接口均是以基座的 域名进行接口转发；由因为数据中台融合，所以子项目请求后端接口均是以 /api/datacenter/项目名 开头；

通过以下 nginx 示例，我们把基座、子项目 的页面访问、接口访问链路 说明白；

# proxy.conf 示例(已做脱敏处理，均不是项目升级名称) server {     listen                80;     server_name           unify.external.dadacenter;     charset utf-8;    location /sub-app{         alias  /export/web/sub-app-web;         try_files $uri $uri/ /index.html =404;    }    location /api/datacenter/subapp {         proxy_pass   http://server-sup-app/;    }    location /susceptor{       alias  /export/web/susceptor;     on;       try_files $uri $uri/ /index.html =404;    }    location /api{         proxy_pass  http://sever-api/;   } }   # server.conf 示例(已做脱敏处理，均不是实际项目) upstream server-sup-app{     server 111.112.113.114:10001; } upstream sever-api{     server 111.112.113.114:1000; }  

鉴权，前端不需要开发，但是需要知道，后端是通过顶级域名种 cookie 鉴权的；例如：unify.external.bigdata 测试环境是在 .external.bigdatao 域名下，这也是为什么本地开发需要配置 host：127.0.01 loca.external.dadacenter ；

六，写在最后，不忘初心

本节提供两个图， 对上文介绍的微前端实践，有进一步的能力提升，有感兴趣的同学欢迎一起讨论；

1，整体流程图；

如图 6 所示，配置流程：配置权限菜单树，然后配置子项目-子项目页面两级；最后把权限菜单树 和 子项目-子项目页面关联起来，形成如图 7 的权限树-子项目关联数据模型；

基座两个调度流程，跟上文类似，但是多了子项目维度，基座在加载子项目的时候，就可以把子项目 在权限树的 权限按钮信息全部给到子项目；

图 6

2 权限菜单树模型；

上文介绍的基座调度流程是简化后的版本，项目节点只有 分组节点、页面节点；但是从能力层缺失了 子项目维度；在设计之初，如图 7 所示：项目节点包含了 分组节点、子项目节点、子项目页面节点、页面节点 4种节点类型；

图 7