CN115086416B - 基于订阅机制的通信系统及通信方法 - Google Patents

Abstract

本申请涉及一种基于订阅机制的通信系统及通信方法，其中，该系统包括：代理端，与服务端连接，用于接收用户根据预设的传输格式构建的消息，传输格式包括消息身份信息和消息内容，通过代理端的消息队列将消息发送至所述服务端；服务端，用于在消息为请求消息时，将消息与消息订阅列表的消息进行消息身份信息的通配，并将通配得到的消息传输给代理端，以使代理端通过消息身份信息将消息中的消息内容分发至对应用户。通过本申请，解决了相关技术中消息无法进行通配订阅以及消息分发过程繁琐的问题，实现了通配订阅以及减轻系统分发消息压力的有益效果。

Description

基于订阅机制的通信系统及通信方法

技术领域

本申请涉及通信技术领域，特别是涉及一种基于订阅机制的通信系统及通信方法。

背景技术

目前软件系统集成化发展，随之也带来了消息传递任务繁重的问题，因此在系统中广泛使用消息订阅机制，以此完成消息的订阅与分发，在这种机制中，消息队列是不可缺少的关键环节。

目前系统的方案，基于不同的消息主题与消息队列的对应关系，代理端与服务端通过中间节点传递消息。这种传递模式可以完成订阅消息的推送，但由于按照消息主题管理各个消息队列，无法提取单个消息的传递节点，导致流转过程不透明，并且通过中间节点的二次分发增加系统负担。

针对相关技术中存在消息无法进行通配订阅以及消息分发过程繁琐的问题，目前还没有提出有效的解决方案。

发明内容

在本实施例中提供了一种基于订阅机制的通信系统及通信方法，以解决相关技术中消息无法进行通配订阅以及消息分发过程繁琐的问题。

第一个方面，在本实施例中提供了一种基于订阅机制的通信系统，包括至少一个代理端和服务端，其中，

所述代理端，与所述服务端连接，用于接收用户根据预设的传输格式构建的消息，所述传输格式包括消息身份信息和消息内容，通过所述代理端的消息队列将所述消息发送至所述服务端；

所述服务端，用于在所述消息为请求消息时，将所述消息与所述消息订阅列表的消息进行消息身份信息的通配，并将通配得到的消息传输给所述代理端，以使所述代理端通过所述消息身份信息将消息中的消息内容分发至对应用户。

在其中一些实施例中，所述代理端包括消息订阅接口、消息发布接口、消息过程调用接口和消息消费接口，其中，

所述消息订阅接口，用于基于所述消息身份信息提供对应用户的消息订阅的通道；

所述消息发布接口，用于提供用户投递消息的通道；

所述消息同步调用接口，用于提供用户过程调用的通道；

所述消息消费接口，用于提供用户处理消息的通道。

在其中一些实施例中，所述消息订阅接口，用于基于所述消息身份信息提供对应用户的消息订阅的通道，包括：

基于所述消息身份信息生成用户关注的订阅消息；

将所述用户插入到订阅者列表；

汇总所述代理端所有用户的消息身份消息并构建订阅消息；

将所述订阅消息投递到消息队列中。

在其中一些实施例中，所述消息发布接口，用于提供用户投递消息的通道，包括：

根据所述预设的传输格式构建消息，并将所述消息投递到所述代理端的消息队列中。

在其中一些实施例中，所述消息同步调用接口，用于提供用户过程调用的通道，包括：

根据所述预设的传输格式构建请求消息，并将所述请求消息投递到所述代理端的消息队列中；

等待应答消息。

在其中一些实施例中，所述消息消费接口，用于提供用户处理消息的通道，包括：

判断新消息是否为同步调用消息；

若是，则判断应答消息是否构建成功；

将所述应答消息投递到所述代理端的消息队列中。

在其中一些实施例中，所述服务端中的所述消息与所述消息订阅列表的消息进行消息身份信息通配，还包括：

在若通配成功之后，则将所述消息投递到传输控制协议通道。

第二个方面，在本实施例中提供了一种基于订阅机制的通信方法，所述方法包括：

