CN113259430A - 一种消息调用方法和装置、电子设备及存储介质 - Google Patents

Abstract

本发明提供一种消息调用方法和装置、电子设备及存储介质，其中，所述方法包括：获取目标格式的请求数据；将所述请求数据进行格式转换，得到统一的经由通信链路传输的请求报文；将所述请求报文发送至服务器，以使服务器根据所述请求报文进行消息调用，生成响应报文并经由所述通信链路发送至所述客户端；将所述响应报文进行解析，得到所述目标格式的响应数据。本方法利用通用的通信协议灵活接入不同种类的消息集群，通过数据格式转换可同时向业务应用暴露多种类型的消息服务，业务应用系统在多版本多语言消息队列框架中灵活切换，使得业务应用系统与消息队列框架能够独立演进，大大降低了业务应用系统使用消息队列框架的复杂度和难度。

Description

一种消息调用方法和装置、电子设备及存储介质

技术领域

本发明涉及计算机技术领域，尤其涉及一种消息调用方法和装置、电子设备及存储介质。

背景技术

随着业务在不断创新发展，业务应用系统在快速迭代过程中会陆续引入多种中间件框架，比如消息队列框架。现有技术中基于消息队列产品官方提供的服务端程序包搭建集群环境，业务应用系统在代码开发框架中引入对应语言SDK(Software DevelopmentKit，软件开发工具包)或者二次封装消息队列产品多版本切换能力的通用SDK，通过调用SDK发起API(Application Programming Interface，应用程序接口)请求。

由于大量不稳定的非官方SDK被引入到业务应用中，在引入SDK的过程会同步带来对应的依赖包。对于业务应用系统来说，间接依赖了更多的程序包，程序包之间也会存在版本冲突。为了解决版本冲突，业务代码需要升级其他程序包或者使用降级版本，同时新引入的程序包可能存在安全风险。

现有技术在业务应用系统中引入消息队列框架的方法使业务应用代码与消息队列框架之间存在强耦合强依赖关系，导致多语言多版本的消息队列框架之间不能灵活切换，业务应用系统使用消息队列框架的复杂度和难度大，二者无法独立演进。

发明内容

本发明提供一种消息调用方法、装置和电子设备，用以解决现有技术中在业务应用系统中引入消息队列框架时，业务应用代码与消息队列框架之间存在强耦合强依赖关系，导致多语言多版本的消息队列框架之间不能灵活切换，业务应用系统使用消息队列框架的复杂度和难度大，二者无法独立演进的问题。

本发明提供一种消息调用方法，用于客户端，所述方法包括：

获取目标格式的请求数据；

将所述请求数据进行格式转换，得到统一的经由通信链路传输的请求报文；

将所述请求报文发送至服务器，以使服务器根据所述请求报文进行消息调用，生成响应报文并经由所述通信链路发送至所述客户端；

将所述响应报文进行解析，得到所述目标格式的响应数据。

根据本发明提供的一种消息调用方法，所述响应报文包括响应行、响应头部和响应体；

所述将所述响应报文进行解析，得到所述目标格式的响应数据，包括：

对所述响应报文进行解析得到响应体，基于所述响应体生成所述目标格式的响应数据。

本发明提供一种消息调用方法，用于服务器，所述方法包括：

接收客户端发送的请求报文；

根据所述请求报文进行消息调用，生成目标格式的响应数据；

将所述响应数据进行格式转换，得到统一的经由通信链路传输的响应报文，并返回至客户端，以使所述客户端通过解析所述响应报文得到目标格式的响应数据。

根据本发明提供的一种消息调用方法，所述服务器包括消息前置服务层、统一消息服务层和消息集群层，所述消息集群层包括至少一个消息队列中间件；

所述根据所述请求报文进行消息调用，生成目标格式的响应数据包括：

所述消息前置服务层接收所述请求报文，将所述请求报文进行解析，得到所述目标格式的请求数据，并将所述请求数据转发至所述统一消息服务层；

所述统一消息服务层根据所述请求数据确定消息队列中间件，并向所述消息队列中间件发送所述请求数据；

所述消息队列中间件根据所述请求数据进行消息队列的读或写操作，并生成目标格式的响应数据。

根据本发明提供的一种消息调用方法，所述请求报文包括请求行、请求头部和请求体；

所述将所述请求报文进行解析，得到所述目标格式的请求数据包括：

对所述请求报文进行解析得到请求体，基于所述请求体生成所述目标格式的请求数据。

根据本发明提供的一种消息调用方法，所述将所述响应数据进行格式转换，得到统一的经由通信链路传输的响应报文，包括：

所述消息队列中间件向所述统一消息服务层返回所述响应数据；

所述统一消息服务层将所述响应数据返回至所述消息前置服务层；

