发明内容
有鉴于此,本公开实施例提供一种业务数据处理方法、装置、服务器及存储介质。
第一方面,本公开实施例提供一种业务数据处理方法,所述方法包括:
响应于接收到客户端发送的业务数据请求,确定所述业务数据请求所请求的业务数据对应的业务场景;
获取所述业务场景下的业务数据标识(ID,Identifier);
生成对应所述业务场景的RPC树;所述RPC树包括至少一个层级,每个层级包括至少一个RPC;
基于所述业务数据ID及所述RPC树,得到所述业务数据;
返回所述业务数据,使得所述业务数据在所述客户端的界面呈现。
上述方案中,所述生成对应所述业务场景的RPC树,包括:
获取所述业务场景对应的RPC等级;
确定对应所述RPC等级的RPC树的层级;
生成对应所述层级的RPC树。
上述方案中,所述方法还包括:
响应于所述业务数据ID的数量为多个,基于预设的过滤规则,对所述多个业务数据ID进行过滤。
上述方案中,所述基于所述业务数据ID及所述RPC树,得到所述业务数据,包括:
基于所述业务数据ID,按照所述RPC树的层级,依次调用每个层级所包括的RPC,得到所述业务数据ID对应的所述业务数据;
其中,相同层级的RPC并行的被调用。
上述方案中,所述获取所述业务场景下的业务数据ID,包括:
解析所述业务数据请求,得到用户关键信息;
确定与所述用户关键信息相适配的业务数据类型;
获取所述业务场景下对应所述业务数据类型的业务数据ID。
上述方案中,所述方法还包括:
响应于所述业务数据的类型为数据传输对象(DTO,Data Transfer Object),对所述业务数据进行数据映射,得到JS对象简谱(JSON,JavaScript Object Notation)格式的所述业务数据。
第二方面,本公开实施例还提供一种业务数据处理装置,所述装置包括:
接口模块,用于响应于接收到客户端发送的业务数据请求,确定所述业务数据请求所请求的业务数据对应的业务场景;
以及,获取所述业务场景下的业务数据ID;
打包模块,用于生成对应所述业务场景的RPC树;所述RPC树包括至少一个层级,每个层级包括至少一个RPC;
以及,基于所述业务数据ID及所述RPC树,得到所述业务数据;
以及,返回所述业务数据,使得所述业务数据在所述客户端的界面呈现。
上述方案中,所述打包模块包括:
加载单元,用于获取所述业务场景对应的RPC等级;
确定对应所述RPC等级的RPC树的层级;
生成对应所述层级的RPC树。
上述方案中,所述打包模块包括:
过滤单元,用于响应于所述业务数据ID的数量为多个,基于预设的过滤规则,对所述多个业务数据ID进行过滤。
上述方案中,所述打包模块包括:
编译单元,用于基于所述业务数据ID,按照所述RPC树的层级,依次调用每个层级所包括的RPC,得到所述业务数据ID对应的所述业务数据;
其中,相同层级的RPC并行的被调用。
上述方案中,所述接口模块包括:
获取单元,用于解析所述业务数据请求,得到用户关键信息;
确定与所述用户关键信息相适配的业务数据类型;
获取所述业务场景下对应所述业务数据类型的业务数据ID。
上述方案中,所述接口模块包括:
映射单元,用于响应于所述业务数据的类型为DTO,对所述业务数据进行数据映射,得到JSON格式的所述业务数据。
第三方面,本公开实施例还提供一种服务器,包括:
存储器,用于存储可执行指令;
处理器,用于执行所述存储器中存储的可执行指令时,实现本公开实施例提供的上述业务数据处理方法。
第四方面,本公开实施例还提供一种存储介质,存储有可执行指令,所述可执行指令被执行时,用于实现本公开实施例提供的上述业务数据处理方法。
应用本公开上述实施例具有以下有益效果:
应用本公开上述实施例,后台服务器接收到客户端发送的业务数据请求后,基于业务数据ID及对应业务场景的RPC树,得到对应的业务数据,提高了业务数据的返回效率,降低服务端的整体响应延时。
具体实施方式
在以下的描述中,涉及到“一些实施例”,其描述了所有可能实施例的子集,但是可以理解,“一些实施例”可以是所有可能实施例的相同子集或不同子集,并且可以在不冲突的情况下相互结合。
除非另有定义,本文所使用的所有的技术和科学术语与属于本公开实施例的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述具体的实施例的目的,不是旨在限制本公开实施例。
本公开实施例提供的附图中的流程图和框图,图示了按照本公开实施例的***、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的***来实现,或者可以用专用硬件与计算机指令的组合来实现。
参见图1,图1是本公开实施例提供的业务数据处理***的一个可选的架构示意图,为实现支撑一个示例性应用,移动终端10(示例性示出了移动终端10-1和移动终端10-2)通过网络20连接服务器30,网络20可以是广域网或者局域网,又或者是二者的组合,使用无线链路实现数据传输。
移动终端10上设置有短视频客户端,移动终端基于短视频客户端,用户基于短视频客户端进行短视频观看,触发短视频客户端发送相应的业务数据请求给服务器30,以请求用于在短视频客户端播放的短视频数据。
相应的,服务器30接收短视频客户端发送的业务数据请求,确定所请求的短视频数据对应的业务场景(如客户端首页对应的短视频播放(feed)场景、客户端用户的短视频发布列表(Post List)场景),获取所确定的业务场景下的短视频ID,生成对应业务场景的RPC树,根据生成的RPC树得到对应短视频ID的视频数据,并返回得到的视频数据给移动终端10。
移动终端10,还用于基于短视频客户端,通过图形界面110(示例性示出了图形界面110-1和图形界面110-2)播放所获取的短视频数据。
下面参见图2,图2是实现本公开实施例的服务器的组成结构示意图。在本公开实施例中,图2示出的服务器仅仅是一个示例,不应对本公开实施例的功能和使用范围带来任何限制。
如图2所示,服务器可以包括处理装置(例如中央处理器、图形处理器等)210,其可以根据存储在只读存储器(ROM,Read-Only Memory)220中的程序或者从存储装置280加载到随机访问存储器(RAM,Random Access Memory)230中的程序而执行各种适当的动作和处理。在RAM 230中,还存储有服务器操作所需的各种程序和数据。处理装置210、ROM 220以及RAM 230通过总线240彼此相连。输入/输出(I/O,Input/Output)接口250也连接至总线240。
通常,以下装置可以连接至I/O接口250:包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置260;包括例如液晶显示器(LCD)、扬声器、振动器等的输出装置270;包括例如磁带、硬盘等的存储装置280;以及通信装置290。通信装置290可以允许服务器与其他设备进行无线或有线通信以交换数据。虽然图2示出了具有各种装置的服务器,但是应理解的是,并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。
特别地,根据本公开的实施例,所提供的流程图描述的过程可以被实现为计算机软件程序。例如,本公开的实施例包括一种计算机程序产品,其包括承载在计算机可读介质上的计算机程序,计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中,计算机程序可以通过通信装置290从网络上被下载和安装,或者从存储装置280被安装,或者从ROM220被安装。在计算机程序被处理装置210执行时,执行本公开实施例的方法中限定的上述功能。
需要说明的是,本公开上述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以包括但不限于电、磁、光、电磁、红外线、或半导体的***、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。
在本公开实施例中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行***、装置或者器件使用或者与其结合使用。而在本公开实施例中,计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,计算机可读信号介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:电线、光缆、射频(RF)等等,或者上述的任意合适的组合。
上述计算机可读介质可以是上述服务器中所包含的;也可以是单独存在,而未装配入服务器中。
上述计算机可读介质承载有一个或者多个程序,当上述一个或者多个程序被该服务器执行时,使得服务器执行本公开实施例提供的上述视频文件的处理方法。
可以以一种或多种程序设计语言或其组合来编写用于执行本公开的操作的计算机程序代码,上述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++,还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中,远程计算机可以通过任意种类的网络,包括局域网(LAN)和广域网(WAN),以连接到用户计算机,或者,可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
描述于本公开实施例中所涉及到的单元和/或模块可以通过软件的方式实现,也可以通过硬件的方式来实现。
对于硬件的方式来说,实现本公开实施例的服务器的单元和/或模块可以被一个或多个应用专用集成电路(ASIC,Application Specific Integrated Circuit)、DSP、可编程逻辑器件(PLD,Programmable Logic Device)、复杂可编程逻辑器件(CPLD,ComplexProgrammable Logic Device)、现场可编程门阵列(FPGA,Field-Programmable GateArray)或其他电子元件实现,用于执行实现本公开实施例提供的方法。
图3为相关技术中后台服务器基于移动终端的短视频客户端获取短视频数据的流程示意图,参见图3,短视频数据的获取通过后台服务器的接口模块(API,ApplicationProgramming Interface)实现,API中集成有应用场景模块、Pack(打包)服务模块、数据模型(model)模块及接口描述语言模块,当应用场景模块接收到短视频数据的获取请求后,确定所要获取的短视频数据的应用场景,调用数据模型模块,数据模型模块串行调用RPC,然后调用Pack服务模块,Pack服务模块通过数据组织的协议(Protobuf IDL),将获取的数据封装打包发送给短视频客户端。该短视频数据的获取方式,数据模型和API的耦合度高,在实际应用中,各业务线频繁改动,导致协同开发效率低,而且当多个短视频客户端同时发送短视频数据请求时,会后台服务器的资源消耗大,对RPC的串行调用导致出现明显的延迟,用户体验低。
图4为本公开实施例提供的业务数据处理方法的流程示意图,参见图4,本公开实施例的业务数据处理方法包括:
步骤401:响应于接收到客户端发送的业务数据请求,确定所述业务数据请求所请求的业务数据对应的业务场景。
在实际应用时,这里所述的客户端可以为设置于移动终端上的短视频客户端,用户可通过短视频客户端进行短视频观看或发布等,当然在其它实施例中,还可以是其它多媒体应用客户端。
以客户端为短视频客户端为例,当用户基于短视频客户端进行短视频观看时,触发短视频客户端发送业务数据请求给后台服务器,后台服务器的API接收到短视频客户端发送的业务数据请求,对业务数据请求进行解析,得到所请求的业务数据对应的业务场景信息,例如,通过解析得到业务场景为第一业务场景,第一业务场景可以为短视频客户端首页对应的短视频播放(feed)场景、或者通过解析得到业务场景为第二业务场景,第二业务场景为客户端用户的短视频发布列表(Post List)场景。
步骤402:获取所述业务场景下的业务数据ID。
在一实施例中,后台服务器的API可通过如下方式获取所确定的业务场景下的业务数据ID:
解析所述业务数据请求,得到用户关键信息;确定与所述用户关键信息相适配的业务数据类型;获取所述业务场景下对应所述业务数据类型的业务数据ID。在实际应用中,用户关键信息可以包括以下至少之一:用户ID、用户对不同类型的业务数据的兴趣度、用户关注的作者(即业务数据的发布者)等。
示例性地,后台服务器的API解析业务数据请求,得到用户对不同短视频类型的兴趣度信息,基于所获取的所述兴趣度信息,获取所确定的业务场景下用户感兴趣(兴趣度最高)的一个或多个(两个或两个以上)短视频ID,如,获取用户感兴趣的六个短视频ID。
步骤403:生成对应所述业务场景的RPC树。
在实际实施时,后台服务器的API获取业务数据ID后,对后台服务器的打包模块(Packer)进行调用,通过后台服务器的打包模块实现RPC树的生成及相应业务数据的获取。
在一实施例中,后台服务器的打包模块可以通过如下方式生成对应所述业务场景的RPC树:
获取所述业务场景对应的RPC等级;确定对应所述RPC等级的RPC树的层级;生成对应所述层级的RPC树。所述RPC树包括至少一个层级,每个层级包括至少一个RPC。
这里,参见图5,图5为本公开实施例提供的远程过程调用接口等级的示意图,在实际应用中,远程过程调用接口(RPC)等级可以包括三个,分别为第一等级(Full等级)、第二等级(Normal等级)及第三等级(Lite等级);不同的业务场景对应不同的RPC等级,例如对于第一业务场景来说,其对应的RPC等级为第一等级。
在实际实施时,每个RPC等级对应不同层级的RPC树,参见图6,图6为本公开实施例提供的RPC树的一个可选的示意图,对于第一等级等级(图6中61所示)来说,其对应的RPC树包括三个层级(L1、L2、L3),对于第二等级等级(图6中62所示)来说,其对应的RPC树包括两个层级(L1、L2),对于第三等级等级(图6中63所示)来说,其对应的RPC树包括一个层级(L1),例如对于某些场景,仅需要短视频的播放地址即可;如此,生成的RPC树与业务场景对应的RPC等级相对应,避免了对无用RPC的无用调用,节省处理时间,提高处理效率;不同的RPC以树的形式排列,使得处于相同层级的RPC并发,即相同层级的RPC并行的被调用,如此,降低服务端的整体响应延时,使得客户端所请求的业务数据更快的返回客户端。
具体地,在一实施例中,后台服务器的打包模块可以包括加载单元(Loader),通过加载单元确定业务场景对应的RPC等级,并生成对应该RPC等级的RPC树,并基于业务数据ID及生成的RPC树,得到业务数据ID对应的元数据。
仍以业务数据为短视频数据为例进行说明,若所确定的场景为短视频客户端首页对应的短视频播放(feed)场景,打包模块中的加载单元确定对应的RPC等级为Full等级,进而生成对应Full等级的RPC树,并基于生成的RPC树得到短视频ID对应的元数据(Material)。在实际应用中,RPC树所包括的RPC可以包括:混排服务(Sati/Sort)、Item源信息(Item,如视频状态、User ID等)、用户信息(User,短视频发布者的相关信息)、短视频播放地址(SmartPlayer)、当前的短视频ID绑定的挑战(Challenge)、当前短视频ID对应的基础信息(Counter,如点赞用户数量、评论数量等)。
在一实施例中,后台服务器的打包模块还可以包括过滤单元(Filter),过滤单元中存储有至少一个预设的过滤规则,当API获取的业务数据ID有多个时,过滤单元基于预设的过滤规则,对多个业务数据ID进行过滤。例如,在实际应用中,预设的过滤规则可以为基于安全角度的安全过滤,例如,对于业务数据ID为短视频ID来说,可以对短视频的私密状态进行过滤,若某些短视频设置了私密(即对其它用户不可见),则过滤掉这些设置了私密状态的短视频ID;在实际应用中,预设的过滤规则还可以为图文过滤,若业务数据ID对应的业务数据中包含当前发送业务数据请求的视频客户端的版本所不支持的图文,则过滤掉这些业务数据ID;在实际应用中,对于业务数据ID为短视频ID来说,预设的过滤规则还可以为短视频状态的过滤,例如,由于审核的原因,某些短视频已下架,则过滤掉这些短视频ID。
步骤404:基于所述业务数据ID及所述RPC树,得到所述业务数据。
这里,在一实施例中,后台服务器的打包模块包括编译单元(Assembler),通过编译单元根据数据压缩协议进行数据打包,封装。
具体地,编译单元可通过如下方式得到客户端所请求的业务数据:
编译单元基于所述业务数据ID,按照所述RPC树的层级,依次调用每个层级所包括的RPC,得到所述业务数据ID对应的所述业务数据;其中,相同层级的RPC并行的被调用。
这里,在实际应用中,编译单元得到的所述业务数据为业务数据ID对应的所述业务场景下的数据集合(客户端展现的信息界面整合的各种字段称为数据集合),数据集合的数据类型为DTO。
步骤405:返回所述业务数据,使得所述业务数据在所述客户端的界面呈现。
在实际应用中,API返回业务数据给客户端之前,接收到打包模块发送的打包形成的DTO,需要对DTO进行数据映射,得到JSON格式的所述业务数据。具体地,API所做的数据映射为从Thrift IDL到Protobuf IDL的数据映射(强化IDL契约精神)。
应用本公开上述实施例,对相关技术中的API进行重构,简化API的功能,Pack服务独立部署,提升API整体的稳定性;RPC以树的形式存在,生成的RPC树与业务场景对应的RPC等级相对应,避免了对无用RPC的无用调用,节省处理时间,提高处理效率,在进行RPC调用时,相同层级的RPC并行的被调用,如此,降低服务端的整体响应延时,使得客户端所请求的业务数据更快的返回客户端,提高用户体验。
接下来以客户端为短视频客户端,用户基于短视频客户端进行短视频播放的场景为例,对本公开实施例提供的业务数据处理方法进行说明。图7为本公开实施例提供的业务数据处理方法的流程示意图,图8为本公开实施例提供的业务数据处理方法的另一流程示意图,应用于服务器,服务器包括用于实现本公开实施例提供的业务数据处理方法的API模块及打包模块,结合图7、图8,本公开实施例提供的业务数据处理方法包括:
步骤701:API接收到短视频客户端发送的短视频数据请求。
这里,在实际应用中,短视频客户端基于用户触发,发送短视频数据请求给后台服务器,以请求短视频数据进行播放,在一实施例中,短视频客户端采用feed流进行短视频播放。feed是一种给用户持续提供内容的数据形式;是由多个内容提供源组成的资源聚合器,由用户主动订阅消息源并且向用户提供内容,一个feed流是一个信息出口,为持续更新并呈现给用户内容的信息流。
在实际应用中,短视频数据请求可以携带如下信息:用户关键信息、短视频客户端的版本信息、业务场景信息等。
其中,用户关键信息可以包括以下至少之一:用户ID、用户对不同类型的业务数据的兴趣度、用户关注的作者(即业务数据的发布者)等。
步骤702:API基于短视频数据请求,确定业务数据请求所请求的业务数据对应的业务场景。
在实际实施时,参见图8,API包括场景确定单元(Feed/PostList),用于对业务数据请求进行解析,得到所请求的业务数据对应的业务场景信息,例如,通过解析得到业务场景为短视频客户端首页对应的短视频播放(feed)场景、或者通过解析得到业务场景为用户的短视频发布列表(Post List)场景。
步骤703:API获取所述业务场景下的多个短视频ID。
在实际实施时,参见图8,API包括获取单元(ID Fetcher),用于解析所述短视频数据请求,得到用户关键信息;确定与所述用户关键信息相适配的短视频类型;获取所述业务场景下对应所述短视频类型的短视频ID。
这里,与用户关键信息相适配的短视频类型可以为用户的兴趣度最高的短视频类型;在一实施例中,所获取的短视频ID的数量可以依据实际情况预先设定,如获取用户感兴趣的六个短视频ID。
步骤704:打包模块生成对应所述业务场景的RPC树。
这里,在实际应用中,API获取多个短视频ID后,对打包模块进行调用,将获取的多个短视频ID传送给打包模块,在一实施例中,打包模块的组成结构如图9所示,包括下载器(加载单元)、过滤器(过滤单元)及组合器(编译单元)。
具体地,加载单元获取到短视频ID及相应的业务场景信息后,初始化单元(newer)确定业务场景对应的RPC等级,以及对应所述RPC等级的RPC树的层级,执行单元(executor)生成对应所述层级的RPC树,然后数据单元基于生成的RPC树得到相应的元数据(Material)。例如,业务场景为feed场景,加载单元确定feed场景对应的RPC等级为Full等级,对应Full等级的RPC树的层级为3层,生成包括3层RPC的RPC树。其中,RPC树所包括的RPC可以包括:混排服务(Sati/Sort)、项目(Item)源信息(Item,如视频状态、Use r ID等)、用户信息(User,短视频发布者的相关信息)、短视频播放地址(Sm artPlayer)、当前的短视频ID绑定的挑战(Challenge)、当前短视频ID对应的基础信息(计数(Counter),如点赞用户数量、评论数量等)。
这里,加载单元得到的数据为所获取的短视频ID对应的元数据。
步骤705:打包模块基于预设的过滤规则对所述多个短视频ID进行过滤。
在实际实施时,参见图9,过滤单元中存储有至少一个预设的过滤规则,通过过滤单元实现对多个短视频ID的过滤。在实际应用中,预设的过滤规则可以为基于安全角度的安全过滤(SecurityFilter),例如,对于业务数据ID为短视频ID来说,可以对短视频的私密状态进行过滤,若某些短视频设置了私密(即对其它用户不可见),则过滤掉这些设置了私密状态的短视频ID;在实际应用中,预设的过滤规则还可以为图文过滤(ImageFilter),若业务数据ID对应的业务数据中包含当前发送业务数据请求的视频客户端的版本所不支持的图文,则过滤掉这些业务数据ID;在实际应用中,对于业务数据ID为短视频ID来说,预设的过滤规则还可以为短视频状态的过滤(StatusFilter),例如,由于审核的原因,某些短视频已下架,则过滤掉这些短视频ID。
步骤706:打包模块基于过滤后得到的短视频ID及所述RPC树,得到对应短视频ID的DTO数据。
在实际实施时,编译单元基于短视频ID,按照所述RPC树的层级,依次调用每个层级所包括的RPC,得到所述短视频ID在所述业务场景下的数据集合,并依据预设的RPC封装格式(即封装顺序,ordered,如图9中的基础信息(base)→制作(maker)→状态信息(Status)→数据统计(Statistics)→视频(video))打包封装成DTO类型的数据,并传递给API;其中,相同层级的R PC并行的被调用。
步骤707:API将所述DTO数据映射成JSON格式的短视频数据,并发送JSON格式的短视频数据给短视频客户端。
在实际实施时,API还包括映射单元(JSON Builder),对DTO数据进行从第一接口描述语言(Thrift IDL)到第二接口描述语言(Protobuf IDL)的数据映射,得到短视频客户端所能够识别的数据格式的短视频数据,返回给短视频客户端,以在短视频客户端的界面进行呈现。
图10为本公开实施例提供的业务数据处理装置的组成结构示意图,参见图10,本公开实施例提供的业务数据处理装置包括:
接口模块11,用于响应于接收到客户端发送的业务数据请求,确定所述业务数据请求所请求的业务数据对应的业务场景;
以及,获取所述业务场景下的业务数据ID;
打包模块12,用于生成对应所述业务场景的RPC树;所述RPC树包括至少一个层级,每个层级包括至少一个RPC;
以及,基于所述业务数据ID及所述RPC树,得到所述业务数据;
以及,返回所述业务数据,使得所述业务数据在所述客户端的界面呈现。
在一实施例中,所述打包模块包括:
加载单元,用于获取所述业务场景对应的RPC等级;
确定对应所述RPC等级的RPC树的层级;
生成对应所述层级的RPC树。
在一实施例中,所述打包模块包括:
过滤单元,用于响应于所述业务数据ID的数量为多个,基于预设的过滤规则,对所述多个业务数据ID进行过滤。
在一实施例中,所述打包模块包括:
编译单元,用于基于所述业务数据ID,按照所述RPC树的层级,依次调用每个层级所包括的RPC,得到所述业务数据ID对应的所述业务数据;
其中,相同层级的RPC并行的被调用。
在一实施例中,所述接口模块包括:
获取单元,用于解析所述业务数据请求,得到用户关键信息;
确定与所述用户关键信息相适配的业务数据类型;
获取所述业务场景下对应所述业务数据类型的业务数据标识ID。
在一实施例中,所述接口模块包括:
映射单元,用于响应于所述业务数据的类型为数据传输对象DTO,对所述业务数据进行数据映射,得到JS对象简谱JSON格式的所述业务数据。
这里需要指出的是:以上涉及业务数据处理装置的描述,与上述业务数据处理方法描述是类似的,同方法的有益效果描述,不做赘述。对于本公开所述视频编码实施例中未披露的技术细节,请参照本发明方法实施例的描述。
本公开实施例还提供了一种可读存储介质,存储介质可以包括:移动存储设备、随机存取存储器(RAM,Random Access Memory)、只读存储器(ROM,Read-Only Memory)、磁碟或者光盘等各种可以存储程序代码的介质。所述可读存储介质存储有可执行指令;
所述可执行指令,用于被处理器执行时实现本公开实施例提供的业务数据处理方法。
以上所述,仅为本公开的具体实施方式,但本公开的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本公开揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本公开的保护范围之内。因此,本公开的保护范围应以所述权利要求的保护范围为准。