接收用户根据预设的传输格式构建的消息，所述传输格式包括消息身份信息和消息内容，通过代理端的消息队列将所述消息发送至服务端；

在所述消息为请求消息时，将所述消息与消息订阅列表的消息进行消息身份信息的通配，并将通配得到的消息传输给所述代理端；

通过所述消息身份信息将消息中的消息内容分发至对应用户。

与相关技术相比，在本实施例中提供的基于订阅机制的系统及方法，其中，系统包括：代理端和服务端；代理端与所述服务端连接，用于接收用户根据预设的传输格式构建的消息，预设的传输格式包括消息身份信息和消息内容，通过代理端的消息队列将消息发送至服务端；服务端，用于在消息为请求消息时，将消息与消息订阅列表的消息进行消息身份信息的通配，并将通配得到的消息传输给代理端，以使代理端通过消息身份信息将消息中的消息内容分发至对应用户，解决了相关技术中消息无法进行通配订阅以及消息分发过程繁琐的问题，实现了通配订阅以及减轻系统分发消息压力的有益效果。

本申请的一个或多个实施例的细节在以下附图和描述中提出，以使本申请的其他特征、目的和优点更加简明易懂。

附图说明

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

图1是根据本申请实施例的一种基于订阅机制的通信系统的结构示意图；

图2是根据本申请实施例的一种基于订阅机制的通信方法的流程图；

图3是根据本申请实施例的一种基于订阅机制的通信系统的服务端的流程图；

图4是根据本申请实施例的一种基于订阅机制的通信系统的代理端示意图；

图5是根据本申请实施例的一种基于订阅机制的通信系统的消息订阅接口的流程图；

图6是根据本申请实施例的一种基于订阅机制的通信系统的消息发布接口的流程图；

图7是根据本申请实施例的一种基于订阅机制的通信系统的消息同步调用接口的流程图；

图8是根据本申请实施例的一种基于订阅机制的通信系统的消息消费接口的流程图。

具体实施方式

为更清楚地理解本申请的目的、技术方案和优点，下面结合附图和实施例，对本申请进行了描述和说明。

除另作定义外，本申请所涉及的技术术语或者科学术语应具有本申请所属技术领域具备一般技能的人所理解的一般含义。在本申请中的“一”、“一个”、“一种”、“该”、“这些”等类似的词并不表示数量上的限制，它们可以是单数或者复数。在本申请中所涉及的术语“包括”、“包含”、“具有”及其任何变体，其目的是涵盖不排他的包含；例如，包含一系列步骤或模块(单元)的过程、方法和系统、产品或设备并未限定于列出的步骤或模块(单元)，而可包括未列出的步骤或模块(单元)，或者可包括这些过程、方法、产品或设备固有的其他步骤或模块(单元)。在本申请中所涉及的“连接”、“相连”、“耦接”等类似的词语并不限定于物理的或机械连接，而可以包括电气连接，无论是直接连接还是间接连接。在本申请中所涉及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。通常情况下，字符“/”表示前后关联的对象是一种“或”的关系。在本申请中所涉及的术语“第一”、“第二”、“第三”等，只是对相似对象进行区分，并不代表针对对象的特定排序。

在本实施例中提供了一种基于订阅机制的通信系统，图1是根据本申请实施例的基于订阅机制的通信系统的结构示意图，如图1所示，该系统包括至少一个代理端100和服务端200；

代理端100，与服务端200连接，用于接收用户根据预设的传输格式构建的消息，传输格式包括消息身份信息和消息内容，通过代理端100的消息队列将消息发送至服务端200；

其中，预设的传输格式包括消息身份信息和消息内容，消息身份信息是一段用户自定义的字符串，通常用“.”符号进行分割；而消息内容是一段没有格式约束的连续的内存块，可以承载用户输入的任意数据。

其中，在代理端接收用户构建的消息之前，代理端会进行初始化，创建消息队列包括消息投递队列与消息消费队列，消息投递队列将消息结构序列化为数据流投递到套接字中，而消息消费队列用于接收消息并将消息传递给订阅用户。