所述消息前置服务层将所述响应数据进行格式转换，得到统一的经由通信链路传输的响应报文。

本发明还提供一种消息调用装置，用于客户端，所述装置包括：

请求报文生成模块，用于获取目标格式的请求数据；

将所述请求数据进行格式转换，得到统一的经由通信链路传输的请求报文；

消息调用模块，用于将所述请求报文发送至服务器，以使服务器根据所述请求报文进行消息调用，生成响应报文并经由所述通信链路发送至所述客户端；

响应报文解析模块，用于将所述响应报文进行解析，得到所述目标格式的响应数据。

根据本发明提供的一种消息调用装置，所述响应报文包括响应行、响应头部和响应体；

所述响应报文解析模块还用于：

对所述响应报文进行解析得到响应体，基于所述响应体生成所述目标格式的响应数据。

本发明还提供一种消息调用装置，用于服务器，所述装置包括：

消息前置服务模块，用于接收客户端发送的请求报文，将所述请求报文进行解析，得到目标格式的请求数据，并将所述请求数据转发至统一消息服务层；

统一消息服务模块，用于根据所述请求数据确定消息队列中间件，并向所述消息队列中间件发送所述请求数据；

消息集群模块，用于根据所述请求数据进行消息队列的读或写操作，并生成目标格式的响应数据。

根据本发明提供的一种消息调用装置，所述请求报文包括请求行、请求头部和请求体；

所述消息前置服务模块还用于：

对所述请求报文进行解析得到请求体，基于所述请求体生成所述目标格式的请求数据。

根据本发明提供的一种消息调用装置，所述消息集群模块还用于：

向所述统一消息服务层返回所述响应数据。

根据本发明提供的一种消息调用装置，所述统一消息服务模块还用于：

将所述响应数据返回至所述消息前置服务层。

根据本发明提供的一种消息调用装置，所述消息前置服务模块还用于：

将所述响应数据进行格式转换，得到统一的经由通信链路传输的响应报文。

本发明还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上述任一种所述消息调用方法的步骤。

本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述任一种所述消息调用方法的步骤。

本发明提供的消息调用方法和装置，在业务代码中不再使用特定消息队列框架的专有协议，而是利用通用的通信协议灵活接入不同种类的消息集群，通过数据格式转换可同时向业务应用暴露多种类型的消息服务，业务应用系统无需关心消息服务的具体版本和消息服务升级的问题，在多版本多语言消息队列框架中灵活切换，业务应用系统与消息队列框架独立演进，大大降低了业务应用系统使用消息队列框架的复杂度和难度。

附图说明

为了更清楚地说明本发明或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为现有技术中业务应用调用Kafka消息队列的几种具体形态的示意图；

图2为业务应用系统与消息队列基础设施的交互结构示意图；

图3是本发明提供的消息调用方法(用于客户端)的流程示意图；

图4是本发明提供的消息调用方法(用于服务器)的流程示意图；

图5是本发明提供的根据所述请求报文进行消息调用，生成目标格式的响应数据的流程示意图；

图6是本发明提供的将所述响应数据进行格式转换，得到统一的经由通信链路传输的响应报文的流程示意图；

图7是本发明提供的消息调用装置(用于客户端)的结构示意图；

图8是本发明提供的消息调用装置(用于服务器)的结构示意图；

图9本发明提供的电子设备的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合本发明中的附图，对本发明中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

首先，以Apache Kafka为例说明业务应用与消息队列框架的强耦合强依赖关系以及如何解耦此种强耦合强依赖关系，涉及到其他类型消息队列中间件，处理过程相似。

Kafka是一种典型的消息队列中间件产品，同时兼顾高性能和高吞吐量，在众多消息框架表现出色，被业务应用系统广泛采用。Kafka由开源社区组织Apache领导并负责维护，官方提供JAVA版本SDK，其他开发语言的SDK比较混乱。现有技术基于Kafka消息中间件框架Apache官方提供的服务端程序包搭建集群环境，业务方在代码开发框架中引入对应语言SDK或者二次封装Kafka多版本切换能力的通用SDK，通过调用SDK发起API请求，SDK会根据创建业务代码中指定的Endpoint信息通过Kafka专有通讯协议和序列化协议向KafkaServer发起调用。在整个交互场景中，业务代码与Kafka消息队列框架代码与扩展机制紧密耦合在一起，有的业务应用为兼容适配多个形态Kafka版本开发通用客户端接口，但是这种模式开发态与运行态依旧使得业务代码与Kafka框架代码处在同一进程中，两者生命周期相同。框架组件的引入必然带来一堆关联的依赖组件，例如引入SDK的过程会同步带来对应的依赖包，例如：Kafka 0.8.2版本依赖于1.2.0版lz4,1.7.6版本slf4j-api,1.1.1.3版本snappy-java，同时这些新引入的第三方依赖包也存在自身依赖包，即传递性依赖，最终依赖结构会形成一棵递归依赖树。对于业务应用来说，间接依赖了更多的程序包，程序包间也会存在版本冲突。为了解决依赖冲突，业务代码不得不考虑升级其他程序包或者使用降级版本。除了依赖冲突问题，新引入程序包可能没有通过安全漏洞扫描，存在潜在安全风险，业务开发工程师需要花费大量时间去排除漏洞，分散了业务本身的开发精力。

