建立消息队列的方法和装置与流程

本发明涉及数据传输领域，尤其涉及一种建立消息队列的方法和装置。

背景技术：

在传统的单机业务系统中，一般按接入层、业务层、持久层来划分结构，但随着业务逻辑的不断复杂化，用户规模的扩大，单机已经无法满足要求，需要进行分布式拆分，按业务场景进行拆分为小的服务，各服务之间通过消息中间件解耦。由于接收端和发送端解耦了，所以相互之间的影响也会降低。而且某个服务可能会被多个其他服务依赖，而这个服务本身也可能会调用很多其他服务，这样的调用关系会变的很复杂，需要集中式的服务治理系统来统一管控。

上述内容仅用于辅助理解本发明的技术方案，并不代表承认上述内容是现有技术。

技术实现要素：

本发明的主要目的在于提供一种建立消息队列的方法和装置，旨在实现通过在消息中间件中建立消息队列，来控制分布式系统中发送端和接收端之间所传输的消息的调用关系。

为实现上述目的，本发明提供的一种建立消息队列的方法，所述建立消息队列的方法包括：

确定待处理消息的业务类型，根据所述业务类型确定所述待处理消息的传输方式；

确定所述待处理消息与待建立的消息队列的对应关系；

根据所述对应关系，以及所述待处理消息的传输方式在消息中间件中建立消息队列。

优选地，所述确定待处理消息的业务类型，根据所述业务类型确定所述待处理消息的传输方式的步骤包括：

若所述待处理消息为待处理服务消息，则所述待处理服务消息的传输方式为同步传输方式；

若所述待处理消息为待处理事件消息，则所述待处理事件消息的传输方式为异步传输方式。

优选地，所述若所述待处理消息为待处理事件消息，则所述待处理事件消息的传输方式为异步传输方式的步骤包括：

若所述待处理消息为待处理事件消息，则判断每个接收端的实例是否都可接收所述待处理事件消息；

若只存在一个接收端可接收所述待处理事件消息，且所述接收端中只存在一个实例接收所述待处理事件消息，则确定所述待处理事件消息的传输方式为单播方式；

若存在至少两个接收端可接收所述待处理事件消息，且所述接收端中存在至少一个实例接收所述待处理事件消息，则确定所述待处理事件消息的传输方式为多播方式；

若所有接收端的实例都接收所述待处理事件消息，则确定所述待处理事件消息的传输方式为广播方式。

优选地，当采用同步传输方式时，所述消息中间件中的消息总线采用Request/Response机制；

当采用异步传输方式时，所述消息中间件的消息总线采用Pub/Sub机制。

优选地，所述确定所述待处理消息与待建立的消息队列的对应关系的步骤包括：

确定所述待处理消息所在的分布式子系统，确定所述分布式子系统对应的业务类别；

根据所述业务类别确定所述业务场景，以及确定所述业务场景所在的部署区域；

确定所述部署区域所在的环境，根据所述环境确定对应的待建立的消息队列。

此外，为实现上述目的，本发明还提供一种建立消息队列的装置，所述建立消息队列的装置包括：

第一确定模块，用于确定待处理消息的业务类型，根据所述业务类型确定所述待处理消息的传输方式；

第二确定模块，用于确定所述待处理消息与待建立的消息队列的对应关系；

建立模块，用于根据所述对应关系，以及所述待处理消息的传输方式在消息中间件中建立消息队列。

优选地，所述第一确定模块还用于若所述待处理消息为待处理服务消息，则所述待处理服务消息的传输方式为同步传输方式；若所述待处理消息为待处理事件消息，则所述待处理事件消息的传输方式为异步传输方式。

优选地，所述第一确定模块包括：

判断单元，用于若所述待处理消息为待处理事件消息，则判断每个接收端的实例是否都可接收所述待处理事件消息；

确定单元，用于若只存在一个接收端可接收所述待处理事件消息，且所述接收端中只存在一个实例接收所述待处理事件消息，则确定所述待处理事件消息的传输方式为单播方式；若存在至少两个接收端可接收所述待处理事件消息，且所述接收端中存在至少一个实例接收所述待处理事件消息，则确定所述待处理事件消息的传输方式为多播方式；若所有接收端的实例都接收所述待处理事件消息，则确定所述待处理事件消息的传输方式为广播方式。

