CN108965365A - 一种数据处理方法及终端、计算机存储介质 - Google Patents

Abstract

本发明公开了一种数据处理方法及终端、计算机存储介质，其中，所述方法包括：将至少两个业务请求合并为第一请求；发送所述第一请求给服务器，请求与服务器建立全双工的通信连接；在基于所述通信连接得到的数据传输通道上，接收对应所述第一请求的反馈数据；根据从所述至少两个业务请求中解析得到的请求参数，将所述反馈数据对应拆分为至少两组第一数据；对所述至少两组第一数据进行格式化处理，得到至少两组第二数据；将所述至少两组第二数据提供给业务应用层，在所述业务应用层中进行业务数据的展示。

Description

一种数据处理方法及终端、计算机存储介质

技术领域

本发明涉及互联网信息技术，尤其涉及一种数据处理方法及终端、计算机存储介质。

背景技术

随着互联网的普及，各用户间、用户和后台服务器间可以很方便的通过互联网进行各种信息交互。以终端和服务器构成的C/S架构为例进行说明，一种实时数据获取的交互过程中，一般采用轮询机制来实现，比如，对于同一组实时数据的更新，需要终端向服务器定时循环的发起http请求，等待服务器返回所请求的数据，再对该数据做处理以展示到终端页面上。

然而，终端的某一个应用，通常是由多个不同的业务模块构成的。虽然，多个业务模块执行的功能可能不同，但是，请求的数据却可能是相同的。比如，需要请求的数据是同一组实时数据，按照现有技术的上述轮询机制，终端上不同的业务模块需要重复冗余的发起请求。由于终端需要不断的向服务器发出请求，这样会占用很多的带宽，这是采用现有技术存在的第一个问题。

终端请求的数据从服务器返回给不同的业务模块之后，由于需要执行不同的功能，因此，其所需要的数据格式也是不同的，目前是各自分别处理，这样不仅数据格式不统一，且占用过多终端处理资源，导致处理效率低下，这是采用现有技术存在的第二个问题。

可见，数据实时更新的冗余请求及数据格式的不统一，会导致终端与服务器交互时占用很多的带宽、占用过多终端处理资源，导致处理效率低下，不论是对终端自身，还是对终端和服务器构成的系统来说，要想达到预期的处理效果都要提高开发和维护成本。然而，相关技术中，对于该问题，尚无有效解决方案。

发明内容

有鉴于此，本发明实施例提供了一种数据处理方法及终端、计算机存储介质，至少解决了现有技术存在的问题。

本发明实施例的一种数据处理方法，所述方法包括：

将至少两个业务请求合并为第一请求；

发送所述第一请求给服务器，请求与服务器建立全双工的通信连接；

在基于所述通信连接得到的数据传输通道上，接收对应所述第一请求的反馈数据；

根据从所述至少两个业务请求中解析得到的请求参数，将所述反馈数据对应拆分为至少两组第一数据；

对所述至少两组第一数据进行格式化处理，得到至少两组第二数据；

将所述至少两组第二数据提供给业务应用层，在所述业务应用层中进行业务数据的展示。

上述方案中，所述将至少两个业务请求合并为第一请求，包括：

将所述至少两个业务请求中，每一个业务请求对应的所述请求参数进行参数类型的分解，得到至少两个第一参数类型和至少两个第二参数类型；

将所述至少两个第一参数类型进行合并，得到第一参数数组；

将所述第一参数数组封装至所述第一请求中的第一字段中。

上述方案中，所述将至少两个业务请求合并为第一请求，包括：

将所述至少两个业务请求中，每一个业务请求对应的所述请求参数进行参数类型的分解，得到至少两个第一参数类型和至少两个第二参数类型；

将所述至少两个第二参数类型进行合并，得到第二参数数组；

将所述第二参数数组封装至所述第一请求中的第二字段中。

上述方案中，所述将至少两个业务请求合并为第一请求，包括：

将所述至少两个业务请求中，每一个业务请求对应的所述请求参数进行参数类型的分解，得到至少两个第一参数类型和至少两个第二参数类型；

将所述至少两个第一参数类型进行合并，得到第一参数数组；

将所述至少两个第二参数类型进行合并，得到第二参数数组；

将所述第一参数数组封装至所述第一请求中的第一字段中；

将所述第二参数数组封装至所述第一请求中的第二字段中。

上述方案中，所述方法还包括：所述将至少两个业务请求合并为第一请求之前，

从所述至少两个业务请求中分别解析出所述请求参数；

将所述请求参数进行参数数据的注册，缓存为第一注册数据；

将与所述请求参数对应的请求数据进行数据回调方式的注册，缓存为第二注册数据。

上述方案中，所述对所述至少两组第一数据进行格式化处理，得到至少两组第二数据，包括：

获取对应于第一业务请求的第一数据处理策略，根据所述第一数据处理策略对第一组第一数据进行格式化处理，得到第一组第二数据，将所述第一组第二数据输出给至少一个业务应用；

获取对应于第二业务请求的第二数据处理策略，根据所述第二数据处理策略对第二组第一数据进行格式化处理，得到第二组第二数据，将所述第二组第二数据输出给至少一个业务应用。

上述方案中，所述对所述至少两组第一数据进行格式化处理，得到至少两组第二数据，包括：

获取对应于第一业务请求的第一数据处理策略，根据所述第一数据处理策略对第一组第一数据进行格式化处理，得到第一组第二数据，将所述第一组第二数据输出给对应第二业务请求的业务应用；

获取对应于第二业务请求的第二数据处理策略，根据所述第二数据处理策略对所述第一组第二数据进行格式化处理，得到第二组第二数据；

将所述第二组第二数据输出给对应下一个业务请求的业务应用，直至对业务请求停止响应；

将所述第一组第二数据和/或所述第二组第二数据输出给至少一个业务应用。

本发明实施例的一种终端，所述终端包括：

合并单元，用于将至少两个业务请求合并为第一请求；

请求单元，用于发送所述第一请求给服务器，请求与服务器建立全双工的通信连接；

接收单元，用于在基于所述通信连接得到的数据传输通道上，接收对应所述第一请求的反馈数据；

拆分单元，用于根据从所述至少两个业务请求中解析得到的请求参数，将所述反馈数据对应拆分为至少两组第一数据；

格式化处理单元，用于对所述至少两组第一数据进行格式化处理，得到至少两组第二数据；

展示单元，用于将所述至少两组第二数据提供给业务应用层，在所述业务应用层中进行业务数据的展示。

上述方案中，所述合并单元，进一步用于：

将所述至少两个业务请求中，每一个业务请求对应的所述请求参数进行参数类型的分解，得到至少两个第一参数类型和至少两个第二参数类型；

将所述至少两个第一参数类型进行合并，得到第一参数数组；

将所述第一参数数组封装至所述第一请求中的第一字段中。

上述方案中，所述合并单元，进一步用于：

将所述至少两个业务请求中，每一个业务请求对应的所述请求参数进行参数类型的分解，得到至少两个第一参数类型和至少两个第二参数类型；

将所述至少两个第二参数类型进行合并，得到第二参数数组；

将所述第二参数数组封装至所述第一请求中的第二字段中。

上述方案中，所述合并单元，进一步用于：

将所述至少两个业务请求中，每一个业务请求对应的所述请求参数进行参数类型的分解，得到至少两个第一参数类型和至少两个第二参数类型；

将所述至少两个第一参数类型进行合并，得到第一参数数组；

将所述至少两个第二参数类型进行合并，得到第二参数数组；

将所述第一参数数组封装至所述第一请求中的第一字段中；

将所述第二参数数组封装至所述第一请求中的第二字段中。

上述方案中，所述格式化处理单元，进一步用于：

获取对应于第一业务请求的第一数据处理策略，根据所述第一数据处理策略对第一组第一数据进行格式化处理，得到第一组第二数据，将所述第一组第二数据输出给至少一个业务应用；

获取对应于第二业务请求的第二数据处理策略，根据所述第二数据处理策略对第二组第一数据进行格式化处理，得到第二组第二数据，将所述第二组第二数据输出给至少一个业务应用。

上述方案中，所述格式化处理单元，进一步用于：

获取对应于第一业务请求的第一数据处理策略，根据所述第一数据处理策略对第一组第一数据进行格式化处理，得到第一组第二数据，将所述第一组第二数据输出给对应第二业务请求的业务应用；

获取对应于第二业务请求的第二数据处理策略，根据所述第二数据处理策略对所述第一组第二数据进行格式化处理，得到第二组第二数据；

将所述第二组第二数据输出给对应下一个业务请求的业务应用，直至对业务请求停止响应；

将所述第一组第二数据和/或所述第二组第二数据输出给至少一个业务应用。

本发明实施例的一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现如上述方案中任一项所述方法的步骤。

本发明实施例的一种服务器，所述服务器包括：

存储器，用于存储能够在处理器上运行的计算机程序；

处理器，用于运行所述计算机程序时，执行如上述方案中任一项所述方法的步骤。

本发明实施例的数据处理方法，包括：将至少两个业务请求合并为第一请求；发送所述第一请求给服务器，请求与服务器建立全双工的通信连接；在基于所述通信连接得到的数据传输通道上，接收对应所述第一请求的反馈数据；根据从所述至少两个业务请求中解析得到的请求参数，将所述反馈数据对应拆分为至少两组第一数据；对所述至少两组第一数据进行格式化处理，得到至少两组第二数据；将所述至少两组第二数据提供给业务应用层，在所述业务应用层中进行业务数据的展示。

