CN107707644A - 请求消息的处理方法、装置、存储介质、处理器及终端 - Google Patents

Abstract

本发明公开了一种请求消息的处理方法、装置、存储介质、处理器及终端。该方法包括：接收来自于发送端的请求消息，其中，请求消息中至少携带有发送端的第一标识信息；根据第一标识信息是否出现在预设白名单中的判断结果，确定对请求消息的处理方式，其中，预设白名单用于确认是否需要对发送端与接收端之间的真实交互数据进行模拟。本发明解决了相关技术在联调测试阶段无法实现分布式服务框架(例如：Dubbo)应用之间交互数据的模拟，从而增加了服务提供方的负担的技术问题。

Description

请求消息的处理方法、装置、存储介质、处理器及终端

技术领域

本发明涉及计算机领域，具体而言，涉及一种请求消息的处理方法、装置、存储介质、处理器及终端。

背景技术

随着互联网技术的飞速发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。

Dubbo开始于电商系统，而电商系统的演变经历了如下过程：

(1)单一应用框架

当网站流量较小时，只需一个应用，将所有功能如下单支付等都部署在一起，以减少部署节点和成本，其缺陷在于：单一的系统架构会使得在开发过程中，占用的资源逐渐增多，而且随着流量的增加将愈发难以维护。

(2)垂直应用框架

垂直应用架构能够解决单一应用架构所面临的扩容问题，其流量能够分散到各个子系统当中，且系统的体积可控，进而在一定程度上降低了开发人员之间协同以及维护的成本，提升了开发效率，然而，其缺陷在于：在垂直架构中相同逻辑代码需要不断的复制，无法复用。

(3)分布式应用架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心。

(4)流动计算架构

随着服务化的进一步发展，服务越来越多，服务之间的调用和依赖关系也愈发复杂，从而诞生了面向服务的架构体系，也因此衍生出了一系列相应的技术，例如：对服务提供、服务调用、连接处理、通信协议、序列化方式、服务发现、服务路由、日志输出等行为进行封装的服务框架。

Dubbo是一个分布式服务框架，其致力于提供高性能和透明化的远程服务调用方案，以及服务治理方案。简而言之，dubbo其实是个服务框架，如果没有分布式的需求，其实是不需要用到的。而只有在分布式情况下，才需要dubbo这样的分布式服务框架的需求，并且本质上是个远程服务调用的分布式框架。

Dubbo核心部分可以包括：

(1)远程通讯，提供对多种基于长连接的框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。

(2)集群容错，提供基于接口方法的透明远程过程调用，包括多协议支持以及软负载均衡，失败容错，地址路由，动态配置等集群支持。

(3)自动发现，基于注册中心目录服务，不仅使得服务消费方能够动态地查找服务提供方，而且还使得地址透明，服务提供方可以平滑地增加或减少机器。

因此，Dubbo能够实现如下功能：透明化的远程方法调用，其就像调用本地方法一样调用远程方法，只需简单配置；软负载均衡及容错机制，其可在内网替代部分硬件负载均衡器，降低成本，减少单点；服务自动注册与发现，其不再需要固定服务提供方地址，注册中心基于接口名查询服务提供者的互联网协议(IP)地址，并且能够平滑地添加或删除服务提供者。

图1是根据相关技术的dubbo的架构示意图。如图1所示，该架构可以包括如下交互流程：

第(1)步，服务运行容器负责启动、加载以及运行服务提供者。

第(2)步，服务提供方在启动时，向注册中心注册自身提供的服务。

第(3)步，服务消费方在启动时，向注册中心订阅自身所需的服务。

第(4)步，注册中心向服务消费方返回服务提供方的地址列表，如果发生变更，则注册中心将基于长连接向服务消费方推送变更数据。

第(5)步，服务消费方从服务提供方的地址列表中，基于软负载均衡算法选取其中一个服务提供方进行调用，如果调用失败，再选取另外一个服务提供方进行调用。

