一种云原生参数映射方法、装置、设备及可读存储介质

技术领域

本申请涉及计算机技术领域，特别涉及一种云原生参数映射方法、装置、设备及可读存储介质。

背景技术

当外部系统与内部系统进行数据交互时，由于外部系统的数据格式和内部系统的数据格式之间存在差异，因此需要通过参数映射方式进行数据格式转化。

目前，参数映射有两种常用的实现方式：开发参数映射系统、业务系统集成参数映射模块。然而，无论采用哪种方式，都会存在一些问题。

开发参数映射系统存在以下问题：

(1)请求链路变长，业务请求处理效率降低。所有业务请求都需要先经过参数映射系统，再由参数映射系统去访问业务系统，多出了参数映射系统处理业务请求环节，导致请求链路变长，业务请求处理效率降低。

(2)存在性能瓶颈。参数映射系统与多个业务系统对接，是所有业务请求的汇集点，当业务请求量较大时，参数映射系统存在性能瓶颈，无法及时处理业务请求，出现处理时间变长、处理能力下降等情况，当业务请求量持续增大时，会进一步演化为系统宕机。

(3)存在业务不可用风险。当参数映射系统出现故障时，会导致业务请求全部中断，出现业务不可用，严重影响业务正常进行。

而业务系统集成参数映射模块存在以下问题：

(1)参数映射能力不通用。每个业务系统都需要自行去集成参数映射功能，浪费开发及测试资源。

(2)参数映射标准不统一。每个业务系统集成的参数映射功能存在差异，导致参数映射配置方式及参数映射实现能力不同。

综上，如何克服上述两种参数映射方案的缺陷，是亟待本领域技术人员解决的问题。

发明内容

本申请的目的是提供一种云原生参数映射方法、装置、设备及可读存储介质，用以解决当前的参数映射方案存在请求链路变长、性能评价、不可用风险高或参数映射规则不统一的问题。其具体方案如下：

第一方面，本申请提供了一种云原生参数映射方法，应用于流量代理端，所述流量代理端基于istio envoy组件实现，该方法包括：

从规则管控端获取当前业务系统的参数映射规则；

响应于调用方对所述当前业务系统的调用，获取原始请求参数；

根据所述参数映射规则，将所述原始请求参数映射为目标请求参数；

通过应用进程间通讯的方式，将携带所述目标请求参数的业务请求发送至所述当前业务系统；

通过应用进程间通讯的方式，获取所述当前业务系统反馈的原始响应参数；

根据所述参数映射规则，将所述原始响应参数映射为目标响应参数；

将携带所述目标响应参数的业务响应发送至所述调用方。

优选的，在所述从规则管控端获取当前业务系统的参数映射规则之前，还包括：

根据当前业务系统的目标接口的参数映射需求，生成参数映射规则；

将所述参数映射规则、所述当前业务系统的标识信息、所述目标接口的标识信息一并提交至规则管控端。

优选的，所述参数映射规则与所述当前业务系统的接口一一对应，所述响应于调用方对所述当前业务系统的调用，获取原始请求参数，包括：

响应于调用方对所述当前业务系统的调用，确定当前调用接口，并获取原始请求参数；

相应的，所述根据所述参数映射规则，将所述原始请求参数映射为目标请求参数，包括：

将所述当前调用接口与所述当前业务系统的参数映射规则进行匹配；根据匹配中的参数映射规则，将所述原始请求参数映射为目标请求参数。

优选的，还包括：

对所述规则管控端上当前业务系统的参数映射规则进行编辑操作，所述编辑操作包括以下任意一项或多项：新增、更新、移除。

优选的，在所述从规则管控端获取当前业务系统的参数映射规则之前，还包括：

注册流量代理端，并将所述流量代理端关联至当前业务系统。

优选的，还包括：

通过动态开关，开启或关闭所述流量代理端的参数映射功能。

第二方面，本申请提供了一种云原生参数映射装置，应用于流量代理端，所述流量代理端基于istio envoy组件实现，该装置包括：

参数映射规则获取模块：用于从规则管控端获取当前业务系统的参数映射规则；

原始请求参数获取模块：用于响应于调用方对所述当前业务系统的调用，获取原始请求参数；

请求参数映射模块：用于根据所述参数映射规则，将所述原始请求参数映射为目标请求参数；

业务请求发送模块：用于通过应用进程间通讯的方式，将携带所述目标请求参数的业务请求发送至所述当前业务系统；

原始响应参数获取模块：用于通过应用进程间通讯的方式，获取所述当前业务系统反馈的原始响应参数；