采用本发明实施例，一方面，将至少两个业务请求合并为第一请求，且请求与服务器建立全双工的通信连接，实现了一次请求，一次连接，多次数据传输，从而避免了多次请求的冗余重复发送。另一方面，在数据传输通道上得到对应第一请求的反馈数据后，先根据请求参数将所述反馈数据对应拆分为至少两组第一数据，对所述至少两组第一数据进行格式化处理，得到至少两组第二数据，使得数据格式统一化，避免占用过多终端处理资源。

附图说明

图1为实现本发明各个实施例的移动终端一个可选的硬件结构示意图；

图2为如图1所示的移动终端的通信系统示意图；

图3为本发明实施例中进行信息交互的各方硬件实体的示意图；

图4为本发明实施例一方法的实现流程示意图；

图5为本发明实施例一系统架构的示意图；

图6为本发明实施例一终端的硬件结构示意图；

图7-8为应用本发明实施例前、后的请求数据量对比示意图；

图8-9为应用本发明实施例前、后的数据同步对比示意图；

图11为应用本发明实施例后页面延时的效果示意图；

图12为采用本发明实施例一终端和服务器构成的整体架构示意图；

图13-16为采用本发明实施例一金融场景中多个金融信息示意图；

图17为采用本发明实施例一数据处理示意图；

图18为采用本发明实施例一数据格式化的示意图；

图19为采用图18进行格式化处理后得到的处理效果示意图。

具体实施方式

下面结合附图对技术方案的实施作进一步的详细描述。

现在将参考附图描述实现本发明各个实施例的移动终端。在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明实施例的说明，其本身并没有特定的意义。因此，"模块"与"部件"可以混合地使用。

在下面的详细说明中，陈述了众多的具体细节，以便彻底理解本发明。不过，对于本领域的普通技术人员来说，显然可在没有这些具体细节的情况下实践本发明。在其他情况下，没有详细说明公开的公知方法、过程、组件、电路和网络，以避免不必要地使实施例的各个方面模糊不清。

另外，本文中尽管多次采用术语“第一”、“第二”等来描述各种元件(或各种阈值或各种应用或各种指令或各种操作)等，不过这些元件(或阈值或应用或指令或操作)不应受这些术语的限制。这些术语只是用于区分一个元件(或阈值或应用或指令或操作)和另一个元件(或阈值或应用或指令或操作)。例如，第一操作可以被称为第二操作，第二操作也可以被称为第一操作，而不脱离本发明的范围，第一操作和第二操作都是操作，只是二者并不是相同的操作而已。

本发明实施例中的步骤并不一定是按照所描述的步骤顺序进行处理，可以按照需求有选择的将步骤打乱重排，或者删除实施例中的步骤，或者增加实施例中的步骤，本发明实施例中的步骤描述只是可选的顺序组合，并不代表本发明实施例的所有步骤顺序组合，实施例中的步骤顺序不能认为是对本发明的限制。

本发明实施例中的术语“和/或”指的是包括相关联的列举项目中的一个或多个的任何和全部的可能组合。还要说明的是：当用在本说明书中时，“包括/包含”指定所陈述的特征、整数、步骤、操作、元件和/或组件的存在，但是不排除一个或多个其他特征、整数、步骤、操作、元件和/或组件和/或它们的组群的存在或添加。

本发明实施例的智能终端(如移动终端)可以以各种形式来实施。例如，本发明实施例中描述的移动终端可以包括诸如移动电话、智能电话、笔记本电脑、数字广播接收器、个人数字助理(PDA，Personal Digital Assistant)、平板电脑(PAD)、便携式多媒体播放器(PMP，Portable Media Player)、导航装置等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。下面，假设终端是移动终端。然而，本领域技术人员将理解的是，除了特别用于移动目的的元件之外，根据本发明的实施方式的构造也能够应用于固定类型的终端。

图1为实现本发明各个实施例的移动终端一个可选的硬件结构示意图。

移动终端100可以包括通信单元110、音频/视频(A/V)输入单元120、用户输入单元130、合并单元140、请求单元141、接收单元142、拆分单元143、格式化处理单元144、输出单元150、存储单元160、接口单元170、处理单元180和电源单元190等等。图1示出了具有各种组件的移动终端，但是应理解的是，并不要求实施所有示出的组件。可以替代地实施更多或更少的组件。将在下面详细描述移动终端的元件。

通信单元110通常包括一个或多个组件，其允许移动终端100与无线通信系统或网络之间的无线电通信(如果将移动终端用固定终端代替，也可以通过有线方式进行电通信)。例如，通信单元具体为无线通信单元时可以包括广播接收单元111、移动通信单元112、无线互联网单元113、短程通信单元114和位置信息单元115中的至少一个，这些单元是可选的，根据不同需求可以增删。

广播接收单元111经由广播信道从外部广播管理服务器接收广播信号和/或广播相关信息。广播信道可以包括卫星信道和/或地面信道。广播管理服务器可以是生成并发送广播信号和/或广播相关信息的服务器或者接收之前生成的广播信号和/或广播相关信息并且将其发送给终端的服务器。广播信号可以包括TV广播信号、无线电广播信号、数据广播信号等等。而且，广播信号可以进一步包括与TV或无线电广播信号组合的广播信号。广播相关信息也可以经由移动通信网络提供，并且在该情况下，广播相关信息可以由移动通信单元112来接收。广播信号可以以各种形式存在，例如，其可以以数字多媒体广播(DMB，Digital Multimedia Broadcasting)的电子节目指南(EPG，Electronic Program Guide)、数字视频广播手持(DVB-H，Digital Video Broadcasting-Handheld)的电子服务指南(ESG，Electronic Service Guide)等等的形式而存在。广播接收单元111可以通过使用各种类型的广播系统接收信号广播。特别地，广播接收单元111可以通过使用诸如多媒体广播-地面(DMB-T，Digital Multimedia Broadcasting-Terrestrial)、数字多媒体广播-卫星(DMB-S，Digital Multimedia Broadcasting-Satellite)、DVB-H，前向链路媒体(MediaFLO，Media Forward Link Only)的数据广播系统、地面数字广播综合服务(ISDB-T，Integrated Services Digital Broadcasting-Terrestrial)等等的数字广播系统接收数字广播。广播接收单元111可以被构造为适合提供广播信号的各种广播系统以及上述数字广播系统。经由广播接收单元111接收的广播信号和/或广播相关信息可以存储在存储单元160(或者其它类型的存储介质)中。

移动通信单元112将无线电信号发送到基站(例如，接入点、节点B等等)、外部终端以及服务器中的至少一个和/或从其接收无线电信号。这样的无线电信号可以包括语音通话信号、视频通话信号、或者根据文本和/或多媒体消息发送和/或接收的各种类型的数据。

无线互联网单元113支持移动终端的无线互联网接入。该单元可以内部或外部地耦接到终端。该单元所涉及的无线互联网接入技术可以包括无线局域网络(Wi-Fi，Wireless Local Area Networks)、无线宽带(Wibro)、全球微波互联接入(Wimax)、高速下行链路分组接入(HSDPA，High Speed Downlink Packet Access)等等。

短程通信单元114是用于支持短程通信的单元。短程通信技术的一些示例包括蓝牙、射频识别(RFID，Radio Frequency Identification)、红外数据协会(IrDA，InfraredData Association)、超宽带(UWB，Ultra Wideband)、紫蜂等等。

位置信息单元115是用于检查或获取移动终端的位置信息的单元。位置信息单元的典型示例是全球定位系统(GPS，Global Positioning System)。根据当前的技术，位置信息单元115计算来自三个或更多卫星的距离信息和准确的时间信息并且对于计算的信息应用三角测量法，从而根据经度、纬度和高度准确地计算三维当前位置信息。当前，用于计算位置和时间信息的方法使用三颗卫星并且通过使用另外的一颗卫星校正计算出的位置和时间信息的误差。此外，位置信息单元115能够通过实时地连续计算当前位置信息来计算速度信息。

A/V输入单元120用于接收音频或视频信号。A/V输入单元120可以包括相机121和麦克风122，相机121对在视频捕获模式或图像捕获模式中由图像捕获装置获得的静态图片或视频的图像数据进行处理。处理后的图像帧可以显示在显示单元151上。经相机121处理后的图像帧可以存储在存储单元160(或其它存储介质)中或者经由通信单元110进行发送，可以根据移动终端的构造提供两个或更多相机121。麦克风122可以在电话通话模式、记录模式、语音识别模式等等运行模式中经由麦克风接收声音(音频数据)，并且能够将这样的声音处理为音频数据。处理后的音频(语音)数据可以在电话通话模式的情况下转换为可经由移动通信单元112发送到移动通信基站的格式输出。麦克风122可以实施各种类型的噪声消除(或抑制)算法以消除(或抑制)在接收和发送音频信号的过程中产生的噪声或者干扰。

用户输入单元130可以根据用户输入的命令生成键输入数据以控制移动终端的各种操作。用户输入单元130允许用户输入各种类型的信息，并且可以包括键盘、鼠标、触摸板(例如，检测由于被接触而导致的电阻、压力、电容等等的变化的触敏组件)、滚轮、摇杆等等。特别地，当触摸板以层的形式叠加在显示单元151上时，可以形成触摸屏。

合并单元140，用于将至少两个业务请求合并为第一请求；请求单元141，用于发送所述第一请求给服务器，请求与服务器建立全双工的通信连接；接收单元142，用于在基于所述通信连接得到的数据传输通道上，接收对应所述第一请求的反馈数据；拆分单元143，用于根据从所述至少两个业务请求中解析得到的请求参数，将所述反馈数据对应拆分为至少两组第一数据；格式化处理单元144，用于对所述至少两组第一数据进行格式化处理，得到至少两组第二数据；相应的，显示单元151，还用于将所述至少两组第二数据提供给业务应用层，在所述业务应用层中进行业务数据的展示。

