Tech 导读 本文基于JDV平台在大促中的各种业务场景，讲解过程中使用情况和技术挑战，通过采取相应的技术创新、技术保障确保系统稳定性，推动数据可视化编排能力在大屏业务场景中发挥更大的价值
01
项目介绍
在今年的敏捷团队建设中，我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢？由此我的Runner探索之旅开始了！
JDV（可视化大屏）是京东内部搭建可视化大屏的数据工具平台，内置10 种模版特效，40 种风格各异的图表、导航等组件。与集团其他数据工具打通，支持一站式、自助化、拖拽式搭建大屏，实现数据切换、联动刷新、大屏下钻等呈现效果，便利高管、采销、产研等全集团范围内的数据可视化诉求。在大促期间京东视界大屏项目，主要服务作战指挥、庆功会、公关场景，实现在大促期间实时数据监控分析，并基于大屏数据进行决策和总结，同时在公关场景下实现对外部媒体、政府、外部企业领导参观，协助公关部对外宣传公司的良好形象。
02
项目挑战
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。
JDV作为视化大屏搭建平台，平台主要由可视化编排和后端服务组成，由于大屏在页面中渲染后会通过指定刷新频率主动获取数据，每次在页面中渲染后就是一个独立运行实例，系统具体架构如下图所示。
图1.系统具体架构示意
- 基于可视化大屏特点，为了解决大屏在使用过程中能够满足秒级更新、跨0点停数、指标数据快速调整、数据高稳定性、备用屏秒级切换等业务场景需要JDV平台能够足够灵活，具体场景细节如下：
- 数据秒级更新：秒级数据刷新对底层数据服务压力较大，我们使用请求隔离、限流等技术手段对大屏请求实现高可用保障，实现全链路读写真实场景多次高保真压测提前发现并解决链路性能问题，并针对QPS高峰等有足够预案处理。
- 跨0点停数：针对周期累计的数据来讲处于临界点也是突变点，0点过后数据接口会重新开始新周期累计，我们必须在多服务多机房多容器存在系统时间偏差场景中精准停数。
- 数据快速调整：在大促期间经常需要根据业务看数需求紧急快速调整，当前基于我们PaaS大屏搭建方案，能保证90%以上需求调整能在分钟内调整完并交付使用。
- 数据高稳定性：大屏一般会投放在高管作战指挥室、各业务线指挥室等，我们要以高质量交付，方便业务基于实时数据调整，避免跳数、刷新异常等问题影响业务看数，从而错过最佳决策时间。
- 备用大屏切换：在搭建大屏过程需要考虑线上和线下大屏使用过程中出现的问题情况，所有在搭建大屏过程除了需要搭建预估场景下使用的大屏外，还需要搭建部分备用屏及拖底屏，确保在大促期间所有大屏的使用都万无一失。
基于以上大屏在大促期间使用场景，本次618大促期间相关挑战也是非常大，主要在大屏搭建量大、使用场景复杂多变、时间紧任务重等方面，具体如下：
- 大屏搭建量大：在大促期间需要搭建大屏数据较多，过程中还需要根据大促场景随时增加大屏数量，大促期间共搭建了80 张大屏，搭建大屏过程中由于大屏涉及相关人员较多，在大促期间沟通成本巨大，从4月底开始陆续评审需求后，5月初就需要完成作战指挥大屏配合全链路压测，京东视界和公关屏逐步进行搭建，过程中大屏需求须随时响应调整。
- 场景复杂多变：大促期间主要分为作战指挥、庆功会、公关大屏3类大屏，每类大屏又涉及各种使用场景，在本次大促过程中开门红后大屏还紧急支持了28H大屏跨0点停数、615高潮期累计、28H实时订单累计、618晚宴等场景。
- 时间紧任务重：大屏搭建整体时间范围在1个月左右，需要完成与业务方沟通确认细节、完成三方接口和三方屏人员质量把控以及完善平台不同场景相关预案并确认预案操作人等事项，预案涉及跨0点停数、制定大屏限流、代理数据源管控、双流切换、线下断网停数、设备切换等不同场景下团队联动演练。
03
技术创新
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。
基于JDV平台在大促期间的重要性及上面提到的各种挑战，在大促前期3月底就已梳理规划对平台进行大促技改事项，主要目的是提升大屏在复用性、实时监控、请求链路合理性、QPS管控等方向能力建设，下面将重点介绍平台在请求状态控制和实时监控方向的思考及技术方案。
3.1 请求状态管控
背景：定时刷新和数据秒级更新是大屏的一个重要能力，大屏编排过程中能够灵活指定数据刷新间隔，当开屏的数量增加都会提升底层数据服务QPS压力，考虑到大屏定时发送请求的特殊性，可以通过控制页面数据请求轮询机制，来避免用户未看大屏情况下定时请求问题。
方案：在该场景下需要通过实现大屏状态识别能力来控制大屏是否定时发送请求，当页面不在当前窗口、页面隐藏、窗口最小化等非活跃状态时，识别页面渲染实例状态动态控制对服务端发送请求机制，通过该方案在一定程度上降低大屏对数据服务QPS压力。
3.2 大屏实例监控
背景：JDV平台是基于编排能力搭建大屏，在系统监控上除了需要接入各种泰山平台监控功能外，同时也要解决降低相同大屏请求QPS、确保不同用户在相同时刻访问的数据一致。为了解决该场景，JDV后端服务采用代理数据源获取数据方式，为了确保数据请求准确无误需要对大屏渲染实例进行实时监控，实时了解用户使用大屏情况、不同用户同时打开大屏数量、对数据服务QPS请求压力等数据的呈现，基于大屏实时使用情况决定是否需要采取预案处理。
图2.心跳上报流程
方案：基于以上大屏使用场景，对大屏渲染实例的实时监控将是非常非常重要功能，为了方便基于大屏实时监控进行异常预案决策，在本次618大促前我们已增加了大屏实时监控能力，该功能也被团队内部认为是监控能力细化的升级版。具体方案流程如“心跳上报流程”图所示，对实例监控的思路主要是基于socket长连接心跳机制（它像心跳一样每隔固定时间发送一次，以此来告诉服务器当前客户端还活着）的借鉴，基于socket心跳上报机制和JDV大屏项目的使用场景通过在页面前端收集用户账号、版本号、IP地址、大屏ID编码、大屏实例ID、大屏交互参数、访问端标识等信息，大屏前端组件将相应心跳上报参数统一进行维护，在指定的上报时间后将会进行心跳上报，同时服务端接收到心跳信息后与代理数据源任务进行关联实时维护任务的存活状态。
图3.
基于心跳上报数据为基础，将心跳上报日志信息进行分析汇总实时掌握每张大屏当前的开屏用户数、开屏实例数、开屏实例数与预估峰值占比、任务创建等信息，具体效果如“实时监控与预案联动效果”图所示，并基于每张大屏异常情况决策是否需要进行预案联动处理。
04
技术保障
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目
JDV平台为了应对各种业务场景，除了上面提到的技术创新方面来保障系统质量外，还在大屏视频录制、编排辅助工具、跳数停止更新、跨0点精准停数、代理数据源任务等方面分别辅助编排提效以及系统质量保障，具体细节如下：
4.1 大屏视频录制
背景：JDV 京东视界场景中跨0点停数及倒计时功能在线下场景使用，即便我们已经进行了相对完备的解决方案，但还需要每次等到凌晨进行功能验证，将极大消耗团队成员时间和精力。
方案：为更好的对停数和倒计时功能进行验证，通过指定大屏访问链接和时间创建录制任务，设计出 JDV 录屏功能。当任务到达指定时间后将进行大屏录制，并将录制的视频保存储到OSS，这样就可以实现对指定时间的大屏进行录制。在这套录制系统的配置下，我们通过视频回放进行功能测试和验证，确保了大屏停数和倒计时功能准确性，极大减少了成员时间和精力的消耗，保障了618庆功宴停数场景的顺利完成。
4.2 编排辅助工具
背景：JDV京东视界场景中需求变化频繁，需要对大屏内容进行相应的调整，而且需要保证极快的响应，在极端场景下还需要对大屏布局进行重构，由于大量编排配置调整后需要快速进行交付使用，所以需要解决需求修改后能高效确认配置的正确性，避免修改错误影响正常使用。
方案：为减少重复工作提高响应效率，我们开发出一些工具提高在大屏编排过程中的工作效率，具体如下：
1.JDV-Relay 浏览器插件，实现一键复制 Relay 元素尺寸、位置、样式、属性等配置信息，可以直接将其粘贴到大屏中，可以一键粘贴完成配置，将之前10多项的配置节省到一次复制粘贴中，极大减少了配置的时间，提高了搭屏的效率。
2.JDV 批量组件修改功能，可以搜索大屏中匹配的组件，并进行统一的修改，可一次修改批量同步操作相关组件需求变更。
3.JDV DIFF工具，在大屏搭建过程中为保障配置的正确性，建立了更改通知机制，一旦发布后的大屏需要修改，将采用DIFF工具对新旧版本的配置进行比对，并针对改动内容标记凸显出来，快速识别其中改动内容确保改动的正确性。
4.3 跳数停止更新
背景：因为大屏数据秒级刷新，在当前使用场景和分布式微服务场景下，任何跨时间周期、服务或网络抖动等问题在大屏上都能被用户感知影响系统稳定性，造成用户体验差数据不准确等问题。
方案：JDV采用未获取新数据不更新数据机制，利用该机制解决偶发性抖动造成跳数问题，确保JDV大促依赖的10多个团队几十个数据接口整个链路服务返回统一状态码，通过对错误或异常状态返回状态码进行区分，实现对数据是否更新准确控制。
4.4 跨0点精准停数
背景：大屏展示某个累计周期统计数据，在线下庆功会场景需要在周期结束最后一秒进行停数。大屏涉及零售、科技、物流等集团多业务线几十数据接口方，接口实现逻辑、接口协议、部署方式等都不统一，并且系统时间理论上不能保证百分之百无差异，如果不能精确停数会导致数据变小、跳0等突变情况，如果停数异常将造成重大事故。
方案：停数问题核心就是精准和稳定平衡关系，精准主要指数据是否能无限接近获取最后一秒真实值，稳定是指能不能100%停到下个累计周期开始之前。因为最后一秒是临界点也是突变点，我们通过监控系统时间偏差和各接口TP99，经过多次演练和测试验证，最终设定一个毫秒级兼顾精准和停数稳定的时间点。
4.5 代理数据源任务
背景：大屏秒级刷新机制，是前端组件定时固定间隔发起批量数据请求，这个机制情况下会随着开屏数量增加，对底层数据服务请求QPS线性增长。
方案：通过分析发现大多数大屏请求具有共性，不同人打开同一个屏，看到往往是同一份数据。基于这个特性，实现了代理数据源功能，对不同人开屏请求进行合并，在后台生成一个查询任务定时获取数据，将数据写入缓存，大屏直接查询缓存中的数据，从而避免多个相同请求对DB或底层数据服务造成查询压力。
05
总结&反思
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目
基于本次618大促JDV平台支持大促过程中的表现，共从大促总结、能力沉淀、待提升项3个方向也进行了相应总结和反思。
5.1 大促总结
针对这次大屏在大促期间能快速响应完美支持大促场景，通过提前识别大促技改、系统多场景预案、技术方案上的创新、ISV人员介入、真实场景演练以及底层PaaS化和配置化能力快速响应紧急需求等密切相关。在大促前能提前规划和识别出根本问题，遇到难点能够通过采用创新方案，精准识别出技改功能点，在系统保障机制等方面起到了非常关键的作用。具体细节如下：
- 识别大促技改：主要在大促前期研发已经识别出历来大促过程中的痛点，通过对大屏组件升级、QPS请求管控、代理数据源任务实时管控等功能上的优化调整，全面提升大屏搭建效率和降低对底层的访问压力，提升系统健壮性及扩展能力。
- 多场景预案：为保障大屏满足各场景下都能稳定运行，基于用户访问限制、跨0点停数、数据双流切换、断网停数、大屏管控切换、视界硬件设备切换等都有相应操作预案，并针对作战指挥、京东视界、公关大屏场景进行停数和预案演练，同时在跨0点特殊场景下，借助录屏工具定时执行实现对跨夜节点场景上对人力资源的释放，提升开发及备战效率。
- 技术创新方向：过去大屏只有系统层级上的监控能力，对用户实时访问大屏情况不能及时进行监控，考虑到大屏项目的重要性及配置化的特殊性，本次大促对大屏设计了心跳上报的能力，通过大屏心跳检测实时掌握用户访问大屏情况以及系统压力，并结合相关预案出现异常情况快速进行操作。
- 高效响应需求：大屏搭建前提前识别大屏搭建工作量巨大而公关屏数量占了一半以上，为解决大量公关屏搭建工作本次公关屏通过数据脱敏组织人员培训引入3个ISV人员主导进行公关屏的搭建，高效解决大屏搭建效率。同时大促过程中借助大屏强大的配置化和底层PaaS化搭建大屏能力，每次有紧急需求都能快速支持，过程中共支持了28H大屏跨0点停数、615高潮期累计、28H实时订单累计、618晚宴等场景需求，为公司高层在大促期间快速决策起到保驾护航的作用。
5.2 能力沉淀
基于本次大促过程遇到的问题共性及能力复用的思考，JDV平台项目中相关功能也能进行复用，以下功能将实现项目赋能提升其他项目的开发效率。
- 实例实时监控：本次大促增加的心跳上报和基于上报日志搭建大屏实时监控功能，刚好可以补齐目前我们系统中更精细化的实时监控能力，通过沉淀为可统一复用能力后方便我们基于用户实时监控进行异常预案联动确保大促稳定性保障。
- 代理数据源：对相同用户请求进行合并，在后台生成查询任务，以降低对依赖数据服务层的请求压力，从而避免由于用户量增加造成对数据服务和DB查询压力，避免触发底层限流等场景使用。
- 录屏任务服务：当系统需要跨0点停数、倒计时功能验证时，为确保在跨0点场景做到真实验证而又无需人员每次等到指定时间点，通过指定时间段自动录屏后续进行回放验证等方式，避免大促期间人员经常凌晨验证释放人员精力提升工作效率。
- 编排配置DIFF：随着开发提效的逐步实践各系统的编排配置能力也将逐步提升，在频繁的配置修改过程中，为保障配置的正确性，各自系统也将越来越需要配置变更通知机制，将配置DIFF工具能力形成复用，对新旧版本的配置进行 DIFF 比对，提升功能修改的高效验证也将变得越来越重要。
5.3 待提升项
同时在本次大促中JDV平台也存在不足需要在后续工作中逐步进行提升，主要体现在沟通成本高、标准规范统一等方面上，后续也将基于本次大促过程中遇到的问题逐步完成项目在更多方向的数字化能力建设。
- 沟通成本高：由于大促期间涉及各方向人员主要有业务方、产研测以及三方接口及三方大屏对应的产研等人员，期间大屏共涉及86张各团队配合过程中各种大小事都需要及时沟通确认，出现这些问题的原因都是由于需求变更调整没有统一在JDV平台数据化造成的，需要先收集到文档再由大屏搭建人员调整编排引发的，在这样的情况下需求调整越多沟通成本也就越高。后续将逐步规划抽取需求变更共性，当修改文案、数字等配置内容时相关业务方或产品能直接在JDV平台进行录入调整，调整后又能立马查看效果实现大屏编排中期也能可见即可得能力。
- 标准规范统一：为降低大屏搭建过程中出问题概率和提升沟通效率，涉及各方依赖项在性能要求、压测文档、停数控制、信息收集反馈等方向上都需要更加的规范，目前各方接口人输出结果时间及要求让JDV大屏多团队协作方向上也能沉淀出一套完整模版，甚至在每次大促过程中各接口人和研发等角色都能收到各自需要完成事项的XBP流程，按照流程标准输出待办事项等。
最后平台发展也希望有更多的建议，大家如果在系统编排等方向上有更好的思路和建议，也可以联系作者让JDV发挥更大的价值！
