CN102281580B - M2m系统及其业务处理方法 - Google Patents

Abstract

本发明公开了一种M2M系统及其业务处理方法。其中，该M2M系统的业务处理方法包括：在业务处理过程中，当机器对机器M2M系统中的第一M2M平台检测到第一应用的业务量满足预定条件时，将业务量分流至第二应用进行处理，其中，第一应用和第二应用相互绑定。通过本发明，能够减少M2M系统中丢消息的现象。

Description

M2M系统及其业务处理方法

技术领域

本发明涉及通信领域，具体而言，涉及一种M2M系统及其业务处理方法。

背景技术

机器对机器(Machine-to-Machine/Man，简称为M2M)是一种以机器终端智能交互为核心的、网络化的应用与服务。它通过在机器内部嵌入无线通信模块，以无线通信、等为接入手段，为客户提供综合的信息化解决方案，以满足客户对监控、指挥调度、数据采集和测量等方面的信息化需求。

M2M终端是满足某种协议(如移动M2M终端基于WMMP协议，电信M2M的终端支持MDMP协议)并具有一定功能(如接收远程M2M平台激活指令、本地故障告警、数据通信、远程升级、数据统计以及端到端的通信交互功能)的终端。

M2M平台是为M2M应用服务的客户端提供统一的M2M终端接入管理、终端设备鉴权和检测控制，并能够转发相应业务数据的系统。M2M应用业务平台是为M2M应用服务客户端提供各类M2M应用服务，实现特定行业业务逻辑处理的应用系统。

物联网非常类似互联网，都是要将众多的设备互联互通起来。只是物联网的目标更为宏大，要将所有终端设备全部互联。

在现有的M2M协议中，运营商通常要求实现一个M2M平台。所有的M2M应用和底层终端都要注册到该平台上面来。M2M应用与底层终端之间通信，底层终端之间通信都要通过M2M平台进行转发。

图1是根据相关技术的M2M系统的示意图。

如图1所示，在M2M系统中，各个M2M平台在处理业务时是相互独立的，从而，在某个M2M平台的应用服务器出现峰值的情况下，往往会发生大量的丢消息情况。

因为M2M所管理的底层设备有其特殊性：设备类型众多，数量巨大，设备与平台有多种通信方式。这就会造成一种情况：M2M平台的信息处理量是非常巨大的。在某些特定情况下，终端发送给单个应用的消息流量本身就可能出现一个巨大的峰值。该单个应用的消息处理能力可能将无法满足消息处理的性能要求。

这种情况下，大量终端发送的数据流就会对M2M平台和上层应用的处理能力提出很高的要求。如何更好地利用现有的资源，来满足突发业务量的处理要求成为一个运营商要面对的难题。

发明人发现上述的相关技术中，M2M系统中丢消息现象比较严重。

发明内容

本发明的主要目的在于提供一种M2M系统及其业务处理方法，以至少解决上述的M2M系统中丢消息现象比较严重的问题。

根据本发明的一个方面，提供了一种M2M系统的业务处理方法，该方法包括：在业务处理过程中，当机器对机器M2M系统中的第一M2M平台检测到第一应用的业务量满足预定条件时，将业务量分流至第二应用进行处理，其中，第一应用和第二应用相互绑定。

进一步地，为M2M系统中的各个应用配置不同的优先级，第一M2M平台将业务量分流至第二应用进行处理包括：第一M2M平台选择各个应用中优先级最高的应用作为第二应用；第一M2M平台将业务量分流至第二应用进行处理。

进一步地，根据终端的类型为M2M系统中的各个应用配置不同的优先级，其中，类型包括以下之一或任意多个的组合：终端类型、消息类型、消息体中数据的类型、消息长度。

进一步地，在第一M2M平台将业务量分流至第二应用进行处理之前，上述方法还包括：确定M2M系统中哪些应用能够绑定，其中，按照以下方式之一或任意多个的组合来确定M2M系统中哪些应用可以绑定：是否具有相同的消息逻辑处理能力；是否具有同样的功能；以及对收到的消息数据是否能够进行协同处理。

进一步地，第一M2M平台检测到第一应用的业务量满足预定条件包括以下之一：第一M2M平台检测到第一应用的业务量超过预设的license限制；第一M2M平台检测到第一应用的业务量超过第一应用所在应用服务器的流量阈值；第一应用所在的服务器发现自身处理能力不足，请求第一M2M平台进行流量控制。