图1为现有技术中业务应用调用Kafka消息队列的几种具体形态，可以看出在业务应用代码环境中每一笔调用都直接或者间接调用Kafka SDK，此种方式会导致以下几方面不利影响。

第一方面，系统运行稳定性易受Kafka框架影响，Kafka版本变更也会导致业务应用程序代码层被动变更，业务方原本稳定运行的代码可能被框架变更所带来的关联风险所影响。Kafka历经三轮通信协议变更，版本也从0.7.0Release版本演化到2.7.0版本，相对应的，业务方也会在不同时间点进行升级维护，每轮迭代升级还伴随着与业务内其他中间件框架产生的依赖冲突、业务代码冲突以及兼容性适配问题。更常见的一个场景是，业务应用系统因框架级联依赖引入大量的外部依赖，业务进程生命周期同Kafka框架生命周期，如果新引入依赖程序包存在代码漏洞，那么风险将会集中爆发，不便于安全监控人员独立介入，无法实施有效的风险隔离措施。Kafka框架和业务代码逻辑绑定在一起，制约着彼此，核心治理逻辑不可避免与业务应用物理耦合，如果Kafka引入bug，需要所有业务配合升级，对业务研发效率造成了损害，而Kafka框架新特性也受限于业务升级，不具备自主控制能力。

第二方面，业务应用代码是通过专有协议和特定语言SDK与Kafka框架交互，官方只有JAVA版本SDK，社区版多语言SDK又非常分散，质量参差不齐，不同语言间难以低成本进行本地调试和快速地建立Mock测试用例，如此一来，业务应用面临着开发态不够敏捷，运行态又存在稳定性风险。

第三方面，系统整体管控与参数配置管理能力受限，Kafka框架安全访问控制策略受限于Kafka本身的能力，对于业务安全认证模式存在干扰，如果相关的安全规则在业务代码中呈现，则受制于业务端升级更新，不同业务应用在应用中很难统一低成本执行组织安全策略或复用组织已有安全管控能力，存在重复建设，同时也不便于组织内统一管控，影响安全策略下发的及时性和执行能力。统一配置管理能力也受限于强耦合，Kafka消息配额管理，调用是否超出阈值，都无法基于不同应用不同服务级别进行QoS分区(SLA区分)，组织需要灵活设置不同环境差异，配置变更实时下发业务实时响应。

第四方面，系统运维能力受限，业务运维与Kafka中间件运维管控交叉混合到一起，职责不清晰。Kafka自身可观测性难以统一度量，故障检测与问题快速定位，实时巡检相关的运维特性不能充分施展。如果Kafka中间件升级过程中不能提供持续、不间断的服务，则会导致业务流量损失，业务不能无感接纳Kafka中间件平滑升级。整个运维治理体系分散到业务中，决策权分散，很难协同，一旦出现突发事件，无法快速响应，统一处置。

第五方面，业务代码替换Kafka框架中间件为其他消息队列框架的切换成本非常高，风险极大，对业务的变动影响非常大。

总的来说，业务应用系统无论是在开发态还是运行态都与Kafka框架紧密耦合，严重制约业务应用系统的创新能力，也制约着组织安全治理与运维管控能力的发展，降低了应用系统运行的稳定性和运营效率，由此，迫切需要一种技术手段来化解这种强耦合强依赖关系，分离Kafka消息框架，使得业务应用做到更好的解耦，减轻业务应用开发负担，享受到不可变基础设施理念带来的红利，进而实现灵活的安全治理，实时的配置下发以及高效的运维管控能力，实现独立的Kafka中间件故障能力检测。整个业务层与消息框架层的交互逻辑与职责非常清晰，易于问题诊断和系统维护，一旦出现突发状况，能够快速定位问题，基于组织统一管控策略，快速恢复系统，保障业务QoS和及时响应业务SLA承诺。

为了解耦业务应用代码与Kafka消息队列框架的强耦合强依赖关系，本发明通过在业务端抽象通用消息模型和参数配置服务、安全管控服务以及通用消息服务，解耦业务应用代码与消息队列框架，从物理上将二者隔离，将原本存在于业务代码中的消息队列依赖组件抽离出来，将消息交互能力、参数化配置以及安全管控策略配置能力抽象化统一下沉到新构建的通用消息基础设施层面，业务代码基于标准化通信协议和通用序列化协议与底层消息队列基础设施进行交互。

