关于数据中台:数据中台商业化数据中台微前端实践

4次阅读

共计 5951 个字符,预计需要花费 15 分钟才能阅读完成。

作者:京东科技 陈云飞

一,需要背景

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

正文完
 0