进一步地，第一M2M平台将业务量分流至第二应用进行处理包括以下之一或任意多个的组合：第一M2M平台将业务量由第一应用服务器分流至第二应用服务器，其中，第一应用服务器和第二应用服务器均与第一M2M平台相连接，第一应用和第二应用分别为第一应用服务器和第二应用服务器上的应用；第一M2M平台经由第二M2M平台将业务量由第三应用服务器分流至第四应用服务器，其中，第三应用服务器和第一M2M平台相连接，第四应用服务器与第二M2M平台相连接，第一应用和第二应用分别为第三应用服务器和第四应用服务器上的应用。

进一步地，第一M2M平台将业务量分流至第二应用进行处理包括：第一M2M平台减少发往第一应用的业务量，上述方法还包括：在第一M2M平台检测到第一应用的业务处理能力恢复的情况下，增加发往第一应用的业务量。

根据本发明的另一方面，提供了一种M2M系统，该M2M系统包括：一个或多个M2M平台，在第一M2M平台检测到第一应用的业务量满足预定条件时，第一M2M平台将业务量分流至第二应用进行处理，其中，第一应用和第二应用相互绑定。

进一步地，第一M2M平台对应多个应用并且各个应用具有不同的优先级，其中，第一M2M平台按照优先级的顺序进行分流。

进一步地，第二应用为第二M2M平台上的应用或第一M2M平台上的应用。

通过本发明，采用在业务处理过程中，当机器对机器M2M系统中的第一M2M平台检测到第一应用的业务量满足预定条件时，将业务量分流至第二应用进行处理，其中，第一应用和第二应用相互绑定，解决了M2M系统中丢消息现象比较严重的问题，进而达到了减少M2M系统中丢消息的效果。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据相关技术的M2M系统的网络示意图；

图2是根据本发明实施例的M2M系统的网络示意图；

图3是根据本发明实施例的M2M系统的业务处理方法的流程图；

图4是根据本发明实施例的M2M平台对终端发送的消息进行分流的工作流程图；

图5是根据本发明实施例的M2M平台对其他M2M平台转发的消息进行处理的工作流程图；

图6是根据本发明实施例的M2M平台恢复发送给应用的消息流量的工作流程图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

图2是根据本发明实施例的M2M系统的网络示意图。

如图2所示，根据本发明实施例的M2M系统包括多个M2M平台，并且多个M2M平台中的各个M2M平台的应用相互绑定，其中，在多个M2M平台中的第一M2M平台检测到业务量超过该应用所在的第一应用服务器的处理能力时，第一M2M平台将业务量分流至M2M系统中第二M2M平台所连接的应用服务器进行处理。其中，在同一个应用服务器上也可能存在多个同种类型的应用或者可分流的应用，此时，第一M2M平台可以将某个应用服务器的第一应用的业务量分流至该应用服务器的第二应用。

通过该M2M系统，在系统中的一个M2M平台所连接的应用服务器超过业务处理能力的情况下，将业务量分流至其他平台连接的应用服务器来处理，或者将某个应用的业务量分流至其他的应用进行处理，能够显著地解决M2M系统中丢消息(比如：M2M平台发给应用的请求消息和应用返回的响应消息等)现象比较严重的问题。

优选地，多个M2M平台中的各个M2M平台具有不同的优先级，其中，各个M2M平台按照优先级的顺序进行分流。通过按照预设的优先级的顺序来进行分流，能够使得各个M2M平台在进行分流时按照优先级的高低来分，从而使得重要的消息不容易丢弃，进而更好地解决了丢包现象严重的问题。

图3是根据本发明实施例的M2M系统的业务处理方法的流程图。

如图3所示，该M2M系统的业务处理方法包括以下步骤：

步骤S302，在业务处理过程中，机器对机器M2M系统中的第一M2M平台检测到第一应用的业务量满足预定条件。

例如，在M2M平台可以提供有配置模块。不同的应用提供商可以在该配置模块上进行配置，其中，配置的内容可以包括：

为注册到该M2M平台上的某个应用配置替代应用，设置多个应用为其备份应用。替代应用是已经注册到其他M2M平台上的应用。如果有多个备份应用的情况下，还需要为这些替代应用设置替代的优先级。

