[发明专利]用于分布式应用系统的数据传输系统和数据传输方法

说明书

技术领域

本发明涉及数据传输技术领域，具体而言，涉及用于分布式应用系统的数据传输系统和数据传输方法。

背景技术

在分布部署的企业应用系统之间要进行通讯，存在着许多问题，其中最重要的问题之一是这些软件系统之间由于从属不同企业组织、远距离等原因而带来在运行状态、网络连接状态的独立性，这种独立性意味着这些需要互相通讯的系统有可能并不是都同时处于运行状态或者连通状态（比如停机维护等）。这类企业应用系统间的数据交换通常都具有数据量大、通讯持续时间长等特点，因而在这样的场景中直接采用传统的面向连接的通讯方案（如TCP、HTTP）实现企业应用系统间的业务数据交换会面临很大复杂度和开发风险，因为通讯的双方的部署特性而无法一致地维持着良好的连接性。

基于发布/订阅模型的消息通讯方案相对于传统的面向连接的通讯方案，天然地具备了将通讯的发送、接收双方分离的特点，使得发送方和接收方之间得到解耦：发送方将数据发送到特定的主题而不用管接收方何时接收；而接收方可在任意合适的时候从其关注的主题中接收数据。

目前，典型的基于发布/订阅模型的消息通讯方案就是采用消息中间件作为通讯基础设施，然而直接在消息中间件之上进行业务数据通讯仍面临着诸多困难。消息中间件单一地以消息作为载体与业务数据和业务操作的多样性之间形成矛盾，这种矛盾产生的问题包括：1、在消息流中区分业务数据和业务操作的边界的问题；2、大数据量传输的事务问题；3、群集部署的接收方的接收处理问题。

1、在消息流中区分业务数据和业务操作的边界的问题

典型的消息中间件对于一个消息的大小都是有限制的，一次业务操作的数据通常都由于数据量大小的问题无法只用一个消息就完成传输，需要分成多个消息进行。基于消息中间件都需要面临的一个问题就是将业务数据分解为多个消息发送并能够在接收方重新组合，并且能够区分不同业务操作发起的同一种业务数据类型的多次传输。这就是所谓业务数据边界和业务操作边界，即一次业务操作和业务数据与承载了这些信息的多个消息的对应关系。

在一次通讯过程中，发送方的业务数据会按照消息中间件定义的消息格式生成一系列的消息并通过消息中间件发送出去，接收方订阅接收到消息之后需要从大量的消息中重新识别出其中包含的业务数据和对应的业务操作。

现有的在消息中区分业务数据和业务操作边界的方法就是：

（1）将业务类别标识符加到消息中，发送方在发送数据时，将消息打上标识，并按顺序发送给消息中间件。

（2）接收方在从中间件订阅收到的每一个消息时根据消息中的标识符对消息分类进行业务处理。

具体地，如图1所示，用户通过操作A将多个数据消息A1A2A3按顺序发送至A系统，并通过操作B将多个数据消息B1B2B3按顺序发送至A系统，然后由A系统按照预定的顺序，如采用A1B1A2B2A3B3将多个数据消息发送至消息中间件。然后，B系统按照相同的顺序，比如A1B1A2B2A3B3从消息中间件获取多个数据消息，并按照每个操作对应的数据消息，分为A1A2A3和B1B2B3后分别用于处理A和处理B。

上述方法依赖于消息中间件的队列中消息顺序的保证，接收方对消息的处理以顺序接收为前提。这种方式存在以下的限制或问题：

（1）发送方需要保证消息发送顺序而无法并发发送；

（2）接收方的处理以顺序接收为前提而无法支持并发接收处理；

（3）在每一个消息上的都需要加上了描述数据的业务属性以及相关消息的标识符的业务边界识别方法增大了在网络传输中非业务数据的冗余。

2、大数据量传输完整性问题

传输完整性是指将一个业务操作数据的多个消息一起发送出去，如果全部消息都成功，则全部消息一起得到处理时，如果存在失败的消息，则已经发送的消息最终会被忽略不做处理。

为了保证一次业务操作的数据都能完整地传输，现有的做法是将一次业务操作的所有数据生成的全部消息都在同一个由消息中间件定义和提供的事务中发送出去。然而这种依赖于消息中间件事务来保证完整性的方式会受到内存的限制，如果数据量过大(如GB级以上)将会大量占用内存而导致消息中间件的崩溃。

3、群集部署的接收方的接收处理问题

在企业应用中，以群集部署应用系统来分担单台服务器压力以提高整个应用系统的吞吐量和处理能力是很常见的实施方案。在群集部署中，逻辑上的一个应用系统在物理上是两个以上的运行于同一台服务器或者不同服务器上的进程，应用系统的处理请求被按照某种特定的规则被均衡地分配给不同的进程实例来处理。