海量数据实时处理架构及用于该架构的实时随需处理平台

摘要

本发明提供了一种海量数据实时处理架构，包括至少一个客户端、应用中间件服务器、至少一个实时信息随需处理平台和相应的操作系统，所述客户端用于显示应用服务的人机界面、接收用户输入的应用服务的有关数据并发送给所述应用中间件服务器，以及显示处理结果；所述应用中间件服务器与每个客户端相连接，用于接收由所述客户端发送的应用服务的有关数据，调用所述实时信息随需处理平台中的应用服务，接收由相应的实时信息随需处理平台传送的处理结果，根据处理结果生成显示界面并传送给相应的客户端；所述每个实时信息随需处理平台与所述应用中间件服务器相连接，用于完成由所述应用中间件服务器调用的应用服务的业务逻辑处理，并将处理结果返回给所述应用中间件服务器。

说明书

技术领域

本发明涉及一种计算机应用技术，具体地说本发明涉及一种海量数据实时处理架构。

背景技术

在计算机软件的发展史上，应用模式相继出现了大型机为中心的计算、C/S(客户/服务器)架构、B/S架构、多层分布式处理架构、Web Service计算、网格计算等技术，这些技术目前在不同场景仍然并存着。大型机为中心的计算、客户/服务器架构主要存在于早先构建的应用中，目前主要的软件架构多为B/S架构、多层分布式处理架构和Web Service方式，支撑这些架构离不开中间件技术，中间件(Middleware)是处于操作系统和应用程序之间的软件，也有人认为它应该属于操作系统中的一部分。人们在使用中间件时，往往是一组中间件集成在一起，构成一个平台(包括开发平台和运行平台)，但在这组中间件中必需要有一个通信中间件，即中间件＝平台+通信，这个定义也限定了只有用于分布式系统中才能称为中间件，同时还可以把它与支撑软件和实用软件区分开来。企业常用的中间件包括消息中间件、交易中间件、应用中间件(或称应用服务器)等，中间件位于应用和底层的操作系统、数据库之间，降低了应用开发的难度和成本，提高了开发速度，使开发者可专注于业务的开发。

图1示出了一种传统的三层架构(下文简称架构1)，客户端是指人机操作界面，例如图形用户界面GUI；交易中间件是指Tuxedo、Cics之类的软件，主要负责业务逻辑处理；数据库，例如oracle、Sqlserver、mysql等关系数据库，也可为内存数据库，负责数据存取，部分业务逻辑也可能通过数据库的存储过程、函数来实现；操作系统(Operating System，简称OS)是一种特殊的用于控制计算机硬件的程序。它是计算机底层的系统软件，负责管理、调度、指挥计算机的软硬件资源使其协调工作。在架构1中，当增加新功能引起客户端操作界面改变时，必须更新客户端程序，导致维护量加大。由于客户端可能运行于不同类型操作系统或不同版本的操作系统之上，开发方面可能需要多种代码适应不同的需求。在架构1中，业务逻辑在中间层的中间件服务器上运行，业务逻辑包含有数据库的访问，当数据量或业务量达到一定程度时，数据库便会成为性能瓶颈，这种瓶颈主要在于磁盘I/O和网络I/O。此种架构克服了传统C/S架构的不足，但其缺点是操作界面改变时，客户端维护量较大；交易中间件和关系数据库部分在数据量大时由于网络I/O和磁盘I/O，会存在性能瓶颈，这种架构不具有海量数据的实时处理能力。

图2示出了常用的B/S架构(下文简称架构2)，B/S(Browser/Server)结构即浏览器和服务器结构。它是随着Internet技术的兴起，对C/S结构的一种变化或者改进的结构。在架构2中，客户端是指在浏览器(Browser)中运行的程序，如sina网站、银行网银程序；应用中间件(或称应用服务器)是指Weblogic、Tomcat、.NETFramework之类的软件主要负责业务逻辑处理；数据库，例如oracle、Sql server、mysql之类的关系数据库，也可为内存数据库，负责数据存取，部分业务逻辑也可能通过数据库的存储过程、函数来实现。在这种结构下，用户界面是通过WWW浏览器(Browser)来实现，极少的业务事务逻辑在前端(Browser)实现，主要业务逻辑在服务器端(Server)实现，形成所谓三层3-tier结构。这样就大大简化了客户端电脑载荷，减轻了系统维护与升级的成本和工作量，降低了用户的总体成本(TCO)。以目前的技术看，局域网建立B/S结构的网络应用，并通过Internet/Intranet模式下数据库应用，相对易于把握、成本也是较低的。它是一次性到位的开发，能实现不同的人员、从不同的地点、以不同的接入方式，比如LAN，WAN，Internet/Intranet等访问和操作共同的数据库；它能有效地保护数据平台和管理访问权限，服务器数据库也很安全。特别是在JAVA这样的跨平台语言出现之后，B/S架构管理软件更是方便、快捷、高效。然而在B/S架构下，用户界面主要业务逻辑在服务器(Server)端实现，极少部分业务逻辑在前端(Browser)实现，应用服务器运行数据负荷较重。在服务端，业务逻辑包含有数据库的访问，当数据量或业务量达到一定程度时，数据库便会成为性能瓶颈，这种瓶颈主要在于磁盘I/O和网络I/O。另一方面，在B/S架构下，服务端使用的开发语言多为java、jsp、asp、C#、PHP等类的语言，这类语言编译出的程序相对于C/C++来说，效率明显要低一些，当数据量大时，对资源的要求会很高，性能方面存在瓶颈。因此这种架构不宜处理大量数据，尤其是实时性要求高的海量数据处理。

