一种基于服务编排数据血缘的API自动生成与路由方法与流程

本发明涉及软件，尤其指一种基于服务编排数据血缘的api自动生成与路由方法。

背景技术：

1、企业数据规模持续扩张，数据呈现多源、异构、实时离线混合部署特点，hive、clickhouse、kafka、对象存储等多数据源并行使用；下游bi、ai、微服务、第三方服务商均需要统一标准化api对外提供数据服务，同时对接口延迟、数据质量、租户差异化sla管控提出严苛要求。

2、行业传统模式为按数据源独立开发api、人工维护接口文档，人力成本高、迭代效率低。上游数据表结构调整、数据延迟波动、数据质量下降时，下游接口极易出现调用中断、数据错误、链路卡顿等线上故障。

3、现有成熟方案仅能实现基础数据血缘采集可视化、简单多租户路由分流、基础接口版本回滚、人工维护接口文档等基础能力。现有技术存在三大根本性短板：

4、路由策略仅依靠url、请求头、租户标识等静态维度判定，无法结合数据自身质量、延迟状态动态调度；

5、数据血缘仅作为事后观测工具，与网关路由、接口版本系统完全割裂，无法主动驱动系统自适应调整；

6、接口、路由、数据血缘三者版本相互独立，仅能单独回滚代码或配置，无法同步还原历史完整数据链路状态。

7、现有申请公布号cn109561226a于2019年4月2日公开的一种api混合多租户路由方法、系统和api网关。其技术方案中仍存在以下缺陷：

8、其一，路由决策维度单一，缺乏数据状态感知能力。对比文件2仅依据appkey、租户id等静态身份标识，通过预配置的路由策略表进行映射和负载均衡。该机制完全依赖租户类型和预设权重，无法感知上游数据源的实际质量状态。当数据源出现异常或降级时，网关仍将请求盲目路由至对应api实例，导致下游接口调用失败或返回错误数据，故障无法在路由层主动规避。

9、其二，数据血缘与网关路由完全割裂，无法形成闭环治理。现有网关不具备数据血缘采集与关联能力，路由决策与数据流转链路相互独立。当上游表结构变更、数据质量下降或延迟飙升时，运维人员需人工排查血缘平台、日志系统和网关配置，定位周期长。更无法实现“血缘状态变化→网关动态调整路由权重/熔断/降级”的自适应闭环，系统弹性严重不足。

10、其三，接口、路由策略与数据版本三者独立演进，缺乏一致性回滚机制。对比文件2仅支持api运行实例url的静态映射，未涉及接口定义版本、路由策略版本与数据表结构版本的关联管理。当上游数据表发生不兼容变更时，仅回滚接口代码或路由配置无法恢复完整的数据链路状态，因为数据版本与路由规则、接口逻辑之间存在时间戳错位，导致历史状态无法精准还原，回滚操作不彻底，极易引发二次故障。

技术实现思路

1、为了解决现有技术的不足，本发明公开了一种基于服务编排数据血缘的api自动生成与路由方法，包括：

2、s1：通过元数据采集器捕获数据源的元数据变更事件，将所述元数据变更事件封装为标准化事件并推送至预设的血缘事件主题；所述标准化事件中内置有数据质量字段和数据延迟时间戳字段；

3、其中，标准化事件为标准化avro事件。

4、s2：路由引擎从所述血缘事件主题中实时读取每条数据链路的所述数据质量和所述数据延迟时间戳，根据所述数据质量和所述数据延迟时间戳对api访问链路进行动态调度；

5、s3：所述路由引擎主动订阅所述血缘事件主题，当捕获到所述元数据变更事件时，自动重算对应租户的专属路由dsl以生成新路由表，并通过配置热更新将所述新路由表热加载至网关；

6、其中配置热更新具体为configmap滚动更新。

7、s4：当api接口定义、动态路由策略或血缘图谱快照发生变更时，生成包含api版本标识、路由策略版本标识和血缘快照标识的唯一三元组标识，将所述唯一三元组标识对应的三元组数据作为原子版本进行关联存储；当接收到回滚指令时，根据所述唯一三元组标识同步还原对应的历史api接口定义、历史动态路由策略和历史血缘图谱快照。

8、本方法通过将数据血缘从被动观测工具升级为主动决策触发器，打通了血缘系统与网关之间的割裂壁垒，实现了上游数据变更时网关路由的毫秒级自动适配与零停机自愈；同时通过三元组原子绑定机制，将接口、路由、血缘三者统一为不可拆分的版本单元，解决了传统方案中分步回滚导致接口持续失效的历史难题，显著提升了系统自动化运维能力和故障恢复效率。

9、可选的，所述数据质量用于表征所述数据链路中数据资产的健康程度；

10、所述数据延迟时间戳用于表征所述数据链路的数据时效性；

11、所述动态路由决策步骤具体包括：

12、将所述数据质量与预设质量阈值进行比较，将所述数据延迟时间戳与预设延迟阈值进行比较，以判定每条数据链路的健康状态。