其中，消息队列是在消息的传输过程中保存消息的容器，代理端可以向消息队列中按照订阅用户以及消息身份信息添加新的消息，其主要目的是提供路由并保证消息的传递。

服务端200，用于在消息为请求消息时，将消息与消息订阅列表300的消息进行消息身份信息的通配，并将通配得到的消息传输给代理端100，以使代理端100通过消息身份信息将消息中的消息内容分发至对应用户。

其中，请求消息本质上是由代理端发送至服务端的请求数据，用户在代理端根据消息身份信息和消息内容构建请求消息，将消息投递至消息队列中并等待对应的应答消息，不仅可以实现消息的订阅与分发，也可以实现消息的同步过程调用，将消息处理节点可视化。

其中，通配是把一个包含通配符的非具体文件名扩展到存储在计算机、服务器或者网络上的一批具体文件名的过程。而通配应用于本申请的消息订阅模型中，在消息为请求消息时，将请求消息与消息订阅列表的消息身份信息所包含的字符串进行模糊匹配。其中根据实际的消息订阅要求将部分字符串自定义为通配符，若两者的消息身份信息包含相同的通配符，则视为通配成功。

目前系统中消息传输的方案，基于不同的消息主题与消息队列的对应关系，代理端与服务端通过中间节点传递消息。这种传递模式可以完成订阅消息的推送，但由于按照消息主题管理各个消息队列，无法提取单个消息的传递节点，导致流转过程不透明，并且通过中间节点的二次分发增加系统负担。而本申请提供了一种基于订阅机制的通信系统，其中，系统包括至少一个代理端和服务端，用户根据消息身份信息和消息内容构建消息投递到代理端，通过代理端的消息队列将消息发送至服务端，且服务端在接收代理端的消息为请求消息时，由于构建的消息包含了消息身份信息和消息内容，导致单个消息被不同的消息身份信息标识，使得可以将消息与消息订阅列表的消息进行消息身份信息的通配，并将通配得到的消息传输给代理端。由此可见，通过预设消息身份信息和设置代理端中的各个接口与服务端解决了相关技术中消息无法进行通配订阅以及消息分发过程繁琐的问题，实现了通配订阅以及减轻系统分发消息压力的有益效果。

在其中一些实施例中，请参阅图3。

步骤S301，代理端的消息队列将消息发送至服务端，服务端获取新消息。

步骤S302，服务端对消息的类型进行判断。

步骤S303至S304，若服务端收到订阅消息，则将消息插入到消息订阅列表。

步骤S305，若服务端收到应答消息，则将消息投递到该消息对应的请求消息的传输控制协议通道中。

步骤S306至S307，若服务端收到请求消息，则根据预设的传输格式在消息订阅列表中通配查找订阅用户。

步骤S308至S309，在通配成功之后则将该消息投递到传输控制协议通道，并进一步传输至代理端。

其中，在服务端判断消息类型之前，该服务端会进行初始化并创建三个对象分别为套接字服务、消息订阅列表以及代理端表，其中套接字是对网络中不同主机上的应用进程之间进行双向通信的端点的抽象，一个套接字就是网络上进程通信的一端，提供了应用层进程利用网络协议交换数据的机制，该服务用于各个代理端之间的数据交换；消息订阅列表是服务端中的消息队列，在服务端接收到各个代理端发送的消息时，记录各个代理端所关注的消息身份信息；代理端表用于记录当前已链接的代理端，便于各个代理端之间进行数据交换。

其中，传输控制协议是一种面向连接的、可靠的、基于字节流的传输层通信协议，主要用于建立一个虚拟连接，以实现高可靠性的数据包交换。而传输控制协议通道是基于传输控制协议实现远程访问或控制本地网络设备的通道，也就是通过端口可以使相互连接的设备共享设备资源。由于传输控制协议通过序列号与确认应答来保证消息的传输，提高了代理端与服务端之间消息传递的可靠性，防止数据的破坏、丢失以及顺序混乱。

