CN117971516A - 消息队列的访问方法、系统、设备及存储介质 - Google Patents

Abstract

本申请公开了消息队列的访问方法、系统、设备及存储介质，该方法包括：基于所述消息队列微服务的连接器接收应用服务的连接器发送的通用消息，其中，基于所述通用消息采用的消息结构整合不同消息队列协议的内容；解析所述通用消息，得到所述应用服务待访问的目标消息队列；连接并访问所述目标消息队列。将不同的消息队列封装为统一的消息队列微服务，并制定统一的消息格式，使得当访问的消息队列对象变化时，无须修改代码，降低开本成本，提高消息队列的访问效率。

Description

消息队列的访问方法、系统、设备及存储介质

技术领域

本申请涉及云计算与大数据技术领域，尤其涉及一种消息队列的访问方法、系统、设备及存储介质。

背景技术

算网业务支撑系统自身也是完全分布式的应用系统，数据和应用分散在多个节点，话单文件、计费规则数据都会存在频繁的分发，为了保证数据传输的可靠性，相关数据必须通过消息队列传送。消息队列用于在消息的生产者和消费者之间，构建一个可靠的中间缓存机制，以发布-订阅方式，实现消息的可靠传递。

主流的消息队列基本功能相似，但又存在不同的侧重，以适应不同的业务场景。例如：kafka吞吐量极为优异，对巨大的消息也能良好的处理，但对于多主题支持非常有限；RocketMQ对多主题支持较好，但对巨大的消息处理存在一些缺陷；RabbitMQ提供最高的数据一致性、稳定性和可靠性，但性能和吞吐量相对较低；ZeroMQ提供最低的时延，支持灵活拓扑，但是不支持消息持久化和崩溃恢复。应用系统开发实现的时候，需要根据不同的业务场景，选择合适的MQ来承载。

因为不同消息队列的协议差异，应用代码访问不同消息队列时，具体代码实现差异极大。例如，ActiveMQ遵循JMS规范，RabbitMQ遵循AMQP规范，而ZeroMQ更像Socket应用，应用系统开发代码是和消息队列的选型强绑定的，当访问的消息队列变换时，存在大量代码的修改甚至重构，导致开发成本增加。

发明内容

本申请实施例通过提供一种消息队列的访问方法、系统、设备及存储介质，旨在将不同的消息队列封装为统一的消息队列微服务，并制定统一的消息格式，使得当访问的消息队列对象变化时，无须修改代码，降低开本成本，提高消息队列的访问效率。

本申请实施例提供了一种消息队列的访问方法，应用于消息队列微服务，所述消息队列微服务设置有与应用服务相同的连接器，所述消息队列的访问方法包括：

基于所述消息队列微服务的连接器接收应用服务的连接器发送的通用消息，其中，基于所述通用消息采用的消息结构整合不同消息队列协议的内容；

解析所述通用消息，得到所述应用服务待访问的目标消息队列；

连接并访问所述目标消息队列。

可选地，所述基于所述消息队列微服务的连接器接收应用服务的连接器发送的通用消息的步骤之前，还包括：

所述消息队列微服务启动时，获取所述消息队列微服务对应的微服务架构类型；

确定所述微服务架构类型对应的服务注册中心，其中，不同类型的微服务架构对应的服务注册中心不同；

获取所述消息队列微服务对应的微服务信息；

向所述服务注册中心注册所述消息队列微服务对应的微服务信息，以使所述应用服务能基于注册的所述微服务信息访问对应的消息队列微服务。

可选地，所述微服务信息至少包括微服务名称、微服务地址和微服务端口，所述向所述服务注册中心注册所述消息队列微服务对应的微服务信息的步骤包括：

向所述服务注册中心注册所述消息队列微服务对应的微服务名称、微服务地址和微服务端口，以使所述应用服务能基于所述微服务名称、所述微服务地址和所述微服务端口访问对应的消息队列微服务。

可选地，所述向所述服务注册中心注册所述消息队列微服务对应的微服务信息的步骤之后，还包括：

配置消息队列，以使所述消息队列微服务与所述消息队列连接。

可选地，所述解析所述通用消息，得到所述应用服务待访问的目标消息队列的步骤包括：

解析所述通用消息，得到消息头信息，所述消息头信息包括：消息属性信息、应用服务标识和消息队列标识中的至少一个；

基于所述消息属性信息、所述应用服务标识和所述消息队列标识中的至少一个，确定目标消息队列。

本申请实施例提供了一种消息队列的访问方法，应用于应用服务，所述应用服务设置有连接器，所述消息队列的访问方法包括：

获取消息头信息和消息体信息，所述消息头信息包括应用服务标识、消息队列标识和消息属性信息中的至少一个，所述消息体信息包括消息内容信息；