具体地，在逻辑解耦层面从业务应用端提取调用规则，通过实施服务能力抽象，基于SDK提取消息服务通用接口，形成可提供的消息服务接口列表，包括消息投递、消息消费、消息确认等业务域服务接口。在物理层面通过实施剥离SDK，去除依赖包，抽象Kafka服务端消息队列服务能力为标准的消息服务，下沉到消息基础服务实施层。两者交互则是通过系统内置框架自动注入sidecar辅助容器或者在消息服务端提供前置代理服务层化解调用关系，业务应用端只需要编写通用HTTP协议或者基于HTTP协议的gRPC协议交互的逻辑代码，可以帮助业务应用更聚焦于业务层面，把有限的开发精力集中在业务模型、业务流程、业务规则等功能开发上。

其中，从业务应用端提取调用规则是指在业务应用代码端，基于JAVA语言开发、Python语言开发或者其他编程语言(包括常用的编程语言Golang、nodejs、C/C++、Kotlin等)，通过提取业务应用代码中安全调用逻辑代码、配置参数逻辑代码以及消息框架调用逻辑代码，剥离安全策略配置相关代码逻辑，剥离手动埋点监测的代码逻辑，剥离业务代码依赖的Kafka组件，将Kafka SDK与相关组件从业务端彻底分离。

其中，业务应用端与消息框架的交互中间层是指业务代码通过标准化协议和通用序列化协议与底层消息队列基础设施进行交互。在通信交互协议上采用标准化通信协议HTTP协议或者基于HTTP2.0的gGRPC协议作为通信载体，序列化协议基于行业通用的序列化协议JSON或者ProtoBuf协议作为数据载体，同时支撑业务代码多语言多形态开发框架，磨平了业务代码多语言、多协议和多种通信方式之间的差异。

其中，消息基础服务设施层是指对分离后的Kafka消息队列服务端集群上采用网格化的设计思想，消息基础服务设施层不但能提供Kafka类型的消息服务，亦可以提供RocketMQ、RabbitMQ等其他消息队列中间件的消息服务。消息基础服务设施层从架构上搭建了消息前置服务层、消息服务层、消息集群层。形成通用的消息前置服务、核心消息服务、消息发布与订阅服务组件、资源绑定组件、消息服务调用组件、实际提供消息交互的消息集群。

通过逻辑层抽象和物理层隔离，业务代码在与Kafka消息队列框架交互方式演变为业务代码使用开发语言内置的HTTP标准通信能力和JSON序列化协议与消息基础实施层的Kafka消息服务交互。可选的，如果业务方具备gRPC(HTTP2.0)通信能力，亦可用gRPC通信能力交互。从整个运行过程看，业务代码进程只通过标准的通信协议和通用的序列化协议交互，无须引入过多的第三方依赖组件，交互过程很轻量。针对Kafka的代码漏洞管控策略可以在基础设施层独立进行，无须业务方联动升级。

此外，业务应用端和消息基础服务设施层均可以支持容器(原生Docker、Kubernetes)、虚机、物理机、私有云等多种部署模式，其中容器模式由消息基础服务设施层提供业务应用端部署形态的sidecar辅助容器自动注入的能力，消息基础服务设施层自身容器化能力依托Kubernetes所支持的丰富workload工作负载定义能力和基于CRD(CustomResourceDefinition)扩展资源自定制的能力。

图2为基于上述解耦方案构建的业务应用系统与消息队列基础设施的交互结构示意图。如图2所示，在通信交互协议上采用HTTP标准化通信协议或基于HTTP2.0的gRPC协议作为通信载体，序列化协议基于行业通用的JSON和ProtoBuf协议，同时支撑业务代码多语言多形态开发框架，磨平了业务代码多语言、多协议和多种通信方式之间的差异。在消息队列服务端集群上采用网格化设计思想，形成通用的消息参数配置、消息发布与订阅服务组件、资源绑定组件、消息服务调用组件，同时支持接入多种形态的消息队列框架，比如Apache RocketMQ、Apache ActiveMQ、Apache RabbitMQ。具体消息队列框架对业务方屏蔽。可以支持业务方便捷地切换到其他消息队列框架，在消息基础服务设施中接入消息绑定、管理数据、链路追踪、消息集群管理等能力，上层业务方只需要通过统一标准的HTTP、gRPCAPI使用框架层提供的消息服务，这样就能做到业务代码与中间件、流量管理能力更彻底的解耦，业务开发工程师更专注、更自由的关注业务代码的开发。