响应参数映射模块：用于根据所述参数映射规则，将所述原始响应参数映射为目标响应参数；

业务响应发送模块：用于将携带所述目标响应参数的业务响应发送至所述调用方。

优选的，还包括：

参数映射规则生成模块：用于根据当前业务系统的目标接口的参数映射需求，生成参数映射规则；

参数映射规则提交模块：用于将所述参数映射规则、所述当前业务系统的标识信息、所述目标接口的标识信息一并提交至规则管控端。

第三方面，本申请提供了一种云原生参数映射设备，包括：

存储器：用于存储计算机程序；

处理器：用于执行所述计算机程序，以实现如上所述的云原生参数映射方法。

第四方面，本申请提供了一种可读存储介质，所述可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时用于实现如上所述的云原生参数映射方法。

本申请所提供的一种云原生参数映射方法，应用于流量代理端，该流量代理端基于istio envoy组件实现，该方法包括：从规则管控端获取当前业务系统的参数映射规则；响应于调用方对当前业务系统的调用，获取原始请求参数；根据参数映射规则，将原始请求参数映射为目标请求参数；通过应用进程间通讯的方式，将携带目标请求参数的业务请求发送至当前业务系统；通过应用进程间通讯的方式，获取当前业务系统反馈的原始响应参数；根据参数映射规则，将原始响应参数映射为目标响应参数；将携带目标响应参数的业务响应发送至调用方。

可见，该方法利用流量代理端实现参数映射功能，第一方面，该流量代理端与业务系统通过应用进程间通讯，无需部署独立的参数映射系统，避免参数映射系统带来的请求链路变长、不可用风险高的问题；第二方面，由于流量代理端基于istio envoy组件实现，因此很轻量，具备高并发、低延迟的特点，有效避免出现性能瓶颈；第三方面，利用规则管控端向流量代理端下发参数映射规则，避免了不同业务系统的参数映射规则不同导致开发工作量较大的问题，且实现了参数映射规则的灵活配置。

此外，本申请还提供了一种云原生参数映射装置、设备及可读存储介质，其技术效果与上述方法的技术效果相对应，这里不再赘述。

附图说明

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

图1为本申请所提供的一种云原生参数映射方法实施例一的流程图；

图2为本申请所提供的一种云原生参数映射方法实施例一的时序图；

图3为本申请所提供的一种云原生参数映射方法实施例二中参数映射规则配置流程示意图；

图4为本申请所提供的一种云原生参数映射方法实施例二中参数映射流程示意图；

图5为本申请所提供的一种云原生参数映射装置实施例的功能框图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面结合附图和具体实施方式对本申请作进一步的详细说明。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

外部系统向内部系统提交数据、或从内部系统查询数据时，外部系统的数据格式和内部系统的数据格式之间存在差异，需要通过参数映射方式进行数据格式转化。针对该问题，本申请的核心是提供一种云原生参数映射方法、装置、设备及可读存储介质，利用规则管控端和流量代理端相互配合完成参数映射过程，避免了前述两种参数映射方案存在的缺陷。

首先，对本申请涉及的技术背景和相关概念进行介绍：

云原生(Cloud Native)技术：有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

服务网格(Service Mesh)：处理服务间通信的基础设施层，负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。在实践中，服务网格通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起，对应用程序来说无需感知代理的存在。

istio：云原生生态中最主流的服务网格开源框架，拥有可以集成任何日志、遥测和策略系统的API接口，高效地运行分布式微服务架构，并提供保护、连接和监控微服务的统一方法，有助于降低这些部署的复杂性，减轻开发团队的压力。

envoy：用c++开发的高性能代理，用于协调服务网格中所有服务的入站和出站流量，istio使用envoy来实现流量代理。istio envoy分为ingressgateway(入口网关)、egressgateway(出口网关)和sidecar(边车)三类，用途略有不同，但主要功能完全相同，都可以实现流量管理、遥测、安全管理、服务高可用等功能。

业务请求：一次向业务系统提交信息或查询数据的过程。

业务响应：业务系统处理业务请求后返回给调用方的数据。

请求链路：一次业务请求所经过的业务系统或业务模块组成的链路。

数据：本申请特指JSON/XML等格式组成的文本。

数据格式：本申请特指数据内部的健值对组成结构。

数据格式转化：本申请特指调整数据内部的健值对组成结构。

参数映射：一种数据格式中的健和另外一种数据格式中的健之间的对应关系。