对所述消息头信息和消息体信息进行封装，得到通用消息；

基于所述应用服务的连接器向消息队列微服务发送所述通用消息，以基于所述通用消息访问对应的消息队列。

可选地，所述消息属性信息包括：消息版本、消息体数据类型、消息优先级、重发标记、压缩标记和消息序号中的至少一个，所述消息内容信息包括主题字节数、消息内容字节数、消息主题和消息内容中的至少一个。

此外，为实现上述目的，本申请还提供了一种消息队列的访问系统，包括：信息获取模块，封装模块和发送模块，其中，

信息获取模块，用于获取消息头信息和消息体信息，所述消息头信息包括应用服务标识、消息队列标识和消息属性信息中的至少一个，所述消息体信息包括消息内容信息；

封装模块，用于对所述消息头信息和消息体信息进行封装，得到通用消息；

发送模块，用于基于应用服务的连接器向消息队列微服务发送所述通用消息，以基于所述通用消息访问对应的消息队列；

或者，所述消息队列的访问系统包括：接收模块，解析模块和访问模块，其中，

接收模块，用于基于所述消息队列微服务的连接器接收应用服务的连接器发送的通用消息，其中，基于所述通用消息采用的消息结构整合不同消息队列协议的内容；

解析模块，用于解析所述通用消息，得到所述应用服务待访问的目标消息队列；

访问模块，用于连接并访问所述目标消息队列。

此外，为实现上述目的，本申请还提供了一种消息队列的访问设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的消息队列的访问程序，所述消息队列的访问程序被所述处理器执行时实现上述的消息队列的访问方法的步骤。

此外，为实现上述目的，本申请还提供了一种计算机可读存储介质，其上存储有消息队列的访问程序，所述消息队列的访问程序被处理器执行时实现上述的消息队列的访问方法的步骤。

本申请实施例中提供的一种消息队列的访问方法、系统、设备及存储介质的技术方案，本申请根据算网的不确定性和消息队列的不同特点，将不同的消息队列封装为统一的消息队列微服务，并制定统一的消息格式，应用系统无需考虑不同消息队列之间的差异，更换消息队列的时候修改本系统的配置即可，降低开本成本，提高消息队列的访问效率。

附图说明

图1为本申请消息队列的访问方法第一实施例的流程示意图；

图2为本申请消息队列的访问方法第四实施例的流程示意图；

图3为本申请ServiceMesh微服务架构示意图；

图4为本申请消息队列的访问系统的一功能模块图；

图5为本申请消息队列的访问系统的另一功能模块图；

图6为本申请实施例方案涉及的硬件运行环境的结构示意图。

本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明，上述附图只是一个实施例图，而不是发明的全部。

具体实施方式

为了更好地理解上述技术方案，下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整地传达给本领域的技术人员。

本申请针对微服务架构应用适配多种消息队列的要求，将消息队列进行再次封装，创新出微服务封装的通用消息队列。无论何种形式的消息队列，都以统一的连接器提供访问。应用系统完全无需了解具体消息队列，仅需要一套规范化、标准化微服务访问代码，访问相同的消息队列微服务，仅需要在集中的消息队列微服务中适配不同的消息队列，可实现免代码修改支持多种消息队列选型。

本申请的消息队列微服务提供SpringCloud和ServiceMesh两种框架支持，启动后可以注册到Eureka、Nacos、etcd、DNS等多种服务注册和发现方式。

在一应用场景下，当采用SpringCloud微服务架构时，采用统一的连接器Feign提供访问。

Spring Cloud是一个用于构建分布式系统的开源微服务框架，它基于SpringBoot构建，并提供了一系列组件和工具，帮助开发人员快速构建和部署分布式系统。SpringCloud提供了诸多功能，包括服务发现、配置管理、负载均衡、熔断器、消息总线等，下面简单介绍一些核心组件和功能：

（1）服务注册与发现（Eureka、Consul）：Spring Cloud提供了服务注册与发现的解决方案，其中Eureka是最为常用的组件之一。它允许微服务在启动时向注册中心注册自己的信息，并且能够从注册中心获取其他服务的信息。

（2）服务调用（Feign、Ribbon）：Spring Cloud提供了基于Netflix的Feign和Ribbon组件，用于简化微服务之间的通信和调用。Feign提供了声明式的API方式来定义和调用远程服务的API，而Ribbon则用于客户端负载均衡。

（3）配置管理：配置管理允许开发人员将应用程序的配置集中管理，并支持灵活的配置刷新，这样可以避免重新部署应用即可更新配置。

（4）断路器：断路器是一种用于处理延迟和容错的开源库，它为分布式系统提供了容错能力，可以防止一个微服务的故障导致整个系统的崩溃。

