CN105119927A - 消息发送、接收方法及终端和消息发送系统 - Google Patents

Abstract

本申请实施例公开了消息发送、接收方法及终端和消息发送系统。所述消息发送方法包括：通过命名服务确定至少一个消息接收终端；检测是否能够与消息接收终端建立连接；通过远程过程调用协议，向一个能够建立连接的消息接收终端发送消息；以及接收消息接收终端返回的消息处理结果。本申请实施例可以在消息发送终端与消息接收终端之间直接通过远程过程调用协议进行消息传输，实现了减少消息到达延迟的目的。

Description

消息发送、接收方法及终端和消息发送系统

技术领域

本申请涉及通信技术领域，具体涉及数据传输技术领域，尤其涉及消息发送、接收方法及终端和消息发送系统。

背景技术

OpenStack是一个开源的云计算管理平台，其支持几乎所有类型的云环境，项目目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。OpenStack可以由Nova、Neutron、Cinder和Keystone等几个主要的组件组合起来完成具体工作。各个组件一般又由部署在不同机器上的各个模块组合起来完成自己的工作。例如，Nova可以由Api、Conductor、Scheduler、Compute等模块组成。各个组件之间可以通过http(超文本传输协议)进行通信，而组件内的各个模块是通过消息队列进行通信。

图1是现有技术中OpenStack的Nova组件中各模块之间进行通信的示意图。如图1所示，Nova组件中的Api、Conductor、Scheduler、和Compute模块之间并不能直接进行通信，而是需要分别与消息队列进行通信。然后由消息队列作为中转站，实现各模块之间的通信。这种通信方式使得所有的消息发送模块都需要将消息发送到消息队列的消息代理(broker)上，而所有的消息接收模块都从broker上订阅消息。

由于各个模块通过消息队列进行通信时，都依赖消息队列的单点broker，其存在容灾能力差、不易扩展等问题，且消息发送有一定的延迟。

发明内容

鉴于现有技术中的上述缺陷或不足，期望能够提供一种可靠的在模块间进行通信的方案。为了实现上述一个或多个目的，本申请提供了消息发送、接收方法及终端和消息发送系统。

第一方面，本申请提供了一种消息发送方法，包括：通过命名服务确定至少一个消息接收终端；检测是否能够与所述消息接收终端建立连接；通过远程过程调用协议，向一个能够建立连接的所述消息接收终端发送消息；以及接收所述消息接收终端返回的消息处理结果。

第二方面，本申请提供了一种消息接收方法，包括：启动远程过程调用协议的监听端口；若通过所述监听端口检测到由消息发送终端发送的消息，则通过所述远程过程调用协议接收所述消息；对所述消息进行处理，并将消息处理结果返回所述消息发送终端。

第三方面，本申请提供了一种消息发送终端，包括：确定模块，用于通过命名服务确定至少一个消息接收终端；检测模块，用于检测是否能够与所述消息接收终端建立连接；消息发送模块，用于通过远程过程调用协议，向一个能够建立连接的所述消息接收终端发送消息；以及结果接收模块，接收所述消息接收终端返回的消息处理结果。

第四方面，本申请提供了一种消息接收终端，包括：启动模块，用于启动远程过程调用协议的监听端口；消息接收模块，用于若通过所述监听端口检测到由消息发送终端发送的消息，则通过所述远程过程调用协议接收所述消息；消息处理模块，用于对所述消息进行处理，并将消息处理结果返回所述消息发送终端。

第五方面，本申请提供了一种消息发送系统，包括：

消息发送终端，用于通过命名服务确定至少一个消息接收终端；检测是否能够与所述消息接收终端建立连接；通过远程过程调用协议，向一个能够建立连接的所述消息接收终端发送消息；以及接收所述消息接收终端返回的消息处理结果；

消息接收终端，用于启动远程过程调用协议的监听端口；若通过所述监听端口检测到由消息发送终端发送的消息，则通过所述远程过程调用协议接收所述消息；对所述消息进行处理，并将消息处理结果返回所述消息发送终端。

本申请提供的消息发送、接收方法及终端和消息发送系统，可以通过命名服务确定消息接收终端，解耦了消息发送和接收终端，使得消息发送终端与消息接收终端之间可以直接通过远程过程调用协议进行消息传输，避免了消息队列的不利影响，减少了消息到达的延迟。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1是现有技术中OpenStack的Nova组件中各模块之间进行通信的示意图；

图2是本申请消息发送方法的一个实施例的流程图；

图3是本申请消息接收方法的一个实施例的流程图；

图4是本申请中OpenStack的Nova组件中各模块之间进行通信的示意图；