配置哪些类型的终端消息才需要使用分流处理进行流量保护。上述类型包括：终端类型、消息类型、消息体中数据的类型、消息长度等。比如：两种类型的终端，防盗告警终端和发送电表度数终端，同时有消息到M2M平台，应用服务器都提出了流量控制的要求。如果需要优先保证告警成功，则根据终端类型配置，只要求对防盗告警终端的消息需要做分流保护，在该种情况下，则防盗告警终端的消息会进行分流处理，而电表度数终端的消息则被丢弃。

根据终端的不同类型，配置消息做分流保护的时候的优先级。类型包括：终端类型、消息类型、消息体中数据的类型、消息长度等。比如：两种类型的终端，防盗告警终端和发送电表度数终端，同时有消息到M2M平台，应用服务器都提出了流量控制的要求。如果需要优先保证告警成功，则可以根据终端类型配置，防盗告警终端的优先级比发送电表度数终端的优先级要高。在该种情况下，防盗告警终端的消息会先进行分流处理，M2M首先保证防盗告警终端的消息分流成功，才去继续对电表度数终端的消息进行分流处理。如果M2M平台来不及都做分流处理，则会首先选择电表度数终端的消息进行丢弃。

在做分流处理的时候，每次调整的消息流量粒度。

其中，在为应用本身配置替代应用的过程中，就将这些在多个M2M平台组成的一个大的系统上注册的多个应用共同绑定组成了一组应用。哪些应用可以进行绑定，是由应用提供商决定。参考的依据包括：应用是否具有相同的消息逻辑处理能力；应用是否具有同样的功能(比如：电力局在北京的M2M平台和重庆的M2M平台都注册了一个获取电表度数的应用，分别获取当地的电表度数。两个应用获取电表度数的处理流程是完全一样的)；应用对收到的消息数据是否能够进行协同处理。

上述的第一M2M平台检测到第一应用的业务量满足预定条件包括以下之一：

第一M2M平台检测到第一应用的业务量超过预设的license限制。其中，可以为每个应用的业务量设定一个license限制。在某个应用的业务量超过为其设定的license限制的情况下，则满足上述预定条件，需要分流。

第一M2M平台检测到第一应用的业务量超过第一应用所在应用服务器的流量阈值。其中，可以为每个应用所在的应用服务器设定一个流量阈值。在某个应用服务器的业务量超过为其设定的流量阈值的情况下，则满足上述预定条件，需要分流。

第一应用所在的服务器发现自身处理能力不足，请求第一M2M平台进行流量控制。

步骤S304，上述第一M2M平台将业务量分流至第二应用进行处理，其中，第一应用和第二应用相互绑定。

在该实施例中，由于第一M2M平台所连接的第一应用服务器在超过业务量的处理能力时，第一M2M平台将业务量分流至M2M系统中的第二M2M平台所连接的应用服务器进行处理，因而，第一M2M平台就不会将处理不了的消息丢掉，进而能够减少丢消息比较严重的现象。

优选地，为M2M系统中各个M2M平台配置不同的优先级，第一M2M平台将业务量分流至M2M系统中的第二M2M平台进行处理包括：第一M2M平台选择M2M系统中优先级最高的M2M平台作为第二M2M平台；第一M2M平台将业务量分流至第二M2M平台进行处理。

在第一M2M平台将业务量分流至第二M2M平台进行处理之后，上述方法还可以包括：第二M2M平台判断业务量是否超过第二M2M平台所管理的第二应用服务器的鉴权限制，其中，第一应用服务器和第二应用服务器为相同类型的应用服务器；在判断结果为是的情况下，第二M2M平台将业务量分流至下一优先级的M2M平台进行处理；在判断结果为否的情况下，第二M2M平台对业务量进行处理。

M2M系统中的第一M2M平台可以通过以下方式之一检测到业务量超过第一应用服务器的处理能力：第一M2M平台接收到来自第一应用服务器的流量请求消息，其中，流量请求消息用于请求对业务量进行分流；第一M2M平台检测到发送至第一应用服务器的业务量超过了第一应用服务器的鉴权限制。

第一M2M平台将业务量分流至M2M系统中的第二M2M平台进行处理可以包括：第一M2M平台减少发往第一应用服务器的业务量。

上述方法还可以包括：在第一M2M平台检测到应用服务器的业务处理能力恢复的情况下，增加发往第一应用服务器的业务量。