在其中一些实施例中，请参阅图4，所述代理端包括消息订阅接口10、消息发布接口20、消息同步调用接口30和消息消费接口40。

下面对各接口进行详细说明：

在其中一些实施例中，消息订阅接口，用于基于消息身份信息提供对应用户的消息订阅的通道，请参阅图5。

步骤S501至S502，上述消息订阅接口在接收到用户关心的消息后，创建订阅用户对象以及对应添加订阅用户关注的消息。

步骤S503，将订阅用户对象插入到订阅者列表中。

步骤S504，汇总该代理端所有订阅用户订阅的消息身份信息，并根据消息身份信息构建订阅消息。

步骤S505，将订阅消息投递到该代理端的消息队列中。

其中，在消息订阅过程中，订阅用户以通配符的形式模糊匹配不同消息身份信息对应的消息，例如：

1)订阅“*”代表订阅所有消息；

2)订阅“.net.”代表订阅任何含有“.net.”的消息身份信息对应的消息；

3)订阅“.app”代表订阅任何以“.app”结尾的消息身份信息对应的消息；

4)订阅“app.”代表订阅任何以“app.”开头的消息身份信息对应的消息。

上述的通配订阅过程，基于预设的消息身份信息，用户可以根据通配符订阅自己关注的消息，并准确接收订阅消息的推送，实现了消息的通配订阅，在保证消息传递准确性的同时，使得消息可被多个订阅用户接收，并且订阅用户可通过通配符接收多个类型的消息，提高了消息传递的效率。

在其中一些实施例中，消息发布接口，用于提供用户投递消息的通道，请参阅图6。

步骤S601，上述消息发布接口提供给用户的参数为消息身份信息和消息内容，用户根据参数来构建消息。

步骤S602，该接口则将消息投递到代理端的消息队列中。

其中，在构建消息的过程中，用户输入消息身份信息与消息内容，然后消息发布接口通过将消息对应的消息身份信息和消息内容传递到代理端，并组装成预设的传输格式。

上述的消息投递过程，用户可以主动构建消息投递至代理端中，并通过预设的传输格式订阅消息，获取自己关心的消息。

在其中一些实施例中，消息同步调用接口，用于提供用户过程调用的通道，请参阅图7。

步骤S701，上述消息同步调用接口提供给用户的参数为消息身份信息和消息内容，用户根据参数来构建请求消息。

步骤S702，该接口将请求消息投递到代理端的消息队列中。

步骤S703，等待应答消息。

其中，应答消息包括与原请求消息对应的消息内容以及反馈信息，反馈信息用于指出消息的到达情况，消息的确认情况或者原始消息是否有错误发生，例如，应答消息中含有消息是否被处理和消息的处理结果。

其中，应答消息与对应的请求消息的消息身份信息相同，以此准确关联到对应的请求消息。

上述的同步调用过程，用户根据消息身份信息和消息内容构建请求消息，并等待服务端返回对应的应答消息，基于消息身份信息可以获取当前的消息处理节点，实现了消息流转的可视化。

在其中一些实施例中，消息消费接口，用于提供用户处理消息的通道，请参阅图8。

步骤S801，上述消息消费接口接收新消息。

步骤S802，判断新消息是否为同步调用消息。

步骤S803，在新消息为同步调用消息的情况下，判断应答消息是否构建成功。

步骤S804，将应答消息投递到代理端的消息队列中。

其中，同步消息传递涉及到等待服务端应答消息的代理端，本质上同步消息传递是双向通信，代理端发送请求消息至服务端，而服务端接收该请求消息并返回应答消息至代理端，且代理端在接收到服务端对应的应答消息之前不会发送另一条消息。

上述的消息消费过程，该接口在获取新消息之后，判断是否为同步调用消息，在新消息为同步调用消息的情况下，判断应答消息是否构建成功，并将应答消息投递到代理端的消息队列中，用户可以从消息队列中获取与请求消息对应的消息进行消费，以此获知消息处理节点或者消息处理结果。

下面通过优选实施例对本实施例进行描述和说明。