优选地，当采用同步传输方式时，所述消息中间件中的消息总线采用Request/Response机制；

当采用异步传输方式时，所述消息中间件的消息总线采用Pub/Sub机制。

优选地，所述第二确定模块还用于确定所述待处理消息所在的分布式子系统，确定所述分布式子系统对应的业务类别；根据所述业务类别确定所述业务场景，以及确定所述业务场景所在的部署区域；确定所述部署区域所在的环境，根据所述环境确定对应的待建立的消息队列。

本发明通过根据所述待处理消息的业务类型确定所述待处理消息的传输方式；并根据所确定的所述待处理消息与待建立的消息队列的对应关系，以及所述待处理消息的传输方式在消息中间件中建立消息队列。实现了通过在消息中间件中建立消息队列，来控制分布式系统中发送端和接收端之间所传输的消息的调用关系。

附图说明

图1为本发明建立消息队列的方法的较佳实施例的流程示意图；

图2为本发明建立消息队列的装置的较佳实施例的功能模块示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

参照图1，提出本发明建立消息队列的方法的第一实施例。

在本实施例中，所述建立消息队列的方法包括：

步骤S10，确定待处理消息的业务类型，根据所述业务类型确定所述待处理消息的传输方式；

在本实施例中，发送端包括服务消费端和事件发布端，接收端包括服务提供端和事件订阅端，所述服务消费端与所述服务提供端对应，所述事件发布端和所述事件订阅端对应。所述发送端和所述接收端存在于分布式系统中，分别与所述分布系统中的消息中间件连接。具体地，所述发送端和所述接收端存在于分布式子系统中，所述分布式子系统组成所述分布式系统。需要说明的是，可以根据业务类型和业务场景来划分分布式子系统，所述发送端决定所述待处理消息的业务类型。消息中间件作为所述分布式系统中所述发送端和所述接收端之间的消息传输工具。

进一步地，所述步骤S10包括：

步骤a，若所述待处理消息为待处理服务消息，则所述待处理服务消息的传输方式为同步传输方式；

步骤b，若所述待处理消息为待处理事件消息，则所述待处理事件消息的传输方式为异步传输方式。

若所接收的所述待处理消息为待处理服务消息，即所述待处理消息是由所述服务消费端发出的，则确定所述待处理服务消息的传输方式为同步传输方式。即当所述服务消费端发出服务请求后，在等待所述服务提供端返回与所述服务请求对应的调用结果或者在超时之前，所述服务消费端处于等待状态，且所述服务消费端不释放其占用的线程资源，直到接收到所述服务提供端根据所述待处理消息返回响应消息或者超时时，才执行下一操作。若所述服务提供端超时或者接收所述待处理消息失败时，所述服务消费端可根据具体情况重新发送所述待处理消息。进一步地，当采用同步传输方式时，所述消息中间件中的消息总线采用Request/Response机制来确保所述服务消费端和所述服务提供端之间传输的所述待处理消息成功发送至对方。

若所述待处理消息为待处理事件消息，则所述待处理事件消息的传输方式为异步传输方式。即当所述事件发布端向所述消息中间件发出所述待处理事件消息后，所述事件发布端不会等待所述事件订阅端返回调用所述待处理事件消息的结果，所述事件发布端在执行完发送所述待处理事件消息的操作后，释放所占用的线程资源。进一步地，当采用异步传输方式时，所述消息中间件的消息总线采用Pub/Sub机制确保所述事件发布端和所述事件订阅端之间传输的所述待处理事件消息成功发送至对方。所述Pub/Sub机制定义了如何向一个内容节点发布和订阅消息，这些节点被称作主题(topic)，主题可以被认为是消息的传输中介，发布者发布消息到主题，订阅者从主题订阅消息，主题使得消息订阅者和消息发布者保持互相独立，不需要接触即可保证消息的传送。可以理解的是，所述主题存在于所述消息中间件中的消息总线中。

进一步地，步骤b包括：

步骤b1，若所述待处理消息为待处理事件消息，则判断每个接收端的实例是否都可接收所述待处理事件消息；