图3示出了一种大数据量处理的技术架构(下文简称架构3)，在架构3中，客户端在Browser中执行，它继承了架构2的一些优点，因此避免了架构1客户端难维护的缺陷。在架构3中，与界面表示层相关的业务逻辑在应用中间件(或称应用服务器)中运行，而比较耗资源的业务逻辑在性能高的交易中间件中执行，交易中间件业务逻辑执行所需参数及执行结果通过中间的应用中间件与客户端交互，这种方式处理克服了架构2应用中间件海量数据处理时的性能缺陷。由于在架构3中，交易中间件中业务逻辑包含有数据库的访问，当数据量或业务量达到一定程度时，数据库仍会成为性能瓶颈，这种瓶颈主要在于磁盘I/O和网络I/O。架构3虽然可以避免架构1和架构2的缺点，但对于每分钟交易量达百万笔的应用来说，关系数据库与交易中间件的性能仍是瓶颈，需要较大的硬件投资来提高性能。

图4示出了另一种大数据量处理的技术架构(下文简称架构4)，架构4是借助消息中间件和交易中间件的分布式处理功能，将业务逻辑处理分布在多台服务器上完成，从而提升了整体处理能力。如在电信计费系统中，将计费中预处理、批价、扣费、入库等过程分布到不同节点(服务器)上处理，或者按地市进行分布式处理等，通过消息中间件和消息中间件的协调处理，系统的整体性能和实时性都得到提高，通过增加更多的硬件和引入消息中间件或交易中间件间的远程服务调用获得更高的吞吐量，现在的企业应用软件系统一般都离不开数据库进行信息的处理，在海量数据(每秒钟需要处理数千条甚至达到数十万条记录)处理系统中，数据库的性能会存在瓶颈，因此一般采用架构4的方案和数量众多的服务器进行处理。由于在架构4中，交易中间件中业务逻辑包含有数据库的访问，当数据量或业务量达到一定程度时，数据库仍会成为性能瓶颈，这种瓶颈主要在于磁盘I/O和网络I/O。即使使用内存数据库，进程间、网络间的开销仍会很大，存在性能瓶颈。架构4的缺点是关系数据库与交易中间件的性能瓶颈仍未解决，系统投资高，维护量较多。

因此，希望提供一种具有海量数据实时处理能力的、系统投资少、维护量小的架构。

发明内容

本发明为解决上述技术问题之一，提出了一种海量数据实时处理架构，所述架构包括至少一个客户端、应用中间件服务器、至少一个实时信息随需处理平台和与所述每个实时随需处理平台相对应的操作系统，所述至少一个客户端用于显示应用服务的人机界面、接收用户输入的应用服务的有关数据并发送给所述应用中间件服务器，以及显示处理结果；所述应用中间件服务器与每个客户端相连接，用于接收由所述客户端发送的应用服务的有关数据，调用所述至少一个实时信息随需处理平台中的应用服务，接收由相应的实时信息随需处理平台传送的处理结果，根据处理结果生成显示界面并传送给相应的客户端；所述每个实时信息随需处理平台与所述应用中间件服务器相连接，用于完成由所述应用中间件服务器调用的应用服务的业务逻辑处理，并将处理结果返回给所述应用中间件服务器。

根据本发明的另一个方面，还提供一种用于海量数据实时处理架构的实时信息随需处理平台，所述架构包括至少一个客户端、应用中间件服务器、至少一个实时信息随需处理平台、与所述每个实时信息随需处理平台相关联的关系数据库和与所述每个实时随需处理平台相对应的操作系统，其中，所述实时信息随需处理平台包括：信息服务总线、至少一个应用组件库、交易中间件引擎、消息中间件引擎和内存数据库引擎；其中所述应用组件库用于存储并管理所述应用服务；所述交易中间件引擎用于调用和执行所述应用服务，以及建立与所述关系数据库的连接池，管理与关系数据库的连接；消息中间件引擎用于管理消息队列并向应用服务提供数据，所述消息中间件引擎还用于配置有触发服务的消息队列在消息到达时自动触发执行相关服务，其执行结果可以写到消息中间件引擎中的其它消息队列中；内存数据库引擎用于存储实时信息随需处理平台中的用户名/口令、表、系统服务名、应用组件库名、应用服务名、队列名、事务信息等字典数据及部分应用表，内存数据库引擎将内存数据库表中的数据写入磁盘，并进行事务处理和系统异常时的数据恢复，应用服务在执行过程中会对内存数据库引擎中的数据进行查询、更新、添加或删除。