第(6)步，服务消费方和服务提供方在内存中累计调用次数与调用时间，定时每分钟向监控中心发送一次统计数据。

通过上述架构可以看出，dubbo具有如下特性：

(1)连通性：注册中心负责服务地址的注册与查找，其相当于目录服务，服务提供方和服务消费方只在启动时与注册中心进行交互。注册中心无需转发请求，压力较小。监控中心负责统计各服务调用次数，调用时间等数据。统计数据先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示服务提供方向注册中心注册其提供的服务以及汇报调用时间到监控中心服务器。此时间不包含网络开销服务消费方向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心。此时间包含网络开销注册中心，服务提供方以及服务消费方三者之间均为长连接，监控中心除外注册中心通过长连接感知服务提供方的存在，服务提供方宕机，注册中心将立即推送事件通知消费方注册中心和监控中心全部宕机，不影响已运行的提供方和消费方，消费方在本地缓存了提供者列表。注册中心和监控中心都是可选的，服务消费方可以直连服务提供方。

(2)健状性：监控中心宕机不影响使用，只是丢失部分采样数据数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务注册中心对等集群。任意一台注册中心宕机后，将自动切换到另一台注册中心。在注册中心全部宕机后，服务提供方和服务消费方仍能通过本地缓存进行通讯。在服务提供方宕机后，不影响使用。但是，在服务提供方全部宕机后，服务消费方应用将无法使用，并无限次重连等待服务提供方恢复。

(3)伸缩性：注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心。服务提供方无状态，可动态增加机器部署实例，注册中心将推送新的服务提供方信息给消费方。

(4)升级性：当服务集群规模进一步扩大，带动治理结构进一步升级，需要实现动态部署，进行流动计算。

联调测试性质为集成测试，其侧重点在于不同模块之间接口的正确性、各个模块之间的数据流和控制流是否按照设计实现其功能以及集成后整体功能的正确性。联调测试介于白盒、黑盒之间，可以称其为灰盒测试，其特点在于：联调测试的关注点是不同模块之间的接口。至于模块如何划分需要根据具体项目来进行有针对性地划分。

目前，相关技术在联调测试阶段无法实现分布式服务框架(例如：Dubbo)应用之间交互数据的模拟，从而增加了服务提供方的负担。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本发明至少部分实施例提供了一种请求消息的处理方法、装置、存储介质、处理器及终端，以至少解决相关技术在联调测试阶段无法实现分布式服务框架(例如：Dubbo)应用之间交互数据的模拟，从而增加了服务提供方的负担的技术问题。

根据本发明其中一实施例，提供了一种请求消息的处理方法，该方法适用于分布式服务框架接口，包括：

接收来自于发送端的请求消息，其中，请求消息中至少携带有发送端的第一标识信息；根据第一标识信息是否出现在预设白名单中的判断结果，确定对请求消息的处理方式，其中，预设白名单用于确认是否需要对发送端与接收端之间的真实交互数据进行模拟。

可选地，请求消息中至少还携带有接收端的第二标识信息，根据判断结果确定对请求消息的处理方式包括：确定第一标识信息出现在预设白名单中；按照第二标识信息将请求消息转发至接收端；接收来自于接收端的响应消息，其中，响应消息中携带有待反馈至发送端的真实交互数据；将响应消息返回至发送端。

可选地，请求消息中至少还携带有接收端的第二标识信息，根据判断结果确定对请求消息的处理方式包括：确定标识信息未出现在预设白名单中；按照第二标识信息获取接收端反馈的响应消息的格式；根据响应消息的格式生成响应消息，其中，响应消息中携带有模拟数据，模拟数据用于引导发送端执行后续正常流程；将响应消息返回至发送端。

可选地，在接收来自于发送端的请求消息之前，还包括：根据第一标识信息将本地名称修改为与发送端的名称相同；将发送端的配置信息中将接收端归属的分组修改为本地归属的分组。

根据本发明其中一实施例，还提供了一种请求消息的处理装置，该装置适用于分布式服务框架接口，包括：