（5）网关：网关是一个基于JVM的路由和过滤器引擎，它提供了动态路由、认证、负载均衡、监控、日志等功能，用于构建微服务的前端门面。

（6）消息总线：消息总线结合消息代理，用于在微服务架构中实现事件驱动的消息总线，以便实现配置的动态刷新等功能。

Feign是一种基于注解的微服务客户端。Feign在微服务架构中扮演着重要的角色，它可以与微服务框架（如Spring Cloud等）集成，用于简化微服务之间的通信和调用。下面是Feign在微服务中的应用和作用：

（1）服务间通信：在微服务架构中，各个服务之间需要频繁地进行通信和调用。Feign可以帮助开发人员定义和调用其他服务的API，而无需手动构造HTTP请求和处理响应，从而简化了服务间通信的过程。

（2）声明式调用：通过Feign，开发人员可以使用接口和注解来声明式地定义远程服务的API调用，这样在代码中就可以像调用本地方法一样来调用远程服务，使得代码更加清晰和易于理解。

（3）负载均衡：Feign可以与服务发现机制（如Eureka、Consul等）集成，实现对服务实例的负载均衡和故障转移，从而提高了系统的可用性和稳定性。

（4）故障处理：在微服务架构中，可能会出现远程服务不可用或响应时间过长的情况，Feign提供了对这些故障情况的处理机制，例如超时设置、重试机制等，可以提高系统的健壮性。

在一应用场景下，当采用ServiceMesh微服务架构时，采用统一的连接器SideCar提供访问。

Service Mesh 是一种用于管理微服务架构中服务间通信的、独立于应用程序代码的基础设施层。它提供了一组功能，包括流量管理、安全性、监控、可观察性等，以解决微服务架构中复杂的网络交互和通信挑战。在 Service Mesh 中，数据平面（Data Plane）负责实际的网络传输和通信，而控制平面（Control Plane）负责对数据平面进行管理和控制。

SideCar是一种基于独立容器的微服务客户端。Sidecar是一种微服务架构中常见的模式，它指的是在每个微服务实例旁边运行一个辅助性的代理应用。Sidecar通常用于提供一些跨越多个微服务实例的功能，比如日志收集、安全认证、监控等。Sidecar应用与主应用（微服务）共享同一台物理机或虚拟机，通过本地通信或共享存储等方式来实现功能的补充和增强。

例如，本申请的ServiceMesh微服务架构如图3所示。本申请的ServiceMesh微服务架构包括多个应用服务，每个应用服务设置有对应的SideCar连接器。同时，ServiceMesh微服务架构包括多个MQ微服务（即消息队列微服务），每个消息队列微服务设置有对应的SideCar连接器。每个消息队列微服务实例可与多个消息队列连接。MQ微服务（即消息队列微服务）内置各种消息队列的支持，采用统一的方式封装消息生产和消息消费的接口。且消息队列微服务和应用服务均设置有SideCar连接器，通过该SideCar连接器能够直接访问消息队列微服务，完全无需了解和关心实际使用什么类型的消息队列，且使得每个应用服务可以访问任意类型的消息队列。

如图1所示，在本申请的第一实施例中，本申请的消息队列的访问方法应用于消息队列微服务，消息队列微服务设置有与应用服务相同的连接器。不同微服务架构下对应的连接器不同，例如，当采用SpringCloud微服务架构时，采用统一的连接器Feign提供访问；当采用ServiceMesh微服务架构时，采用统一的SideCar连接器提供访问，可根据当前的微服务架构适配对应的连接器。本申请以SideCar连接器为例。具体地，本申请的消息队列的访问方法包括以下步骤：

步骤S110，基于所述消息队列微服务的连接器接收应用服务的连接器发送的通用消息，其中，基于所述通用消息采用的消息结构整合不同消息队列协议的内容。

在本实施例中，应用微服务通过SideCar连接器连接消息队列微服务的SideCar连接器，同步需要插入消息队列的消息。为了使得应用服务能够通过统一的接口访问消息队列微服务，本申请定义了一套通用消息，该通用消息由消息头和消息体两部分组成。基于该通用消息采用的消息结构整合不同消息队列协议的内容，可以解析和映射到不同的消息队列协议，从而使得应用微服务能够访问不同的消息队列，实现应用服务免代码修改支持多种消息队列选型。

在本实施例中，该通过消息采用的消息结构能够整合的消息队列协议包括：JMS、AMQP、MQTT、kafka，使得应用服务能够访问不同的消息队列。以下将对各个消息队列协议进行介绍：

