作者：京东物流 李武勇

背景概括：

供应链大屏做为物流的核心报表，为管理者提供大促决策时的依据。页面指标超过 170+，依赖接口 30+，复杂度较高，数据链路较长，同时稳定性要求高。

本文将分享供应链大屏是如何保障双 11 供应链大屏的稳定性。

一，供应链大屏全链路流程图

保障的首要步骤是绘制供应链大屏全链路流程图。在梳理出概览图之后，深入指标加工的各个细节去发现问题，然后是因地制宜的制定保障方案。

下边是梳理的供应链大屏加工的全流程图，图中标注了各个风险点的保障方案。

二，供应链大屏风险点梳理

在有了加工全链路之后，按照从左到右、从上往下的思路分析各个流程节点的薄弱点。

大屏加工按照分层的概念，从左到右依次是数据接入层、指标加工层、指标存储层、指标服务层。

下边是各个模块保障的风险点：

1，数据接入层：

◦加工链路长：从数据产生到指标加工完成，经过了报表库、多层蜂巢任务、多层 JDQ、多层 Flink 任务、DTS、CK、Easydata

◦涉及依赖方多：依赖大件、服务、逆向、B2B、LDC、冷链、实时数据团队

◦涉及接入类型多：离线 Hive、jsf 接口、http 接口、业务导入、CK

2，指标加工层：

◦指标存在多种维度，指标计算有先后顺序

◦外部依赖无法保证 100%，数据加工需要有重算功能，需要一定的容错性及故障自动恢复功能

◦业务促销策略需要灵活调整（促销策略受友商影响，需支持随时调整）

3，指标存储层：

◦多业务互相影响

◦指标异常需要快速定位

4，指标服务层：

◦需要保障接口稳定性

◦外部依赖接口需要可降级

◦外部依赖接口需要有兜底

◦多个业务服务如何隔离

5，监控管理：

◦指标加工如何监控

◦加工链路异常如何快速定位

三，技术上的保障策略

1，数据接入层

1.1，加工链路长

1.1.1，全链路确定边界，边界一定要是清晰的，整个大屏按照责任方拆分为 4 个区域：

•蜂巢部分：蜂巢团队保障

•实时加工任务：实时数据团队保障

•各个接口提供方：各个接口方保障

•大屏加工及查询部分：SCM 保障（自己小组负责）

1.1.2，要求各依赖方及接口做高可用

•蜂巢：蜂巢保障高可用、蜂巢报警、蜂巢监控、蜂巢压测

•实时加工任务：加工任务双流保障、FLINK 加工链路压测

•各个接口提供方：确定接口保障范围及接口 SLA

1.1.3，监控前置

蜂巢、实时 FLINK 任务都加上了 SCM 研发，数据积压作为下游也能提前知晓，同时也是对上游监控的一个补充

具体信息见第三节第 5 项“监控管理”

1.2，涉及依赖方多

梳理出所有依赖接口，与各依赖方确定 SLA，下边是部分接口示例：

1.3，涉及接入类型多

按照各种类型指定相应措施：

•离线 Hive：与离线确定大促重保任务、离线任务监控、烽火台增加离线推数据表的监控

•业务导入：协助业务做大促数据校验、页面开发大促双 11 导入数据模拟（见四节）

•外部 JSF、HTTP 接口：监控、重试、降级、兜底

2，指标加工层

2.1，指标存在多种维度，指标计算有先后顺序

指标加工分层，按维度拆分不同的表（单仓指标、区域指标），按功能作用拆分表（分钟表、小时表、缓存表、历史表）

2.2，重算、容错及快速恢复

外部依赖无法保证 100%，数据加工需要有重算功能，需要一定的容错性及故障快速恢复功能

加工容错：对外部每个接口做通用降级方案，接口异常取最近 30min 内上一次结果

快速恢复方案：提前设计容错方案，保障在单个或多个外部接口异常时，能快速重算指标并恢复

2.3，业务促销策略需要灵活调整（促销策略受友商影响，需支持随时调整）

抽象出业务策略，通过 DUCC 灵活配置调整