接口单元170用作至少一个外部装置与移动终端100连接可以通过的接口。例如，外部装置可以包括有线或无线头戴式耳机端口、外部电源(或电池充电器)端口、有线或无线数据端口、存储卡端口、用于连接具有识别单元的装置的端口、音频输入/输出(I/O)端口、视频I/O端口、耳机端口等等。识别单元可以是存储用于验证用户使用移动终端100的各种信息并且可以包括用户识别单元(UIM，User Identify Module)、客户识别单元(SIM，Subscriber Identity Module)、通用客户识别单元(USIM，Universal SubscriberIdentity Module)等等。另外，具有识别单元的装置(下面称为"识别装置")可以采取智能卡的形式，因此，识别装置可以经由端口或其它连接装置与移动终端100连接。接口单元170可以用于接收来自外部装置的输入(例如，数据信息、电力等等)并且将接收到的输入传输到移动终端100内的一个或多个元件或者可以用于在移动终端和外部装置之间传输数据。

另外，当移动终端100与外部底座连接时，接口单元170可以用作允许通过其将电力从底座提供到移动终端100的路径或者可以用作允许从底座输入的各种命令信号通过其传输到移动终端的路径。从底座输入的各种命令信号或电力可以用作用于识别移动终端是否准确地安装在底座上的信号。输出单元150被构造为以视觉、音频和/或触觉方式提供输出信号(例如，音频信号、视频信号、振动信号等等)。输出单元150可以包括显示单元151、音频输出单元152等等。

显示单元151可以显示在移动终端100中处理的信息。例如，移动终端100可以显示相关用户界面(UI，User Interface)或图形用户界面(GUI，Graphical User Interface)。当移动终端100处于视频通话模式或者图像捕获模式时，显示单元151可以显示捕获的图像和/或接收的图像、视频、或图像以及相关功能的UI或GUI等等。

同时，当显示单元151和触摸板以层的形式彼此叠加以形成触摸屏时，显示单元151可以用作输入装置和输出装置。显示单元151可以包括液晶显示器(LCD，LiquidCrystal Display)、薄膜晶体管LCD(TFT-LCD，Thin Film Transistor-LCD)、有机发光二极管(OLED，Organic Light-Emitting Diode)显示器、柔性显示器、三维(3D)显示器等等中的至少一种。这些显示器中的一些可以被构造为透明状以允许用户从外部观看，这可以称为透明显示器，典型的透明显示器可以例如为透明有机发光二极管(TOLED)显示器等等。根据特定想要的实施方式，移动终端100可以包括两个或更多显示单元(或其它显示装置)，例如，移动终端可以包括外部显示单元(未示出)和内部显示单元(未示出)。触摸屏可用于检测触摸输入压力以及触摸输入位置和触摸输入面积。

音频输出单元152可以在移动终端处于呼叫信号接收模式、通话模式、记录模式、语音识别模式、广播接收模式等等模式下时，将通信单元110接收的或者在存储单元160中存储的音频数据转换音频信号并且输出为声音。而且，音频输出单元152可以提供与移动终端100执行的特定功能相关的音频输出(例如，呼叫信号接收声音、消息接收声音等等)。音频输出单元152可以包括扬声器、蜂鸣器等等。

存储单元160可以存储由处理单元180执行的处理和控制操作的软件程序等等，或者可以暂时地存储已经输出或将要输出的数据(例如，电话簿、消息、静态图像、视频等等)。而且，存储单元160可以存储关于当触摸施加到触摸屏时输出的各种方式的振动和音频信号的数据。

存储单元160可以包括至少一种类型的存储介质，所述存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等等)、随机访问存储器(RAM，Random AccessMemory)、静态随机访问存储器(SRAM，Static Random Access Memory)、只读存储器(ROM，Read Only Memory)、电可擦除可编程只读存储器(EEPROM，Electrically ErasableProgrammable Read Only Memory)、可编程只读存储器(PROM，Programmable Read OnlyMemory)、磁性存储器、磁盘、光盘等等。而且，移动终端100可以与通过网络连接执行存储单元160的存储功能的网络存储装置协作。

处理单元180通常控制移动终端的总体操作。例如，处理单元180执行与语音通话、数据通信、视频通话等等相关的控制和处理。又如，处理单元180可以执行模式识别处理，以将在触摸屏上执行的手写输入或者图片绘制输入识别为字符或图像。

电源单元190在处理单元180的控制下接收外部电力或内部电力并且提供操作各元件和组件所需的适当的电力。

这里描述的各种实施方式可以以使用例如计算机软件、硬件或其任何组合的计算机可读介质来实施。对于硬件实施，这里描述的实施方式可以通过使用特定用途集成电路(ASIC，Application Specific Integrated Circuit)、数字信号处理器(DSP，DigitalSignal Processing)、数字信号处理装置(DSPD，Digital Signal Processing Device)、可编程逻辑装置(PLD，Programmable Logic Device)、现场可编程门阵列(FPGA，FieldProgrammable Gate Array)、处理器、控制器、微控制器、微处理器、被设计为执行这里描述的功能的电子单元中的至少一种来实施，在一些情况下，这样的实施方式可以在处理单元180中实施。对于软件实施，诸如过程或功能的实施方式可以与允许执行至少一种功能或操作的单独的软件单元来实施。软件代码可以由以任何适当的编程语言编写的软件应用程序(或程序)来实施，软件代码可以存储在存储单元160中并且由处理单元180执行。其中，存储单元160的一个具体硬件实体可以为存储器，处理单元180的一个具体硬件实体可以为控制器。

至此，已经按照其功能描述了移动终端。下面，为了简要起见，将描述诸如折叠型、直板型、摆动型、滑动型移动终端等等的各种类型的移动终端中的滑动型移动终端作为示例。因此，本发明能够应用于任何类型的移动终端，并且不限于滑动型移动终端。

如图1中所示的移动终端100可以被构造为利用经由帧或分组发送数据的诸如有线和无线通信系统以及基于卫星的通信系统来操作。

现在将参考图2描述其中根据本发明实施例的移动终端能够操作的通信系统。

这样的通信系统可以使用不同的空中接口和/或物理层。例如，由通信系统使用的空中接口包括例如频分多址(FDMA，Frequency Division Multiple Access)、时分多址(TDMA，Time Division Multiple Access)、码分多址(CDMA，Code Division MultipleAccess)和通用移动通信系统(UMTS，Universal Mobile Telecommunications System)(特别地，长期演进(LTE，Long Term Evolution))、全球移动通信系统(GSM)等等。作为非限制性示例，下面的描述涉及CDMA通信系统，但是这样的教导同样适用于其它类型的系统。

参考图2，CDMA无线通信系统可以包括多个移动终端100、多个基站(BS，BaseStation)270、基站控制器(BSC，Base Station Controller)275和移动交换中心(MSC，Mobile Switching Center)280。MSC280被构造为与公共电话交换网络(PSTN，PublicSwitched Telephone Network)290形成接口。MSC280还被构造为与可以经由回程线路耦接到BS270的BSC275形成接口。回程线路可以根据若干已知的接口中的任一种来构造，所述接口包括例如E1/T1、ATM、IP、PPP、帧中继、HDSL、ADSL或xDSL。将理解的是，如图2中所示的系统可以包括多个BSC275。

每个BS270可以服务一个或多个分区(或区域)，由多向天线或指向特定方向的天线覆盖的每个分区放射状地远离BS270。或者，每个分区可以由用于分集接收的两个或更多天线覆盖。每个BS270可以被构造为支持多个频率分配，并且每个频率分配具有特定频谱(例如，1.25MHz，5MHz等等)。

分区与频率分配的交叉可以被称为CDMA信道。BS270也可以被称为基站收发器子系统(BTS，Base Transceiver Station)或者其它等效术语。在这样的情况下，术语“基站”可以用于笼统地表示单个BSC275和至少一个BS270。基站也可以被称为“蜂窝站”。或者，特定BS270的各分区可以被称为多个蜂窝站。

如图2中所示，广播发射器(BT，Broadcast Transmitter)295将广播信号发送给在系统内操作的移动终端100。如图1中所示的广播接收单元111被设置在移动终端100处以接收由BT295发送的广播信号。在图2中，示出了几个卫星300，例如可以采用GPS卫星300。卫星300帮助定位多个移动终端100中的至少一个。

在图2中，描绘了多个卫星300，但是理解的是，可以利用任何数目的卫星获得有用的定位信息。如图1中所示的位置信息单元115通常被构造为与卫星300配合以获得想要的定位信息。替代GPS跟踪技术或者在GPS跟踪技术之外，可以使用可以跟踪移动终端的位置的其它技术。另外，至少一个GPS卫星300可以选择性地或者额外地处理卫星DMB传输。

作为无线通信系统的一个典型操作，BS270接收来自各种移动终端100的反向链路信号。移动终端100通常参与通话、消息收发和其它类型的通信。特定基站接收的每个反向链路信号被在特定BS270内进行处理。获得的数据被转发给相关的BSC275。BSC275提供通话资源分配和包括BS270之间的软切换过程的协调的移动管理功能。BSC275还将接收到的数据路由到MSC280，其提供用于与PSTN290形成接口的额外的路由服务。类似地，PSTN290与MSC280形成接口，MSC280与BSC275形成接口，并且BSC275相应地控制BS270以将正向链路信号发送到移动终端100。