若所述待处理消息为待处理事件消息，即所述待处理消息为所述事件发布端所发送的，则判断每个接收端的实例是否都可以接收所述待处理事件消息。需要说明的是，所述实例可以接收所述待处理消息，也可以发送所述待处理消息，一个发送端和接收端可以对应着一个或者多个实例。

步骤b2，若只存在一个接收端可接收所述待处理事件消息，且所述接收端中只存在一个实例接收所述待处理事件消息，则确定所述待处理事件消息的传输方式为单播方式；

步骤b3，若存在至少两个接收端可接收所述待处理事件消息，且所述接收端中存在至少一个实例接收所述待处理事件消息，则确定所述待处理事件消息的传输方式为多播方式；

若只存在一个接收端可接收所述待处理事件消息，且所述接收端中只存在一个实例接收所述待处理事件消息，则确定所述待处理事件消息的传输方式为单播方式。若存在至少两个接收端可接收所述待处理事件消息，且所述接收端中存在至少一个实例接收所述待处理事件消息，则确定所述待处理事件消息的传输方式为多播方式。所述服务治理表为所述消息中间件的实例与可接收所述待处理事件消息之间的映射关系表，从所述服务治理表中可以知道所述消息中间件中的实例是否可以接收到所述待处理事件消息。

步骤b4，若所有接收端的实例都接收所述待处理事件消息，则确定所述待处理事件消息的传输方式为广播方式。

若所有在线接收端的实例都接收所述待处理事件消息，则确定所述待处理事件消息的传输方式为广播方式。需要说明的是，所述广播方式在消息总线中是不确保消息送达到对方的，若所述发送端通过广播方式发送所述待处理消息，所述接收端未能正常监测到所述待处理消息，所述待处理消息则会丢失，且所述待处理消息在到达消息中间件时，并不会缓存所述待处理消息，而是直接发送给所有接收端对应的实例。可以理解的是，在所述广播方式下传输所述待处理事件消息，若所述接收端错过所述待处理事件消息，则无法再次获取所述待处理事件消息。

步骤S20，确定所述待处理消息与待建立的消息队列的对应关系；

步骤S30，根据所述对应关系，以及所述待处理消息的传输方式在消息中间件中建立消息队列。

确定所述待处理消息与待建立的消息队列的对应关系，根据所述待处理消息与待建立的消息队列的对应关系和所述待处理消息的传输方式在所述消息中间件中建立消息队列。所述消息队列是在消息的传输过程中保存消息的容器，消息队列管理器在将消息从它的源中继到它的目标时充当中间人，队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收端不可用，消息队列会保留消息，直到可以成功地传递它。

进一步地，若采用同步传输方式传输所述待处理消息，在所述消息中间件中建立所述消息队列后，所述接收端监测所述消息队列，所述发送端往所述消息队列里面发所述待处理消息。当所述接收端在所述消息队列中监测到所述待处理消息后，处理所述待处理消息，并返回对应的响应消息给所述发送端后，所述发送端再次发送所述待处理消息至所述消息队列中。

如若采用单播方式传输所述待处理消息，每个待处理消息对应着一个消息队列；若采用多播方式传输所述待处理消息，每个待处理消息对应着至少两个消息队列；若采用广播方式传输所述待处理消息，每个待处理消息不对应着消息队列，即若采用广播方式传输所述待处理消息，不在所述消息中间件中建立所述消息队列，或者说在所述消息中间建立所述消息队列的个数为零。但是会建立topic，且不持久化消息。

若采用单播方式传输所述待处理消息，则在所述消息中间件中建立一个消息队列后，所述接收端监测所述消息队列，所述发送端往所述消息队列发送所述待处理消息。当所述发送端将所述待处理消息发送至所述消息队列中后，不等待所述接收端返回对应的响应消息，直接再次向所述消息队列中发送所述待处理消息。当所述接收端在所述消息队列中监测到所述待处理消息时，处理所述待处理消息。

若采用多播方式传输所述待处理消息，则在所述消息中间件中建立至少两个消息队列后，所述接收端监测所述消息队列，所述发送端往所述消息队列发送所述待处理消息。当所述发送端将所述待处理消息发送至所述消息队列后，不等待所述接收端返回对应的响应消息，直接再次向所述消息队列发送所述待处理消息。当所述接收端在所述消息队列中监测到所述待处理消息时，处理所述待处理消息。需要说明的是，在多播方式下，会存在多个消息队列，每个消息队列对应着一个接收端。当所述发送端发送所述待处理消息至所述消息队列时，会同时发送至各个消息队列中。

