一种残膜回收机防缠绕挑膜装置的制 一种秧草收获机用电力驱动行走机构

数据处理的方法、平台、电子设备以及存储介质与流程

2022-09-03 15:42:31 来源:中国专利 TAG:


1.本技术涉及互联网领域,尤其涉及一种数据处理的方法、平台、电子设备以及存储介质。


背景技术:

2.目前,在互联网企业内部,需要多部门共同协作才能高效完成公司复杂业务。随着公司各部门微服务架构的不断落地,项目数量也出现大量的增长,这样也会带来一些问题:每个服务都需要管理很多其它部门系统(以下简称:三方系统)的api(application programminginterface,应用程序接口),当某些api的地址或者接口有变动时,工作人员需要排查所有的微服务项目。相同的api可能会被不同的项目同时使用,如图1,这样代码中会出现大量的冗余代码。
3.因此,相关技术存在项目代码中包含大量冗余内容的问题。


技术实现要素:

4.本技术提供了一种数据处理的方法、平台、电子设备以及存储介质,以至少解决相关技术中存在项目代码中包含大量冗余内容的问题。
5.根据本技术实施例的一个方面,提供了一种数据处理的方法,该方法包括:
6.获取第一业务数据,其中,所述第一业务数据为客户端发送的请求数据;
7.确定对所述第一业务数据待执行的目标数据处理操作;
8.根据所述目标数据处理操作,得到第二业务数据;
9.将所述第二业务数据发送至响应第三方。
10.根据本技术实施例的另一个方面,还提供了一种数据处理的平台,该平台包括:
11.获取模块,用于获取第一业务数据,其中,所述第一业务数据为客户端发送的请求数据;
12.第一确定模块,用于确定对所述第一业务数据待执行的目标数据处理操作;
13.得到模块,用于根据所述目标数据处理操作,得到第二业务数据;
14.第一发送模块,用于将所述第二业务数据发送至响应第三方。
15.根据本技术实施例的又一个方面,还提供了一种电子设备,包括处理器、通信接口、存储器和通信总线,其中,处理器、通信接口和存储器通过通信总线完成相互间的通信;其中,存储器,用于存储计算机程序;处理器,用于通过运行所述存储器上所存储的所述计算机程序来执行上述任一实施例中的方法步骤。
16.根据本技术实施例的又一个方面,还提供了一种计算机可读的存储介质,该存储介质中存储有计算机程序,其中,该计算机程序被设置为运行时执行上述任一实施例中的方法步骤。
17.在本技术实施例中,通过获取第一业务数据,其中,第一业务数据为客户端发送的请求数据;确定对第一业务数据待执行的目标数据处理操作;根据目标数据处理操作,得到
第二业务数据;将第二业务数据发送至响应第三方。由于本技术实施例设置一第三方系统接口管理平台,利用该第三方系统接口管理平台集中管理所有响应第三方系统api,减少了客户端业务系统配置和维护各种响应第三方系统的接口,同时利用第三方系统接口管理平台统一处理请求业务数据,可以有效减少了冗余代码,以及代码复杂度,进而解决了相关技术中存在的项目代码中包含大量冗余内容的问题。
附图说明
18.此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本发明的实施例,并与说明书一起用于解释本发明的原理。
19.为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,对于本领域普通技术人员而言,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
20.图1是相关技术的业务系统与响应第三方系统的api调用情况示意图;
21.图2是根据本技术实施例的一种可选的引入第三方系统接口管理平台后api调用情况示意图;
22.图3是根据本技术实施例的一种可选的数据处理的方法的整体设计方案示意图;
23.图4是根据本技术实施例的一种可选的路由转发处理方案示意图;
24.图5是根据本技术实施例的一种可选的接口异常重试方案示意图;
25.图6是根据本技术实施例的一种可选的数据模拟方案示意图;
26.图7是根据本技术实施例的一种可选的支持对响应第三方接口执行熔断机制示意图;
27.图8是根据本技术实施例的一种可选的异常告警方案示意图;
28.图9是根据本技术实施例的一种可选的异常告警界面示意图;
29.图10是根据本技术实施例的一种可选的对请求数据统计示意图;
30.图11是根据本技术实施例的一种可选的接口数据统计页面示意图;
31.图12是根据本技术实施例的一种可选的录入页面信息界面图;
32.图13是根据本技术实施例的一种可选的接口基本配置界面图;
33.图14是根据本技术实施例的一种可选的接口响应相关信息界面图;
34.图15是根据本技术实施例的一种可选的数据处理的方法的流程示意图;
35.图16是根据本技术实施例的一种可选的数据处理的平台结构框图;
36.图17是根据本技术实施例的一种可选的电子设备的结构框图。
具体实施方式
37.为了使本技术领域的人员更好地理解本技术方案,下面将结合本技术实施例中的附图,对本技术实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本技术一部分的实施例,而不是全部的实施例。基于本技术中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本技术保护的范围。
38.需要说明的是,本技术的说明书和权利要求书及上述附图中的术语“第一”、“第
二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本技术的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
39.在本技术实施例及后续实施例中,均以第三方系统接口管理平台为执行主体侧,具体地,该方法的流程可以包括以下步骤:
40.步骤1,获取第一业务数据,其中,所述第一业务数据为客户端发送的请求数据;
41.步骤2,确定对所述第一业务数据待执行的目标数据处理操作;
42.步骤3,根据所述目标数据处理操作,得到第二业务数据;
43.步骤4,将所述第二业务数据发送至响应第三方。
44.可选地,如图3,本技术实施例设置了一第三方系统接口管理平台 (即图3中的三方接口接入系统)作为介于业务系统和第三方系统(即响应第三方)的中间介质,这样,第三方系统接口管理平台获取到业务系统(即客户端)发来的第一业务数据,通过该第一业务数据为请求数据,然后第三方系统接口管理平台对该第一业务数据进行处理(比如目标数据处理操作),进而得到第二业务数据,然后将处理完的业务数据发送至第三方系统。
45.在本技术实施例中,通过获取第一业务数据,其中,第一业务数据为客户端发送的请求数据;确定对第一业务数据待执行的目标数据处理操作;根据目标数据处理操作,得到第二业务数据;将第二业务数据发送至响应第三方。由于本技术实施例设置一第三方系统接口管理平台,利用该第三方系统接口管理平台集中管理所有响应第三方系统api,减少了客户端业务系统配置和维护各种响应第三方系统的接口,同时利用第三方系统接口管理平台统一处理请求业务数据,可以有效减少了冗余代码,以及代码复杂度,进而解决了相关技术中存在的项目代码中包含大量冗余内容的问题。
46.作为一种可选实施例,确定对所述第一业务数据待执行的目标数据处理操作包括:
47.获取目标综合方案中包含的多个数据子处理方案,其中,每种所述数据子处理方案对应一种数据处理操作;
48.将所述第一业务数据与所述数据子处理方案进行数据自适配,确定出目标数据子处理方案;
49.基于所述目标数据子处理方案,确定所述目标数据处理操作。
50.可选地,如图2和图3,在第三方系统接口管理平台中包含路由转发、限流、熔断、数据模拟、统一认证、数据统计、监控告警、负载均衡等功能,可以将第三方系统接口管理平台中包含的功能统一到一个目标综合方案中,然后对应的转发、限流、熔断、数据模拟等作为目标综合方案中的数据子处理方案,在得到第一业务数据后,只需要将第一业务数据与各个数据子处理方案进行数据自适配,即可得到对第一业务数据进行处理的目标数据处理操作。
51.另外,通过图3可以得知,在业务系统侧,每个业务系统通过sdk 接入第三方系统接口管理平台,经第三方系统接口管理平台完成数据流转后再返回给业务系统。
52.作为一种可选实施例,数据子处理方案包括路由转发处理方案,所述根据所述目标数据处理操作,得到第二业务数据包括:
53.从所述第一业务数据中获取请求所述响应第三方的接口协议;
54.根据所述路由转发处理方案中的协议适配,自动适配所述接口协议,得到目标接口,其中,所述目标接口为能够请求所述响应第三方的接口;
55.通过所述目标接口,发送所述第二业务数据,其中,当前的所述第二业务数据与所述第一业务数据相同。
56.可选地,如图4,响应第三方系统的api的协议可能是多种多样的,有的是http的接口,有的是webservice协议,或者是基于dubbo的 rpc协议,第三方系统接口管理平台集成了这些协议的路由转发功能,当业务系统使用sdk发送第一业务数据,请求接入响应第三方系统时,由第三方系统接口管理平台自动适配响应第三方接口的协议,然后将请求响应数据进行数据自动适配,得到向响应第三方发送第一业务数据的目标接口。在这里,由于第三方系统接口管理平台起到的是路由转发功能,并未对第一业务数据作出处理,所以当前的第二业务数据即为获取到的第一业务数据。
57.在本技术实施例中,第三方系统接口管理平台实现多协议适配路由转发功能,将集中管理部门内所有调用响应第三方系统api,减少了业务系统配置和维护各种响应第三方系统接口。
58.作为一种可选实施例,所述数据子处理方案包括接口异常重试方案,所述根据所述目标数据处理操作,得到第二业务数据包括:
59.获取所述第一业务数据中包含的第一接口的请求信息,其中,所述第一接口为请求所述响应第三方的任一接口;
60.在确定所述第一接口的请求信息对应的请求次数小于次数阈值的情况下,开启对所述第一接口的重试方案,得到所述第二业务数据;或者,在确定所述第一接口的请求信息对应的请求时长小于时长阈值的情况下,开启对所述第一接口的所述重试方案,得到所述第二业务数据。
61.可选地,对于一些支持幂等的接口,可以通过页面配置每个api 接口的重试次数,当接口请求出现超时或者异常时,第三方系统接口管理平台支持接口重试功能。重试功能实现如图5所示:
62.第三方系统接口管理平台获取到向第一接口的请求信息后,可以加载第一接口,配置缓存(包含重试次数阈值)。
63.在确定对第一接口的请求信息次数大于或者等于该次数阈值后,就可以直接利用第一接口反馈响应数据。在确定对第一接口的请求信息次数小于次数阈值,则重启第一接口重试方案。
64.同时,在本技术实施例中,还设置了时长阈值,在确定所述第一接口的请求信息对应的请求时长小于时长阈值的情况下,也重启第一接口的重试方案。
65.也即是,在本技术实施例中,设置接口的重试方案,给予一定的容错,支持动态可配置的超时重试机制。
66.作为一种可选实施例,数据子处理方案包括数据模拟方案,所述根据所述目标数据处理操作,得到第二业务数据包括:
67.在获取到所述第一业务数据中包含了模拟配置信息的情况下,对所述第一业务数据进行拦截;
68.开启模拟操作,模拟出基于所述第一业务数据的响应数据作为所述第二业务数据。
69.可选地,如图6,在本技术实施例中,在跨部门协作开发时,如果某些响应第三方接口没开发完成,可以在第三方系统接口管理平台上设有数据模拟(mock)机制,通过拦截数据请求(如第一业务数据),完成对第一业务数据的响应信息的模拟,得到模拟后的第二业务数据,然后发送第二业务数据值客户端,从而不影响自身的项目研发流程。
70.这时,可以通过页面配置api接口模拟的开关和模拟响应数据。
71.作为一种可选实施例,在所述将所述第二业务数据发送至响应第三方之后,所述方法还包括:
72.接收所述响应第三方的响应信息;
73.在确定所述响应信息中对应的异常次数大于或者等于第一异常阈值的情况下,开启数据熔断机制;
74.将熔断结果发送至所述客户端,或者,将位于当前时刻的前一时刻的数据库内存储的数据发送至所述客户端。
75.可选地,为了降低下游系统故障导致第三方系统接口管理平台宕机。当同一个api短时间内不可用或者响应时间太长时,会开启熔断机制,超过熔断时间限制后会恢复熔断,熔断过程中会根据后台配置的操作执行。具体实现机制如图7所示:
76.在多次调用响应第三方接口时,接收到的响应信息内若都存在异常,则根据出现异常的次数与预设的第一异常阈值进行数值大小的比较,若异常次数大于或者等于第一异常阈值,则开启熔断机制,之后判断熔断机制是否超过熔断时间限制,若超过熔断时间限制,则可以恢复熔断机制,若未超过熔断时间限制,则将熔断结果(即熔断后的数据)发送至客户端,给客户返回一个友好提示,也可以返回上一次缓存在redis中的数据。
77.另外,当管理的系统和api数量逐渐增加后,第三方系统接口管理平台就像一个流量网关,需要支持高并发、高性能。本技术实施例引入了spring reactor响应式编程,通过异步模型提高了系统的吞吐量和并发量。
78.本技术实施例的第三方系统接口管理平台可以对响应第三方系统 api流量集中处理,可以针对这些流量制定统一的数据处理和监控,同时第三方系统接口管理平台支持负载均衡、异步模型、熔断限流机制,具备高并发、高性能、高可用特性。
79.作为一种可选实施例,数据子处理方案包括异常告警方案,所述根据所述目标数据处理操作,得到第二业务数据包括:
80.获取所述第一业务数据中包含的第二接口的请求信息,其中,所述第二接口为请求所述响应第三方的任一接口;
81.在确定所述第二接口出现异常数据的情况下,将预设时长设置为滑动窗口的前进步长,并在数据库内存储在所述预设时长内出现的所述异常数据,其中,每个所述预设时长对应一个所述滑动窗口;
82.在目标滑动窗口内包含的所述异常数据大于或者等于第二异常阈值的情况下,根据所述目标滑动窗口对应的告警级别,触发异常告警,其中,所述目标滑动窗口为所述滑动
窗口的子集,每个所述滑动窗口对应一种告警级别。
83.可选地,本技术实施例采用滑动窗口算法对api接口的异常告警进行降噪,具体可参见图8:
84.首先设置窗口滑动的前进步长:预设时长,可以设为1分钟、1 小时、1天等。每个预设时长对应设置告警级别,比如1分钟内出现 10次异常(也可以是5次等,不做限定),对应的告警级别为p0,1 小时内出现10次异常,对应的告警级别为p1,1天内出现10次异常,对应的告警级别为p2等。
85.在确定第一业务数据中对第二接口的请求信息为异常数据时,首次出现不告警,加入redis缓存,后续出现异常数据时,将异常数据存储到数据库(比如mysql)内,根据得到的异常数据个数匹配对应的告警降噪,比如在后续目标滑动窗口,1分钟内出现异常数据大于了10 次,则选择p0告警级别进行告警,可选择告警组和告警方式(dd、 qywx等通信软件),再将告警存储到数据库(如mysql)中。
86.各级别异常告警,就能够在通信软件中有异常告警提示,并@到该接口的负责人。
87.通信软件内点击