移动终端中通信单元110的移动通信单元112基于移动终端内置的接入移动通信网络(如2G/3G/4G等移动通信网络)的必要数据(包括用户识别信息和鉴权信息)接入移动通信网络为移动终端用户的网页浏览、网络多媒体播放等业务传输移动通信数据(包括上行的移动通信数据和下行的移动通信数据)。

通信单元110的无线互联网单元113通过运行无线热点的相关协议功能而实现无线热点的功能，无线热点支持多个移动终端(移动终端之外的任意移动终端)接入，通过复用移动通信单元112与移动通信网络之间的移动通信连接为移动终端用户的网页浏览、网络多媒体播放等业务传输移动通信数据(包括上行的移动通信数据和下行的移动通信数据)，由于移动终端实质上是复用移动终端与通信网络之间的移动通信连接传输移动通信数据的，因此移动终端消耗的移动通信数据的流量由通信网络侧的计费实体计入移动终端的通信资费，从而消耗移动终端签约使用的通信资费中包括的移动通信数据的数据流量。

图3为本发明实施例中进行信息交互的各方硬件实体的示意图，图3中包括：终端设备1，服务器2。其中，终端设备1由终端设备11-14构成，终端设备11-14通过有线网络或者无线网络与服务器进行信息交互。终端设备11-14包括手机、台式机、PC机、一体机等类型。采用本发明实施例，主要的处理逻辑在终端执行，包括：将业务请求发送给服务器之前，先在终端进行多个业务请求的合并，及，从服务器得到反馈数据(反馈数据可以理解为原始数据)后，将反馈数据拆分为对应多个业务请求的多个数据，对多个数据进行格式化的处理，输出给执行各个业务的各个业务模块，而无需执行各个业务的各个业务模块自行处理。服务器的作用是根据终端的请求来提供上述原始数据，且该原始数据的反馈方式只有第一次需要终端发起请求，当建立了终端与服务器间的全双工通信的数据传输通道后，服务器每当监测到最新的数据，就基于该数据传输通道主动推送给终端。比如，业务模块包括：股票模块1-5，如果股票模块1、股票模块2、股票模块3分别发送股票信息请求，股票模块4、股票模块5也分别发送股票信息请求，由于请求的数据可能有相同的部分，因此，多次的请求会得到部分重复的相同数据，带来数据冗余，而且，终端与服务器间的多次请求带来的数据交互会占用带宽，降低处理效率。采用本发明实施例，是将多次请求合并后再发送给服务器，来请求原始数据，因此，“化繁为简”，提高了处理效率。将合并请求得到的原始数据拆分后，得到股票模块1、股票模块2、股票模块3、股票模块4、股票模块5分别所需的数据。但是，这个数据是原始数据，不一定符合各个股票模块的实际格式需求，因此，采用本发明实施例，可以按照各个股票模块的实际格式需求，对原始数据进行格式化处理，之后，将处理后的数据直接提供给各个股票模块直接展示即可。采用本发明实施例，可以达到实时数据同步、数据格式统一，避免了冗余请求占用的过多带宽及自行进行格式处理占用的过多终端处理资源，最终，提高了数据处理效率。

终端的处理逻辑10包括：S1、将至少两个业务请求合并为第一请求，发送第一请求给服务器，请求与服务器建立全双工的通信连接。S2、在基于通信连接得到的数据传输通道上，接收对应第一请求的反馈数据，根据从至少两个业务请求中解析得到的请求参数，将反馈数据根据请求参数对应拆分为至少两组第一数据。S3、对至少两组第一数据进行格式化处理，得到至少两组第二数据后，将至少两组第二数据提供给业务应用层，在业务应用层中进行业务数据的展示。

上述图3的例子只是实现本发明实施例的一个系统架构实例，本发明实施例并不限于上述图3所述的系统结构，基于上述图3所述的系统架构，提出本发明方法各个实施例。

本发明实施例的数据处理方法，如图4所示，所述方法包括：终端将至少两个业务请求合并为第一请求(101)。终端发送所述第一请求给服务器，并请求与服务器建立全双工的通信连接(102)。在基于所述通信连接得到的数据传输通道上，终端接收对应所述第一请求的反馈数据(103)。具体的，终端和服务器间只需要做一个握手的动作，就可以实现在单个请求和应答的标准(TCP)连接上进行全双工通讯。然后，在终端和服务器之间就形成了一条快速通道(如该数据传输通道)，两者之间就直接可以数据互相传送。每当有新数据时，服务器就主动推送数据给终端，具体是将数据主动推送给终端上的浏览器应用，而不用终端发起请求。也就是说，只有一次请求，一次连接，连续的多次数据交换，从而避免了采用轮询机制需要重复发起多次请求导致过多占用带宽的问题，提高了数据处理效率。

本发明实施例的数据处理方法，还包括：根据从所述至少两个业务请求中解析得到的请求参数(如股票业务中的产品代码和/或技术指标等)，将所述反馈数据对应拆分为至少两组第一数据(104)。对所述至少两组第一数据进行格式化处理，得到至少两组第二数据(105)。

本发明实施例中，上述解析、格式化处理等操作都可以通过终端中设置的中间件来实现。通过该中间件的一次数据格式化处理，就可以通用到各种业务。由于是抽离模块的机制，因此，独立性高、复用性高，适用于各种场景的使用。中间件的处理逻辑符合“黑盒”逻辑。“黑盒”逻辑指：接入方接入时，只需要按照约定给与请求的请求参数，即可拿到请求所需要的、格式化后的数据，而无需关注内部的具体实现方式。对应不同业务的数据，都是通过该中间件事先格式化处理好的，在终端侧的用户侧，或称终端上层业务应用这一侧，无需分别执行对应的处理，只需要得到经中间件格式化处理所得到的输出数据，并直接显示该输出数据到业务应用上即可，从而，避免了终端中各个业务模块(如用于执行不同业务应用的对应模块)自行执行处理所过多占用终端处理资源的问题，提高了数据处理效率。

本发明实施例的数据处理方法，还包括：将所述至少两组第二数据提供给业务应用层，在所述业务应用层中进行业务数据的展示(106)。在本发明实施例中，中、高、低端的浏览器都可以使用同一套输入、接受相同格式输出。在不同业务应用中进行切换时，还可以包括：自动根据系统类型进行行情数据的获取方式切换。

采用本发明实施例，可以确保数据的实时同步更新、且数据格式为统一的数据格式，既不会导致终端与服务器交互时占用很多的带宽，又不会占用过多终端处理资源，使得就数据处理效率而言，无论是对终端自身，还是对终端和服务器构成的系统来说，以最少的开发和维护成本，能达到最佳的预期处理效果。

本发明实施例中，在终端可以设置中间件，该中间件用于执行上述S1-S3构成的处理逻辑10。该处理逻辑10可以兼容终端的低端浏览器和高端浏览器。这些浏览器可以是网页版本的，也可以以浏览器应用的形式存在。

本发明实施例中，以应用为例，所谓低端浏览器指：采用轮询机制与后台服务器进行交互的应用客户端，如在获取信息的实时更新时，该应用客户端是定时循环地向服务器发起超文本传输协议(HTTP，HyperText Transfer Protocol)轮询请求、或者Comet长轮询请求，等待服务器返回所请求的数据，之后，还可以对该数据做格式化的处理，以最终将处理后的数据展示到应用客户端的页面上。其中，1)HTTP是一个终端和服务器端请求和应答的标准。终端是终端用户，服务器端是网站。通过使用Web浏览器、网络爬虫或者其它的工具，终端发起一个到服务器上指定端口(默认端口为80)的HTTP请求。终端可以称为用户代理(user agent)。应答的服务器上存储着(一些)资源，比如HTML文件和图像。这个应答服务器为源服务器(origin server)。在用户代理和源服务器中间可能存在多个中间层。比如，由终端上的HTTP应用客户端发起一个HTTP请求，建立一个到服务器指定端口(默认是80端口)的TCP连接。HTTP服务器则在那个端口监听该应用客户端发送过来的请求。一旦收到请求，服务器向该应用客户端发回一个状态行，比如"HTTP/1.1 200OK"，以作为响应消息。2)Comet是一种新的Web应用架构，基于这种架构开发的应用中，服务器端会主动以异步的方式向终端上的应用推送数据，而不需要终端上的应用显式的发出请求。

本发明实施例中，以应用为例，所谓高端浏览器指：与上述轮询机制这种超级耗费带宽流量的方式相比，采用websocket模式的数据全双工通信方式，不受限于浏览器http的请求限制，改变了应用客户端需要多次、多业务模块向后台服务器数据请求的方式，通过单一链接来实现全双工的通信。所谓websocket指：在单个TCP连接上进行全双工通讯的协议。

可见：本发明实施例可以兼容各种高、中、低端浏览器的使用，对于同一套数据请求，对于使用方，具备了傻瓜式的接入，实时高效准确的输出数据给业务层使用。

本发明实施例中，通过该中间件可以抽离各个模块各个业务需要独立重复处理数据的功能，合并数据格式化需求，生成一套相同输入、格式化输出的黑盒处理逻辑，完成了一套推送行情系统，使得金融业务，最需要重视的数据实时性和统一性得到了很好的解决。使得数据处理过程对于业务和模块来说，都是不需要关注的过程，完全黑盒输出到业务端。采用本发明实施例，大大节省了实时金融业务的数据请求带宽，提供了实时准确的数据更新，减少了业务和模块间的数据差异化表现，给与用户对金融产品的分析研究提供了最直观、有效的依据。