JMS（Java Message Service）是Java平台中用于创建、发送、接收和处理消息的API规范，它是一种异步通讯的方式。JMS提供了一种标准的方式，使得应用程序可以通过消息来进行通信，而不需要直接依赖特定的通讯协议或消息中间件。JMS 定义了两种消息模型包括点对点模型和发布/订阅模型。其中，对于点对点模型，消息生产者发送消息到队列，消息消费者从队列中接收并处理消息，每条消息只能被一个消费者接收。对于发布/订阅模型：消息生产者发送消息到主题，多个消息消费者可以订阅这个主题，并且每个消费者都可以接收到消息副本。常见的JMS实现包括 Apache ActiveMQ、RabbitMQ、IBM MQ等。

AMQP（Advanced Message Queuing Protocol）是一种面向消息中间件的开放标准通信协议，旨在提供高效、可靠的异步消息传递机制。AMQP支持多种消息传递模式，包括点对点、发布/订阅、请求/应答等，同时还支持消息的路由、过滤和转换等功能，能够满足各种复杂的消息传递需求。常见的AMQP实现包括RabbitMQ、Apache Qpid等，提供了完整的AMQP协议栈的实现，在微服务架构、事件驱动架构和大规模数据处理等领域具有重要作用。

MQTT（Message Queuing Telemetry Transport）是一种轻量级的消息传输协议。MQTT使用发布/订阅模型，消息发布者（发布者）将消息发布到特定的主题，而消息订阅者（应用服务）可以订阅感兴趣的主题并接收相应的消息。

kafka使用发布/订阅模型，消息发布者（生产者）将消息发布到称为主题的类别中，而消息订阅者（应用服务）则可以订阅感兴趣的主题并接收相应的消息。

在本实施例中，该通用消息包括消息头信息和消息体信息。其中，消息头信息包括应用服务标识、消息队列标识和消息属性信息中的至少一个，消息体信息包括消息内容信息。消息属性信息包括：消息版本、消息体数据类型、消息优先级、重发标记、压缩标记和消息序号中的至少一个，消息内容信息包括主题字节数、消息内容字节数、消息主题和消息内容中的至少一个。消息采用该消息结构进行封装之后，能够被不同的消息队列微服务识别和解析，能够访问不同的消息队列。

步骤S120，解析所述通用消息，得到所述应用服务待访问的目标消息队列。

在本实施例中，消息队列微服务在接收到应用服务发送的通用消息之后，对该通用消息进行解析，解析得到消息队列标识，进而基于该消息队列标识确定该应用服务待访问的目标消息队列。

在本实施例中，消息队列微服务能通过连接器与不同的应用服务连接，接收不同应用服务对消息队列的访问请求。消息队列微服务在接收到通用消息之后，只能确定有应用服务发送消息队列的访问请求，但是无法具体确定是哪一个应用服务发送的访问请求。因此，该通用消息还封装有应用服务标识，通过解析得到的应用服务标识能够使得消息队列微服务能够确定是哪一个应用服务发送的访问请求，也便于根据消息确定主题和消费者，将消息反馈至应用服务，使得应用服务能够同步接收消息，完成消息的处理。

步骤S130，连接并访问所述目标消息队列。

本实施例根据上述技术方案，根据算网的不确定性和消息队列的不同特点，将不同的消息队列封装为统一的消息队列微服务，并制定统一的消息格式，应用系统无需考虑不同消息队列之间的差异，更换消息队列的时候修改本系统的配置即可，降低开本成本，提高消息队列的访问效率。

可选地，步骤S120包括：

步骤S121，解析所述通用消息，得到消息头信息，所述消息头信息包括：消息属性信息、应用服务标识和消息队列标识中的至少一个。

步骤S122，基于所述消息属性信息、所述应用服务标识和所述消息队列标识中的至少一个，确定目标消息队列。

在本实施例中，应用服务标识用于指示是哪个应用服务发送的通用消息。其长度设置为8Bytes。消息队列标识用于指示该通用消息发送至哪个消息队列，其长度设置为8Bytes。消息属性信息包括：消息版本、消息体数据类型、消息优先级、重发标记、压缩标记和消息序号中的至少一个。

消息版本的长度为1Byte，采用数字1-255表示。

消息体数据类型的长度为1Byte，用“0”表示二进制类型，用“1”表示文本类型，接口支持所有HTTP协议的消息体数据类型，内部转换为二进制类型和文本类型两类。

消息优先级的长度为4bit，采用0-9表示。

重发标记用于指示消息是否为重复消息，其长度为1bit，用“0”表示非重发消息，用“1”表示重发消息。

压缩标记用于指示不同的数据压缩方式，其长度为3bit，用“0”表示非压缩，用“1”表示gzip压缩方式，用“2”表示Snappy压缩方式，用“3”表示LZ4压缩方式，用“4”表示zstd压缩方式。

消息序号的长度为16Bytes，其表示消息全局唯一标识，为兼容全局唯一标识符/通用唯一标识符保留16字节（128bits）长度。