本优选实施例的基于订阅机制的通信系统，包括至少一个代理端和服务端：

代理端，与服务端连接，用于接收用户根据预设的传输格式构建的消息，传输格式包括消息身份信息和消息内容，通过代理端的消息队列将消息发送至服务端；

其中，代理端包括消息订阅接口、消息发布接口、消息同步调用接口以及消息消费接口，消息订阅接口，用于基于消息身份信息提供对应用户的消息订阅的通道；消息发布接口，用于提供用户投递消息的通道；消息同步调用接口，用于提供用户过程调用的通道；消息消费接口，用于提供用户处理消息的通道。

服务端，用于在消息为请求消息时，将消息与消息订阅列表的消息进行消息身份信息的通配，并将通配得到的消息传输给代理端，以使代理端通过消息身份信息将消息中的消息内容分发至对应用户。

其中，在消息为订阅消息时，则将消息插入到消息订阅列表；在消息为应答消息时，则将消息投递到该消息对应的请求消息的传输控制协议通道中。

通过本实施例，代理端中包含多个消息处理接口，能够在代理端接收到的消息数量较多时有效缓解消息压力，并在服务端进行消息类型判断，依据不同类型消息的传递通道对应处理各类消息，同时，基于消息身份信息，消息在代理端和服务端的流转过程中保持可视化。

在本实施例中还提供了一种基于订阅机制的通信方法。图2是本实施例的另一种基于订阅机制的通信方法的流程图，如图2所示，该流程包括如下步骤：

步骤S201，接收用户根据预设的传输格式构建的消息，传输格式包括消息身份信息和消息内容，通过代理端的消息队列将消息发送至服务端；

其中，预设的传输格式包括消息身份信息和消息内容，消息身份信息是一段用户自定义的字符串，通常用“.”符号进行分割；而消息内容是一段没有格式约束的连续的内存块，可以承载用户输入的任意数据。

其中，在代理端接收用户构建的消息之前，代理端会进行初始化，创建消息队列包括消息投递队列与消息消费队列，消息投递队列将消息结构序列化为数据流投递到套接字中，而消息消费队列用于接收消息并将消息传递给订阅用户。

其中，消息队列是在消息的传输过程中保存消息的容器，代理端可以向消息队列中按照订阅用户以及消息身份信息添加新的消息，其主要目的是提供路由并保证消息的传递。

步骤S202，在消息为请求消息时，将消息与消息订阅列表的消息进行消息身份信息的通配，并将通配得到的消息传输给代理端；

其中，请求消息本质上是由代理端发送至服务端的请求数据，用户在代理端根据消息身份信息和消息内容构建请求消息，将消息投递至消息队列中并等待对应的应答消息，不仅可以实现消息的订阅与分发，也可以实现消息的同步过程调用，将消息处理节点可视化。

其中，通配是把一个包含通配符的非具体文件名扩展到存储在计算机、服务器或者网络上的一批具体文件名的过程。而通配应用于本申请的消息订阅模型中，在消息为请求消息时，将请求消息与消息订阅列表的消息的消息身份信息所包含的字符串进行模糊匹配，其中本申请根据实际的消息订阅要求将部分字符串自定义为通配符，若两者的消息身份信息包含相同的的通配符，则视为通配成功。

步骤S203，通过消息身份信息将消息中的消息内容分发至对应用户。

本实施例中提供了一种基于订阅机制的通信方法，用户根据消息身份信息和消息内容构建消息投递到代理端，通过代理端的消息队列将消息发送至服务端，且服务端在接收代理端的消息为请求消息时，将消息与消息订阅列表的消息进行消息身份信息的通配，并将通配得到的消息传输给代理端。由此可见，通过系统解决了相关技术中消息无法进行通配订阅以及消息分发过程繁琐的问题，实现了通配订阅以及减轻系统分发消息压力的有益效果。

在其中一些实施例中，该方法还包括：

消息订阅，基于所述消息身份信息实现对应用户的消息订阅；