通过对M2M系统的具体实现流程进行修改，将上层应用进行组合。从而可以当业务量出现峰值的时候，由M2M平台负责将多余的业务量进行分流，传递给其它M2M平台上的同组应用进行处理。

图4是根据本发明实施例的M2M平台对终端发送的消息进行分流的工作流程图。

如图4所示，分流的过程可以包括以下步骤：

步骤S401，终端发送消息至平台。

步骤S402，M2M平台判断是否需要将消息发送至应用。在判断结果为是的情况下转步骤S403，在判断结果为否的情况下转步骤S404。

步骤S403，M2M平台应用是否超过license限制。在判断结果为是的情况下转步骤S405，在判断结果为否的情况下转步骤S406。

步骤S404，M2M平台发送消息至终端。

步骤S405，判断应用是否存在同组应用。在判断结果为是的情况下转步骤S407，在判断结果为否的情况下转步骤S410。

步骤S406，判断是否收到应用流控告警。在判断结果为是的情况下转步骤S405，在判断结果为否的情况下转步骤S409。

步骤S407，M2M平台查找同组应用的路由。

步骤S408，M2M平台分流配置粒度的消息到替代应用注册的平台。

步骤S409，M2M平台发送消息至应用。

步骤S410，流程结束。

随着M2M平台的发展，在终端与上层应用之间可能会出现多对多的关系。即，一个终端可能会同时在多个应用上进行注册，并向应用提供采集的数据。

在M2M平台很好的实现了互联互通的情况下，同一家应用提供商可能在多个M2M平台上都注册有自己的应用。或者不同的应用提供商都有自己的应用注册在不同的M2M平台上，但是各个应用的功能非常类似。在这种情况下，对于如何提高应用业务处理能力的问题，本发明提出了如下解决方案：

在业务处理过程中，如果当前的业务量超过了某个应用的处理能力，则应用可以向M2M平台下发消息告知M2M平台需要对其进行流量控制。

在业务处理过程中，M2M平台在向应用转发终端消息的时候，先检查发送到该应用的业务量是否超过了该应用的License限制。然后检查是否收到了应用的流量控制请求。

如果上述的两个检查有一个没有通过，则M2M平台根据消息类型等信息，去检查该消息是否需要启动分流保护。如果需要则查找该应用是否有同组应用。如果有同组应用，则在其中查找到一个可替代的应用。

在分流的过程中，M2M平台逐渐减少到该应用的消息流量，减少的速度按照配置模块上配置的速度进行。发送的过程可以如下：

M2M平台首先检查被转发消息的消息体中是否有目的应用的标识。如果没有则在消息头中添加目的应用的标识；如果有则修改被转发消息的目的应用标识为替代应用的标识。

M2M平台将该消息转发到该替代应用所属的M2M平台，在转发的消息中，携带有可替代应用的信息(包括替代应用的标识和各自的替代优先级)。

替代应用所属的M2M平台接收到其他M2M平台转发过来的消息后，先执行上述的两个检查。

如果上述步骤的两个检查有一个没有通过，则M2M平台将该消息继续转发给下一优先级的替代应用所属的M2M平台。目的M2M平台在接收到消息后，将进行分流。如果步骤D的两个检查都通过，则M2M平台将该消息发送给该应用。流程结束。

如果替代应用所属的M2M平台接收到其他M2M平台转发过来的消息后，上述两个检查有一个没有通过，且自身已经是最后一个可替代应用所属的M2M平台，则该M2M平台将该消息丢弃。

图5是根据本发明实施例的M2M平台对其他M2M平台转发的消息进行处理的工作流程图。

如图5所示，M2M平台对其他M2M平台转发的消息进行处理可以包括以下步骤：

步骤S501，M2M平台收到来自其他平台的分流的消息。

步骤S502，判断M2M平台应用是否超过license限制。在判断结果为是的情况下转步骤S503，在判断结果为否的情况下转步骤S504。

步骤S503，判断是否还有下一级的替代应用。在判断结果为是的情况下转步骤S505，在判断结果为否的情况下转步骤S508。

步骤S504，M2M平台判断是否收到应用流控告警。

步骤S505，平台查找应用的路由。

步骤S506，平台发送消息至同组应用。

步骤S507，M2M发送消息至所连接的应用。

步骤S508，流程结束。