接收模块，用于接收来自于发送端的请求消息，其中，请求消息中至少携带有发送端的第一标识信息；处理模块，用于根据第一标识信息是否出现在预设白名单中的判断结果，确定对请求消息的处理方式，其中，预设白名单用于确认是否需要对发送端与接收端之间的真实交互数据进行模拟。

可选地，请求消息中至少还携带有接收端的第二标识信息，处理模块包括：第一确定单元，用于确定第一标识信息出现在预设白名单中；转发单元，用于按照第二标识信息将请求消息转发至接收端；接收单元，用于接收来自于接收端的响应消息，其中，响应消息中携带有待反馈至发送端的真实交互数据；第一反馈单元，用于将响应消息返回至发送端。

可选地，请求消息中至少还携带有接收端的第二标识信息，处理模块包括：第二确定单元，用于确定标识信息未出现在预设白名单中；获取单元，用于按照第二标识信息获取接收端反馈的响应消息的格式；生成单元，用于根据响应消息的格式生成响应消息，其中，响应消息中携带有模拟数据，模拟数据用于引导发送端执行后续正常流程；第二反馈单元，用于将响应消息返回至发送端。

可选地，上述装置还包括：调整模块，用于根据第一标识信息将本地名称修改为与发送端的名称相同，以及将发送端的配置信息中将接收端归属的分组修改为本地归属的分组。

根据本发明其中一实施例，还提供了一种存储介质，存储介质包括存储的程序，其中，在程序运行时控制存储介质所在设备执行上述请求消息的处理方法。

根据本发明其中一实施例，还提供了一种处理器，处理器用于运行程序，其中，程序运行时执行上述请求消息的处理方法。

根据本发明其中一实施例，还提供了一种终端，包括：一个或多个处理器，存储器，显示装置以及一个或多个程序，其中，一个或多个程序被存储在存储器中，并且被配置为由一个或多个处理器执行，一个或多个程序用于执行上述请求消息的处理方法。

在本发明至少部分实施例中，采用接收来自于发送端的请求消息，该请求消息中至少携带有发送端的第一标识信息的方式，通过第一标识信息是否出现在预设白名单中的判断结果，确定对请求消息的处理方式，该预设白名单用于确认是否需要对发送端与接收端之间的真实交互数据进行模拟，达到了便于在联调测试阶段实现分布式服务框架应用之间交互数据模拟的目的，从而实现了减少对服务提供方的依赖、在真实交互数据与模拟数据之间进行灵活选择的技术效果，进而解决了相关技术在联调测试阶段无法实现分布式服务框架(例如：Dubbo)应用之间交互数据的模拟，从而增加了服务提供方的负担的技术问题。

附图说明

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

图1是根据相关技术的dubbo的架构示意图；

图2是根据本发明其中一实施例的请求消息的处理方法的流程图；

图3是根据本发明其中一优选实施例的请求消息的处理方法的示意图；

图4是根据本发明其中另一优选实施例的请求消息的处理方法的示意图；

图5是根据本发明其中一实施例的请求消息的处理装置的结构框图；

图6是根据本发明其中一优选实施例的请求消息的处理装置的结构框图。

具体实施方式

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

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

根据本发明其中一实施例，提供了一种请求消息的处理方法的实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图2是根据本发明其中一实施例的请求消息的处理方法的流程图，如图2所示，该方法包括如下步骤：

步骤S22，接收来自于发送端的请求消息，其中，请求消息中至少携带有发送端的第一标识信息；

步骤S24，根据第一标识信息是否出现在预设白名单中的判断结果，确定对请求消息的处理方式，其中，预设白名单用于确认是否需要对发送端与接收端之间的真实交互数据进行模拟。