在本实施例中，消息队列微服务根据消息头的应用服务标识、消息队列标识、消息数据类型、优先级、数据压缩方式中的至少一个，查询微服务配置选择预定的消息队列，将标准消息头根据预定消息队列的规则完成转义，将通用消息发送至目标消息队列。

本实施例根据上述技术方案，本申请制定统一的消息格式，该消息结构能够支持不同消息队列协议的内容，实现映射到不同的消息队列，实现对不同类型的消息队列的访问，无需修改适配代码，提高消息队列的访问效率。

进一步地，基于第一实施例，在本申请的第二实施例中，步骤S110之前，还包括以下步骤：

步骤S210，所述消息队列微服务启动时，获取所述消息队列微服务对应的微服务架构类型。

步骤S220，确定所述微服务架构类型对应的服务注册中心，其中，不同类型的微服务架构对应的服务注册中心不同。

步骤S230，获取所述消息队列微服务对应的微服务信息。

步骤S240，向所述服务注册中心注册所述消息队列微服务对应的微服务信息，以使所述应用服务能基于注册的所述微服务信息访问对应的消息队列微服务。

在本实施例中，消息队列微服务在启动时，需要进行服务注册。不同微服务架构存在对应的服务注册中心，根据不同的微服务架构，将微服务信息注册至对应的服务注册中心。

服务注册是微服务架构中的一个关键概念，它用于实现服务发现和动态路由，使得微服务能够相互发现和通信。在微服务架构中，每个微服务在启动时会向服务注册中心注册自己提供的服务，包括微服务名称、微服务地址、微服务端口等信息。服务注册中心会维护所有注册的服务信息，并对外提供查询接口，以便其他微服务或客户端可以动态地发现和调用这些服务。通过服务注册能够实现以下作用：

（1）服务发现：通过服务注册中心，微服务可以获取到其他微服务的位置和通讯地址，从而能够进行跨服务的调用和协同工作。

（2）动态路由：服务注册中心可以根据服务的健康状态、负载情况等动态调整路由策略，确保请求能够被正确地路由到可用的服务实例上。

（3）故障处理：当某个服务出现故障或需要下线时，服务注册中心可以及时更新服务列表，使得其他服务能够在不中断服务的情况下进行调整和适应。

在本实施例中，本申请根据不同的微服务架构，注册到Eureka、Nacos、etcd或DNS中。

Eureka 是 Netflix 开源的基于REST的服务治理框架，用于构建分布式系统中的微服务架构。它主要包括Eureka 服务器和Eureka客户端两部分，用于实现服务注册、发现和故障转移。Eureka 服务器允许服务将自己注册到注册中心，并能够查询可用的服务实例。客户端通过查询 Eureka 服务器来发现和调用服务，从而实现了服务之间的解耦。

Nacos（Dynamic Naming and Configuration Service）是开源的一款服务发现、配置管理和服务管理平台。它提供了注册中心、配置中心和服务管理等功能，适用于云原生架构和微服务体系下的服务注册、发现与配置管理。Nacos 提供了服务注册和发现功能，服务提供者可以通过Nacos注册自己的服务实例，并且服务消费者可以通过Nacos 查询可用的服务实例，实现了服务之间的解耦。

etcd可以用作服务发现的工具，服务实例可以将自己的位置信息注册到etcd中，客户端可以通过etcd查询可用的服务实例。

DNS（Domain Name System，域名系统）是互联网中用于将域名转换为对应 IP 地址的分布式数据库系统。DNS允许用户通过易记的域名来访问Internet上的资源，例如网站、邮件服务器等。当用户输入一个域名时，DNS系统会将这个域名解析成对应的 IP 地址，从而使得计算机能够连接到相应的服务。

本实施例根据上述技术方案，能够确定微服务架构类型对应的服务注册中心，将消息队列微服务对应的微服务信息注册至对应的服务注册中心，使得应用服务能基于注册的微服务信息访问对应的消息队列微服务，且以便其他微服务或客户端可以动态地发现和调用这些服务。

可选地，步骤S240包括以下步骤：

步骤S241，向所述服务注册中心注册所述消息队列微服务对应的微服务名称、微服务地址和微服务端口，以使所述应用服务能基于所述微服务名称、所述微服务地址和所述微服务端口访问对应的消息队列微服务。

在本实施例中，微服务信息至少包括微服务名称、微服务地址和微服务端口，向服务注册中心注册微服务名称、微服务地址和微服务端口，能够使得应用服务能基于微服务名称、微服务地址和微服务端口顺利地访问对应的消息队列微服务。

进一步地，基于第二实施例，在本申请的第三实施例中，步骤S240之后，还包括以下步骤：