{    "sTime": "2024-11-xx 00:00:00"， // 大屏策略时间开始    "eTime": "2024-11-xx 19:59:59"， // 大屏策略时间结束    "tbSTime": "2023-11-xx 00:00:00"， //同比开始    "tbETime": "2023-11-xx 19:59:59"，//同比结束    "hbSTime": "2024-06-xx 00:00:00"，//环比开始    "hbETime": "2024-06-xx 19:59:59"，//环比结束    "showType": "24h"，//类型，24h同20h小时，都可以    "special24hCompDateStr": "2024-11-xx"，//大促24h特殊对比日期，（4h，28h不使用） 主要影响预测；主要用作非 4h/28h 的预测不使用昨日了；    "specialCompDateStr": ""       //大促4h/28h预测对比天数}

2.4，大屏加工及查询部分

指标缓存：使用 redis 缓存指标

接口压测：forcebot 按预估量压测

链路双流：

下边是 SCM 指标加工查询 CK 的一键主备切换功能，在收到报警时可以快速切换查询链路

3，指标存储层

3.1，多业务互相影响

3.1.1，根据业务，Mysql 采用一主三从的方式，数据库划分为：

主库、大屏查询、核心看板查询、其它报表

3.1.2，根据服务划分，大屏及核心报表存储 Mysql，easybi 报表使用 Doris（Doris 数据由 Mysql binlog 异步同步）

3.2，指标异常需要快速定位

3.2.1，打标字段存储为 json

根据 sql 从 json 里边过滤

3.2.2，mysql 数据通过 binlog 异步存储到 Doris（Doris 支持更长时间数据）

4，指标服务层

4.1，需要保障接口稳定性

•压测

•底层存储隔离

•业务隔离

4.2，需要可降级

外部接口单次异常，取当前促销策略内，最近 30min 的上一次成功数据

4.3，需要有兜底

预测时异常品类的兜底策略，保障数据不会异常

5，监控管理

总结为 2 个点：

1，监控前置：尽可能监控前置，提前感知上游异常，提前采取保障措施

2，监控全面：尽可能能覆盖所有环节；加工环节、查询环节、推数据环节、数据准确性环节

5.1，蜂巢：报警增加 SCM 研发，研发监控前置

下边是我们收到上游蜂巢的报警，以及积压恢复告警

5.2，实时加工

5.2.1，报警增加 SCM 研发，研发监控前置

下边是我们收到的实时 JDQ 报警

5.2.2，我们维护了一份实时任务的 JDQ 层级列表，我们也能快速定位具体积压点

图 1 是实时加工链路，红色箭头从我们开始，箭头指向更远端上游。

图 2 是我们维护的 JDQ 对应的上级各个速查监控 url，红色箭头从我们开始，箭头指向更远端上游的表。

5.3，SCM 加工监控全域看板（依赖方接口可用率、自己方法可用率、是否调用）：

5.4，SCM 接口查询监控全域看板：

5.5，SCM 指标数据准确性监控：

主要使用烽火台，监控数据是否重复写入，数据量级是否合理以及依赖数据是否具备

四，其它流程上的保障策略

1，沟通协同，建立大屏大促保障沟通群

由于涉及众多依赖方，大促沟通保障群建立了一条高效快捷的沟通机制

2，依赖方全链路演练

每年两次大促间隔时间长，各系统负责研发可能会变化，研发人员配置也可能会生疏。组织大屏全链路预发演练，一方面各系统人员都建立起沟通，另一方面提前熟悉配置，也校验了配置策略的正确性。

另外大屏大促需求都临近大促，各个系统方都有变化，这些变化基本都是大促特殊策略设置平时也验证不了，全链路对特殊的策略下的演练，也能提前发现功能的一些隐藏问题。

3，与业务联动、业务导入提前模拟校验

3.1，针对大屏用到的历史同环比数据，聚合到各个维度，拉着业务去确认数据的准确性

针对业务导入数据：通过策略修改及 mock 日期配置，业务可以在预发环境看到提前导入的双 11 数据在大屏的展示，保障业务导入数据的准确性。下方展示了跟业务联动，测试各个策略时间段下各个条线的业务数据准确性。

3.2，策略配置双人 double check，历史问题归纳总结为 check SOP

4，结果第一

结果第一，是我们保障大屏的方向指导，所以我们不光着眼于我们自己的系统，还从全流程上不断地去找方法、找薄弱点，去保障大屏的稳定性、数据的准确性，更好地服务于业务。

结果第一，也是每次大促我们催着业务导数，而不是业务有问题了找我们然后才解决。业务说省区的都不着急为啥你们研发着急，不导入是省区的问题又不是你们研发的问题。对于这个问题，我是这么回复业务“我们的目标是双 11 大屏的稳定与准确，而不是说是因为谁的问题导致的大屏数据异常”，这是我对结果第一的理解，这也是我认为我们团队能做好大屏保障的根本原因。

5，团队的力量

双十一大屏保障的好，并不是一个人的努力，而是团队内每个人的齐心协力，以及上下游的同事共同协作支持才达成的。我深知一个人的力量终究是有限的，但团队的力量可以创造无限的可能。