基于上述业务应用系统与消息队列基础设施的交互结构，图3为本发明提供的消息调用方法(用于客户端)的流程示意图，如图3所示，该方法包括：

步骤310，获取目标格式的请求数据。

需要说明的是，消息队列中间件有多种类型，每种类型的中间件还存在多版本和多语言的产品，业务应用系统在调用消息队列中间件时，通常会通过专有协议和特定语言SDK与特定的消息队列中间件交互，比如业务代码可能同时存在JAVA、Python、NodeJS、golang、C/C++等多种语言，并且对应语言的SDK版本也不同，例如Kafka JAVA SDK-0.8、Kafka JAVA SDK-1.0、Kafka Python SDK-3.0、Kafka Python SDK-1.1等。本发明不考虑消息队列中间件的版本和语言，基于业务应用系统的版本和语言生成请求数据，其中，业务应用系统的数据格式为目标格式。

步骤320，将所述请求数据进行格式转换，得到统一的经由通信链路传输的请求报文。

具体地，在通信交互协议上采用HTTP标准化通信协议或基于HTTP2.0的gRPC协议作为通信载体，将多种格式的请求数据包装为统一的HTTP请求报文。HTTP请求报文由请求行、请求头部和请求体三个部分组成，其中，请求行由请求方法字段、URL字段和HTTP协议版本三个字段组成；请求头部由关键字/值对组成，用于通知服务器有关客户端请求的信息；请求体包含数据的主体部分。

步骤330，将所述请求报文发送至服务器，以使服务器根据所述请求报文进行消息调用，生成响应报文并经由所述通信链路发送至所述客户端。

具体地，服务器构建消息队列基础设施能力层，灵活接入不同种类的消息集群，同时可向业务应用暴露多种类型的消息服务，使得业务开发可以在多语言多版本的不同类型的消息队列中间件之间灵活切换。

步骤340，将所述响应报文进行解析，得到所述目标格式的响应数据。

具体地，业务应用系统接收响应报文并根据HTTP协议或基于HTTP2.0的gRPC协议解析HTTP响应报文得到响应体，基于响应体生成业务应用系统可直接处理的目标格式的响应数据。HTTP响应报文包括响应行、响应头部和响应体，其中，响应行一般由协议版本、状态码及其描述组成；响应头用于描述服务器的基本信息和数据信息，服务器通过这些数据信息通知客户端如何处理返回的数据；响应体即响应的消息体，可以为多种数据类型，比如纯数据、HTML页面或JavaScript代码等。

本发明提供的消息调用方法，在业务代码中不再使用特定消息队列框架的专有协议，而是利用通用的通信协议灵活接入不同种类的消息集群，通过数据格式转换可同时向业务应用暴露多种类型的消息服务，业务应用系统无需关心消息服务的具体版本和消息服务升级的问题，在多版本多语言消息队列框架中灵活切换，业务应用系统与消息队列框架独立演进，大大降低了业务应用系统使用消息队列框架的复杂度和难度。

图4为本发明提供的消息调用方法(用于服务器)，如图4所示，该方法包括：

步骤410，接收客户端发送的请求报文。

具体地，在通信交互协议上采用HTTP标准化通信协议或基于HTTP2.0的gRPC协议作为通信载体，接收业务应用系统发送的统一格式的HTTP请求报文。HTTP请求报文由请求行、请求头部和请求体三个部分组成，其中，请求行由请求方法字段、URL字段和HTTP协议版本三个字段组成；请求头部由关键字/值对组成，用于通知服务器有关客户端请求的信息；请求体包含数据的主体部分。

步骤420，根据所述请求报文进行消息调用，生成目标格式的响应数据。

具体地，服务器构建消息队列基础设施能力层，灵活接入不同种类的消息集群，同时可向业务应用暴露多种类型的消息服务，根据业务应用系统发送的请求报文，调用特定的消息队列中间件，由该消息队列中间件生成对应格式的响应数据，当前消息队列中间件的数据格式为目标格式。

步骤430，将所述响应数据进行格式转换，得到统一的经由通信链路传输的响应报文，并返回至客户端，以使所述客户端通过解析所述响应报文得到目标格式的响应数据。

具体地，服务器根据HTTP协议或基于HTTP2.0的gRPC协议包装响应数据得到HTTP响应报文。HTTP响应报文包括响应行、响应头部和响应体，其中，响应行一般由协议版本、状态码及其描述组成；响应头用于描述服务器的基本信息和数据信息，服务器通过这些数据信息通知客户端如何处理返回的数据；响应体即响应的消息体，可以为多种数据类型，比如纯数据、HTML页面或JavaScript代码等。