步骤S310，配置消息队列，以使所述消息队列微服务与所述消息队列连接。

在本实施例中，各消息队列微服务可根据配置，分别通过各消息队列协议，实现与相应的消息队列连接。可预先配置所有消息队列协议，使得消息队列微服务能够访问不同的消息队列。还可根据应用服务的需求配置相应的消息队列，使得应用服务可访问对应的消息队列。当应用服务所要访问的消息队列变化时，可通过更改配置实现快速的消息队列的切换，无需修改代码，提高应用服务对消息队列的访问效率。

在本实施例中，消息队列微服务配置消息队列包括以下步骤：

（1）初始化连接容器，包括容器种类（匹配不同的消息队列类型）、消息队列地址以及消息队列端口。

（2）创建消息队列连接工厂。在分布式系统中，消息队列是一种常见的中间件，用于解耦合异步处理各个系统之间的通信。为了能够使用消息队列，我们需要建立一个连接工厂，这个连接工厂能够创建和维护消息队列的连接。

首先，需要确定使用哪种消息队列服务。常见的消息队列服务包括RabbitMQ、Kafka、ActiveMQ等。选择哪种服务取决于具体的应用场景和需求，例如消息的吞吐量、延迟、可靠性等。

接下来，需要配置消息队列服务的地址和端口。这通常可以在配置文件中设置，也可以通过环境变量等方式进行配置。

然后，需要创建连接工厂的实现。这个实现需要依赖于具体的消息队列服务，并且需要提供创建连接的方法。通常，连接工厂的实现需要包括建立连接、维护连接、关闭连接等功能。

最后，需要在应用程序中使用连接工厂。应用程序可以通过连接工厂创建消息队列的连接，然后使用这个连接发送和接收消息。这样，就可以通过连接工厂来统一管理消息队列的连接，并且避免在每个应用程序中都重复实现连接的建立和维护。

创建消息队列连接工厂是分布式系统中一项重要的任务。通过连接工厂，方便地使用和管理消息队列服务，并且提高应用程序的可靠性和可维护性。

（3）创建主题消息连接及会话。

（4）创建消息发送者及消费者。在分布式系统中，消息发送者和消费者是核心组件之一。它们通过消息传递来交换信息，实现系统间的异步通信和数据共享。在创建消息发送者和消费者时，需要选择一个适合系统的消息中间件，例如ActiveMQ、RabbitMQ、Kafka等。这些消息中间件提供了消息的发送、接收、持久化、分发等功能，可以满足不同场景下的需求。在创建消息发送者时，需要先创建一个连接到消息中间件的客户端，然后通过该客户端发送消息。以ActiveMQ为例，可以使用Apache ActiveMQ的客户端API来创建消息发送者。在创建消息消费者时，也需要先创建一个连接到消息中间件的客户端，然后通过该客户端接收消息。以ActiveMQ为例，可以使用Apache ActiveMQ的客户端API来创建消息消费者。

本实施例根据上述技术方案，通过消息队列微服务配置消息队列，使得应用服务能够通过消息队列微服务访问对应的消息队列。

如图2所示，在本申请的第四实施例中，本申请的消息队列的访问方法应用于应用服务，包括以下步骤：

步骤S410，获取消息头信息和消息体信息，所述消息头信息包括应用服务标识、消息队列标识和消息属性信息中的至少一个，所述消息体信息包括消息内容信息。

步骤S420，对所述消息头信息和消息体信息进行封装，得到通用消息。

步骤S430，基于所述应用服务的连接器向消息队列微服务发送所述通用消息，以基于所述通用消息访问对应的消息队列。

在本实施例中，应用微服务通过SideCar连接器连接消息队列微服务的SideCar连接器，同步需要插入消息队列的消息。为了使得应用服务能够通过统一的接口访问消息队列微服务，本申请定义了一套通用消息，该通用消息由消息头和消息体两部分组成。该通用消息采用的消息结构能够整合不同消息队列协议的内容，可以解析和映射到不同的消息队列协议，从而使得应用微服务能够访问不同的消息队列，实现应用服务免代码修改支持多种消息队列选型。

在本实施例中，该通用消息包括消息头信息和消息体信息中的至少一个。其中，消息头信息包括应用服务标识、消息队列标识和消息属性信息中的至少一个，消息体信息包括消息内容信息。消息属性信息包括：消息版本、消息体数据类型、消息优先级、重发标记、压缩标记和消息序号中的至少一个，消息内容信息包括主题字节数、消息内容字节数、消息主题和消息内容中的至少一个。消息采用该消息结构进行封装之后，能够被不同的消息队列微服务识别和解析，能够访问不同的消息队列。

