作者：京东科技 陈云飞
在以往的业务场景中，用户进入五花八门的菜单体系中，往往会产生迷茫情绪，难以理解平台名称及具体作用，导致数据开发与管理学习成本较高，降低工作效率。为此我们整合从数据接入，数据开发，数据管理的全链路流程，期望让用户体验一站式数据开发与管理的便捷性；并提供不同业务场景，方便根据业务场景进行进一步数据开发与管理工作，为数据应用平台打下夯实规范的数据基础，方便用户在数据平台里，对于数据开发和数据应用进行便捷性的切换，因此我们设计目前的门户基座，可以快速浏览各个平台，同时串联数据开发与管理的工作，减少用户的试错成本，提升工作效率。
基座子-项目交互简图如图1；
1，基座的业务页面比较简单，主要包含：顶部边栏、左侧边栏、公共子菜单、顶级平台菜单；
2，点击左上角图标，显示顶级平台菜单，点击平台，在基座左侧边栏动态显示平台一级菜单；
3，点击基座左侧边栏，在公共子菜单，动态显示一级菜单下边的二级、三级菜单；
4，点击基座左侧边栏或者公共子菜单，需要基座调度，在子项目区域正确加载子项目及子项目页面；
图 1
数据中台新门户基座要接入老数据平台一、老数据平台二等 多平台的前端项目，并且原有前端子项目在门户基座呈现任意子项目、任意子项目页面 任意混搭的需求；新门户要接入的项目关系详情如图2；
图 2
数据中台融合指的是京东体系内，其他对外独立交付的数据中台，比如京东工业、京东城市等项目；数据中台商业化的子项目不仅在新门户容器内，也可以按需打包进其他数据中台容器；下面简称 数据中台融合；
原有数据中台接入子应用的方式有多种：iframe 嵌套、@weus 微应用、链接跳转等；
• url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
• UI 不同步，DOM 结构不共享。想象一下屏幕右下角 1/4 的 iframe 里来一个带遮罩层的弹框，同时我们要求这个弹框要浏览器居中显示，还要浏览器 resize 时自动居中..
• 全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果。
• 慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程。
•weus 是京东内部研发已经不再维护了，如果有新的问题需要自己解决，对微前端有新需求也需要自己去实现；
•weus 没有严格的 css 沙箱、js 沙箱，而在我们的需求中，沙箱机制是刚需，我们要接入的子项目在 window 上挂在哪些变量，无法通过规范做到强有力的制约（因为要接入的项目是已经写完了）
•weus 在微前端功能实现，没有qiankun 丰富健全，比如全局状态管理、虽然 weus 实现了子应用的预加载，但是比较机械，是把所有注册的子应用都缓存，实际可能不需要，qiankun 就比较灵活可以根据需要手动缓存等；
链接跳转，指的是点击一个菜单，跳转到另一个页面。这种方式不符合 “一站式 ”大数据平台产品定位；
通过几种实现方式的对比，最终决定以 qiankun 微前端为基础，结合我们的实际业务场景，通过权限菜单树 和 子项目关联来实现基座对子项目的调度，具体方案请参照 三，基座技术方案详细描述；
跨子项目跳转
指的是子项目没通过基座自行跳转，基座此时需要根据 url 匹配正确的基座显示；
触发节点
点击菜单，菜单对应的节点即为触发节点，跨子项目跳转（刷新页面）没有触发节点，以跳转后url 对应的页面节点为触发节点；
页面节点
权限菜单树中，挂载了子项目页面的节点
门户节点
狭义指的是，当前页面节点对应的公共子菜单父级节点；广义指的是通过页面节点向父系节点查询，最终确认公共子菜单、基座边栏的显示，并通过页面节点确定菜单高亮等行为；
第一子系节点
指的是在由触发节点查页面节点时，只关注子节点中的第一个，如果当前节点的第一个节点不是页面节点，继续在孙子节点的第一个，直到节点类型为页面节点为止；
调度引擎
指的是在基座中，对权限树数据处理，接收基座业务层调度，通过对权限树遍历、查询操作对业务层输出运算结果的一个抽象分层；
如图3 为基座技术方案的整体流程图，下面详细介绍
图 3
•如图 3 所示，首先会在权限中心配置权限菜单树，权限菜单树有很多级，比如一级平台，二级平台，二级平台一级菜单，二级菜单等，三级菜单等；
•然后需要在菜单树上，挂在子项目的页面，子项目页面的一些权限按钮等；
•最后权限中心对不同的用户赋予权限菜单树的子集；
•基座从接口拿到权限菜单树关联页面数据后，触发调度引擎初始化、并把基座的业务更新函数传给调度引擎；
•基座获取到菜单树以后，广度优先算法（如图4）遍历整个树结构，并建立节点间父子关联关系。根据节点是否挂载了子项目页面定义前端节点类型 ；最终形成图 5 的数据；
•在树遍历过程中，会统一在基座左侧边栏这一层级的节点，做一个门户节点的标记；
图4
•如图 5 所示，前端调度关系中，把权限菜单树分成 两种节点类型，挂载了子项目页面的节点，定义为页面节点。另一种没挂载子项目页面的节点，定义为分组节点；在基座调度中，不关心权限按钮节点，在数据处理中，页面节点就是整个权限菜单树的叶子节点；
图 5
•点击基座边栏，触发点击菜单流程，点击的节点即为 “触发节点”；
•由触发节点，向第一子系节点查页面节点，查页面节点同时，会同时匹配门户节点；
•没有匹配到门户节点，由触发节点向父系节点匹配门户节点；
•这时没有直接的触发节点，只能通过 url 上的标识和菜单树上的页面节点进行匹配
•匹配到页面节点以后，由页面节点向父系节点查门户节点；
•这里的运算结果主要包含：基座左侧边栏、公共子菜单菜单树列表、菜单高亮、产品平台名称等一系列基座需要正确显示所需要的数据；
•基座调度引擎，根据触发调度的类型；如果是点击菜单触发会执行 切换页面操作，刷新和跨子项目跳转则不需要触发；
•基座调度引擎，在接收基座业务层调度指令后，通过对图 5 权限树的遍历、查询操作，最终获取运算结果；
• 调用基座业务层的更新函数，执行运算结果，到此基座调度流程结束；
•基座业务层主要包含：左侧边栏、顶部边栏、顶级平台菜单等 UI显示；
•基座调度层，以 qiankun 微前端为基础，丰富扩展了权限树数据处理、调度运算、双向通信、子项目分组分步预加载策略等；
•基座在执行主题切换时候，通过 qiankun 的 setGlobalState 通知子项目；子项目在绑定项目空间等特定需求时，通过调度引擎封装的 eventCenter 和基座反向通信；
•跨子项目跳转，子项目会自行触发 pushState，点击基座菜单跳转流程，由调度引擎触发 pushState 触达
• qiankun 的 pushSate 劫持策略，触发 popstate 子项目页面因此触发更新；
图 6
基座调度引擎通过监听 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"
);
js 沙箱利用 qiankun 沙箱机制；
css 沙箱，qiankun 的 css 沙箱不健全；我们接入的又是老项目，目前的策略是 ：
•基座通过特殊命名空间 .susceptor、element-ui 通过 .spr 跟子项目隔离；
•子项目通过特殊命名空间，例如 .datacenter-xxx 跟基座隔离
•子项目对 .el- 不执行隔离，目的是为了统一控制布局、主题，同时做性能优化；
基座和子项目，属于典型的主从结构，采用单向数据流通信；为了满足特殊场景子项目跟基座通信需求，在 qiankun 的通信基础上，封装了 eventCenter 仅用于 子项目 跟基座通信；
•基座 -> 子项目，通过qiankun 的 onGlobalStateChange 通信
•子项目 -> 基座，通过 subActions 封装的 eventCenter 通信
目前标品基座已经加载了 30多个前端子项目，这么多前端子项目在首个子项目挂载后执行预加载，有可能会阻塞正常页面访问；
分组指的是，通过产品划定的平台，只有切换到当前平台才会加载到当前平台的子项目；
分步指的是，当前平台子项目过多时，一次预加载少量子项目，分多次预加载；
动态指的是，基座在首个子项目挂载后，会检测网速，只有网速良好时才会执行预加载；
跨子项目跳转的背景在于 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
})();
}
由于微前端的技术形态，子项目在基座中加载实质是基座容器的 一段 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 ；
本节提供两个图， 对上文介绍的微前端实践，有进一步的能力提升，有感兴趣的同学欢迎一起讨论；
如图 6 所示，配置流程：配置权限菜单树，然后配置子项目-子项目页面两级；最后把权限菜单树 和 子项目-子项目页面关联起来，形成如图 7 的权限树-子项目关联数据模型；
基座两个调度流程，跟上文类似，但是多了子项目维度，基座在加载子项目的时候，就可以把子项目 在权限树的 权限按钮信息全部给到子项目；
图 6
上文介绍的基座调度流程是简化后的版本，项目节点只有 分组节点、页面节点；但是从能力层缺失了 子项目维度；在设计之初，如图 7 所示：项目节点包含了 分组节点、子项目节点、子项目页面节点、页面节点 4种节点类型；
图 7