在接收到用户关心的消息后，创建订阅用户对象以及对应添加订阅用户关注的消息，将订阅用户对象插入到订阅者列表中，然后汇总该代理端所有订阅用户订阅的消息身份信息，并根据消息身份信息构建订阅消息，进而将订阅消息投递到该代理端的消息队列中。

其中，在消息订阅过程中，订阅用户以通配符的形式模糊匹配不同消息身份信息对应的消息，例如：

1)订阅“*”代表订阅所有消息；

2)订阅“.net.”代表订阅任何含有“.net.”的消息身份信息对应的消息；

3)订阅“.app”代表订阅任何以“.app”结尾的消息身份信息对应的消息；

4)订阅“app.”代表订阅任何以“app.”开头的消息身份信息对应的消息。

上述的通配订阅过程，基于预设的消息身份信息，用户可以根据通配符订阅自己关注的消息，并准确接收订阅消息的推送，实现了消息的通配订阅，在保证消息传递准确性的同时，使得消息可被多个订阅用户接收，并且订阅用户可通过通配符接收多个类型的消息，提高了消息传递的效率。

在其中一些实施例中，该方法还包括：

消息发布，用户投递消息至代理端；

其中，提供给用户的参数为消息身份信息和消息内容，用户根据参数来构建消息，该接口则将消息投递到代理端的消息队列中。

其中，在构建消息的过程中，用户输入消息身份信息与消息内容，然后消息发布接口通过将消息对应的消息身份信息和消息内容传递到代理端，并组装成预设的传输格式。

上述的消息投递过程，用户可以主动构建消息投递至代理端中，并通过预设的传输格式订阅消息，以此主动获取自己关心的多个类型消息。

在其中一些实施例中，该方法还包括：

消息同步调用，用户实现同步过程调用；

提供给用户的参数为消息身份信息和消息内容，用户根据参数来构建请求消息，该接口将请求消息投递到代理端的消息队列中，并等待应答消息。

其中，应答消息包括与原请求消息对应的消息内容以及反馈信息，反馈信息用于指出消息的到达情况，消息的确认情况或者原始消息是否有错误发生，例如，应答消息中含有消息是否被处理和消息的处理结果。

其中，应答消息与对应的请求消息的消息身份信息相同，以此准确关联到对应的请求消息。

上述的同步调用过程，用户根据消息身份信息和消息内容构建请求消息，并等待服务端返回对应的应答消息，基于消息身份信息可以获取当前的消息处理节点，实现了消息流转的可视化。

在其中一些实施例中，该方法还包括：

消息消费，用户进行消息处理；

其中，在接收到新消息后，判断新消息是否为用户关注的消息，若该消息是用户订阅的消息则进一步判断是否为同步调用消息，在新消息为同步调用消息的情况下，判断应答消息是否构建成功，并将应答消息投递到代理端的消息队列中。

其中，同步消息传递涉及到等待服务端应答消息的代理端，本质上同步消息传递是双向通信，代理端发送请求消息至服务端，而服务端接收该请求消息并返回应答消息至代理端，且代理端在接收到服务端对应的应答消息之前不会发送另一条消息。

上述的消息消费过程，在获取新消息之后，判断是否为同步调用消息，在新消息为同步调用消息的情况下，判断应答消息是否构建成功，并将应答消息投递到代理端的消息队列中，用户可以从消息队列中获取与请求消息对应的消息进行消费，以此获知消息处理节点或者消息处理结果。

应该明白的是，这里描述的具体实施例只是用来解释这个应用，而不是用来对它进行限定。根据本申请提供的实施例，本领域普通技术人员在不进行创造性劳动的情况下得到的所有其它实施例，均属本申请保护范围。

显然，附图只是本申请的一些例子或实施例，对本领域的普通技术人员来说，也可以根据这些附图将本申请适用于其他类似情况，但无需付出创造性劳动。另外，可以理解的是，尽管在此开发过程中所做的工作可能是复杂和漫长的，但是，对于本领域的普通技术人员来说，根据本申请披露的技术内容进行的某些设计、制造或生产等更改仅是常规的技术手段，不应被视为本申请公开的内容不足。