若采用广播方式传输所述待处理消息时，由于并未在所述消息中间件中建立所述消息队列，则多个接收端的多个实例直接在所述消息中间件监测所述待处理消息，所述发送端在将所述待处理消息发送至所述消息中间件中后，直接再次发送其它的所述待处理消息，并不会等待所述接收端返回对应的响应消息，且所述消息中间件中的所有接收端都可监测到所述待处理处理消息。

需要说明的是，所述待处理消息是缓存在所述消息队列中的，若所述接收端的实例取走所述待处理消息后，所述消息队列中的所述待处理消息则不再存在，同一个接收端的其它实例则无法再获取所述待处理消息，从而实现了只有一个实例可接收所述待处理消息。可以理解的是，一个待处理消息被同一个部署区域中的一个接收端处理一个即可。

本实施例通过根据所述待处理消息的业务类型确定所述待处理消息的传输方式；并根据所确定的所述待处理消息与待建立的消息队列的对应关系，以及所述待处理消息的传输方式在消息中间件中建立消息队列。实现通过在消息中间件中建立消息队列，来控制分布式系统中发送端和接收端之间所传输的消息的调用关系。

进一步地，基于第一实施例提出本发明建立消息队列的方法的第二实施例。

在本实施例中，所述步骤S20包括：

步骤c，确定所述待处理消息所在的分布式子系统，确定所述分布式子系统对应的业务类别；

步骤d，根据所述业务类别确定所述业务场景，以及确定所述业务场景所在的部署区域；

步骤e，确定所述部署区域所在的环境，根据所述环境确定对应的待建立的消息队列。

确定所述待处理消息所在的分布式子系统，以及确定所述分布式子系统所对应的业务类别。需要说明的是，所述业务类别包括服务和事件。根据所述业务类别确定所述业务场景。当确定所述业务场景后，确定所述业务场景所在的部署区域，以及确定所述部署区域所在的环境。需要说明的是，所述环境包括所述分布式系统的开发环境、测试环境和生产环境等。当确定所述部署区域所在的环境后，根据所述环境确定对应的待建立的消息队列，以此实现通过消息中间件中消息队列来控制分布式系统中发送端和接收端之间的调用关系。可以理解的是，每个待建立的消息队列都有对应的所述待处理消息、分布式子系统、业务类别、业务场景、部署区域和环境。

需要说明的是，由于分布式系统架构的不同，所述分布式系统中不同的部署区域中都可能存在接收端，并且在不同的环境中都存在有接收端。

本发明进一步提供一种建立消息队列的装置。

参照图2，提出本发明建立消息队列的装置的第一实施例。

在本实施例中，所述建立消息队列的装置包括：

第一确定模块10，用于确定待处理消息的业务类型，根据所述业务类型确定所述待处理消息的传输方式；

在本实施例中，发送端包括服务消费端和事件发布端，接收端包括服务提供端和事件订阅端，所述服务消费端与所述服务提供端对应，所述事件发布端和所述事件订阅端对应。所述发送端和所述接收端存在于分布式系统中，分别与所述分布系统中的消息中间件连接。具体地，所述发送端和所述接收端存在于分布式子系统中，所述分布式子系统组成所述分布式系统。需要说明的是，可以根据业务类型和业务场景来划分分布式子系统，所述发送端决定所述待处理消息的业务类型。消息中间件作为所述分布式系统中所述发送端和所述接收端之间的消息传输工具。

进一步地，所述第一确定模块10还用于若所述待处理消息为待处理服务消息，则所述待处理服务消息的传输方式为同步传输方式；若所述待处理消息为待处理事件消息，则所述待处理事件消息的传输方式为异步传输方式。

若所接收的所述待处理消息为待处理服务消息，即所述待处理消息是由所述服务消费端发出的，所述第一确定模块10则确定所述待处理服务消息的传输方式为同步传输方式。即当所述服务消费端发出服务请求后，在等待所述服务提供端返回与所述服务请求对应的调用结果或者在超时之前，所述服务消费端处于等待状态，且所述服务消费端不释放其占用的线程资源，直到接收到所述服务提供端根据所述待处理消息返回响应消息或者超时时，才执行下一操作。若所述服务提供端超时或者接收所述待处理消息失败时，所述服务消费端可根据具体情况重新发送所述待处理消息。进一步地，当采用同步传输方式时，所述消息中间件中的消息总线采用Request/Response机制来确保所述服务消费端和所述服务提供端之间传输的所述待处理消息成功发送至对方。