13、本方案通过将数据质量和延迟时间戳量化为可比较的路由判定基准，使路由引擎能够精准量化每条数据链路的实时健康状态，为后续动态调度提供客观、可量化的决策依据，克服了传统方案仅依赖静态参数无法感知底层数据真实质量的缺陷。

14、可选的，所述动态路由决策步骤还包括：当所述数据质量低于所述预设质量阈值或所述数据延迟时间戳超过所述预设延迟阈值的劣化链路，降低所述劣化链路的流量权重，并将业务流量切换至健康备用链路。

15、本方案通过自动识别劣化链路并将其降权或隔离，从根源上杜绝了“慢数据”和低质量数据占用业务流量的情况，显著降低了全链路业务延迟波动幅度，保障了高优先级租户的sla稳定性，大幅减少了因数据劣化引发的业务投诉。

16、可选的，在步骤s2中，

17、当数据质量大于第一阈值或数据延迟时间戳小于第二阈值时，血缘事件订阅频率不大于第一频率；

18、当数据质量小于第三阈值或数据延迟时间戳大于第四阈值时，血缘时间订阅频率不小于第二频率；

19、当数据质量小于等于第一阈值且大于等于第二阈值且数据延迟时间戳小于等于第二阈值且大于等于第四阈值时，血缘时间订阅频率小于第一频率且大于第二频率。

20、具体的，

21、当数据质量大于第一阈值或数据延迟时间戳小于200ms时，血缘事件订阅频率不大于30s/次；

22、当数据质量小于第三阈值或数据延迟时间戳大于800ms时，血缘时间订阅频率不小于1s/次；

23、当数据质量小于等于第一阈值且大于等于第二阈值且数据延迟时间戳小于等于800ms且大于等于200ms时，血缘时间订阅频率小于30s/次且大于1s/次。

24、所述第一阈值和所述第三阈值具体分别为数据质量评分90分和60分。

25、所述数据质量评分为0~100分区间综合加权得分，由数据完整性、数据准确性、数据唯一性、数据时效性四项指标加权计算，单项指标满分25分，总分为四项分数之和；其中完整性统计字段缺失占比、准确性校验值域与主键冲突、唯一性统计重复数据比例、时效性结合链路延迟时间戳线性打分。基于总分划分三级链路健康等级：健康链路（评分＞90分）、亚健康链路（60分≤评分≤90分）、劣化故障链路（评分＜60分）。所述第一阈值和所述第三阈值具体分别为数据质量评分90分和60分。当数据质量小于等于第一阈值90分且大于等于第二阈值60分、且数据延迟时间戳小于等于800ms且大于等于200ms时，血缘事件订阅频率小于30s/次且大于1s/次。当数据质量评分＞90分（健康链路），血缘事件订阅频率固定为30s/次；当数据质量评分＜60分（劣化故障链路），血缘事件订阅频率固定为1s/次。

26、数据完整性指标（25分）

27、统计链路采样周期内非空字段占比，缺失率0%得25分，缺失率每提升4%扣1分；若关键字段存在空值，单次直接扣10分。

28、数据准确性指标（25分）

29、校验字段值域、格式、关联主键匹配度，异常数据占比0%得25分，每存在2%脏数据扣1分；存在跨表主键冲突直接判定单项0分。

30、数据唯一性指标（25分）

31、统计主键/唯一索引重复数据条数，无重复得25分，重复数据占比每提升5%扣1分。

32、数据时效性指标（25分）

33、结合链路延迟时间戳打分：链路延迟≤200ms得25分；200ms＜延迟≤800ms线性递减至10分；延迟＞800ms该项直接得0分。

34、总分计算公式：

35、数据质量评分=完整性得分+准确性得分+唯一性得分+时效性得分。

36、健康链路（评分＞90分）：四项指标均无明显异常，数据完整、低延迟；对应订阅频率固定30s/次，降低集群资源消耗。

37、亚健康链路（60分≤评分≤90分）：少量脏数据或中等延迟，无致命数据缺陷；对应订阅频率动态区间1~30s/次，随分数越低自动缩短轮询间隔。

38、劣化故障链路（评分＜60分）：存在大量脏数据、主键冲突或高延迟；对应订阅频率固定1s/次，实时捕获上游元数据变更，快速切换流量规避故障。

39、现有技术血缘事件订阅采用固定轮询频率，全天恒定消耗集群消息、计算资源；本方案基于链路健康度动态自适应调整订阅频次，日常稳定时段减少70%消息交互量，劣化故障时段响应速度提升90%，形成“动态调度-事件订阅”双向联动。

40、可选的，所述s3具体包括：

41、所述路由引擎作为消费者实时监听kafka集群中所述血缘事件主题的消息；

42、当解析出所述元数据变更事件涉及上游数据表的字段变更或分区变更时，触发针对受影响租户的路由dsl重算过程；