图5是本申请消息发送终端的一个实施例的功能模块构架示意图；

图6是本申请消息接收终端的一个实施例的功能模块构架示意图；

图7是本申请消息发送系统的一个实施例的功能模块构架示意图；

图8是适于用来实现本申请实施例的终端设备或服务器的计算机系统的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。

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

请参考图2，其示出了本申请消息发送方法的一个实施例的流程200。本实施例主要以该方法应用于OpenStack组件中的模块来举例说明，例如，该模块可以是Nova组件中的Api、Conductor、Scheduler、或Compute模块，也可以是Neutron组件中的各个模块。当上述模块作为消息发送终端时，可以应用本实施例中描述的方法进行消息发送。本实施例的消息发送方法，可以包括以下步骤：

如图2所示，在步骤201中，通过命名服务确定至少一个消息接收终端。

在本实施例中，命名服务(NamingService)提供了一种为对象命名的机制，可以定位任何通过网络可以访问的机器上的对象，使得用户可以在无需知道对象位置的情况下获取和使用对象。也就是说，消息发送终端可以根据指定的命名，直接获得相应的消息接收终端。例如，如果消息发送终端的待发送消息中指定了主机名和端口，即Host和Port时，就可以直接根据主机名确定出消息接收终端。在使用命名服务时，首先要将对象在命名服务器上注册，然后其他用户就可以通过命名服务器的地址和该对象在命名服务器上注册的JNDI(JavaNamingandDirectoryInterface，Java命名和目录接口)找到该对象，并获得其引用。

在本实施例的一个可选实现方式中，通过命名服务确定至少一个消息接收终端可以包括：基于待发送消息的主题，通过命名服务获取消息接收终端的部署信息；根据部署信息，确定至少一个消息接收终端。在本实施例中，如果消息发送终端的待发送消息中未指定主机名和端口，但是指定了主题即待发送消息的Topic时，消息发送终端和消息接收终端之间可以通过主题来交换消息。具体地，消息发送终端可以把消息发布到相应的主题字符串(TopicString)，消息接收终端可以在主题上注册。消息发送终端可以获得在该主题上注册的消息接收终端的部署信息，例如，IP地址(互联网协议地址，InternetProtocolAddress)和端口等。通过获取在该主题上注册的所有消息接收终端的部署信息，就可以根据部署信息确定出一个或多个消息接收终端。

接着，在步骤202中，检测是否能够与消息接收终端建立连接。

在本实施例中，当在上述步骤201中确定出一个或多个消息接收终端后，可以进一步检测每个消息发送终端是否能和消息接收终端成功的建立连接，也就是对消息接收终端进行“健康检查”。由于机器本身故障或其它原因，有可能出现消息发送终端无法与某一个消息接收终端建立连接的情况，如果消息发送终端直接将消息发送给这样的消息接收终端，就会导致消息发送失败的问题。因此，在进行消息发送前，需要对消息发送终端和消息接收终端之间的连接情况进行检测。例如，可以由消息发送终端向每一个消息接收终端发送连接请求，如果该请求得到了消息接收终端的正常响应，则认为二者之间可以正常连接，该消息接收终端是“健康”的，否则认为二者之间无法正常连接，该消息接收终端是“不健康”的。

继而，在步骤203中，通过远程过程调用协议，向一个能够建立连接的消息接收终端发送消息。

当在上述步骤202中确定出消息发送终端能够与一个或多个消息接收终端建立连接后，可以通过远程过程调用(RemoteProcedureCall，RPC)协议，向一个能够建立连接的消息接收终端发送消息。其中，RPC是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议可以假定某些传输协议的存在，从而为通信程序之间携带信息数据。RPC通常可以采用客户机/服务器模式。在本实施例中，消息发送终端可以是一个客户机，而消息接收终端可以是一个服务器。消息发送终端可以向一个能够建立连接的消息接收终端发起RPC调用，并通过RPC协议向该终端发送消息。这样，消息发送终端在发送消息时，可以选取一个“健康”的消息接收终端进行发送。在这种情况下，即使有某个消息接收终端宕机，也不会影响整个集群的正常运行。

在本实施例的一个可选实现方式中，消息发送方法还包括：采用轮询调度的方式，从多个能够建立连接的消息接收终端中确定出一个向其发送消息的消息接收终端。轮询调度(Round-RobinScheduling)的原理是每一次把来自用户的请求轮流分配给内部中的服务器，从1开始，直到N(内部服务器个数)，然后重新开始循环。在本实施例中，可以采用轮询调度的方式，确定出向哪一个消息接收终端发送消息，并且该消息接收终端可以与消息发送终端成功建立连接。这种确定唯一消息接收终端的方式十分简洁，无需记录当前所有连接的状态，降低了系统消耗。