若所述待处理消息为待处理事件消息，所述第一确定模块10则确定所述待处理事件消息的传输方式为异步传输方式。即当所述事件发布端向所述消息中间件发出所述待处理事件消息后，所述事件发布端不会等待所述事件订阅端返回调用所述待处理事件消息的结果，所述事件发布端在执行完发送所述待处理事件消息的操作后，释放所占用的线程资源。进一步地，当采用异步传输方式时，所述消息中间件的消息总线采用Pub/Sub机制确保所述事件发布端和所述事件订阅端之间传输的所述待处理事件消息成功发送至对方。所述Pub/Sub机制定义了如何向一个内容节点发布和订阅消息，这些节点被称作主题(topic)，主题可以被认为是消息的传输中介，发布者发布消息到主题，订阅者从主题订阅消息，主题使得消息订阅者和消息发布者保持互相独立，不需要接触即可保证消息的传送。可以理解的是，所述主题存在于所述消息中间件中的消息总线中。

进一步地，所述第一确定模块10包括：

判断单元，用于若所述待处理消息为待处理事件消息，则判断每个接收端的实例是否都可接收所述待处理事件消息；

若所述待处理消息为待处理事件消息，即所述待处理消息为所述事件发布端所发送的，则判断每个接收端的实例是否都可以接收所述待处理事件消息。需要说明的是，所述实例可以接收所述待处理消息，也可以发送所述待处理消息，一个发送端和接收端可以对应着一个或者多个实例。

确定单元，用于若只存在一个接收端可接收所述待处理事件消息，且所述接收端中只存在一个实例接收所述待处理事件消息，则确定所述待处理事件消息的传输方式为单播方式；若存在至少两个接收端可接收所述待处理事件消息，且所述接收端中存在至少一个实例接收所述待处理事件消息，则确定所述待处理事件消息的传输方式为多播方式；

若只存在一个接收端可接收所述待处理事件消息，且所述接收端中只存在一个实例接收所述待处理事件消息，则确定所述待处理事件消息的传输方式为单播方式。若存在至少两个接收端可接收所述待处理事件消息，且所述接收端中存在至少一个实例接收所述待处理事件消息，则确定所述待处理事件消息的传输方式为多播方式。所述服务治理表为所述消息中间件的实例与可接收所述待处理事件消息之间的映射关系表，从所述服务治理表中可以知道所述消息中间件中的实例是否可以接收到所述待处理事件消息。

所述确定单元还用于若所有接收端的实例都接收所述待处理事件消息，则确定所述待处理事件消息的传输方式为广播方式。

若所有在线接收端的实例都接收所述待处理事件消息，则确定所述待处理事件消息的传输方式为广播方式。需要说明的是，所述广播方式在消息总线中是不确保消息送达到对方的，若所述发送端通过广播方式发送所述待处理消息，所述接收端未能正常监测到所述待处理消息，所述待处理消息则会丢失，且所述待处理消息在到达消息中间件时，并不会缓存所述待处理消息，而是直接发送给所有接收端对应的实例。可以理解的是，在所述广播方式下传输所述待处理事件消息，若所述接收端错过所述待处理事件消息，则无法再次获取所述待处理事件消息。

第二确定模块20，用于确定所述待处理消息与待建立的消息队列的对应关系；

建立模块30，用于根据所述对应关系，以及所述待处理消息的传输方式在消息中间件中建立消息队列。

第二确定模块20确定所述待处理消息与待建立的消息队列的对应关系，建立模块30根据所述待处理消息与待建立的消息队列的对应关系和所述待处理消息的传输方式在所述消息中间件中建立消息队列。所述消息队列是在消息的传输过程中保存消息的容器，消息队列管理器在将消息从它的源中继到它的目标时充当中间人，队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收端不可用，消息队列会保留消息，直到可以成功地传递它。