43、将重算生成的所述新路由表通过所述configmap滚动更新发布至api网关实例。

44、本方案通过路由引擎主动订阅血缘事件并自动触发路由重算与热加载，使上游表结构或分区变更后网关能够毫秒级自动适配，全程无需人工干预，实现了线上变更零停机，大幅减少了人工运维操作量，显著提升了系统的自动化运维能力。

45、可选的，所述唯一三元组标识的表达式为：

46、api_ver+strategy_ver+lineage_snapshot_id；

47、将所述唯一三元组标识对应的三元组数据作为原子版本进行关联存储具体包括：将所述api接口定义、所述动态路由策略和所述血缘图谱快照作为同一原子版本整体存储至图数据库及类git血缘仓库中。

48、本方案通过将接口、路由、血缘三方数据绑定为同一原子版本并存储于图数据库和类git仓库中，确保了每一次变更所对应的完整数据链路状态得以精确留存，为后续精准回滚提供了坚实的数据基础，彻底解决了传统方案中三者独立管理导致版本不一致的问题。

49、可选的，所述当接收到回滚指令时，根据所述唯一三元组标识同步还原对应的历史api接口定义、历史动态路由策略和历史血缘图谱快照。

50、具体包括：接收外部输入的血缘快照id；根据所述血缘快照id从所述图数据库或所述类git血缘仓库中调取匹配的唯一三元组标识；基于调取的所述唯一三元组标识同步执行：还原历史完整血缘图谱、热加载匹配的历史动态路由策略、同步恢复对应版本的历史api接口定义，以完成全链路复位。

51、本方案通过仅需输入血缘快照id即可一键触发三件事同步执行，实现了接口、路由、数据链路结构的全链路一键复位，将传统方案中长达2至4小时的故障恢复时间缩短至30秒以内，故障恢复效率提升95%以上，彻底规避了回滚后接口仍持续报错的问题。

52、可选的，对于唯一三元组标识设有存储压缩与生命周期回收机制，包括：

53、增量快照存储：唯一三元组标识仅存储变更增量数据，未变动的api版本标识、路由策略版本标识和血缘快照标识复用历史快照指针，不重复全量落地；

54、冷热分层存储：近n天访问频次大于第一频次唯一三元组标识存入内存图数据库，超过n天访问频次低于第一频次的历史版本自动迁移至低成本对象存储，超过n*12天的废弃快照自动清理。

55、具体的，在冷热分层存储中，近7天高频访问三元组存入内存图数据库，超过7天低频历史版本自动迁移至低成本对象存储，超过90天的废弃快照自动清理。

56、同等业务变更频次下，传统全量快照存储30天产生120gb数据；本增量分层存储方案30天仅产生18gb数据，存储容量降低85%，无海量存储膨胀风险。

57、可选的，还包括租户隔离与资源管控步骤：为各租户配置独立的专属路由dsl，每条路由规则内置tenant_id占位符。

58、此方案实现了租户间路由策略完全隔离；采用独立的缓存键隔离方案，缓存键格式为tenant:{id}:route:{hash}，避免缓存穿透和数据串读；为各租户配置独立的资源配额上限，防止单租户抢占公共资源。

59、进一步的，通过租户级独立dsl、缓存键隔离和资源配额管控的三重隔离机制，实现了多租户之间路由策略、缓存数据和计算资源的全面隔离，有效防止了高流量租户挤占其他租户算力和带宽资源，保障了低优先级业务的sla稳定性。

60、可选的，存储压缩与生命周期回收机制还包括租户隔离分库分片：按tenant_id做分片存储，单租户变更数据独立分区。

61、可选的，还包括自动化文档同步步骤：监听接口版本变更事件，生成openapi规范文档并推送至开发者门户，同时触发webhook消息通知，通知下游调用方接口变更信息。

62、本方案通过接口版本变更自动触发文档生成和推送，确保openapi文档与接口迭代实时同步，从根本上解决了人工维护文档滞后于代码迭代的问题，避免了开发人员因依据过期文档调用接口而导致的参数缺失和字段不匹配报错，提升了接口调用的成功率与开发协作效率。

63、本发明的有益效果：

64、1、毫秒级自动适配，路由引擎主动订阅血缘事件，上游数据变更后网关路由自动重算与热加载，全程零停机，彻底消除人工运维操作。

65、2、全链路一键精准回滚，通过api版本、路由策略、血缘图谱的三元组原子绑定，仅需输入血缘快照id即可同步还原三类数据，将故障恢复时间从2-4小时缩短至30秒以内，恢复效率提升95%以上，彻底解决传统分步回滚导致的接口持续失效问题。

66、3、多租户全面隔离，通过租户级独立dsl、缓存键隔离、资源配额管控三重机制，保障租户间路由策略、缓存数据与计算资源互不干扰，防止高流量租户抢占公共资源。此外，接口变更自动触发openapi文档生成与推送，确保文档与代码实时同步，避免因过期文档导致调用失败。