最后，在步骤204中，接收消息接收终端返回的消息处理结果。

当在上述步骤203中将消息发送给一个消息接收终端后，消息接收终端可以对接收到的消息进行处理，例如，根据消息中的参数进行计算等然后再将消息处理结果发回给消息发送终端。此时，消息发送终端就可以接收消息接收终端返回的消息处理结果。本领域技术人员可以理解，这个消息处理结果返回的步骤也可以是通过RPC协议完成的。

本实施例提供的消息发送方法，可以通过命名服务确定消息接收终端，解耦了消息发送和接收终端，使得消息发送终端与消息接收终端之间可以直接通过远程过程调用协议进行消息传输，避免了消息队列的不利影响，减少了消息到达的延迟。

请进一步参考图3，其示出了本申请消息接收方法的一个实施例的流程300。

如图3所示，在步骤301中，启动远程过程调用协议的监听端口。

在本实施例中，可以首先启动远程过程调用协议，即RPC协议的监听端口。该端口可以是消息接收终端上用于进行RPC调用的端口。

接着，在步骤302中，若通过监听端口检测到由消息发送终端发送的消息，则通过远程过程调用协议接收消息。

在本实施例中，当在上述步骤301中启动端口监听后，如果通过监听端口检测到由消息发送终端发送给本端口的消息，也就是检测到消息发送终端所发送的消息中，指定的目标端口是自己的端口号时，则可以通过RPC协议接收该消息。

最后，在步骤303中，对消息进行处理，并将消息处理结果返回消息发送终端。

当在上述步骤302中接收到消息后，消息接收终端可以对接收到的消息进行处理，例如，根据消息中的参数进行计算等然后再将消息处理结果发回给消息发送终端。此时，消息发送终端就可以接收消息接收终端返回的消息处理结果。

图4是本申请中OpenStack的Nova组件中各模块之间进行通信的示意图。如图4所示，除了Api模块和Scheduler模块之间不能直接通信外，Nova组件中的Api、Scheduler和Conductor、Compute模块，以及Conductor和Compute模块之间都可以直接进行通信。由于各个模块之间都是通过RPC协议直接进行通信，从而避免了消息队列的不利影响，减少了消息到达的延迟。

请进一步参考图5，其示出了本申请消息发送终端的一个实施例的结构示意图。

如图5所示，本实施例的消息发送终端500包括：确定模块510、检测模块520、消息发送模块530和结果接收模块540。

确定模块510，用于通过命名服务确定至少一个消息接收终端。

检测模块520，用于检测是否能够与消息接收终端建立连接。

消息发送模块530，用于通过远程过程调用协议，向一个能够建立连接的消息接收终端发送消息。

结果接收模块540，接收消息接收终端返回的消息处理结果。

在本实施例的一个可选实现方式中，确定模块510进一步用于，基于待发送消息的主题，通过命名服务获取消息接收终端的部署信息；根据部署信息，确定至少一个消息接收终端。

在本实施例的一个可选实现方式中，消息发送终端500还包括：

轮训模块，用于采用轮询调度的方式，从多个能够建立连接的消息接收终端中确定出一个向其发送消息的消息接收终端。

请进一步参考图6，其示出了本申请消息接收终端的一个实施例的结构示意图。

如图6所示，本实施例的消息接收终端600包括：启动模块610、消息接收模块620和消息处理模块630。

启动模块610，用于启动远程过程调用协议的监听端口。

消息接收模块620，用于若通过监听端口检测到由消息发送终端发送的消息，则通过远程过程调用协议接收消息。

消息处理模块630，用于对消息进行处理，并将消息处理结果返回消息发送终端。

应当理解，图5和6中记载的诸单元或模块与参考图2和3描述的方法中的各个步骤相对应。由此，上文针对方法描述的操作和特征同样适用于图5和6中的终端及其中包含的单元或模块，在此不再赘述。

请进一步参考图7，其示出了本申请消息发送系统的一个实施例的结构示意图。

如图7所示，本实施例的消息发送系统700包括：消息发送终端710和消息接收终端720。

消息发送终端710，用于通过命名服务确定至少一个消息接收终端720；检测是否能够与消息接收终端720建立连接；通过远程过程调用协议，向一个能够建立连接的消息接收终端720发送消息；以及接收消息接收终端720返回的消息处理结果。

消息接收终端720，用于启动远程过程调用协议的监听端口；若通过监听端口检测到由消息发送终端710发送的消息，则通过远程过程调用协议接收消息；对消息进行处理，并将消息处理结果返回消息发送终端710。