附图说明

为了更完整地理解本发明及其优点，现在结合附图描述本发明的具体实施方式，附图中相同的参考标记代表相似的含义，其中：

图1示出了一种传统的三层架构的示意图；

图2示出了传统的B/S架构的示意图；

图3示出了一种传统的大数据量处理的技术架构的示意图；

图4示出了另一种传统的大数据量处理的技术架构的示意图；

图5示出了根据本发明的实施例的海量数据实时处理架构的示意图；

图6示出了根据本发明的海量数据实时处理架构中的实时信息随需处理平台的示意图；

图7示出了图6所示的实时信息随需处理平台的原理图；

图8示出了图6所示的实时信息随需处理平台的分布式处理图。

具体实施方式

图5示出了根据本发明的实施例的海量数据实时处理架构的示意图。图5所示的海量数据实时处理架构包括至少一个客户端，例如1000，1100，...，1n00、应用中间件服务器2000、至少一个实时信息随需处理平台，例如3000，3100，...，3n00和与所述每个实时随需处理平台相对应的操作系统4000，...，4n00，所述至少一个客户端用于显示应用服务的人机界面、接收用户输入的应用服务的有关数据并发送给所述应用中间件服务器，以及显示处理结果；所述应用中间件服务器与各个客户端相连接，用于接收由所述客户端发送的应用服务的有关数据，调用所述至少一个实时信息随需处理平台中的应用服务，接收相应的实时信息随需处理平台传送的处理结果，根据处理结果生成显示界面并传送给相应的客户端；所述每个实时信息随需处理平台与所述应用中间件服务器相连接，用于完成由所述应用中间件服务器调用的应用服务的业务逻辑处理，并将处理结果返回给所述应用中间件服务器。其中，所述实时信息随需处理平台代替了架构4中的交易中间件、消息中间件和部分关系数据库的功能。

在本架构中，应用服务的使用者——用户在浏览器中输入URL地址通过客户端程序，例如1000，使用应用服务，客户端程序1000通过网络与应用中间件服务器2000建立连接，应用中间件服务器2000将人机界面显示在客户端程序1000中，用户在人机界面上选择所需要的功能并输入相关数据，应用中间件服务器2000获得用户的输入和所选择的功能，进一步调用实时信息随需处理平台3000上的应用服务，应用服务在实时信息随需处理平台3000上完成比较费资源的业务逻辑处理后将处理结果发回到应用中间件服务器2000，应用中间件服务器2000根据返回的处理结果生成相应页面，并将所需最终结构显示在客户端程序1000。实时信息随需处理平台3000运行在操作系统4000之上，有时还要访问基于磁盘的关系数据库5000，当然，关系数据库5000在本架构中根据应用不同是可选的。本发明保留了架构2、架构3和架构4中客户端易维护等优点，后端的处理性能也得到大幅提升，同时硬件的成本更低，能够满足海量数据实时处理和业务灵活多变的需求。本发明可以使同等数据量下需要的服务器数量成倍降低或者在服务器配置相当的情况下处理数倍的数据，甚至可以处理以前单位时间内难以完成的数据量或新业务。

图6示出了根据本发明的海量数据实时处理架构中的实时信息随需处理平台的示意图。所述实时信息随需处理平台包括：信息服务总线3010、至少一个应用组件库3050、交易中间件引擎3020、消息中间件引擎3040和内存数据库引擎3030。应用中间件服务器2000是通过信息服务总线3010来调用实时信息随需处理平台3000上的应用服务的。应用组件库3050用于存储并管理应用服务，它通过交易中间件引擎3020被调度和执行；交易中间件引擎3020完成服务的调度和执行，在包含关系数据库5000时，所述交易中间件引擎3020还建立关系数据库连接池，管理与关系数据库5000的连接。消息中间件引擎3040用于管理消息队列并向应用服务提供数据，应用服务可从消息中间件引擎3040管理的消息队列中获取数据，消息中间件引擎3040还用于配置有触发服务的消息队列(简称触发队列)在消息到达时自动触发执行相关服务，其执行的结果也可写到消息中间件引擎3040中的其它消息队列中。内存数据库引擎3030用于存储实时信息随需处理平台中的用户名/口令、表、系统服务名、应用组件库名、应用服务名、队列名、事务信息等字典数据及部分应用表，内存数据库引擎3030将内存数据库表中的数据写入磁盘，例如采取cache或批处理的方式写入磁盘，并进行事务处理和系统异常时的数据恢复，应用服务在执行过程中会对内存数据库引擎3030中的数据进行查询、更新、添加或删除。