本发明提供的消息调用方法，在业务代码中不再使用特定消息队列框架的专有协议，而是利用通用的通信协议灵活接入不同种类的消息集群，通过数据格式转换可同时向业务应用暴露多种类型的消息服务，业务应用系统无需关心消息服务的具体版本和消息服务升级的问题，在多版本多语言消息队列框架中灵活切换，业务应用系统与消息队列框架独立演进，大大降低了业务应用系统使用消息队列框架的复杂度和难度。

基于上述实施例，所述服务器构建的消息队列基础设施能力层包括消息前置服务层、统一消息服务层和消息集群层，所述消息集群层包括至少一个消息队列中间件。图5为根据所述请求报文进行消息调用，生成目标格式的响应数据的流程示意图，如图5所述，步骤420包括：

步骤510，所述消息前置服务层接收所述请求报文，将所述请求报文进行解析，得到所述目标格式的请求数据，并将所述请求数据转发至所述统一消息服务层。

具体地，消息前置服务层接收请求报文，根据HTTP协议或基于HTTP2.0的gRPC协议解析HTTP响应报文得到请求体，基于请求体生成目标格式的请求数据。

步骤520，所述统一消息服务层根据所述请求数据确定消息队列中间件，并向所述消息队列中间件发送所述请求数据。

步骤530，所述消息队列中间件根据所述请求数据进行消息队列的读或写操作，并生成目标格式的响应数据。

基于上述实施例，图5为将所述响应数据进行格式转换，得到统一的经由通信链路传输的响应报文的流程示意图，如图6所示，步骤430包括：

步骤610，所述消息队列中间件向所述统一消息服务层返回所述响应数据。

步骤620，所述统一消息服务层将所述响应数据返回至所述消息前置服务层。

具体地，对于业务应用系统提出的消息队列读取请求，服务器需要将读取的数据加以包装返回给业务方，对于消息队列的写入请求，服务器也需要向业务方返回写入成功或失败的状态信息。

步骤630，所述消息前置服务层将所述响应数据进行格式转换，得到统一的经由通信链路传输的响应报文。

具体地，消息前置服务层根据HTTP协议或基于HTTP2.0的gRPC协议包装响应数据得到HTTP响应报文。HTTP响应报文包括响应行、响应头部和响应体，其中，响应行一般由协议版本、状态码及其描述组成；响应头用于描述服务器的基本信息和数据信息，服务器通过这些数据信息通知客户端如何处理返回的数据；响应体即响应的消息体，可以为多种数据类型，比如纯数据、HTML页面或JavaScript代码等。

下面对本发明提供的消息调用装置进行描述，下文描述的消息调用装置与上文描述的消息调用方法可相互对应参照。

图7为本发明提供的消息调用装置(用于客户端)的结构示意图，如图7所示，该装置包括：

请求报文生成模块710，用于获取目标格式的请求数据；

将所述请求数据进行格式转换，得到统一的经由通信链路传输的请求报文。

需要说明的是，消息队列中间件有多种类型，每种类型的中间件还存在多版本和多语言的产品，业务应用系统在调用消息队列中间件时，通常会通过专有协议和特定语言SDK与特定的消息队列中间件交互，本发明不考虑消息队列中间件的版本和语言，基于业务应用系统的版本和语言生成请求数据，其中，业务应用系统的数据格式为目标格式。

具体地，在通信交互协议上采用HTTP标准化通信协议或基于HTTP2.0的gRPC协议作为通信载体，将多种格式的请求数据包装为统一的HTTP请求报文。HTTP请求报文由请求行、请求头部和请求体三个部分组成，其中，请求行由请求方法字段、URL字段和HTTP协议版本三个字段组成；请求头部由关键字/值对组成，用于通知服务器有关客户端请求的信息；请求体包含数据的主体部分。

消息调用模块720，用于将所述请求报文发送至服务器，以使服务器根据所述请求报文进行消息调用，生成响应报文并经由所述通信链路发送至所述客户端。

具体地，服务器构建消息队列基础设施能力层，灵活接入不同种类的消息集群，同时可向业务应用暴露多种类型的消息服务，使得业务开发可以在多语言多版本的不同类型的消息队列中间件间灵活切换。

响应报文解析模块730，用于将所述响应报文进行解析，得到所述目标格式的响应数据。

具体地，业务应用系统接收响应报文并根据HTTP协议或基于HTTP2.0的gRPC协议解析HTTP响应报文得到响应体，基于响应体生成业务应用系统可直接处理的目标格式的响应数据。HTTP响应报文包括响应行、响应头部和响应体，其中，响应行一般由协议版本、状态码及其描述组成；响应头用于描述服务器的基本信息和数据信息，服务器通过这些数据信息通知客户端如何处理返回的数据；响应体即响应的消息体，可以为多种数据类型，比如纯数据、HTML页面或JavaScript代码等。