当天不再提醒’,次日00点之后解除白名单,如图9所示的告警界面。
88.当前异常告警策略也包括默认策略:默认策略:只要该接口出现异常,就能够在通信软件中有异常告警提示,并@到该接口的负责人。
89.在本技术实施例中,任何响应第三方系统api出现问题,可以及时告警通知,对于重复的告警做降噪处理,做到不漏报、不骚扰。
90.作为一种可选实施例,在所述将所述第二业务数据发送至响应第三方之后,所述方法还包括:
91.接收所述响应第三方被请求接口反馈的响应信息,其中,所述响应信息包含所述被请求接口的被请求数量、所述被请求接口在预设时间内的成功数量和失败数量;
92.根据所述响应信息确定响应时长;
93.根据所述响应时长确定所述预设时间内的超时数量、响应最短时间和响应最长时间;
94.将所述响应信息、所述超时数量、所述响应最短时间以及所述响应最长时间存储在数据库,并通过展示工具显示在所述客户端。
95.可选地,如图10,基于filebeat、kafka、flink采集请求响应日志 (包括被请求接口的被请求数量、被请求接口在预设时间内的成功数量、失败数量、响应时长等),将所有请求响应数据存入数据库(如 clickhouse)内,通过展示软件将统计结果进行客户端的前端显示。
96.如图11,图11为接口统计页面,其包括检索框,便于使用者对其检索,
97.检索条件:
98.时间范围:默认“过去24小时”;
99.servicekey:接口对应的唯一标识;
100.显示列表如下:
101.servicekey:接口对应的唯一标识;
102.url:显示接口的url路径,如:/api/stopreceive/group/indexvalue;
103.请求数:此检索时间内该接口的请求数量;
104.失败率(%):统计时间范围内接口请求数量中失败的百分比;
105.超时数:统计时间范围内接口请求数量中超时的数量;
106.max(ms):统计时间范围内接口请求中,接口响应时间最大的时间,单位为毫秒;
107.min(ms):统计时间范围内接口请求中,接口响应时间的最小时间,单位为毫秒;
108.avg(ms):统计时间范围内接口请求中,接口平均响应的时间,单位为毫秒。
109.在本技术实施例中,针对海量数据统计,提供一套完整的日志采集方案,这样通过后台非常直观的看到响应第三方系统api的响应情况,包括请求数、失败率、超时数、最大响应时长、最小响应时长、平均响应时长等。
110.作为一种可选实施例,本技术实施例描述第三方系统接口管理平台的页面录入信息,如图12所示,第三方系统接口管理平台中,提供可以录入响应第三方系统的页面,并能够区分不同环境,能够动态的更新响应第三方系统域名。
111.在图12中,录入信息包括:
112.系统名称:响应第三方系统的名称,如:楼盘字典系统。
113.日常环境:响应第三方系统的日常环境域名;
114.准生产环境:响应第三方系统的准生产环境域名;
115.正式环境:响应第三方系统的正式环境域名;
116.备注:备注信息。
117.另外,第三方系统接口管理平台提供响应第三方系统的api接口管理,如图13,是接口基本配置界面图。
118.servicekey:对应接口的唯一标识,业务系统可以用过sdk传入该参数,第三方系统接口管理平台可以自动识别该参数对应的响应第三方接口。
119.系统:可以选择响应第三方系统。
120.host:选择响应第三方系统后,自动显示出此环境下的对应的域名;比如:登陆的是准生产环境的第三方系统接口管理平台,那么此时如图13选择“库存系统”,则对应“库存系统”的准生产环境的域名。
121.方法路径:api接口对应的请求方式和请求的url路径。
122.数据来源:可以选择“模拟(mock)数据”或“真实数据”,当选择“mock数据”则当业务系统发送此接口的请求,则响应数据为mock 数据。
123.接口文档地址:可以录入接口文档的url路径,便于使用者进行查看。
124.接口请求设置包括:超时:第三方系统接口管理平台调用响应第三方接口的超时时间,默认5000ms,能够动态修改超时时间,应对不用接口的超时设置。
125.重试:第三方系统接口管理平台调用响应第三方接口失败后的超时重试次数,能够针对查询或幂等的接口进行重试,支持动态动态重试次数。
126.请求数据位置:
127.body:对应http请求头信息中content-type:application/json的请求方式。
128.formdata:对应http请求头信息中content-type: application/x-www-form-urlencoded的请求方式。
129.header参数:对应http请求头信息中的header信息,格式为key/vlue 形式。
130.第三方系统接口管理平台也要设置响应相关信息页面,如图14,包括:
131.code字段名称:响应第三方接口响应码对应的字段,如:code。
132.成功响应码:定义了响应第三方接口返回的成功响应码,这样就能够兼容响应第三方接口返回成功响应码不统一的情况。
133.data字段名称:响应第三方接口返回数据的字段
134.message字段名称:响应第三方接口返回的message信息的字段
135.异常code白名单:第三方系统接口管理平台能够对异常的接口返回作出响应,能够对异常信息进行通信软件进行告警,而有一些异常 code,业务人员不需要关注,则可以在此配置对应的白名单,进行过滤,避免不必要的异常告警。
136.异常关键字白名单:业务人员不需要关注的异常,除了通过异常 code白名单进行配置,还可以返回异常信息中的关键字进行过滤,进一步过滤无效告警。
137.告警策略类型:
138.告警策略类型分为:默认策略和频次策略,具体实施方式参考上述实施例,在此不再赘述。
139.熔断类型:
140.熔断类型分为:无操作、返回默认配置数据、返回缓存上一次请求数据。
141.无操作:对熔断之后的处理不进行特殊处理,直接返回到业务系统。
142.返回默认配置数据:对熔断之后的处理进行返回配置的数据,配置内容在字段”熔断配置“中进行配置。
143.返回缓存上一次请求数据:对接口熔断之后处理进行返回上一次缓存在redis中的数据,针对一些查询接口里在熔断之后进行依旧高可用。
144.熔断配置:
145.当熔断类型为“返回默认配置数据”时,熔断之后的接口返回为此配置的json数据。
146.mock返回rowcode:当接口数据来源为“mock数据”时,可以自定义返回的编码,业务系统可以根据mock的rowcode进行多成功、失败的场景覆盖。
147.mock返回数据:当接口数据来源为“mock数据”时,返回此字段中配置的json数据。
148.基于上述各实施例的内容,作为一种可选实施例,本技术实施例提供一种数据处理的方法的整体流程,如图15,包括如下步骤:
149.第三方系统接口管理平台录入响应第三方接口及相关配置;第三方系统接口管理平台缓存接口;
150.业务系统使用sdk请求该缓存接口;
151.第三方系统接口管理平台加载缓存接口,对请求数据进行数据处理操作,将处理后的数据发送至响应第三方系统;
152.响应第三方系统对接收到的处理后的数据进行内部逻辑操作,得到响应数据,将响应数据发送至第三方系统接口管理平台;
153.第三方系统接口管理平台接收响应数据,进行数据存储;
154.第三方系统接口管理平台对响应数据进行异常判断,若异常,则进行异常监控进而异常告警,若未异常,则将响应数据发送至业务系统。
155.需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本技术并不受所描述的动作顺序的限制,因为依据本技术,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本技术所必须的。
156.通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本技术的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如rom(read-only memory,只读存储器) /ram(random access memory,随机存取存储器)、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,或者网络设备等)执行本技术各个实施例所述的方法。
157.根据本技术实施例的另一个方面,还提供了一种用于实施上述数据处理的方法的数据处理的平台。图16是根据本技术实施例的一种可选的数据处理的平台结构框图,如图16所示,该平台可以包括:
158.获取模块1601,用于获取第一业务数据,其中,所述第一业务数据为客户端发送的请求数据;
159.第一确定模块1602,用于确定对所述第一业务数据待执行的目标数据处理操作;
160.得到模块1603,用于根据所述目标数据处理操作,得到第二业务数据;
161.第一发送模块1604,用于将所述第二业务数据发送至响应第三方。
162.需要说明的是,该实施例中的获取模块1601可以用于执行上述步骤s201,该实施例中的第一确定模块1602可以用于执行上述步骤 s202,该实施例中的得到模块1603可以用于执行上述步骤s203,该实施例中的第一发送模块1604可以用于执行上述步骤s204。
163.通过上述模块,本技术实施例设置一第三方系统接口管理平台,利用该第三方系统接口管理平台集中管理所有响应第三方系统api,减少了客户端业务系统配置和维护各种响应第三方系统的接口,同时利用第三方系统接口管理平台统一处理请求业务数据,可以有效减少了冗余代码,以及代码复杂度,进而解决了相关技术中存在的项目代码中包含大量冗余内容的问题。
164.作为一种可选的实施例,第一确定模块包括:
165.第一获取单元,用于获取目标综合方案中包含的多个数据子处理方案,其中,每种所述数据子处理方案对应一种数据处理操作;
166.第一适配单元,用于将所述第一业务数据与所述数据子处理方案进行数据自适配,确定出目标数据子处理方案;
167.确定单元,用于基于所述目标数据子处理方案,确定所述目标数据处理操作。
168.作为一种可选的实施例,数据子处理方案包括路由转发处理方案,得到模块包括:
169.第二获取单元,用于从所述第一业务数据中获取请求所述响应第三方的接口协议;
170.第二适配单元,用于根据所述路由转发处理方案中的协议适配,自动适配所述接口协议,得到目标接口,其中,所述目标接口为能够请求所述响应第三方的接口;
171.发送单元,用于通过所述目标接口,发送所述第二业务数据,其中,当前的所述第二业务数据与所述第一业务数据相同。
172.作为一种可选的实施例,数据子处理方案包括接口异常重试方案,得到模块包括:
173.第三获取单元,用于获取所述第一业务数据中包含的第一接口的请求信息,其中,所述第一接口为请求所述响应第三方的任一接口;
174.得到单元,用于在确定所述第一接口的请求信息对应的请求次数小于次数阈值的情况下,开启对所述第一接口的重试方案,得到所述第二业务数据;或者,在确定所述第一接口的请求信息对应的请求时长小于时长阈值的情况下,开启对所述第一接口的所述重试方案,得到所述第二业务数据。
175.作为一种可选的实施例,数据子处理方案包括数据模拟方案,得到模块包括:
176.拦截单元,用于在获取到所述第一业务数据中包含了模拟配置信息的情况下,对所述第一业务数据进行拦截;
177.模拟单元,用于开启模拟操作,模拟出基于所述第一业务数据的响应数据作为所述第二业务数据。
178.作为一种可选的实施例,该平台还包括:
179.第一接收模块,用于在所述将所述第二业务数据发送至响应第三方之后,接收所述响应第三方的响应信息;
180.开启模块,用于在确定所述响应信息中对应的异常次数大于或者等于第一异常阈值的情况下,开启数据熔断机制;
181.第二发送模块,用于将熔断结果发送至所述客户端,或者,将位于当前时刻的前一时刻的数据库内存储的数据发送至所述客户端。
182.作为一种可选的实施例,数据子处理方案包括异常告警方案,得到模块包括:
183.第四获取单元,用于获取所述第一业务数据中包含的第二接口的请求信息,其中,所述第二接口为请求所述响应第三方的任一接口;
184.设置单元,用于在确定所述第二接口出现异常数据的情况下,将预设时长设置为滑动窗口的前进步长,并在数据库内存储在所述预设时长内出现的所述异常数据,其中,每个所述预设时长对应一个所述滑动窗口;
185.告警单元,用于在目标滑动窗口内包含的所述异常数据大于或者等于第二异常阈值的情况下,根据所述目标滑动窗口对应的告警级别,触发异常告警,其中,所述目标滑动窗口为所述滑动窗口的子集,每个所述滑动窗口对应一种告警级别。
186.可选地,该平台包括:
187.第二接收模块,用于在所述将所述第二业务数据发送至响应第三方之后,接收所述响应第三方被请求接口反馈的响应信息,其中,所述响应信息包含所述被请求接口的被请求数量、所述被请求接口在预设时间内的成功数量和失败数量;
188.第二确定模块,用于根据所述响应信息确定响应时长;
189.第三确定模块,用于根据所述响应时长确定所述预设时间内的超时数量、响应最短时间和响应最长时间;
190.显示模块,用于将所述响应信息、所述超时数量、所述响应最短时间以及所述响应最长时间存储在数据库,并通过展示工具显示在所述客户端。
191.根据本技术实施例的又一个方面,还提供了一种用于实施上述数据处理的方法的电子设备,该电子设备可以是服务器、终端、或者其组合。
192.图17是根据本技术实施例的一种可选的电子设备的结构框图,如图17所示,包括处理器1701、通信接口1702、存储器1703和通信总线1704,其中,处理器1701、通信接口1702和存储器1703通过通信总线1704完成相互间的通信,其中,
193.存储器1703,用于存储计算机程序;
194.处理器1701,用于执行存储器1703上所存放的计算机程序时,实现如下步骤:
195.获取第一业务数据,其中,所述第一业务数据为客户端发送的请求数据;
196.确定对所述第一业务数据待执行的目标数据处理操作;
197.根据所述目标数据处理操作,得到第二业务数据;
198.将所述第二业务数据发送至响应第三方。
199.可选地,在本实施例中,上述的通信总线可以是pci(peripheralcomponent interconnect,外设部件互连标准)总线、或eisa(extendedindustry standard architecture,扩展工业标准结构)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示,图17中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
200.通信接口用于上述电子设备与其他设备之间的通信。
201.存储器可以包括ram,也可以包括非易失性存储器(non-volatilememory),例如,至少一个磁盘存储器。可选地,存储器还可以是至少一个位于远离前述处理器的存储装置。
202.作为一种示例,如图17所示,上述存储器1703中可以但不限于包括上述数据处理的平台中的获取模块1601、第一确定模块1602、得到模块1603、第一发送模块1604。此外,还可以包括但不限于上述数据处理的平台中的其他模块单元,本示例中不再赘述。
203.上述处理器可以是通用处理器,可以包含但不限于:cpu(centralprocessing unit,中央处理器)、np(network processor,网络处理器)等;还可以是dsp(digital signal processing,数字信号处理器)、asic (application specific integrated circuit,专用集成电路)、fpga(field- programmable gate array,现场可编程门阵列)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
204.此外,上述电子设备还包括:显示器,用于显示数据处理的结果。
205.可选地,本实施例中的具体示例可以参考上述实施例中所描述的示例,本实施例在此不再赘述。
206.本领域普通技术人员可以理解,图17所示的结构仅为示意,实施上述数据处理的方法的设备可以是终端设备,该终端设备可以是智能手机(如android手机、ios手机等)、平板电脑、掌上电脑以及移动互联网设备(mobile internet devices,mid)、pad等终端设备。图17 其并不对上述电子设备的结构造成限定。例如,终端设备还可包括比图17中所示更多或者更少的组件(如网络接口、显示装置等),或者具有与图17所示的不同的配置。
207.本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成,该程序可以存储于一计算机可读存储介质中,存储介质可以包括:闪存盘、 rom、ram、磁盘或光盘等。
208.根据本技术实施例的又一个方面,还提供了一种存储介质。可选地,在本实施例
中,上述存储介质可以用于执行数据处理的方法的程序代码。
209.可选地,在本实施例中,上述存储介质可以位于上述实施例所示的网络中的多个网络设备中的至少一个网络设备上。
210.可选地,在本实施例中,存储介质被设置为存储用于执行以下步骤的程序代码:
211.获取第一业务数据,其中,所述第一业务数据为客户端发送的请求数据;
212.确定对所述第一业务数据待执行的目标数据处理操作;
213.根据所述目标数据处理操作,得到第二业务数据;
214.将所述第二业务数据发送至响应第三方。
215.可选地,本实施例中的具体示例可以参考上述实施例中所描述的示例,本实施例中对此不再赘述。
216.可选地,在本实施例中,上述存储介质可以包括但不限于:u盘、 rom、ram、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
217.根据本技术实施例的又一个方面,还提供了一种计算机程序产品或计算机程序,该计算机程序产品或计算机程序包括计算机指令,该计算机指令存储在计算机可读存储介质中;计算机设备的处理器从计算机可读存储介质读取该计算机指令,处理器执行该计算机指令,使得该计算机设备执行上述任一个实施例中的数据处理的方法步骤。
218.上述本技术实施例序号仅仅为了描述,不代表实施例的优劣。
219.上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在上述计算机可读取的存储介质中。基于这样的理解,本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在存储介质中,包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本技术各个实施例数据处理的方法的全部或部分步骤。
220.在本技术的上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
221.在本技术所提供的几个实施例中,应该理解到,所揭露的客户端,可通过其它的方式实现。其中,以上所描述的装置实施例仅仅是示意性的,例如单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,单元或模块的间接耦合或通信连接,可以是电性或其它的形式。
222.作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例中所提供的方案的目的。
223.另外,在本技术各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
224.以上所述仅是本技术的优选实施方式,应当指出,对于本技术领域的普通技术人
员来说,在不脱离本技术原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本技术的保护范围。
再多了解一些

本文用于企业家、创业者技术爱好者查询,结果仅供参考。

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表

相关文献