信息服务总线3010、交易中间件引擎3020、内存数据库引擎3030、消息中间件引擎3040、应用组件库3050及其内部的应用服务组件位于实时信息随需处理平台3000同一个进程空间内，它们采用多线程方式并行运行，内部的通讯效率高，能充分利用CPU、内存和系统总线的带宽。对于那些不常访问的数据，如日志和历史数据等，则可通过交易中间件引擎(3020)存取到基于磁盘的关系数据库(5000)中。换句话说，实时信息随需处理平台3000能充分利用服务器的资源，其性能的制约因素在于CPU、内存和系统总线的带宽，而这些是服务器中最快的部件，而现在常用的架构1-架构4，其性能瓶颈主要在于磁盘I/O和网络I/O，磁盘和网络的性能与CPU、内存和系统总线等快速部件性比，性能明显慢很多。

本发明将交易中间件引擎3020、内存数据库引擎3030、消息中间件引擎3040、应用组件库3050及信息服务总线3010技术有机地集成在一起，共同构成了实时信息随需处理平台。实时信息处理平台中的各种组件，包括应用组件和系统组件之间通过信息服务总线或消息队列进行互相通信，这种通信是在同一进程空间和内存中进行，通过线程互斥锁保持数据同步，这种通信方式相对于传统的交易中间件与数据库、交易中间件与消息中间件之间的进程间、网络间效率要高效得多，总体性能有10倍以上的提高。消息可以直接触发一个服务；服务可以直接使用内存数据库；服务的结果可以返回给服务调用者，可以写入到内存数据库或关系数据库中，也可以写入到消息队列中。平台中的各种组件能够高度并发进行，充分利用多CPU多核服务器的运算能力。

图7示出了图6所示的实时信息随需处理平台的原理图。如图7所示平台中的各应用组件以服务的形式存在于应用组件库中，以服务的形式对外部，例如更前端的应用中间件服务器或其它软件系统提供服务。更具体而言，应用组件库实际上是一个动态连接库，应用组件或称服务组件是具有特定形式的函数。例如，对于C/C++语言，应用组件具有一个服务入口参数，一个服务出口参数及一个服务出口参数长度参数，函数的返回值为整型，0表示成功，负值表示一个错误代码。这种方式非常方便应用开发人员设计和开发。一个应用组件库3050可包含1个或多个应用组件3060，3061，...，实时信息随需处理平台3000可挂接多个应用组件库3050，3051，...，305n。应用组件库3050的载体动态连接库的生成方式与不同的操作系统和编译器相关，如在linux上操作系统上用gcc编译需要-shared参数。

对于单个实时信息随需处理平台无法完成的处理，可以通过分布式处理进行。如图8所示，实时信息随需处理平台间通过远程服务调用或消息队列消息服务进行通信，从而达到更大的处理量。平台间通过远程服务调用或消息队列消息服务进行通信，从而达到更大的处理量。为避免多个平台之间的I/O瓶颈问题，可以将大的业务逻辑划分为一个个子逻辑在平台内部处理，平台间采用大数据块方式进行通信，因此总体效率会非常高。而在架构3和架构4中，许多业务需要与关系数据库实时通信，大数据块通信方式往往不能够使用。

本发明的架构适用于linux、Unix和Windows平台。而且既适用于嵌入式系统，也适用于非嵌入式系统。

架构5海量数据处理能力得到大幅提升的原因在于，架构5中用实时信息随需处理平台(3000)代替了传统的交易中间件和消息中间件，关系数据库的一部分功能也被转移到实时信息随需处理平台的内存数据库中。应用组件间的交互及应用组件与内存数据库的交互、应用组件与消息中间件的访问都在实时信息随需处理平台内部完成，相对于一般的进程间、机器间访问，避免了许多不必要的I/O开销，因此性能得到大幅提高。

使用本发明的架构单位时间内的处理能力可有数倍或十倍的提升，而且数据量越大，效果越明显。而且本架构的实时处理能力很强，通常情况下服务可在毫秒级甚至数十微秒级完成。此外，由于机器数量成倍减少，既可以利用廉价的pc服务器，也可以用高端的unix服务器，另外可以免掉昂贵的中间件费用，减少甚至免去关系数据库的费用，因此本架构的实时成本很低。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，还可以做出各种改进、替换和变化。这些改进、替换和变化在不脱离由附随的权利要求及其等同技术的范围的前提下，也应视为本发明的保护范围。