下面对本申请提供的一种云原生参数映射方法实施例一进行介绍，参见图1和图2，实施例一应用于流量代理端，所述流量代理端基于istio envoy组件实现，该方法包括：

S101、从规则管控端获取当前业务系统的参数映射规则；

S102、响应于调用方对所述当前业务系统的调用，获取原始请求参数；

S103、根据所述参数映射规则，将所述原始请求参数映射为目标请求参数；

S104、通过应用进程间通讯的方式，将携带所述目标请求参数的业务请求发送至所述当前业务系统；

S105、通过应用进程间通讯的方式，获取所述当前业务系统反馈的原始响应参数；

S106、根据所述参数映射规则，将所述原始响应参数映射为目标响应参数；

S107、将携带所述目标响应参数的业务响应发送至所述调用方。

本实施例涉及三个功能模块：规则管控端、流量代理端、业务系统，首先对三者的功能进行介绍：

规则管控端：负责管理和控制参数映射规则，其中管理功能包括对参数映射规则的新增、更新、移除等，控制功能包括参数映射规则的下发，还可以包括流量代理端的注册。

流量代理端：负责代理业务系统入口流量和出口流量，依据参数映射规则完成入口请求参数的映射和出口响应参数的映射。流量代理端很轻量，具有高并发、低延迟的特性，业务系统几乎感知不到流量代理端的存在。

业务系统：用于实现常规业务功能。

需要说明的是，本实施例的流量代理端基于istio envoy组件实现，其核心逻辑如下：在业务请求到达业务系统的服务器进程前，利用同一服务器上的拦截进程对其进行拦截，然后进行请求参数映射，将业务请求的原始请求参数映射为目标请求参数，映射完之后，将携带目标请求参数的业务请求通过进程间通讯的方式发送至业务系统中。在业务响应离开业务系统的服务器进程后，利用同一服务器上的拦截进程对其进行拦截，通过进程间通讯的方式获取业务响应，然后进行响应参数映射，将原始响应参数映射为目标映射参数，最终将携带目标响应参数的业务响应发送至调用方。

综上，本实施例中，流量代理端与业务系统一一对应，二者通过应用进程间通讯的方式进行通讯，规则管控端用于管理多个流量代理端。

在执行真正的参数映射过程之前，需要将参数映射规则提交到规则管控端。实际应用中，一个业务系统往往存在多种接口，参数映射规则与接口一一对应。因此，在提交参数映射规则的时候，不仅需要指定生效的业务系统，还需要进一步指定生效的接口。因此，在S101之前，还包括以下过程：根据当前业务系统的目标接口的参数映射需求，生成参数映射规则；将所述参数映射规则、所述当前业务系统的标识信息、所述目标接口的标识信息一并提交至规则管控端。

相应的，在S102中，在检测到调用方对当前业务系统的调用之后，不仅要获取原始请求参数，还需要确定当前调用接口。而在S103中，具体过程如下：将所述当前调用接口与所述当前业务系统的参数映射规则进行匹配；根据匹配中的参数映射规则，将所述原始请求参数映射为目标请求参数；若不存在匹配中的参数映射规则，则表明当前调用接口没有注册参数映射规则，跳过参数映射过程。

基于上述规则管控端的特性，在提交参数映射规则之后，还可以实现以下过程：对所述规则管控端上当前业务系统的参数映射规则进行编辑操作，所述编辑操作包括以下任意一项或多项：新增、更新、移除。

基于上述规则管控端的特性，在将参数映射规则下发至流量代理端之前，还包括以下过程：注册流量代理端，并将所述流量代理端关联至当前业务系统。

基于服务网格的配置能力，在注册流量代理端之后，本实施例还能够实现：通过动态开关，开启或关闭所述流量代理端的参数映射功能。

本实施例所提供一种云原生参数映射方法，该方法利用流量代理端实现参数映射功能，因此，首先，该流量代理端与业务系统通过应用进程间通讯，无需部署独立的参数映射系统，避免参数映射系统带来的请求链路变长、不可用风险高的问题；再者，由于流量代理端基于istio envoy组件实现，因此很轻量，具备高并发、低延迟的特点，有效避免出现性能瓶颈；最后，该方法利用规则管控端向流量代理端下发参数映射规则，避免了不同业务系统的参数映射规则不同导致开发工作量较大的问题，且实现了参数映射规则的灵活配置。

下面开始详细介绍本申请提供的一种云原生参数映射方法实施例二，实施例二以实际应用为例对参数映射过程进行了详尽的描述，具体分两部分：参数映射规则的配置过程和参数映射过程。