本发明实施例中，就websocket模式而言，是一种在单个TCP连接上进行全双工通讯的协议。具体的，websocket协议是基于TCP的一种新的协议。websocket作为基于TCP的套接字API的占位符，实现了浏览器与服务器全双工通信。很多网站为了实现即时通讯，所用的技术都是轮询。轮询是在特定的时间间隔(如每1秒)，由浏览器对服务器发出HTTP请求，然后由服务器返回最新的数据给应用客户端的浏览器。这种传统的HTTP请求的模式带来的问题是：浏览器需要不断的向服务器发出请求，然而，HTTP请求的报文头是非常长的，里面包含的有用数据可能只是一个很小的值，这样会占用很多的带宽。而比较新的技术去做轮询的效果是Comet技术，这种技术虽然可达到全双工通信，但依然需要发出请求。而websocket是在浏览器和服务器只需要做一个握手的动作，然后，浏览器和服务器之间就形成了一条快速通道。两者之间就直接可以数据互相传送。

需要指出的是，本发明实施例中的websocket模式，不同于现有websocket技术，现有websocket具有很大的浏览器局限性，业内使用也是只局限于高级浏览器中使用。而本发明实施例是将websocket和数据轮询在系统内部进行了结合，自动根据系统类型进行行情数据的获取方式切换，相对于业务侧来说，根本不需要关注自身浏览器的类型，中高低端浏览器都使用同一套输入、接受相同格式输出。

本发明实施例中，就请求合并而言，将所述至少两个业务请求中，每一个业务请求对应的所述请求参数进行参数类型的分解，得到至少两个第一参数类型(如产品代码)和至少两个第二参数类型(如技术指标)。将所述至少两个第一参数类型进行合并，得到第一参数数组。将所述第一参数数组封装至所述第一请求中的第一字段中，终端发送第一请求给服务器。

之后，根据从所述至少两个业务请求中解析得到的请求参数，将所述反馈数据对应拆分为至少两组第一数据，包括：从第一字段中，解析出由至少两个第一参数类型合并得到的第一参数数组，从第一参数数组中解析出至少两个第一参数类型，比如，对应第一业务请求的第一参数类型为n1，从所述反馈数据中将n1对应的请求数据查询出来，若该请求数据为n1_1，……，n1_x，x为大于1的正整数，则将请求数据“n1_1，……，n1_x”提供给终端侧的中间件进行格式化处理，得到输出数据为“N1_1，……，N1_x”，将输出数据“N1_1，……，N1_x”提供给触发该第一业务请求的第一业务应用(或称实现该第一业务应用的第一业务模块)使用，至少可以展示该输出数据“N1_1，……，N1_x”。

本发明实施例中，就请求合并而言，将所述至少两个业务请求中，每一个业务请求对应的所述请求参数进行参数类型的分解，得到至少两个第一参数类型(如产品代码)和至少两个第二参数类型(如技术指标)。将所述至少两个第二参数类型进行合并，得到第二参数数组。将所述第二参数数组封装至所述第一请求中的第二字段中。

之后，根据从所述至少两个业务请求中解析得到的请求参数，将所述反馈数据对应拆分为至少两组第一数据，包括：从第二字段中，解析出由至少两个第二参数类型合并得到的第二参数数组，从第二参数数组中解析出至少两个第二参数类型，比如，对应第二业务请求的第二参数类型为n2，从所述反馈数据中将n2对应的请求数据查询出来，若该请求数据为n2_1，……，n2_x，x为大于1的正整数，则将请求数据“n2_1，……，n2_x”提供给终端侧的中间件进行格式化处理，得到输出数据为“N2_1，……，N2_x”，将输出数据“N2_1，……，N2_x”提供给触发该第二业务请求的第二业务应用(或称实现该第二业务应用的第二业务模块)使用，至少可以展示该输出数据“N2_1，……，N2_x”。

本发明实施例中，就请求合并而言，将所述至少两个业务请求中，每一个业务请求对应的所述请求参数进行参数类型的分解，得到至少两个第一参数类型(如产品代码)和至少两个第二参数类型(如技术指标)。将所述至少两个第一参数类型进行合并，得到第一参数数组。将所述至少两个第二参数类型进行合并，得到第二参数数组。将所述第一参数数组封装至所述第一请求中的第一字段中。将所述第二参数数组封装至所述第一请求中的第二字段中。

结合上述两个实施例的描述，本实施例在发送所述第一请求后，根据从所述至少两个业务请求中解析得到的请求参数，将所述反馈数据对应拆分为至少两组第一数据，包括：分别从第一字段及第二字段中，解析出第一参数数组及第二参数数组。对应第一业务请求的第一参数类型为n1，从所述反馈数据中将n1对应的请求数据查询出来，若该请求数据为n1_1，……，n1_x，x为大于1的正整数，则将请求数据“n1_1，……，n1_x”提供给终端侧的中间件进行格式化处理，得到输出数据为“N1_1，……，N1_x”，将输出数据“N1_1，……，N1_x”提供给触发该第一业务请求的第一业务应用(或称实现该第一业务应用的第一业务模块)使用，至少可以展示该输出数据“N1_1，……，N1_x”。同理，对应第二业务请求的第二参数类型为n2，从所述反馈数据中将n2对应的请求数据查询出来，若该请求数据为n2_1，……，n2_x，x为大于1的正整数，则将请求数据“n2_1，……，n2_x”提供给终端侧的中间件进行格式化处理，得到输出数据为“N2_1，……，N2_x”，将输出数据“N2_1，……，N2_x”提供给触发该第二业务请求的第二业务应用(或称实现该第二业务应用的第二业务模块)使用，至少可以展示该输出数据“N2_1，……，N2_x”。

本发明实施例中，所述将至少两个业务请求合并为第一请求之前，进行信息注册和存档。具体的，从所述至少两个业务请求中分别解析出所述请求参数。以某金融场景为例，比如，股票业务应用中，包括多个股票代码，如XX银行、XX制造企业、XX制药、XX化工等。本文中股票代码一个广泛的指代词可以为“产品代码”，但不限于该具体的名称。

每一个股票代码都有关键词字段，且多个股票代码间可以具备相同或不同的关键词字段，基于该股票代码和/或关键词字段可以构成请求参数，根据请求参数向服务器请求所需要的数据。在本实施例中，可以理解为不同的股票业务应用所需要的数据，可以是相同的数据，也可以是不同的数据。以股票而言，它对数据的实时性、是否能及时更新、以及数据格式的统一性具备比较高的要求。对此，采用本发明实施例，在确定了需要获取数据的股票代码字段和需要获取数据的关键词字段之后，将这两种信息(如股票代码字段和关键词字段)进行注册，如通过终端中的注册模块来实现。除了注册这两种信息，还需要在注册模块中注册好数据回调的方式，以便在终端与服务器间建立websocket形式的数据传输通道后，可以根据该数据回调的方式来实时获取到服务器主动推送过来的数据。之后，可以根据中间件的格式化处理，得到格式化处理后的数据对象，最终，对该格式化处理后的数据对象进行业务数据的展示。也就是说，对于终端的业务应用侧，只需要关注自己需要的产品代码和信息关键词字段，输出给两个信息，及进行注册。之后，会得到统一格式化处理后的数据对象，直接使用并展示数据即可，无需关心中间的各个处理环节，从而提高了数据处理效率。

本发明实施例中，将所述请求参数进行参数数据的注册，缓存为第一注册数据。第一注册数据用于指代一种注册信息的类型，对应多个业务请求，由于每一个业务请求中都包含请求参数(请求参数可能相同或不同)，因此，在第一注册数据中实际上包括多个注册信息，每个注册信息与每一个业务请求相对应，根据每一个业务请求中的请求参数所生成。每个注册信息是在发起业务请求时予以注册，触发切换请求或注销请求时，予以从所述第一注册数据中注销。

本发明实施例中，将与所述请求参数对应的请求数据进行数据回调方式的注册，缓存为第二注册数据。具体的，可以通过终端侧的注册模块发起注册请求(如参数数据的注册、及数据回调方式的注册)，将第一注册数据和第二注册数据都缓存下来，以便后续进行数据的推送分发。对应多个业务请求，可以有多个注册模块，给每个注册模块分配一个注册ID，然后进行注册数据的合并处理，以便向服务器做统一的请求处理。在合并后得到的一个统一的第一请求中，可以包含并后的产品代码，封装入第一请求的字段“symbols”中，还可以包含合并后的技术指标，封住入第一请求的字段“keys”中。终端向服务器发起第一请求，请求建立websocket形式的数据传输通道，以进行数据交互处理。将“symbols”和“keys”都发送给服务器。最后，当终端监听到回调事件，对基于该回调事件反馈的数据做接受处理，得到反馈数据后，根据之前分配的注册ID进行反馈数据的拆分，对应到不同的多个业务请求，进行格式化处理后再提供给多个业务使用。

本发明实施例中，根据之前注册的信息来获取数据。根据从所述至少两个业务请求中解析得到的请求参数，将所述反馈数据对应拆分为至少两组第一数据。具体的，根据所述第二注册数据得到所述反馈数据；根据所述第一注册数据将所述反馈数据对应拆分为至少两组第一数据。

本发明实施例中，对所述至少两组第一数据进行格式化处理，得到至少两组第二数据，可以采用管道流数据的形式。具体的，获取对应于第一业务请求的第一数据处理策略，根据所述第一数据处理策略对第一组第一数据进行格式化处理，得到第一组第二数据，将所述第一组第二数据输出给至少一个业务应用。获取对应于第二业务请求的第二数据处理策略，根据所述第二数据处理策略对第二组第一数据进行格式化处理，得到第二组第二数据，将所述第二组第二数据输出给至少一个业务应用。采用本发明实施例，每个管道的输出都可以在不同数据处理层面上单独使用