通过上述步骤，可以采用接收来自于发送端的请求消息，该请求消息中至少携带有发送端的第一标识信息的方式，通过第一标识信息是否出现在预设白名单中的判断结果，确定对请求消息的处理方式，该预设白名单用于确认是否需要对发送端与接收端之间的真实交互数据进行模拟，达到了便于在联调测试阶段实现分布式服务框架应用之间交互数据模拟的目的，从而实现了减少对服务提供方的依赖、在真实交互数据与模拟数据之间进行灵活选择的技术效果，进而解决了相关技术在联调测试阶段无法实现分布式服务框架(例如：Dubbo)应用之间交互数据的模拟，从而增加了服务提供方的负担的技术问题。

上述第一标识信息可以包括但不限于：发送端的名称、发送端的互联网协议(IP)地址、用户标识。

在联调测试环节下，至少根据第一标识信息中的关键数据(例如：IP地址和用户标识)从预设白名单中查找是否存在与IP地址和用户标识对应的信息项，进而判断出返回模拟结果或应用交互产生的真实结果。例如，软件系统开发中的应用之间的调用使用到Dubbo的接口，并对Dubbo接口的返回数据存在逻辑上的处理。开发人员和测试人员在联调测试过程中需要对应用之间交互的Dubbo接口产生真实数据的进行联调和模拟Dubbo接口的返回模拟数据的测试。因此，在软件系统应用提供一个可以模拟Dubbo接口应用并且可以根据对关键数据的判断结果，反馈模拟测试数据或应用之间交互产生的真实数据。

可选地，在步骤S22，接收来自于发送端的请求消息之前，还可以包括以下执行步骤：

步骤S20，根据第一标识信息将本地名称修改为与发送端的名称相同；

步骤S21，将发送端的配置信息中将接收端归属的分组修改为本地归属的分组。

具体地，在软件系统中模拟一个相同名称(即，与接收端的名称相同)、归属不同分组的Dubbo接口应用。通过修改发送端的配置文件，将接收端归属的分组修改为Dubbo接口应用归属的分组，进而实现对发送端与模拟Dubbo接口应用产生数据的交互，模拟Dubbo接口应用可以对请求数据进行处理。Dubbo接口应用根据关键数据是否出现在预设白名单中的判断结果，确定反馈应用交互产生的真实数据或在应用交互中产生模拟数据。

可选地，上述请求消息中至少还携带有接收端的第二标识信息，在步骤S24中，根据判断结果确定对请求消息的处理方式可以包括以下执行步骤：

步骤S241，确定第一标识信息出现在预设白名单中；

步骤S242，按照第二标识信息将请求消息转发至接收端；

步骤S243，接收来自于接收端的响应消息，其中，响应消息中携带有待反馈至发送端的真实交互数据；

步骤S244，将响应消息返回至发送端。

上述第二标识信息可以包括但不限于：接收端的名称、接收端的IP地址、用户标识。

通过Web应用服务器(例如：tomcat服务器)使用Spring框架(其为一个轻量级控制反转和面向切面的容器框架)在系统中提供两个对外的dubbo接口，其分别为：模拟Dubbo接口和转发Dubbo接口。图3是根据本发明其中一优选实施例的请求消息的处理方法的示意图。如图3所示，在确定发送端的IP地址和用户标识出现在预设白名单中之后，可以先通过模拟Dubbo接口应用将请求消息发送至转发Dubbo接口应用，再由转发Dubbo接口应用将请求消息转发至接收端。在接收端对请求消息处理完毕后，会向转发Dubbo接口应用返回携带有待反馈至发送端的真实交互数据的响应消息。通过上述转发Dubbo接口应用能够解决在Spring注册过程中Dubbo接口的provider与consumer的接口不可同名的问题。

可选地，请求消息中至少还携带有接收端的第二标识信息，在步骤S24中，根据判断结果确定对请求消息的处理方式可以包括以下执行步骤：

步骤S245，确定标识信息未出现在预设白名单中；

步骤S246，按照第二标识信息获取接收端反馈的响应消息的格式；

步骤S247，根据响应消息的格式生成响应消息，其中，响应消息中携带有模拟数据，模拟数据用于引导发送端执行后续正常流程；