本实施例的参数映射规则配置流程如图3所示，包括：

S301、根据业务系统不同接口的参数映射需求配置参数映射规则。

S302、将参数映射规则提交到规则管控端，提交时声明生效系统和生效接口，后续可以新增规则、更新规则、移除规则。

S303、规则管理控制端在收到参数映射规则后，校验生效系统关联的流量代理端是否已注册，如已注册，则进入S304，否则等待流量代理端注册时拉取参数映射规则。

S304、向该流量代理端下发参数映射规则。

本实施例的基于流量代理实现参数映射流程如图4所示，包括：

S401、请求方发起对业务系统的业务请求，流量代理端获取当前请求接口和原始请求参数。

S402、流量代理端根据当前请求接口匹配参数映射规则。如匹配成功，则进行参数映射，将原始请求参数映射为目标请求参数，并将目标请求参数封装进业务请求体中；如匹配失败，则跳过参数映射。

S403、流量代理端通过应用进程间通讯的方式，将携带目标请求参数的业务请求传递到业务系统。而后，业务系统处理业务，并返回业务响应。因业务系统的出口流量已被流量代理端代理，业务系统的业务响应实际是通过应用进程间通讯的方式传递到了流量代理端。

S404、流量代理端进行参数映射，将原始响应参数映射为目标响应参数，并将目标响应参数封装进业务响应体中；如匹配失败，则跳过参数映射。

S405、流量代理端向请求方返回携带目标响应参数的业务响应。

综上，本实施例提供了一种云原生参数映射方法，包括但不限于以下优点：

第一，参数映射能力轻量化、通用化。istio envoy组件的流量代理能力是服务网格的基础能力，将参数映射能力嵌入到流量代理能力中，使得参数映射能力成为服务网格的基础能力，服务网格内的任何服务均可以直接使用该能力，不需要单独部署参数映射系统或开发参数映射模块，实现通用化。

第二，参数映射动态管理。通过服务网格的配置管控能力和配置下发能力，无需引入额外组件或系统即可通过配置动态管理参数映射，可随时开启、停止参数映射功能，可随时新增、更新、移除规则，参数映射的一切都可以动态进行管理，大大降低了操作难度。

第三，缩短业务请求链路，提升业务请求处理效率。通过流量代理方式实现参数映射功能，无需部署额外参数映射系统，缩短了业务请求链路，减少了业务请求响应时间，提升了业务请求处理效率。

第四，去除参数映射性能瓶颈。流量代理很轻量，具有高并发、低延迟的特性，业务系统几乎感知不到流量代理的存在。每个业务系统关联一个流量代理端，不存在参数映射性能瓶颈。

下面本申请的参数映射方案与现有技术中两种参数映射方案进行性能对比。

现有技术中，基于参数映射系统的参数映射方案的实现过程为：开发独立于业务系统的参数映射系统，将参数映射规则提交至参数映射系统中；每当请求方调用业务系统时，业务请求先经过参数映射系统进行处理，再将处理后的业务请求传输至业务系统；每当业务系统发送业务响应时，业务响应先经过参数映射系统进行处理，再将处理后的业务响应发送至请求方。可见，该方案导致请求链路变长，且单个参数映射系统处理多个业务系统的业务需求，存在性能瓶颈问题，且不可用风险较高。

参数映射系统处理压力计算公式为：处理压力＝单业务系统参数映射处理压力*并发业务系统数量。

参数映射系统新增全新映射规则调整耗时为：调整耗时＝系统功能开发耗时+系统功能测试耗时+系统发布窗口等待耗时。

参数映射系统代码复杂度：一套整合的参数映射代码。

基于上述公式，假设“单业务系统参数映射处理压力”值为100，“并发业务系统数量”值为10，“系统功能开发耗时”值为200，“系统功能测试耗时”值为100，“系统发布窗口等待耗时”值为500，“一套整合的参数映射代码”值为300，则结果如下：

处理压力＝100*10＝1000。

调整耗时＝200+100+500＝800。

代码复杂度＝300。

现有技术中，基于集成参数映射模块的参数映射方案的实现过程为：针对业务系统的参数映射需求，开发参数映射模块；每当请求方调用业务系统时，业务请求先经过参数映射模块进行处理，再将处理后的业务请求传输至业务系统；每当业务系统发送业务响应时，业务响应先经过参数映射模块进行处理，再将处理后的业务响应发送至请求方。可见，该方案中参数映射模块只是针对该业务系统的，由于不同业务系统的参数映射需求不同，因此该方案的开发工作量较大。