本发明实施例中，对所述至少两组第一数据进行格式化处理，得到至少两组第二数据，可以采用管道流数据的形式。具体的，获取对应于第一业务请求的第一数据处理策略，根据所述第一数据处理策略对第一组第一数据进行格式化处理，得到第一组第二数据，将所述第一组第二数据输出给对应第二业务请求的业务应用。获取对应于第二业务请求的第二数据处理策略，根据所述第二数据处理策略对所述第一组第二数据进行格式化处理，得到第二组第二数据。将所述第二组第二数据输出给对应下一个业务请求的业务应用，直至对业务请求停止响应。将所述第一组第二数据和/或所述第二组第二数据输出给至少一个业务应用。采用本发明实施例，每个管道的输出都可以作为另一个业务模块的输入。

本发明实施例中，从输入而言，是终端作为接入方接入由终端和服务器构成的数据处理系统时，按照约定给予服务器终端所请求的请求参数，之后，无需关注各个处理环节，从输出而言，即无需关注内部的实现方式，就可以直接拿到终端请求所需要的、格式化处理后的数据。实际应用中，可以采用管道式的数据处理流。具体来说，管道式的数据处理流指：对于触发多个业务请求的多个业务应用(或称实现该业务应用的业务模块)而言，一个业务模块的输出作为另一个业务模块的输入，“输入-输出”所形成的“管道”互相连接，进行数据的流处理。每个管道的输出都可以在不同数据处理层面上单独使用，也就是说，某前端业务模块的数据，在实际应用中是可以在任意一个业务模块上都可以单独使用的，也可以经过多个业务模块后流转至某个中间业务模块或者末端的业务模块进行使用。也就是说，基于该中间件的管道式的数据处理流，相对于接入的业务侧来说，也是一个黑盒逻辑，即不需要关注内部数据处理过程如何，只需要关注自己需要什么样的数据即可。

本发明实施例中，根据多个业务间的切换请求，可以注销之前业务对应的注册信息，以释放资源，提高数据处理效率。同样的，至于业务自身的注销请求，也同样会导致注册信息的注销，以释放资源，提高数据处理效率。具体的，在所述业务应用层中进行业务数据的展示时，所述业务数据对应于第一业务请求。获取业务切换请求，当所述业务切换请求为由第一业务请求切换至第二业务请求时，在所述第一注册数据中注销对应于所述第一业务请求的注册信息，将对应于第二业务请求的注册信息予以注册。所述注册信息包括从第二业务请求中解析出的请求参数。

一个实例为：如果业务侧此时要展现业务模块C的自选组合数据，当前需要将业务模块A的自选组合切换到后台时，可以注销业务模块A对应的注册信息，将与业务模块C对应的注册信息予以注册。

本发明实施例的数据处理系统，如图5所示，包括终端41和服务器42。在将业务请求发送给服务器之前，先在终端41进行多个业务请求的合并。从服务器42得到反馈数据(反馈数据可以理解为原始数据)后，将反馈数据拆分为对应多个业务请求的多个数据，对多个数据进行格式化的处理，输出给执行各个业务的各个业务模块，而无需执行各个业务的各个业务模块自行处理。服务器42的作用是根据终端的请求来提供上述原始数据，且该原始数据的反馈方式只有第一次需要终端发起请求，当建立了终端41与服务器42间的全双工通信的数据传输通道后，服务器42每当监测到最新的数据，就基于该数据传输通道主动推送给终端41。其中，终端41包括：合并单元411，用于将至少两个业务请求合并为第一请求；请求单元412，用于发送所述第一请求给服务器，请求与服务器建立全双工的通信连接；接收单元413，用于在基于所述通信连接得到的数据传输通道上，接收对应所述第一请求的反馈数据；拆分单元414，用于根据从所述至少两个业务请求中解析得到的请求参数，将所述反馈数据对应拆分为至少两组第一数据；格式化处理单元415，用于对所述至少两组第一数据进行格式化处理，得到至少两组第二数据；展示单元416，用于将所述至少两组第二数据提供给业务应用层，在所述业务应用层中进行业务数据的展示。

在本发明实施例一实施方式中，所述合并单元，进一步用于：将所述至少两个业务请求中，每一个业务请求对应的所述请求参数进行参数类型的分解，得到至少两个第一参数类型和至少两个第二参数类型；将所述至少两个第一参数类型进行合并，得到第一参数数组；将所述第一参数数组封装至所述第一请求中的第一字段中。

在本发明实施例一实施方式中，所述合并单元，进一步用于：将所述至少两个业务请求中，每一个业务请求对应的所述请求参数进行参数类型的分解，得到至少两个第一参数类型和至少两个第二参数类型；将所述至少两个第二参数类型进行合并，得到第二参数数组；将所述第二参数数组封装至所述第一请求中的第二字段中。

在本发明实施例一实施方式中，所述合并单元，进一步用于：将所述至少两个业务请求中，每一个业务请求对应的所述请求参数进行参数类型的分解，得到至少两个第一参数类型和至少两个第二参数类型；将所述至少两个第一参数类型进行合并，得到第一参数数组；将所述至少两个第二参数类型进行合并，得到第二参数数组；将所述第一参数数组封装至所述第一请求中的第一字段中；将所述第二参数数组封装至所述第一请求中的第二字段中。

在本发明实施例一实施方式中，所述终端还包括：注册单元，用于：从所述至少两个业务请求中分别解析出所述请求参数；将所述请求参数进行参数数据的注册，缓存为第一注册数据；将与所述请求参数对应的请求数据进行数据回调方式的注册，缓存为第二注册数据。

在本发明实施例一实施方式中，所述格式化处理单元，进一步用于：获取对应于第一业务请求的第一数据处理策略，根据所述第一数据处理策略对第一组第一数据进行格式化处理，得到第一组第二数据，将所述第一组第二数据输出给至少一个业务应用；获取对应于第二业务请求的第二数据处理策略，根据所述第二数据处理策略对第二组第一数据进行格式化处理，得到第二组第二数据，将所述第二组第二数据输出给至少一个业务应用。

在本发明实施例一实施方式中，所述格式化处理单元，进一步用于：获取对应于第一业务请求的第一数据处理策略，根据所述第一数据处理策略对第一组第一数据进行格式化处理，得到第一组第二数据，将所述第一组第二数据输出给对应第二业务请求的业务应用；获取对应于第二业务请求的第二数据处理策略，根据所述第二数据处理策略对所述第一组第二数据进行格式化处理，得到第二组第二数据；将所述第二组第二数据输出给对应下一个业务请求的业务应用，直至对业务请求停止响应；将所述第一组第二数据和/或所述第二组第二数据输出给至少一个业务应用。

本发明实施例的计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现如上述实施例任一项所述数据处理方法的步骤。

本发明实施例的终端，如图6所示，所述终端包括：存储器61，用于存储能够在处理器上运行的计算机程序；处理器62，用于运行所述计算机程序时，执行如上述实施例中数据处理方法的步骤。所述终端还可以包括：外部通信接口63，外部通信接口63用于与服务器等外设进行信息交互。所述终端还可以包括：内部通信接口64，所述内部通信接口64具体可以是PCI总线等总线接口。

这里需要指出的是：以上涉及终端和服务器项的描述，与上述方法描述是类似的，同方法的有益效果描述，不做赘述。对于本发明终端和服务器实施例中未披露的技术细节，请参照本发明方法流程描述的实施例所描述内容。

以一个现实应用场景为例对本发明实施例阐述如下：

以金融场景为例，采用本发明实施例，可以是一种实时准确的多终端金融数据获取和输出系统。本文中，Push行情推送系统指：本发明实现的该金融数据实时获取、格式化输出的系统。本发明实施例支持如手机终端(iOS、Android的手机终端)和PC终端等终端设备，对金融场景中的所有股票的实时价格、涨跌额、涨跌幅等实时数据，以服务器端主动推送的方式推送到终端进行展现。

在金融产品的实时数据获取展现中，一般采用HTTP轮询或者Comet长轮询机制来实现。对于同一组金融产品，获取信息的实时变更，需要应用客户端定时循环的发起HTTP请求，等待服务器的返回，再对数据做格式化处理以展示到页面上。而且不同业务模块，如果有重复的金融产品，都需要重复冗余的发起请求，处理数据。没有合并统一处理的系统来做支撑。开发、维护成本都很大，而且模块和业务之间的数据更新不一致也成了一个不可避免的事实。

如图7所示为一种数据的获取方式。可以看出，市面上的产品，对金融产品的实时数据获取，都是做了定时循环的http请求，等待服务器的数据返回。而且不能排除此时其实已经休盘或者未开盘休市等状态下，无效多余的请求发送。更加致命的是，因为应用客户端不能保证此次请求，服务端数据是否已经有更新，是否是一个合理有效必须的请求，只能等待返回数据来判断是否是新数据，需要更新展现到页面上。导致了非常多，高达80％的多余http的请求，严重浪费了带宽和服务器负载。也就是说，采用HTTP轮询方式，没有一个通用的数据处理中间件，导致所有数据到达都要单独重复进行格式化处理。轮询方式虽然可以取得实时的数据更新，但是存在以下几个问题。

第一：依靠大量重复的HTTP请求来保证实时数据获取。浏览器需要不断的向服务器发出请求，然而HTTP请求的报文头(header)是非常长的，里面包含的有用数据可能只是一个很小的值，这样会占用很多的带宽。

