作者：京东科技 陈云飞
一，需要背景
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