在本实施例的一个可选实现方式中，消息发送终端710和消息接收终端720均为OpenStack组件中的模块。例如，消息发送终端710和消息接收终端720可以分别为OpenStack的Nova组件中的Conductor模块和Compute模块。

上述实施例提供的消息发送、接收终端和消息发送系统，可以通过命名服务确定消息接收终端，解耦了消息发送和接收终端，使得消息发送终端与消息接收终端之间可以直接通过远程过程调用协议进行消息传输，避免了消息队列的不利影响，减少了消息到达的延迟。

下面参考图8，其示出了适于用实现本申请实施例的终端设备或服务器的计算机系统800的结构示意图。

如图8所示，计算机系统800包括中央处理单元(CPU)801，其可以根据存储在只读存储器(ROM)802中的程序或者从存储部分808加载到随机访问存储器(RAM)803中的程序而执行各种适当的动作和处理。在RAM803中，还存储有系统800操作所需的各种程序和数据。CPU801、ROM802以及RAM803通过总线804彼此相连。输入/输出(I/O)接口805也连接至总线804。

以下部件连接至I/O接口805：包括键盘、鼠标等的输入部分806；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分807；包括硬盘等的存储部分808；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至I/O接口805。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入存储部分808。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括有形地包含在机器可读介质上的计算机程序，所述计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分809从网络上被下载和安装，和/或从可拆卸介质811被安装。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，所述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括确定模块、检测模块、消息发送模块和结果接收模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，确定模块还可以被描述为“用于通过命名服务确定至少一个消息接收终端的模块”。

作为另一方面，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中所述终端中所包含的计算机可读存储介质；也可以是单独存在，未装配入终端中的计算机可读存储介质。所述计算机可读存储介质存储有一个或者一个以上程序，所述程序被一个或者一个以上的处理器用来执行描述于本申请的消息发送方法。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离所述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (10)

1.一种消息发送方法，其特征在于，包括：

通过命名服务确定至少一个消息接收终端；

检测是否能够与所述消息接收终端建立连接；

通过远程过程调用协议，向一个能够建立连接的所述消息接收终端发送消息；以及

接收所述消息接收终端返回的消息处理结果。

2.根据权利要求1所述的方法，其特征在于，所述通过命名服务确定至少一个消息接收终端包括：

基于待发送消息的主题，通过命名服务获取消息接收终端的部署信息；

根据所述部署信息，确定至少一个消息接收终端。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

采用轮询调度的方式，从多个能够建立所述连接的消息接收终端中确定出一个向其发送消息的消息接收终端。

4.一种消息接收方法，其特征在于，包括：

启动远程过程调用协议的监听端口；

若通过所述监听端口检测到由消息发送终端发送的消息，则通过所述远程过程调用协议接收所述消息；

对所述消息进行处理，并将消息处理结果返回所述消息发送终端。

5.一种消息发送终端，其特征在于，包括：

确定模块，用于通过命名服务确定至少一个消息接收终端；

检测模块，用于检测是否能够与所述消息接收终端建立连接；

消息发送模块，用于通过远程过程调用协议，向一个能够建立连接的所述消息接收终端发送消息；以及

结果接收模块，接收所述消息接收终端返回的消息处理结果。

6.根据权利要求5所述的终端，其特征在于，所述确定模块进一步用于，基于待发送消息的主题，通过命名服务获取消息接收终端的部署信息；根据所述部署信息，确定至少一个消息接收终端。

7.根据权利要求5所述的终端，其特征在于，所述终端还包括：

轮训模块，用于采用轮询调度的方式，从多个能够建立所述连接的消息接收终端中确定出一个向其发送消息的消息接收终端。

8.一种消息接收终端，其特征在于，包括：

启动模块，用于启动远程过程调用协议的监听端口；

消息接收模块，用于若通过所述监听端口检测到由消息发送终端发送的消息，则通过所述远程过程调用协议接收所述消息；

消息处理模块，用于对所述消息进行处理，并将消息处理结果返回所述消息发送终端。

9.一种消息发送系统，其特征在于，包括：

消息发送终端，用于通过命名服务确定至少一个消息接收终端；检测是否能够与所述消息接收终端建立连接；通过远程过程调用协议，向一个能够建立连接的所述消息接收终端发送消息；以及接收所述消息接收终端返回的消息处理结果；

消息接收终端，用于启动远程过程调用协议的监听端口；若通过所述监听端口检测到由消息发送终端发送的消息，则通过所述远程过程调用协议接收所述消息；对所述消息进行处理，并将消息处理结果返回所述消息发送终端。

10.根据权利要求9所述的系统，其特征在于，所述消息发送终端和消息接收终端均为OpenStack组件中的模块。