第二：多个业务、不同模块，对于同一组金融产品的数据获取方式是单独重复冗余进行的。每个模块维护自己的一个定时器，对于返回数据做自己的数据处理。这样导致的问题是数据格式化处理的重复冗余。一处需求更改，多处模块需要同时修改。容易造成格式化不一致，给与用户很差的用户体验。

第三：多个业务、不同模块的数据更新不一致。由于单独的数据获取，时间不能保证实时同步。导致更新存在时差，同一时刻，同一支金融产品的信息数据可能存在不一致的情况。

针对以上问题，本发明实施例采用的是websocket方式，实时性高。将金融产品数据的实时获取展现，抽离成一个功能强大、数据精准、高度统一展现的系统，如Push行情推送系统，通过该系统可以解决以上提出的三个问题，使得金融业务，最需要重视的数据实时性和统一性得到了很好的解决。

由于在数据获取方式上，改变了http请求轮询，这样超级耗费带宽流量的方式，变成了使用websocket模式的数据全双工通信方式，因此，可以不受限于浏览器http的请求限制。由于改变应用客户端多次多模块数据请求的方式，变成了单一链接，全双工通信方式。实现了一套数据处理中间件，抽离各个模块各个业务需要独立重复处理数据的功能，合并数据格式化需求，生成一套相同输入、格式化输出的黑盒处理逻辑，完成了一套Push行情推送系统，使得金融业务，最需要重视的数据实时性和统一性得到了很好的解决。使得数据处理过程对于业务和模块来说，都是不需要关注的过程，完全黑盒输出到业务端。本发明，大大节省了实时金融业务的数据请求带宽，提供了实时准确的数据更新，减少了业务和模块间的数据差异化表现。兼容各种高、中、低端浏览器使用，对于同一套数据请求，只需要做好配置，即可黑盒得到需要的格式化后的数据。对于使用方，可以实时高效准确得数据输出等一系列特点。支持跨终端展现。由于所使用的技术是支持跨多终端的新技术，而且本发明实现方式是具有模块化、独立性的特点。方便无缝迁移、多点接入展现。

本发明实施例应用于金融产品的实时信息更新展现场景中，可以实时、直观看到用户关注产品的价格、涨跌幅、涨跌额等等所有的技术指标。适用于所有金融产品业务和模块的调用，一套后台服务的支持，即可同步到多个业务，多个模块的获取展现。而且保证了模块间数据的高度一致性。最重要的是，还大大节省了用户带宽、提升了速度，提供了完全无损的用户体验。具有省流量、动态、实时、高效、一致、直观的特点。在实际应用中，只需要确定需要获取信息的产品代码字段、需要获取信息的关键词字段，将两种信息注册到该发明提供的系统中，注册好回调方法。就可以实时获取到服务器推送过来的数据，并且拿到黑盒格式化后的数据对象。其中提供了所需要的以及进过计算的金融技术指标。业务侧只需要关注自己需要的产品代码和信息关键词字段，以及信息数据的展现和后续功能处理即可。

在多个业务模块进行数据获取时，需要单独进行数据请求。单独维护一个定时器，各自进行获取逻辑的处理，包括市场类型、市场时间、长短板行情数据的区分等等操作。每个业务模块都要发送大量的重复请求到服务器端。导致网络开销急增。采用本发明实施例，只有一次链接，连续的数据交换，一次数据格式化处理，就可以通用到各种业务，各种场景使用。抽离模块独立性高，复用性高。采用本发明实施例，可以看到由图7的大量请求，减少到了一次请求。如下图8所示。

多个业务模块改进之前，由于都是单独进行的数据获取和展现，导致模块间同步性差，不能保证同一时刻数据返回是一致的。采用本发明实施例前、后的对比示意图如图9和图10所示，图9中的数据是不同步的，而图10中的数据则为同步的。

在性能优化方面，在实际业务中，采用本发明实施例，整页页面延时有了显著的提升，整页平均延时从4.17s提升到了3.18s，延时时间减少了23.7％。如图11所示。

如图12所示为采用本发明实施例的一个架构，包括：终端侧包括多个注册模块，通过注册模块将请求参数(如产品代码和/或技术指标)予以注册，还可以将数据回调的方式进行注册。通过分配的ID来区分不同的注册模块。将多个业务请求进行请求合并，具体的，是将多个业务请求中包含的请求参数，如产品代码“symbols”进行合并，如技术指标“keys”进行合并。终端与服务器间建立全双工通信，如websocket后，发送合并后的请求给服务器。服务器每当监听到新数据，就将原始数据主动推送给终端解析。在终端侧设置中间件，中间件至少包括：数据解析模块、格式化处理模块及数据预处理模块，通过这些模块的处理可以得到解析后的格式化数据，通过push数据处理模块将格式化数据推送给业务应用层进行展示。

采用本发明实施例的一个具体的业务场景中，假设有n个模块需要进行实时信息的获取。每个模块都有相同或者不同的产品，每个模块都需要获取相同或者不同的技术指标。

假设n1模块的产品目录如图13所示，n1模块需要获取的技术指标如下：市场类型、名字、价格、代码、昨收价、今开价、涨跌幅、涨跌额。更加通俗地，我们可以把n1可以看做是一个指数指标的展示模块，其中主要包括了各个市场指数的技术指标，用作参考指示用。

假设n2模块的产品目录如图14-15所示，n2模块需要获取的技术指标如下：市场类型、证券名称、证券代码、最新价格、昨收盘、今开盘、买1价、买1量、买2价、买2量、买3价、买3量、时间戳、涨跌幅、涨跌额、成交量。更加通俗地，我们可以把n2可以看做是用户的自选列表1，其中包括了用户关注的产品，需要实时看到该支产品的各技术指标，用作用户交易买卖的指导。

假设n3模块的产品目录如图16所示，n3模块需要获取的技术指标和n2模块一样，具体如下：市场类型、证券名称、证券代码、最新价格、昨收盘、今开盘、买1价、买1量、买2价、买2量、买3价、买3量、时间戳、涨跌幅、涨跌额、成交量。更加通俗地，我们可以把n3可以看做是用户的自选列表2，其中包括了用户次要关注的产品，需要实时看到该支产品的各技术指标，用作用户交易买卖的指导。

其中n2和n3模块需要做切换进行查看。体现在技术侧，就是需要对实时数据获取进行注销和注册切换。以便实时释放资源，最小化需要的流量带宽，满足用户的数据实时需求。

首先，在业务侧，要进行系统接入时，要执行注册操作。

app.Push.setUser()；

针对以上的实际业务例子，技术侧主要分为以下内容：

一、格式化需要获取信息的金融产品代码

用symbols指示每个模块需要获取信息的产品代码。将每个模块需要获取的产品代码汇总成一个独立的数组结构存放。格式化后的产品代码如下：

Symbols_modle1＝["sz399006","sz399005","hkHSI","hkHSCEI","hkHSCCI","usDJI","usIXIC","usINX"]；

Symbols_modle2＝["sh600800","sh601766","usIBB","usMO","s_jj000700","sh600700","sh000161","h k01128","sz000700","s_jj161033","usAAPL","usCNET","sz000955","hk08071","hk03009","usINX","sh513500","usIXIC","usDJI","sh000001","sh000040","nq430005","sh601127","sh603123"]；

Symbols_modle3＝["s_jj000052","hk00005","s_jj000005","hk00002","sh000001"]；

二、确定需要获取的指标关键词

用Keys指示每个模块需要获取的技术指标。将每个模块需要获取的技术指标汇总成一个独立的数组结构存放。格式化后的技术指标如下所示：

Keys_modle1＝['Mkt','Name','Symbol','Price','Chg','ChgRatio','Turnover']；

Keys_modle2＝['Mkt','Name','ExpDate','IOPV','Symbol','ACCIOPVGR','Price','PrevClose','Open','Vol','_Vol','Uptodate','TimeStamp','Chg','ChgRatio','High','Low','Turnover','TurnoverRate','PE','Status','CS','MktCap_H']；

Keys_modle3＝