经过一段时间以后，原始的第一个应用的业务处理能力恢复，该业务将给所属的M2M平台下发消息，告知平台自身的处理能力恢复。或者经过一段时间后，M2M平台发现发往第一个应用的消息流量回落到了小于该M2M平台License的程度。该M2M平台将逐渐减少发往其他替代M2M平台的上行消息流量，逐渐增加发送往第一个应用的消息流量。整个修改发送路径的过程是个渐进的过程。每次增加的消息流量粒度为M2M平台的配置模块上配置的流浪粒度。最终直至所有的消息上行流量到发送往第一个应用。

图6是根据本发明实施例的M2M平台恢复发送给应用的消息流量的工作流程图。

步骤S601，M2M平台判断是否收到应该的恢复请求。在判断结果为是的情况下转步骤S602，在判断结果为否的情况下转步骤S603。

步骤S602，M2M平台增加配置粒度的消息至第一个应用。

步骤S603，判断流量是否回落到license下。在判断结果为是的情况下转步骤S602，在判断结果为否的情况下转步骤S604。

步骤S604，M2M平台发送消息至替代应用。

步骤S605，流程结束。

在所有的上行消息都处理完成以后，可以根据情况做相应的后续处理：如果消息的类型是文件下载类等类型，即替代应用已经完成了第一个应用的所有处理功能，则不再需要做后续处理；如果消息类型是告警等类型，即替代应用不能完全完成第一个应用的处理功能，则后续第一个应用向其他应用发起请求，要求其他应用返回原始消息的数据；或者其他应用向第一个应用主动上传收到的原始消息的数据，最终汇总原始消息的数据或者中间处理结果到原始的第一个应用中去。

以下以电力系统的业务提供商为应用业务提供商进行描述。

假定电力系统的业务提供商需要与多个M2M平台下注册的终端建立订购关系(例如：在一个地区一个M2M平台的情况下，电力系统的业务提供商需要采集多个地区的电表的度数)，则该应用业务提供商需要在多个M2M平台上注册不同的应用(例如：电力系统的业务提供商在多个地区的M2M平台注册采集电表度数的应用)。

在这种情况下，可以将该应用业务提供商的多个类型的应用绑定在一起，构成一组应用。该应用业务提供商可以在某地的M2M平台A的配置模块上进行操作，做如下配置：

将其他地区的M2M平台上注册的采集电表度数的应用App2、App3、App4等配置为该地M2M平台A上注册的采集电表度数的应用App1的替代应用。应用App2、App3、App4等所注册的M2M平台上都保存有所注册的应用的路由信息。

将终端类型为电表度数采集器，消息类型为电表度数上报的消息配置为需要做分流保护。

在某种情况下，M2M平台A上，终端的上行流量出现了峰值的情况(例如：电力系统的电表度数发送终端设置了定时，在某个时间段，集体发送电表度数给应用)。该M2M平台A上注册的对应应用App1对如此大量的消息处理能力不足。

这种情况下，应用App1向M2M平台A发送指令，告知M2M平台A自身处理能力不足，请做溢出处理，需要对终端上行的业务数据进行分流。M2M平台A查找自身的替代列表，将以后的消息发送给替代优先级为第二的在M2M平台B上的应用App2。在转发的消息中，携带有可替代应用的信息(包括替代应用的标识和各自的替代优先级)。

M2M平台B在接受到该消息以后，先检查App2是否处理能力不足。如果没有发现App2发送了处理能力不足的指令，则将该消息发送给App2。由App2对消息进行处理。如果App2也出现了处理能力不足的情况，则M2M平台B查找下一个可替换的应用，并将该消息转发给该应用。

这样所有的电表度数的数据对于该电力系统的业务应用提供商来说都没有丢失，剩下的只需要在多个应用之间(例如：App1和App2之间)交换数据。

如果经过一段时间，App1的处理能力恢复，又可以处理新的终端数据了。则App1给M2M平台A发送指令，告知M2M平台A自身的处理能力恢复。由于M2M平台A的管理人员配置了流量平滑恢复的粒度为P条/分钟，以后的上行消息，M2M平台A将到应用App1的流量每分钟逐渐增加P条消息。其他消息将继续转发给App2。直至所有的流量都恢复为发送给应用App1。

在所有的上行消息都处理完以后，由于都是该电力系统的业务应用提供商的应用，所有App1向App2、App3、App4等发送请求消息，在收到请求消息后，App2、App3、App4等将收到的电表度数数据同步给App1。