“实施例”一词在本申请中指的是结合实施例描述的具体特征、结构或特性可以包括在本申请的至少一个实施例中。该短语出现在说明书中的各个位置并不一定意味着相同的实施例，也不意味着与其它实施例相互排斥而具有独立性或可供选择。本领域的普通技术人员能够清楚或隐含地理解的是，本申请中描述的实施例在没有冲突的情况下，可以与其它实施例结合。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对专利保护范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims (8)

1.一种基于订阅机制的通信系统，其特征在于，包括：代理端和服务端；

所述代理端，与所述服务端连接，用于接收用户根据预设的传输格式构建的消息，所述传输格式包括消息身份信息和消息内容，通过所述代理端的消息队列将所述消息发送至所述服务端；

所述服务端，用于在所述消息为请求消息时，将所述消息与所述消息订阅列表的消息进行消息身份信息的通配，并将通配得到的消息传输给所述代理端，以使所述代理端通过所述消息身份信息将消息中的消息内容分发至对应用户；

其中，所述代理端包括消息订阅接口、消息发布接口、消息同步调用接口和消息消费接口；所述消息订阅接口，用于基于所述消息身份信息提供对应用户的消息订阅的通道；所述消息发布接口，用于提供用户投递消息的通道；所述消息同步调用接口，用于提供用户过程调用的通道；所述消息消费接口，用于提供用户处理消息的通道；

其中，所述消息消费接口，用于提供用户处理消息的通道，包括：判断新消息是否为同步调用消息；若是，则判断应答消息是否构建成功；将所述应答消息投递到所述代理端的消息队列中。

2.根据权利要求1所述的基于订阅机制的通信系统，其特征在于，所述服务端，用于在所述消息为订阅消息时，将所述消息插入到订阅者列表。

3.根据权利要求1所述的基于订阅机制的通信系统，其特征在于，所述服务端，用于在所述消息为应答消息时，将所述消息投递到传输控制协议通道中。

4.根据权利要求1所述的基于订阅机制的通信系统，其特征在于，所述消息订阅接口，用于基于所述消息身份信息提供对应用户的消息订阅的通道，包括：

基于所述消息身份信息生成用户关注的订阅消息；

将所述用户插入到订阅者列表；

汇总所述代理端所有用户的消息身份消息并构建订阅消息；

将所述订阅消息投递到消息队列中。

5.根据权利要求1所述的基于订阅机制的通信系统，其特征在于，所述消息发布接口，用于提供用户投递消息的通道，包括：

根据所述预设的传输格式构建消息，并将所述消息投递到所述代理端的消息队列中。

6.根据权利要求1所述的基于订阅机制的通信系统，其特征在于，所述消息同步调用接口，用于提供用户过程调用的通道，包括：

根据所述预设的传输格式构建请求消息，并将所述请求消息投递到所述代理端的消息队列中；

等待应答消息。

7.根据权利要求1所述的基于订阅机制的通信系统，其特征在于，所述服务端中的所述消息与所述消息订阅列表的消息进行消息身份信息通配，还包括：

在若通配成功之后，则将所述消息投递到传输控制协议通道。

8.一种基于订阅机制的通信方法，其特征在于，包括：

接收用户根据预设的传输格式构建的消息，所述传输格式包括消息身份信息和消息内容，通过代理端的消息队列将所述消息发送至服务端；

在所述消息为请求消息时，将所述消息与消息订阅列表的消息进行消息身份信息的通配，并将通配得到的消息传输给所述代理端；

通过所述消息身份信息将消息中的消息内容分发至对应用户；

其中，所述代理端还用于消息订阅、消息发布、消息同步调用和消息消费；所述消息订阅，基于所述消息身份信息实现对应用户的消息订阅；所述消息发布，用户投递消息至所述代理端；所述消息同步调用，用户实现同步过程调用；所述消息消费，用户进行消息处理；

其中，所述消息消费，用户进行消息处理，包括：判断新消息是否为同步调用消息；若是，则判断应答消息是否构建成功；将所述应答消息投递到所述代理端的消息队列中。