在本实施例中，应用服务标识用于指示是哪个应用服务发送的通用消息。其长度设置为8Bytes。消息队列标识用于指示该通用消息发送至哪个消息队列，其长度设置为8Bytes。消息属性信息包括：消息版本、消息体数据类型、消息优先级、重发标记、压缩标记和消息序号中的至少一个。

消息版本的长度为1Byte，采用数字1-255表示。

消息体数据类型的长度为1Byte，用“0”表示二进制类型，用“1”表示文本类型，接口支持所有HTTP协议的消息体数据类型，内部转换为二进制类型和文本类型两类。

消息优先级的长度为4bit，采用0-9表示。

重发标记用于指示消息是否为重复消息，其长度为1bit，用“0”表示非重发消息，用“1”表示重发消息。

压缩标记用于指示不同的数据压缩方式，其长度为3bit，用“0”表示非压缩，用“1”表示gzip压缩方式，用“2”表示Snappy压缩方式，用“3”表示LZ4压缩方式，用“4”表示zstd压缩方式。

消息序号的长度为16Bytes，其表示消息全局唯一标识，为兼容全局唯一标识符/通用唯一标识符保留16字节（128bits）长度。

本实施例根据上述技术方案，本申请制定统一的消息格式，该消息结构能够支持不同消息队列协议的内容，实现映射到不同的消息队列，实现对不同类型的消息队列的访问，无需修改适配代码，提高消息队列的访问效率。

本申请实施例提供了消息队列的访问方法的实施例，需要说明的是，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本申请提供了一种消息队列的访问系统，如图4所示，所述消息队列的访问系统包括：信息获取模块10，封装模块20和发送模块30。

信息获取模块10，用于获取消息头信息和消息体信息，所述消息头信息包括应用服务标识、消息队列标识和消息属性信息中的至少一个，所述消息体信息包括消息内容信息；

封装模块20，用于对所述消息头信息和消息体信息进行封装，得到通用消息；

发送模块30，用于基于应用服务的连接器向消息队列微服务发送所述通用消息，以基于所述通用消息访问对应的消息队列；

如图5所示，本申请消息队列的访问系统还包括：接收模块40，解析模块50和访问模块60。

接收模块40，用于基于所述消息队列微服务的连接器接收应用服务的连接器发送的通用消息，其中，基于所述通用消息采用的消息结构整合不同消息队列协议的内容；

解析模块50，用于解析所述通用消息，得到所述应用服务待访问的目标消息队列；

访问模块60，用于连接并访问所述目标消息队列。

本申请消息队列的访问系统具体实施方式与上述消息队列的访问方法各实施例基本相同，在此不再赘述。

如图6所示，图6为本申请实施例方案涉及的消息队列的访问设备的硬件运行环境的结构示意图。该消息队列的访问设备可以包括：处理器1001，例如CPU，存储器1005，用户接口1003，网络接口1004，通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏、输入单元比如键盘，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口（如WI-FI接口）。存储器1005可以是高速RAM存储器，也可以是稳定的存储器，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图6中示出的消息队列的访问设备结构并不构成对消息队列的访问设备限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图6所示，作为一种存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及消息队列的访问程序。其中，操作系统是管理和控制消息队列的访问设备硬件和软件资源的程序，消息队列的访问程序以及其它软件或程序的运行。

在图6所示的消息队列的访问设备中，用户接口1003主要用于连接终端，与终端进行数据通信；网络接口1004主要用于后台服务器，与后台服务器进行数据通信；处理器1001可以用于调用存储器1005中存储的消息队列的访问程序。

在本实施例中，消息队列的访问设备包括：存储器1005、处理器1001及存储在所述存储器上并可在所述处理器上运行的消息队列的访问程序，其中：

处理器1001调用存储器1005中存储的消息队列的访问程序时，执行以下操作：

基于所述消息队列微服务的连接器接收应用服务的连接器发送的通用消息，其中，基于所述通用消息采用的消息结构整合不同消息队列协议的内容；

解析所述通用消息，得到所述应用服务待访问的目标消息队列；

连接并访问所述目标消息队列。

处理器1001调用存储器1005中存储的消息队列的访问程序时，还执行以下操作：

获取消息头信息和消息体信息，所述消息头信息包括应用服务标识、消息队列标识和消息属性信息中的至少一个，所述消息体信息包括消息内容信息；

对所述消息头信息和消息体信息进行封装，得到通用消息；

基于所述应用服务的连接器向消息队列微服务发送所述通用消息，以基于所述通用消息访问对应的消息队列。

基于同一发明构思，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有消息队列的访问程序，所述消息队列的访问程序被处理器执行时实现如上所述的消息队列的访问方法的各个步骤，且能达到相同的技术效果，为避免重复，这里不再赘述。