进一步地，若采用同步传输方式传输所述待处理消息，在所述消息中间件中建立所述消息队列后，所述接收端监测所述消息队列，所述发送端往所述消息队列里面发所述待处理消息。当所述接收端在所述消息队列中监测到所述待处理消息后，处理所述待处理消息，并返回对应的响应消息给所述发送端后，所述发送端再次发送所述待处理消息至所述消息队列中。

如若采用单播方式传输所述待处理消息，每个待处理消息对应着一个消息队列；若采用多播方式传输所述待处理消息，每个待处理消息对应着至少两个消息队列；若采用广播方式传输所述待处理消息，每个待处理消息不对应着消息队列，即若采用广播方式传输所述待处理消息，不在所述消息中间件中建立所述消息队列，或者说在所述消息中间建立所述消息队列的个数为零。但是会建立topic，且不持久化消息。

若采用单播方式传输所述待处理消息，则在所述消息中间件中建立一个消息队列后，所述接收端监测所述消息队列，所述发送端往所述消息队列发送所述待处理消息。当所述发送端将所述待处理消息发送至所述消息队列中后，不等待所述接收端返回对应的响应消息，直接再次向所述消息队列中发送所述待处理消息。当所述接收端在所述消息队列中监测到所述待处理消息时，处理所述待处理消息。

若采用多播方式传输所述待处理消息，则在所述消息中间件中建立至少两个消息队列后，所述接收端监测所述消息队列，所述发送端往所述消息队列发送所述待处理消息。当所述发送端将所述待处理消息发送至所述消息队列后，不等待所述接收端返回对应的响应消息，直接再次向所述消息队列发送所述待处理消息。当所述接收端在所述消息队列中监测到所述待处理消息时，处理所述待处理消息。需要说明的是，在多播方式下，会存在多个消息队列，每个消息队列对应着一个接收端。当所述发送端发送所述待处理消息至所述消息队列时，会同时发送至各个消息队列中。

若采用广播方式传输所述待处理消息时，由于并未在所述消息中间件中建立所述消息队列，则多个接收端的多个实例直接在所述消息中间件监测所述待处理消息，所述发送端在将所述待处理消息发送至所述消息中间件中后，直接再次发送其它的所述待处理消息，并不会等待所述接收端返回对应的响应消息，且所述消息中间件中的所有接收端都可监测到所述待处理处理消息。

需要说明的是，所述待处理消息是缓存在所述消息队列中的，若所述接收端的实例取走所述待处理消息后，所述消息队列中的所述待处理消息则不再存在，同一个接收端的其它实例则无法再获取所述待处理消息，从而实现了只有一个实例可接收所述待处理消息。

本实施例通过根据所述待处理消息的业务类型确定所述待处理消息的传输方式；并根据所确定的所述待处理消息与待建立的消息队列的对应关系，以及所述待处理消息的传输方式在消息中间件中建立消息队列。实现通过在消息中间件中建立消息队列，来控制分布式系统中发送端和接收端之间所传输的消息的调用关系。

进一步地，基于第一实施例提出本发明建立消息队列的装置的第二实施例。

在本实施例中，所述第二确定模块20还用于确定所述待处理消息所在的分布式子系统，确定所述分布式子系统对应的业务类别；根据所述业务类别确定所述业务场景，以及确定所述业务场景所在的部署区域；确定所述部署区域所在的环境，根据所述环境确定对应的待建立的消息队列。

所述第二确定模块20确定所述待处理消息所在的分布式子系统，以及确定所述分布式子系统所对应的业务类别。需要说明的是，所述业务类别包括服务和事件。根据所述业务类别确定所述业务场景。当确定所述业务场景后，确定所述业务场景所在的部署区域，以及确定所述部署区域所在的环境。需要说明的是，所述环境包括所述分布式系统的开发环境、测试环境和生产环境等。当确定所述部署区域所在的环境后，根据所述环境确定对应的待建立的消息队列，以此实现通过消息中间件中消息队列来控制分布式系统中发送端和接收端之间的调用关系。可以理解的是，每个待建立的消息队列都有对应的所述待处理消息、分布式子系统、业务类别、业务场景、部署区域和环境。

需要说明的是，由于分布式系统架构的不同，所述分布式系统中不同的部署区域中都可能存在接收端，并且在不同的环境中都存在有接收端。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。