['Mkt','Name','ExpDate','IOPV','Symbol','ACCIOPVGR','Price','PrevClose','Open','Vol','_Vol','Uptodate','TimeStamp','Chg','ChgRatio','High','Low','Turnover','

TurnoverRate','PE','Status','CS','MktCap_H']；

三、注册到系统中

系统对外放出的模块为push模块。业务的使用方式为简单的注册调用。假设业务的全局关键词为app。则直接引用进来进行注册。

app.Push＝require('push')；

由于，假设有三个模块n1-n3需要数据的实时更新获取，那么，在业务侧只需要简单的进行三个模块的注册，其余的复杂处理工作交给后续系统内部进行处理。接下来的节会进行介绍。这里，还需要对注册过的信息进行一个存档，以便于后续不需要的时候进行及时的注销，释放资源。假设每个注册过的模块，我们都给与一个名字，存放到app.pushReg这个数组中。

分别注册三个模块，假设当前索引为n：

Var regid_n＝app.Push.reg({

Symbols:Symbols_modlen，

Keys：Keys_modlen

},function(data){

//对服务器推送的push格式化数据进行处理

})

将注册生成的id推送到存档数组里，进行备忘。app.pushReg.push(regid_n)；

四、系统进行注册数据的合并

Push系统接收到注册模块的注册请求，会首先将模块的注册信息都缓存下来，以便后续进行数据推送分发。然后给每个注册模块分配一个注册id，例如上一注册到系统环节里的regidn。然后，进行注册数据的合并处理，以便向服务器做统一请求处理。假设合并过后的产品代码字段为symbols，合并后的技术指标字段为keys。假设支持websocket的服务器地址为URI_SOTCKS。那么，需要向服务器做websocket的数据发送处理。将symbols和keys都发送到服务器上。监听onmessage的回调事件，对事件的data数据做接受处理。具体流程如下图17所示，包括：从产品的角度而言，在终端设置有产品“Push行情推送系统”。终端还包括多个注册模块，通过注册模块将请求参数(如产品代码和/或技术指标)予以注册及存档，可以放入存档模块中。还可以将数据回调的方式进行注册，连同上述注册数据一起进行缓存。通过分配的ID来区分不同的注册模块。将多个业务请求进行请求合并，具体的，是将多个业务请求中包含的请求参数，如产品代码“symbols”进行合并，如技术指标“keys”进行合并。之后，进行浏览器兼容性判断，如果终端是低端浏览器，则终端采用轮询的机制与服务器进行交互，具体的，是采用行情数据轮询及行情数据广播的方式进行。如果终端是高、中端浏览器，则终端与服务器间建立全双工通信，如websocket后，发送合并后的请求给服务器。服务器每当监听到新数据，就将原始数据主动推送给终端解析，可以得到解析后的格式化数据，将格式化数据推送给业务应用层进行展示。

五、数据处理中间件

接下来，对于监听到的数据，做格式化处理。

数据格式化方面引用liunx|NodeJS的管道(pipeline)的概念，发明了管道式数据处理，将每一个(input/out)作为下一个(input/out)。形象化表示如下图18所示，方便业务和模块之间共同使用一套通用、有效、直观的数据。减少了业务之间的重复冗余工作，而且很重要的是，减少了业务维护工作，避免模块之间数据不同步的问题。其中，数据处理中间件，主要做格式化处理的工作。具体目标如下所示：减少模块重复冗余工作，统一解析数据结构，一处更改多处生效，黑盒输出到业务侧。经该数据处理中间件进行处理后，得到的效果如图19的实例所示。

六、业务进行数据展现

业务侧拿到经过数据处理中间件格式化以后的数据后，进行相应业务的展示处理等操作。在前面的内容中，提到了对于现在不需要进行获取信息的模块可以进行注销操作。因为，已经有存档模块，对所有进行注册的信息进行了数据的存储。如果业务侧此时要展现模块n3的自选组合数据，模块n2的自选组合要进行切换到后台的操作。那么，此时需要进行的就是注销n2，注册n3到push行情系统中。具体技术操作如下：

app.Push.unreg(regid_n2)；

Var regid_3＝app.Push.reg({

Symbols:Symbols_modle3，

Keys：Keys_modle3

},function(data){

//对服务器推送的push格式化数据展现到业务场景中

})

七、中止信息交互

当业务要进行关闭，或者数据信息获取要主动终止时。要进行系统的注销操作，实时释放资源。

app.Push.setUser()；

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本发明各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本发明上述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (15)

1.一种数据处理方法，其特征在于，所述方法包括：

将至少两个业务请求合并为第一请求；

发送所述第一请求给服务器，请求与服务器建立全双工的通信连接；

在基于所述通信连接得到的数据传输通道上，接收对应所述第一请求的反馈数据；

根据从所述至少两个业务请求中解析得到的请求参数，将所述反馈数据对应拆分为至少两组第一数据；

对所述至少两组第一数据进行格式化处理，得到至少两组第二数据；

将所述至少两组第二数据提供给业务应用层，在所述业务应用层中进行业务数据的展示。

2.根据权利要求1所述的方法，其特征在于，所述将至少两个业务请求合并为第一请求，包括：

将所述至少两个业务请求中，每一个业务请求对应的所述请求参数进行参数类型的分解，得到至少两个第一参数类型和至少两个第二参数类型；

将所述至少两个第一参数类型进行合并，得到第一参数数组；

将所述第一参数数组封装至所述第一请求中的第一字段中。

3.根据权利要求1所述的方法，其特征在于，所述将至少两个业务请求合并为第一请求，包括：

将所述至少两个业务请求中，每一个业务请求对应的所述请求参数进行参数类型的分解，得到至少两个第一参数类型和至少两个第二参数类型；

将所述至少两个第二参数类型进行合并，得到第二参数数组；

将所述第二参数数组封装至所述第一请求中的第二字段中。

4.根据权利要求1所述的方法，其特征在于，所述将至少两个业务请求合并为第一请求，包括：

将所述至少两个业务请求中，每一个业务请求对应的所述请求参数进行参数类型的分解，得到至少两个第一参数类型和至少两个第二参数类型；

将所述至少两个第一参数类型进行合并，得到第一参数数组；

将所述至少两个第二参数类型进行合并，得到第二参数数组；

将所述第一参数数组封装至所述第一请求中的第一字段中；

将所述第二参数数组封装至所述第一请求中的第二字段中。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：所述将至少两个业务请求合并为第一请求之前，

从所述至少两个业务请求中分别解析出所述请求参数；

将所述请求参数进行参数数据的注册，缓存为第一注册数据；

将与所述请求参数对应的请求数据进行数据回调方式的注册，缓存为第二注册数据。

6.根据权利要求1至5任一项所述的方法，其特征在于，所述对所述至少两组第一数据进行格式化处理，得到至少两组第二数据，包括：

获取对应于第一业务请求的第一数据处理策略，根据所述第一数据处理策略对第一组第一数据进行格式化处理，得到第一组第二数据，将所述第一组第二数据输出给至少一个业务应用；

获取对应于第二业务请求的第二数据处理策略，根据所述第二数据处理策略对第二组第一数据进行格式化处理，得到第二组第二数据，将所述第二组第二数据输出给至少一个业务应用。

7.根据权利要求1至5任一项所述的方法，其特征在于，所述对所述至少两组第一数据进行格式化处理，得到至少两组第二数据，包括：

获取对应于第一业务请求的第一数据处理策略，根据所述第一数据处理策略对第一组第一数据进行格式化处理，得到第一组第二数据，将所述第一组第二数据输出给对应第二业务请求的业务应用；

获取对应于第二业务请求的第二数据处理策略，根据所述第二数据处理策略对所述第一组第二数据进行格式化处理，得到第二组第二数据；

将所述第二组第二数据输出给对应下一个业务请求的业务应用，直至对业务请求停止响应；

将所述第一组第二数据和/或所述第二组第二数据输出给至少一个业务应用。

8.一种终端，其特征在于，所述终端包括：

合并单元，用于将至少两个业务请求合并为第一请求；

请求单元，用于发送所述第一请求给服务器，请求与服务器建立全双工的通信连接；

接收单元，用于在基于所述通信连接得到的数据传输通道上，接收对应所述第一请求的反馈数据；

拆分单元，用于根据从所述至少两个业务请求中解析得到的请求参数，将所述反馈数据对应拆分为至少两组第一数据；

格式化处理单元，用于对所述至少两组第一数据进行格式化处理，得到至少两组第二数据；

展示单元，用于将所述至少两组第二数据提供给业务应用层，在所述业务应用层中进行业务数据的展示。

9.根据权利要求8所述的终端，其特征在于，所述合并单元，进一步用于：

将所述至少两个业务请求中，每一个业务请求对应的所述请求参数进行参数类型的分解，得到至少两个第一参数类型和至少两个第二参数类型；

将所述至少两个第一参数类型进行合并，得到第一参数数组；

将所述第一参数数组封装至所述第一请求中的第一字段中。

10.根据权利要求8所述的终端，其特征在于，所述合并单元，进一步用于：

将所述至少两个业务请求中，每一个业务请求对应的所述请求参数进行参数类型的分解，得到至少两个第一参数类型和至少两个第二参数类型；

将所述至少两个第二参数类型进行合并，得到第二参数数组；

将所述第二参数数组封装至所述第一请求中的第二字段中。

11.根据权利要求8所述的终端，其特征在于，所述合并单元，进一步用于：

将所述至少两个业务请求中，每一个业务请求对应的所述请求参数进行参数类型的分解，得到至少两个第一参数类型和至少两个第二参数类型；

将所述至少两个第一参数类型进行合并，得到第一参数数组；

将所述至少两个第二参数类型进行合并，得到第二参数数组；

将所述第一参数数组封装至所述第一请求中的第一字段中；

将所述第二参数数组封装至所述第一请求中的第二字段中。

12.根据权利要求8至11任一项所述的终端，其特征在于，所述格式化处理单元，进一步用于：

获取对应于第一业务请求的第一数据处理策略，根据所述第一数据处理策略对第一组第一数据进行格式化处理，得到第一组第二数据，将所述第一组第二数据输出给至少一个业务应用；

获取对应于第二业务请求的第二数据处理策略，根据所述第二数据处理策略对第二组第一数据进行格式化处理，得到第二组第二数据，将所述第二组第二数据输出给至少一个业务应用。

13.根据权利要求8至11任一项所述的终端，其特征在于，所述格式化处理单元，进一步用于：

获取对应于第一业务请求的第一数据处理策略，根据所述第一数据处理策略对第一组第一数据进行格式化处理，得到第一组第二数据，将所述第一组第二数据输出给对应第二业务请求的业务应用；

获取对应于第二业务请求的第二数据处理策略，根据所述第二数据处理策略对所述第一组第二数据进行格式化处理，得到第二组第二数据；

将所述第二组第二数据输出给对应下一个业务请求的业务应用，直至对业务请求停止响应；

将所述第一组第二数据和/或所述第二组第二数据输出给至少一个业务应用。

14.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现如权利要求1至7任一项所述方法的步骤。

15.一种服务器，其特征在于，所述服务器包括：

存储器，用于存储能够在处理器上运行的计算机程序；

处理器，用于运行所述计算机程序时，执行如权利要求1至7任一项所述方法的步骤。