步骤S248，将响应消息返回至发送端。

图4是根据本发明其中另一优选实施例的请求消息的处理方法的示意图。如图4所示，在确定发送端的IP地址和用户标识出现在预设白名单中之后，则无需通过模拟Dubbo接口应用将请求消息发送至转发Dubbo接口应用，进而无需再由转发Dubbo接口应用将请求消息转发至接收端。但是，模拟Dubbo接口应用需要按照接收端的响应消息格式构造模拟数据来代替接收端向发送端返回响应消息，其不同之处在于：在上述真实交互数据中，接收端既可以向发送端返回肯定的响应结果也可以向发送端返回否定的响应结果；然而，模拟Dubbo接口应用在模拟数据中通常会向发送端返回肯定的响应结果，以便发送端继续执行后续的正常流程。

根据本发明其中一实施例，还提供了一种请求消息的处理装置的实施例，图5是根据本发明其中一实施例的请求消息的处理装置的结构框图，如图5所示，接收模块10，用于接收来自于发送端的请求消息，其中，请求消息中至少携带有发送端的第一标识信息；处理模块20，用于根据第一标识信息是否出现在预设白名单中的判断结果，确定对请求消息的处理方式，其中，预设白名单用于确认是否需要对发送端与接收端之间的真实交互数据进行模拟。

可选地，上述请求消息中至少还携带有接收端的第二标识信息，处理模块20可以包括：第一确定单元(图中未示出)，用于确定第一标识信息出现在预设白名单中；转发单元(图中未示出)，用于按照第二标识信息将请求消息转发至接收端；接收单元(图中未示出)，用于接收来自于接收端的响应消息，其中，响应消息中携带有待反馈至发送端的真实交互数据；第一反馈单元(图中未示出)，用于将响应消息返回至发送端。

可选地，上述请求消息中至少还携带有接收端的第二标识信息，处理模块20可以包括：第二确定单元(图中未示出)，用于确定标识信息未出现在预设白名单中；获取单元(图中未示出)，用于按照第二标识信息获取接收端反馈的响应消息的格式；生成单元(图中未示出)，用于根据响应消息的格式生成响应消息，其中，响应消息中携带有模拟数据，模拟数据用于引导发送端执行后续正常流程；第二反馈单元(图中未示出)，用于将响应消息返回至发送端。

可选地，图6是根据本发明其中一优选实施例的请求消息的处理装置的结构框图，如图6所示，上述装置还可以包括：调整模块30，用于根据第一标识信息将本地名称修改为与发送端的名称相同，以及将发送端的配置信息中将接收端归属的分组修改为本地归属的分组。

根据本发明其中一实施例，还提供了一种存储介质，存储介质包括存储的程序，其中，在程序运行时控制存储介质所在设备执行上述请求消息的处理方法。上述存储介质可以包括但不限于：U盘、只读存储器(ROM)、随机存取存储器(RAM)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

根据本发明其中一实施例，还提供了一种处理器，处理器用于运行程序，其中，程序运行时执行上述请求消息的处理方法。上述处理器可以包括但不限于：微处理器(MCU)或可编程逻辑器件(FPGA)等的处理装置。

根据本发明其中一实施例，还提供了一种终端，包括：一个或多个处理器，存储器，显示装置以及一个或多个程序，其中，一个或多个程序被存储在存储器中，并且被配置为由一个或多个处理器执行，一个或多个程序用于执行上述请求消息的处理方法。在一些实施例中，上述终端可以是台式电脑、平板电脑、笔记本电脑以及移动互联网设备(MobileInternet Devices，简称为MID)等终端设备。上述显示装置可以是触摸屏式的液晶显示器(LCD)，该液晶显示器可使得用户能够与终端的用户界面进行交互。此外，上述终端还可以包括：输入/输出接口(I/O接口)、通用串行总线(USB)端口、网络接口和/或电源。

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

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (11)

1.一种请求消息的处理方法，其特征在于，所述方法适用于分布式服务框架接口，包括：