集成参数映射模块处理压力计算公式：处理压力＝单业务系统参数映射处理压力+参数映射模块占用业务系统资源产生的压力。

集成参数映射模块新增全新映射规则调整耗时：调整耗时＝系统功能开发耗时+系统功能测试耗时+系统发布窗口等待耗时。

集成参数映射模块代码复杂度：多套参数映射代码。

基于上述公式中，假设“单业务系统参数映射处理压力”值为100，“参数映射模块占用业务系统资源产生的压力”值为100，“系统功能开发耗时”值为200，“系统功能测试耗时”值为100，“系统发布窗口等待耗时”值为500，“多套参数映射代码”值为500，则结果如下：

处理压力＝100+100＝200。

调整耗时＝200+100+500＝800。

代码复杂度＝500。

本申请中，处理压力计算公式：处理压力＝单业务系统参数映射处理压力(不会对业务系统产生任何压力)。

新增全新映射规则调整耗时：调整耗时＝系统功能开发耗时+系统功能测试耗时(无需等待发布窗口)。

代码复杂度：一套分散的参数映射代码。

基于上述公式中，假设“单业务系统参数映射处理压力”值为100，“系统功能开发耗时”值为200，“系统功能测试耗时”值为100，“一套分散的参数映射代码”值为100，则结果如下：

处理压力＝100。

调整耗时＝200+100＝300。

代码复杂度＝100。

可见，现有技术中，处理压力分别为1000和200，本申请处理压力为100，分别下降了90％及50％，处理压力下降幅度很大，单位硬件资源的参数映射处理能力大幅提升，在同等条件下，可节省大量的硬件资源。

现有技术中，调整耗时均为800，本申请调整耗时为300，下降了62.5％，节省了人员成本，提高了响应效率。

现有技术中，代码复杂度分别为300和500，本申请代码复杂度为100，分别下降了66.7％及80％，大大降低了代码复杂度，减少了代码维护成本和代码熟悉成本。

下面对本申请实施例提供的云原生参数映射装置进行介绍，下文描述的云原生参数映射装置与上文描述的云原生参数映射方法可相互对应参照。

本实施例的云原生参数映射装置，应用于流量代理端，所述流量代理端基于istioenvoy组件实现，如图5所示，该装置包括：

参数映射规则获取模块501：用于从规则管控端获取当前业务系统的参数映射规则；

原始请求参数获取模块502：用于响应于调用方对所述当前业务系统的调用，获取原始请求参数；

请求参数映射模块503：用于根据所述参数映射规则，将所述原始请求参数映射为目标请求参数；

业务请求发送模块504：用于通过应用进程间通讯的方式，将携带所述目标请求参数的业务请求发送至所述当前业务系统；

原始响应参数获取模块505：用于通过应用进程间通讯的方式，获取所述当前业务系统反馈的原始响应参数；

响应参数映射模块506：用于根据所述参数映射规则，将所述原始响应参数映射为目标响应参数；

业务响应发送模块507：用于将携带所述目标响应参数的业务响应发送至所述调用方。

在一些具体的实施例中，还包括：

参数映射规则生成模块：用于根据当前业务系统的目标接口的参数映射需求，生成参数映射规则；

参数映射规则提交模块：用于将所述参数映射规则、所述当前业务系统的标识信息、所述目标接口的标识信息一并提交至规则管控端。

本实施例的云原生参数映射装置用于实现前述的云原生参数映射方法，因此该装置中的具体实施方式可见前文中的云原生参数映射方法的实施例部分，例如，参数映射规则获取模块501、原始请求参数获取模块502、请求参数映射模块503、业务请求发送模块504、原始响应参数获取模块505、响应参数映射模块506、业务响应发送模块507，分别用于实现上述云原生参数映射方法中步骤S101，S102，S103，S104，S105，S106，S107。所以，其具体实施方式可以参照相应的各个部分实施例的描述，在此不再展开介绍。

另外，由于本实施例的云原生参数映射装置用于实现前述的云原生参数映射方法，因此其作用与上述方法的作用相对应，这里不再赘述。

此外，本申请还提供了一种云原生参数映射设备，包括：

存储器：用于存储计算机程序；

处理器：用于执行所述计算机程序，以实现如上文所述的云原生参数映射方法。

最后，本申请提供了一种可读存储介质，所述可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时用于实现如上文所述的云原生参数映射方法。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上对本申请所提供的方案进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。