由于本申请实施例提供的存储介质，为实施本申请实施例的方法所采用的存储介质，故而基于本申请实施例所介绍的方法，本领域所属人员能够了解该存储介质的具体结构及变形，故而在此不再赘述。凡是本申请实施例的方法所采用的存储介质都属于本申请所欲保护的范围。

需要说明的是，在本文中，术语“ 包括”、“ 包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“ 包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

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

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

Claims (10)

1.一种消息队列的访问方法，其特征在于，应用于消息队列微服务，所述消息队列微服务设置有与应用服务相同的连接器，所述消息队列的访问方法包括：

基于所述消息队列微服务的连接器接收应用服务的连接器发送的通用消息，其中，基于所述通用消息采用的消息结构整合不同消息队列协议的内容；

解析所述通用消息，得到所述应用服务待访问的目标消息队列；

连接并访问所述目标消息队列。

2.如权利要求1所述的消息队列的访问方法，其特征在于，所述基于所述消息队列微服务的连接器接收应用服务的连接器发送的通用消息的步骤之前，还包括：

所述消息队列微服务启动时，获取所述消息队列微服务对应的微服务架构类型；

确定所述微服务架构类型对应的服务注册中心，其中，不同类型的微服务架构对应的服务注册中心不同；

获取所述消息队列微服务对应的微服务信息；

向所述服务注册中心注册所述消息队列微服务对应的微服务信息，以使所述应用服务能基于注册的所述微服务信息访问对应的消息队列微服务。

3.如权利要求2所述的消息队列的访问方法，其特征在于，所述微服务信息至少包括微服务名称、微服务地址和微服务端口，所述向所述服务注册中心注册所述消息队列微服务对应的微服务信息的步骤包括：

向所述服务注册中心注册所述消息队列微服务对应的微服务名称、微服务地址和微服务端口，以使所述应用服务能基于所述微服务名称、所述微服务地址和所述微服务端口访问对应的消息队列微服务。

4.如权利要求2所述的消息队列的访问方法，其特征在于，所述向所述服务注册中心注册所述消息队列微服务对应的微服务信息的步骤之后，还包括：

配置消息队列，以使所述消息队列微服务与所述消息队列连接。

5.如权利要求1所述的消息队列的访问方法，其特征在于，所述解析所述通用消息，得到所述应用服务待访问的目标消息队列的步骤包括：

解析所述通用消息，得到消息头信息，所述消息头信息包括：消息属性信息、应用服务标识和消息队列标识中的至少一个；

基于所述消息属性信息、所述应用服务标识和所述消息队列标识中的至少一个，确定目标消息队列。

6.一种消息队列的访问方法，其特征在于，应用于应用服务，所述应用服务设置有连接器，所述消息队列的访问方法包括：

获取消息头信息和消息体信息，所述消息头信息包括应用服务标识、消息队列标识和消息属性信息中的至少一个，所述消息体信息包括消息内容信息；

对所述消息头信息和消息体信息进行封装，得到通用消息；

基于所述应用服务的连接器向消息队列微服务发送所述通用消息，以基于所述通用消息访问对应的消息队列。

7.如权利要求6所述的消息队列的访问方法，其特征在于，所述消息属性信息包括：消息版本、消息体数据类型、消息优先级、重发标记、压缩标记和消息序号中的至少一个，所述消息内容信息包括主题字节数、消息内容字节数、消息主题和消息内容中的至少一个。

8.一种消息队列的访问系统，其特征在于，所述消息队列的访问系统包括：信息获取模块，封装模块和发送模块，其中，

信息获取模块，用于获取消息头信息和消息体信息，所述消息头信息包括应用服务标识、消息队列标识和消息属性信息中的至少一个，所述消息体信息包括消息内容信息；

封装模块，用于对所述消息头信息和消息体信息进行封装，得到通用消息；

发送模块，用于基于应用服务的连接器向消息队列微服务发送所述通用消息，以基于所述通用消息访问对应的消息队列；

或者，所述消息队列的访问系统包括：接收模块，解析模块和访问模块，其中，

接收模块，用于基于所述消息队列微服务的连接器接收应用服务的连接器发送的通用消息，其中，基于所述通用消息采用的消息结构整合不同消息队列协议的内容；

解析模块，用于解析所述通用消息，得到所述应用服务待访问的目标消息队列；

访问模块，用于连接并访问所述目标消息队列。

9.一种消息队列的访问设备，其特征在于，所述消息队列的访问设备包括：存储器、处理器及存储在所述存储器上并在所述处理器上运行的消息队列的访问程序，所述消息队列的访问程序被所述处理器执行时实现如权利要求1-7中任一项所述的消息队列的访问方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有消息队列的访问程序，所述消息队列的访问程序被处理器执行时实现权利要求1-7中任一项所述的消息队列的访问方法的步骤。