本发明提供的消息调用装置，在业务代码中不再使用特定消息队列框架的专有协议，而是利用通用的通信协议灵活接入不同种类的消息集群，通过数据格式转换可同时向业务应用暴露多种类型的消息服务，业务应用系统无需关心消息服务的具体版本和消息服务升级的问题，在多版本多语言消息队列框架中灵活切换，业务应用系统与消息队列框架独立演进，大大降低了业务应用系统使用消息队列框架的复杂度和难度。

图8为本发明提供的消息调用装置(用于服务器)的结构示意图，如图8所示，该装置包括：

消息前置服务模块810，用于接收客户端发送的请求报文，将所述请求报文进行解析，得到目标格式的请求数据，并将所述请求数据转发至统一消息服务层。

统一消息服务模块820，用于根据所述请求数据确定消息队列中间件，并向所述消息队列中间件发送所述请求数据。

消息集群模块830，用于根据所述请求数据进行消息队列的读或写操作，并生成目标格式的响应数据。

本发明提供的消息调用装置，在业务代码中不再使用特定消息队列框架的专有协议，而是利用通用的通信协议灵活接入不同种类的消息集群，通过数据格式转换可同时向业务应用暴露多种类型的消息服务，业务应用系统无需关心消息服务的具体版本和消息服务升级的问题，在多版本多语言消息队列框架中灵活切换，业务应用系统与消息队列框架独立演进，大大降低了业务应用系统使用消息队列框架的复杂度和难度。

基于上述实施例，所述请求报文包括请求行、请求头部和请求体；

所述消息前置服务模块810还用于：

对所述请求报文进行解析得到请求体，基于所述请求体生成所述目标格式的请求数据。

基于上述实施例，所述消息集群模块830还用于：

向所述统一消息服务层返回所述响应数据。

基于上述实施例，所述统一消息服务模块820还用于：

将所述响应数据返回至所述消息前置服务层。

基于上述实施例，所述消息前置服务模块810还用于：

将所述响应数据进行格式转换，得到统一的经由通信链路传输的响应报文。

图9示例了一种电子设备的实体结构示意图，如图9所示，该电子设备可以包括：处理器(processor)910、通信接口(Communications Interface)920、存储器(memory)930和通信总线940，其中，处理器910，通信接口920，存储器930通过通信总线940完成相互间的通信。处理器910可以调用存储器930中的逻辑指令，以执行提供的消息调用方法，其中，消息调用方法包括，用于客户端的消息调用方法和用于服务器的消息调用方法，用于客户端的消息调用方法包括：获取目标格式的请求数据；将所述请求数据进行格式转换，得到统一的经由通信链路传输的请求报文；将所述请求报文发送至服务器，以使服务器根据所述请求报文进行消息调用，生成响应报文并经由所述通信链路发送至所述客户端；将所述响应报文进行解析，得到所述目标格式的响应数据。对应地，用于服务器的消息调用方法，包括：接收客户端发送的请求报文；根据所述请求报文进行消息调用，生成目标格式的响应数据；将所述响应数据进行格式转换，得到统一的经由通信链路传输的响应报文，并返回至客户端，以使所述客户端通过解析所述响应报文得到目标格式的响应数据。

此外，上述的存储器930中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

另一方面，本发明还提供一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，计算机能够执行上述各实施例所提供的消息调用方法，其中，消息调用方法包括，用于客户端的消息调用方法和用于服务器的消息调用方法，用于客户端的消息调用方法包括：获取目标格式的请求数据；将所述请求数据进行格式转换，得到统一的经由通信链路传输的请求报文；将所述请求报文发送至服务器，以使服务器根据所述请求报文进行消息调用，生成响应报文并经由所述通信链路发送至所述客户端；将所述响应报文进行解析，得到所述目标格式的响应数据。对应地，用于服务器的消息调用方法，包括：接收客户端发送的请求报文；根据所述请求报文进行消息调用，生成目标格式的响应数据；将所述响应数据进行格式转换，得到统一的经由通信链路传输的响应报文，并返回至客户端，以使所述客户端通过解析所述响应报文得到目标格式的响应数据。

又一方面，本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现以执行上述各实施例所提供的消息调用方法，其中，消息调用方法包括，用于客户端的消息调用方法和用于服务器的消息调用方法，用于客户端的消息调用方法包括：获取目标格式的请求数据；将所述请求数据进行格式转换，得到统一的经由通信链路传输的请求报文；将所述请求报文发送至服务器，以使服务器根据所述请求报文进行消息调用，生成响应报文并经由所述通信链路发送至所述客户端；将所述响应报文进行解析，得到所述目标格式的响应数据。对应地，用于服务器的消息调用方法，包括：接收客户端发送的请求报文；根据所述请求报文进行消息调用，生成目标格式的响应数据；将所述响应数据进行格式转换，得到统一的经由通信链路传输的响应报文，并返回至客户端，以使所述客户端通过解析所述响应报文得到目标格式的响应数据。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

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

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (15)