接收来自于发送端的请求消息，其中，所述请求消息中至少携带有所述发送端的第一标识信息；

根据所述第一标识信息是否出现在预设白名单中的判断结果，确定对所述请求消息的处理方式，其中，所述预设白名单用于确认是否需要对所述发送端与接收端之间的真实交互数据进行模拟。

2.根据权利要求1所述的方法，其特征在于，所述请求消息中至少还携带有所述接收端的第二标识信息，根据所述判断结果确定对所述请求消息的处理方式包括：

确定所述第一标识信息出现在所述预设白名单中；

按照所述第二标识信息将所述请求消息转发至接收端；

接收来自于所述接收端的响应消息，其中，所述响应消息中携带有待反馈至所述发送端的真实交互数据；

将所述响应消息返回至所述发送端。

3.根据权利要求1所述的方法，其特征在于，所述请求消息中至少还携带有所述接收端的第二标识信息，根据所述判断结果确定对所述请求消息的处理方式包括：

确定所述标识信息未出现在所述预设白名单中；

按照所述第二标识信息获取所述接收端反馈的响应消息的格式；

根据所述响应消息的格式生成响应消息，其中，所述响应消息中携带有模拟数据，所述模拟数据用于引导所述发送端执行后续正常流程；

将所述响应消息返回至所述发送端。

4.根据权利要求1所述的方法，其特征在于，在接收来自于所述发送端的所述请求消息之前，还包括：

根据所述第一标识信息将本地名称修改为与所述发送端的名称相同；

将所述发送端的配置信息中将所述接收端归属的分组修改为本地归属的分组。

5.一种请求消息的处理装置，其特征在于，所述装置适用于分布式服务框架接口，包括：

接收模块，用于接收来自于发送端的请求消息，其中，所述请求消息中至少携带有所述发送端的第一标识信息；

处理模块，用于根据所述第一标识信息是否出现在预设白名单中的判断结果，确定对所述请求消息的处理方式，其中，所述预设白名单用于确认是否需要对所述发送端与接收端之间的真实交互数据进行模拟。

6.根据权利要求5所述的装置，其特征在于，所述请求消息中至少还携带有所述接收端的第二标识信息，所述处理模块包括：

第一确定单元，用于确定所述第一标识信息出现在所述预设白名单中；

转发单元，用于按照所述第二标识信息将所述请求消息转发至接收端；

接收单元，用于接收来自于所述接收端的响应消息，其中，所述响应消息中携带有待反馈至所述发送端的真实交互数据；

第一反馈单元，用于将所述响应消息返回至所述发送端。

7.根据权利要求5所述的装置，其特征在于，所述请求消息中至少还携带有所述接收端的第二标识信息，所述处理模块包括：

第二确定单元，用于确定所述标识信息未出现在所述预设白名单中；

获取单元，用于按照所述第二标识信息获取所述接收端反馈的响应消息的格式；

生成单元，用于根据所述响应消息的格式生成响应消息，其中，所述响应消息中携带有模拟数据，所述模拟数据用于引导所述发送端执行后续正常流程；

第二反馈单元，用于将所述响应消息返回至所述发送端。

8.根据权利要求5所述的装置，其特征在于，所述装置还包括：

调整模块，用于根据所述第一标识信息将本地名称修改为与所述发送端的名称相同，以及将所述发送端的配置信息中将所述接收端归属的分组修改为本地归属的分组。

9.一种存储介质，其特征在于，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行权利要求1至4中任意一项所述的请求消息的处理方法。

10.一种处理器，其特征在于，所述处理器用于运行程序，其中，所述程序运行时执行权利要求1至4中任意一项所述的请求消息的处理方法。

11.一种终端，其特征在于，包括：一个或多个处理器，存储器，显示装置以及一个或多个程序，其中，所述一个或多个程序被存储在所述存储器中，并且被配置为由所述一个或多个处理器执行，所述一个或多个程序用于执行权利要求1至4中任意一项所述的请求消息的处理方法。