上面的说明是针对应用的业务处理能力不足的情况。对于M2M给应用分配的License不足，导致无法将终端的上行消息发送给应用的情况，具体流程与上面的说明类似，不再赘述。

从以上的描述中，可以看出，通过本发明，可以方便地实现：在应用出现故障的时候，为了保证业务功能的正常使用，提供替代应用接管应用的功能，保证业务的正常处理不会中断。在应用恢复了以后，再切换回正常的应用。同时也可以大大提高应用的可靠性。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种M2M系统的业务处理方法，其特征在于，在业务处理过程中，当机器对机器M2M系统中的第一M2M平台检测到第一应用的业务量满足预定条件时，将所述业务量分流至第二应用进行处理，其中，所述第一应用和所述第二应用相互绑定，所述第二应用为第二M2M平台上的应用或第一M2M平台上的应用；

其中，在所述第一M2M平台将所述业务量分流至第二应用进行处理之前，所述方法还包括：确定所述M2M系统中哪些应用能够绑定，其中，按照以下方式之一或任意多个的组合来确定所述M2M系统中哪些应用可以绑定：是否具有相同的消息逻辑处理能力；是否具有同样的功能；以及对收到的消息数据是否能够进行协同处理。

2.根据权利要求1所述的业务处理方法，其特征在于，为所述M2M系统中的各个应用配置不同的优先级，所述第一M2M平台将所述业务量分流至第二应用进行处理包括：

所述第一M2M平台选择所述各个应用中优先级最高的应用作为所述第二应用；

所述第一M2M平台将所述业务量分流至所述第二应用进行处理。

3.根据权利要求2所述的业务处理方法，其特征在于，根据终端的类型为所述M2M系统中的各个应用配置不同的优先级，其中，所述类型包括以下之一或任意多个的组合：

终端类型、消息类型、消息体中数据的类型、消息长度。

4.根据权利要求1至3中任一项所述的业务处理方法，其特征在于，所述第一M2M平台检测到第一应用的业务量满足预定条件包括以下之一：

所述第一M2M平台检测到所述第一应用的业务量超过预设的license限制；

所述第一M2M平台检测到所述第一应用的业务量超过所述第一应用所在应用服务器的流量阈值；

所述第一应用所在的服务器发现自身处理能力不足，请求所述第一M2M平台进行流量控制。

5.根据权利要求1至3中任一项所述的业务处理方法，其特征在于，所述第一M2M平台将所述业务量分流至第二应用进行处理包括以下之一或任意多个的组合：

所述第一M2M平台将所述业务量由第一应用服务器分流至第二应用服务器，其中，所述第一应用服务器和所述第二应用服务器均与所述第一M2M平台相连接，所述第一应用和所述第二应用分别为所述第一应用服务器和所述第二应用服务器上的应用；

所述第一M2M平台经由第二M2M平台将所述业务量由第三应用服务器分流至第四应用服务器，其中，所述第三应用服务器和所述第一M2M平台相连接，所述第四应用服务器与所述第二M2M平台相连接，所述第一应用和所述第二应用分别为所述第三应用服务器和所述第四应用服务器上的应用。

6.根据权利要求1所述的业务处理方法，其特征在于，

所述第一M2M平台将所述业务量分流至第二应用进行处理包括：

所述第一M2M平台减少发往所述第一应用的业务量，

所述方法还包括：

在所述第一M2M平台检测到所述第一应用的业务处理能力恢复的情况下，增加发往所述第一应用的业务量。

7.一种M2M系统，包括一个或多个M2M平台，其特征在于，在第一M2M平台检测到第一应用的业务量满足预定条件时，所述第一M2M平台将所述业务量分流至第二应用进行处理，其中，所述第一应用和第二应用相互绑定，所述第二应用为第二M2M平台上的应用或第一M2M平台上的应用；

其中，在所述第一M2M平台将所述业务量分流至第二应用进行处理之前，还包括：确定所述M2M系统中哪些应用能够绑定，其中，按照以下方式之一或任意多个的组合来确定所述M2M系统中哪些应用可以绑定：是否具有相同的消息逻辑处理能力；是否具有同样的功能；以及对收到的消息数据是否能够进行协同处理。

8.根据权利要求7所述的M2M系统，其特征在于，所述第一M2M平台对应多个应用并且各个应用具有不同的优先级，其中，所述第一M2M平台按照所述优先级的顺序进行分流。