1.一种消息调用方法，其特征在于，用于客户端，所述方法包括：

获取目标格式的请求数据；

将所述请求数据进行格式转换，得到统一的经由通信链路传输的请求报文；

将所述请求报文发送至服务器，以使服务器根据所述请求报文进行消息调用，生成响应报文并经由所述通信链路发送至所述客户端；

将所述响应报文进行解析，得到所述目标格式的响应数据。

2.根据权利要求1所述的消息调用方法，其特征在于，所述响应报文包括响应行、响应头部和响应体；

所述将所述响应报文进行解析，得到所述目标格式的响应数据，包括：

对所述响应报文进行解析得到响应体，基于所述响应体生成所述目标格式的响应数据。

3.一种消息调用方法，其特征在于，用于服务器，所述方法包括：

接收客户端发送的请求报文；

根据所述请求报文进行消息调用，生成目标格式的响应数据；

将所述响应数据进行格式转换，得到统一的经由通信链路传输的响应报文，并返回至客户端，以使所述客户端通过解析所述响应报文得到目标格式的响应数据。

4.根据权利要求3所述的消息调用方法，其特征在于，所述服务器包括消息前置服务层、统一消息服务层和消息集群层，所述消息集群层包括至少一个消息队列中间件；

所述根据所述请求报文进行消息调用，生成目标格式的响应数据包括：

所述消息前置服务层接收所述请求报文，将所述请求报文进行解析，得到所述目标格式的请求数据，并将所述请求数据转发至所述统一消息服务层；

所述统一消息服务层根据所述请求数据确定消息队列中间件，并向所述消息队列中间件发送所述请求数据；

所述消息队列中间件根据所述请求数据进行消息队列的读或写操作，并生成目标格式的响应数据。

5.根据权利要求4所述的消息调用方法，其特征在于，所述请求报文包括请求行、请求头部和请求体；

所述将所述请求报文进行解析，得到所述目标格式的请求数据包括：

对所述请求报文进行解析得到请求体，基于所述请求体生成所述目标格式的请求数据。

6.根据权利要求4所述的消息调用方法，其特征在于，所述将所述响应数据进行格式转换，得到统一的经由通信链路传输的响应报文，包括：

所述消息队列中间件向所述统一消息服务层返回所述响应数据；

所述统一消息服务层将所述响应数据返回至所述消息前置服务层；

所述消息前置服务层将所述响应数据进行格式转换，得到统一的经由通信链路传输的响应报文。

7.一种消息调用装置，其特征在于，用于客户端，所述装置包括：

请求报文生成模块，用于获取目标格式的请求数据；

将所述请求数据进行格式转换，得到统一的经由通信链路传输的请求报文；

消息调用模块，用于将所述请求报文发送至服务器，以使服务器根据所述请求报文进行消息调用，生成响应报文并经由所述通信链路发送至所述客户端；

响应报文解析模块，用于将所述响应报文进行解析，得到所述目标格式的响应数据。

8.根据权利要求7所述的消息调用装置，其特征在于，所述响应报文包括响应行、响应头部和响应体；

所述响应报文解析模块还用于：

对所述响应报文进行解析得到响应体，基于所述响应体生成所述目标格式的响应数据。

9.一种消息调用装置，其特征在于，用于服务器，所述装置包括：

消息前置服务模块，用于接收客户端发送的请求报文，将所述请求报文进行解析，得到目标格式的请求数据，并将所述请求数据转发至统一消息服务层；

统一消息服务模块，用于根据所述请求数据确定消息队列中间件，并向所述消息队列中间件发送所述请求数据；

消息集群模块，用于根据所述请求数据进行消息队列的读或写操作，并生成目标格式的响应数据。

10.根据权利要求9所述的消息调用装置，其特征在于，所述请求报文包括请求行、请求头部和请求体；

所述消息前置服务模块还用于：

对所述请求报文进行解析得到请求体，基于所述请求体生成所述目标格式的请求数据。

11.根据权利要求9所述的消息调用装置，其特征在于，所述消息集群模块还用于：

向所述统一消息服务层返回所述响应数据。

12.根据权利要求9所述的消息调用装置，其特征在于，所述统一消息服务模块还用于：

将所述响应数据返回至所述消息前置服务层。

13.根据权利要求9所述的消息调用装置，其特征在于，所述消息前置服务模块还用于：

将所述响应数据进行格式转换，得到统一的经由通信链路传输的响应报文。

14.一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1至6任一项所述消息调用方法的步骤。

15.一种非暂态计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至6任一项所述消息调用方法的步骤。

Images