CN116567090A - 一种服务数据传输方法、系统、电子设备及存储介质 - Google Patents

Abstract

本方案涉及一种服务数据传输方法、系统、电子设备及存储介质，该方法包括：接收服务消费端发送的服务消费请求，获取所述服务消费请求中的包头信息；根据所述包头信息将所述服务消费请求转发给与所述服务消费请求对应的服务提供端，以使服务提供端处理接收的所述服务消费请求得到返回包并将所述返回包反馈给路由转发中心；接收所述返回包，并将所述返回包发送给所述服务消费端。本发明实施例解决了传统DUBBO组件数据传输方法传输通道复杂，防火墙规则复杂的问题，可应用于信息技术领域。

Description

一种服务数据传输方法、系统、电子设备及存储介质

技术领域

本发明涉及信息技术领域，具体涉及一种服务数据传输方法、系统、电子设备及存储介质。

背景技术

随着互联网的发展，企业的应用规模不断扩大，常规的垂直架构已经无法适应，分布式服务架构已普遍应用，目前应用广泛的分布式服务架构包括DUBBO组件，DUBBO服务提供端在注册中心注册服务，注册中心在接收到注册请求之后，根据接口类缓存该注册中心；服务提供端向注册中心订阅服务，注册中心在接收到订阅请求之后，根据接口类查找该订阅服务对应的提供者地址，并将提供者地址列表推送给该消费者；服务提供端在收到推送的提供者列表之后，与每个提供者建立连接通道，消费者发起服务消费请求时，就通过对应的连接通道将请求发送给服务提供端，服务提供端再将处理结果通过原路返回给消费者。

可以看出DUBBO组件是去中心化的，消息交互是网状的。DUBBO服务的消费者与提供者之间，会建立长连接，在复杂网络中，需要开通消费者与提供者之间的防火墙。在大型企业中，应用的数量会有几十甚至几百个，部署的实例数往往会达到几千甚至更多，应用的迭代升级将会非常频繁，而服务的变动和服务器增减，都将会导致相关防火墙开通或关闭，一个服务的变动，都有可能导致影响到N条防火墙规则的变动，服务提供端的变动就会比较频繁而导致服务消费端和服务提供端之间的数据传输通道网络复杂而导致防火墙规则变得复杂，增加工作人员的运维难度，一旦有防火墙规则的遗漏，就会导致DUBBO服务的消费异常。

采用去中心化的传统DUBBO服务的数据传输办法还存在因对服务器的吞吐量高而浪费服务器资源，因完成过程复杂而导致效率低下。

发明内容

本发明的目的在于解决现有技术中存在的技术问题。为此，本发明提出一种服务数据传输方法、系统、电子设备及存储介质，简化服务消费端和服务提供端之间的数据传输通道网络而使防火墙规则变得简单，提高数据传输效率。

本发明第一方面提供了一种服务数据传输方法，应用于路由转发中心，包括：

接收服务消费端发送的服务消费请求，获取所述服务消费请求中的包头信息；所述包头信息包括服务特征码信息。

根据所述包头信息将所述服务消费请求转发给与所述服务消费请求对应的服务提供端，以使服务提供端处理接收的所述服务消费请求得到返回包并将所述返回包反馈给路由转发中心。

接收所述返回包，并将所述返回包发送给所述服务消费端。

可选地，所述服务消费请求包括包头和包体，所述获取所述服务消费请求中的包头信息，具体包括：

将所述服务消费请求按照第一预设规则进行解码，获得所述服务消费请求的包头和包体。

将所述包头按照第二预设规则进行解码，得到包头信息；所述包头包括包头信息和包体的特征信息。

可选地，所述根据所述包头信息将所述服务消费请求转发给与所述服务消费请求对应的服务提供端，具体包括：

将所述服务特征码信息与预设的路由配置信息进行匹配，找到与所述服务消费请求对应的服务提供端。

将所述服务消费请求根据负载均衡策略发送给所述对应的服务提供端。

其中，所述路由配置信息包括所有服务提供端提供服务的服务特征码信息。

为了解决上述问题，本发明第二方面提供了一种服务数据传输方法，应用于注册中心，包括：

获取所有服务提供端的注册信息，根据所述注册信息确定所有服务的服务提供端地址列表；所述注册信息包括服务特征码信息；

将所述服务提供端地址列表按照预设格式封装成同步文件，并将所述同步文件发送给路由转发中心，以使所述路由转发中心根据所述同步文件更新路由配置信息。

可选地，所述方法还包括：

根据所述注册信息校验所述服务提供端的合法性。

若合法性校验通过，将服务提供端的注册信息进行封装。

否则，放弃将服务提供端的注册信息进行封装。

可选地，所述方法还包括：

接收服务消费端发送的订阅服务请求；所述订阅服务请求包括服务信息和服务消费端的地址。

根据所述服务信息和服务提供端地址列表确定服务提供端的地址。

根据服务提供端的地址和服务消费端的地址确定路由转发中心地址。

将所述路由转发中心地址发送给服务消费端。

本发明第二方面所述方法还包括：

根据所述订阅服务请求校验所述服务消费端服务的合法性。

若合法性校验通过，开始执行确定服务提供端的地址。

为了解决上述问题之一，本发明第三方面提供一种服务数据传输系统，包括路由转发中心以及与所述路由转发中心连接的服务消费端和服务提供端，包括：

服务消费端，用于发送服务消费请求，以及接收返回包；

路由转发中心，用于接收所述服务消费请求，并获取所述服务消费请求中的包头信息，根据所述包头信息将所述服务消费请求转发给服务消费端中与服务消费请求对应的服务提供端；

服务提供端，用于接收并处理所述服务消费请求得到返回包，将返回包通过所述路由转发中心发送给所述服务消费端。

为了解决上述问题之一，本发明第四方面提供了一种服务数据传输系统，包括：

服务消费端，用于发送服务消费请求，以及接收返回包；

路由转发中心，用于接收所述服务消费请求，并获取所述服务消费请求中的包头信息；根据所述包头信息将所述服务消费请求转发给服务消费端中与服务消费请求对应的服务提供端；

服务提供端，用于接收并处理所述服务消费请求，根据所述服务消费请求将返回包通过所述路由转发中心发送给所述服务消费端。

为了解决上述问题之一，本发明第四方面一种电子设备，所述电子设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现前述任一方法。

为了解决上述问题之一，本发明第五方面提供了一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序或计算机指令，当所述计算机程序或计算机指令被处理器运行时，实现前述任一方法。

本发明的有益效果如下：本发明通过在服务消费端和服务提供端之间增加了一个路由转发中心，路由转发中心接收服务消费端发送的服务消费请求，获取服务消费请求中的包头信息；根据包头信息将服务消费请求转发给与所述服务消费请求对应的服务提供端，服务提供端处理接收的服务消费请求得到返回包并将返回包反馈给路由转发中心；接收返回包，并将返回包发送给服务消费端，完成服务数据的传输。该方案使服务提供端和服务消费端的服务器增减，只与该路由转发中心有关，与服务提供端无关。另外通过这个网络结构的转变，将原先的每个服务的变动和服务器的增减，都将影响M(受影响的服务提供端数量)+N(受影响的服务提供端数量)条防火墙规则的变动，优化成只影响一条防火墙规则的变动，简化服务消费端和服务提供端之间的数据传输通道网络而使防火墙规则变得简单，降低工作人员的运维难度，在服务需求高峰期消费正常，服务器资源浪费，提高了提供服务的效率。

附图说明

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

图1是本发明实施例提供的一种服务数据传输的结构示意图；

图2是本发明实施例提供的一种服务数据传输方法的流程图；

图3是本发明实施例提供的一种服务消费请求的数据格式示意图；

图4是本发明实施例提供的一种注册中心为服务提供端提供注册的流程图；

图5是本发明实施例提供的一种注册中心与路由转发中心信息同步功能的流程示意图；

图6是本发明实施例提供的一种服务提供端向注册中心注册的流程图；

图7是本发明实施例提供的一种注册中心接受服务提供端订阅服务的流程图；

图8是本发明实施例提供的一种服务数据传输方法路由转发中心处理数据的示意图；

图9是本发明实施例提供的一种服务数据传输系统的结构示意图；

图10是本发明实施例提供的一种电子设备的结构示意图。

具体实施方式

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

需要说明的是，虽然在装置示意图中进行了功能模块划分，在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于装置中的模块划分，或流程图中的顺序执行所示出或描述的步骤。说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。需要说明的是本方案提供的各实施例之间的技术方案可以相互使用。

为了更好的理解本发明，实施例基于DUBBO组件对本发明的技术方案进行解释说明，该方法也可以基于其他分布式架构实现服务数据传输，现对相关概念进行描述。

开源分布式服务架构DUBBO组件：是目前常见的微服务架构的基础框架，相对于另一种常见的微服务架构spring cloud，DUBBO组件在性能上是其两倍。DUBBO是阿里巴巴公司开源的一个高性能优秀的服务框架，它使得应用可通过高性能的远程调用(RemoteProcrdure Call，RPC)实现服务的输出和输入功能，可以和Spring框架无缝集成。DUBBO是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及面向服务架构(Service-Oriented Architecture，SOA)服务治理方案。

吞吐量：是指对网络、设备、端口、虚电路或其他设施在单位时间内成功的传输数据的数量，以比特、字节、分组等为测量单位计量。

负载均衡：分为软件负载均衡和硬件负载均衡，是建立在现有网络之上，它提供了一种廉价有效透明的方法扩展网络设备和服务的宽带、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。负载均衡的意思是分摊到多个操作单元上执行，从而完成工作任务。

变动服务器与路由转发中心的防火墙策略：在未引入路由转发中心前，原每个服务的变动和中心变动服务器的增减，都将影响M(受影响的服务提供端数量)+N(受影响的服务提供端数量)条防火墙规则的变动。引入路由转发中心之后，服务的变动、路由转化中心的增减都不影响防火墙规则或只影响一条防火墙规则的变动。假设变动的服务有M个提供者，有N个消费者；变动的服务器上部署的应用，有X个服务提供端，有Y个服务提供端，在引入路由转发中心之前，N个服务提供端变动和M个服务提供端变动发生变动，有(X*N+Y*M)个中心服务器发生变动，引入路由转发中心之后，服务提供端变动和服务提供端都不发生变动，只有一个服务器会发生变动。

系统说明：请参见图1，图1是为本发明系统的简要示意图，图中字母A表示服务消费端，字母B表示服务提供端。本发明所述的方法的实施系统包括消费服务端、路由转发中心、服务提供端，路由转发中心与服务消费端连接，双向通信；路由转发中心与服务提供端连接，双向通信；服务消费者与服务提供者之间不直接通信，在DUBBO服务的消费者与提供者之间增加一个路由转发中心，承当转发和承接功能。

系统调用服务时，消费者发起的所有的DUBBO服务请求，都会发送到该路由转发中心，再由该路由转发中心转发给对应的DUBBO服务提供者。服务提供端的数据返回包也会反馈给路由转发中心，由路由转发中心将返回包发送给服务消费端。

为了解决上述问题，本发明一些实施例提供一种服务数据传输方法，旨在简化服务消费端和服务提供端之间的数据传输通道网络而使防火墙规则变得简单，降低工作人员的运维难度，保证DUBBO服务在服务需求高峰期消费正常，提高了提供服务的效率。如图2所示，图2是基于DUBBO组件的数据传输方法地流程图，方法包括以下步骤：

S110、接收服务消费端发送的服务消费请求。

S120、获取所述服务消费请求中的包头信息；所述包头信息包括服务特征码信息；

S130、根据所述包头信息将所述服务消费请求转发给与所述服务消费请求对应的服务提供端，以使服务提供端处理接收的所述服务消费请求得到返回包并将所述返回包反馈给路由转发中心；

S140、接收所述返回包，并将所述返回包发送给所述服务消费端。

上述服务特征码信息包括服务的服务编码和服务的版本号。

上述服务消费端可以为任何一个需要消费服务的设备，包括个人电脑、笔记本电脑和手机等移动终端，服务提供端可以为任何一个提供服务的设备，可以包括但不限于个人电脑、笔记本电脑和手机等移动终端和服务器。

上述路由转发中心包含至少一个路由转发设备或至少一级路由转发设备，所述路由转发设备包括硬件设备和软件设备。所述路由转发中心的路由转发设备中存储有服务提供端的地址列表、各个路由转发设备的地址列表、路由设备的对外接口地址(即路径地址)以及服务类型。其中服务提供端的地址列表、各个路由转发设备的地址列表以及服务类型以一一映射的关系存储，形成调用数据包的路由路径，不同的路由转发路径可以根据改变控制手段以及路径的地址来设置。方便路由转发中心在根据注册中心转发过来的服务提供端的注册信息对路由配置信息进行更新和方便注册中心查阅路由转发中心提供服务提供端所需服务的供应地址。

具体地，路由转发中心承当转发和调用的功能，服务消费端在需要服务时，执行以下步骤：接收服务消费端发送的服务消费请求；获取所述服务消费请求中的包头信息；所述包头信息包括服务特征码信息。所述服务消费请求包含了请求服务的请求包，所述请求包包括包头和包体。

DUBBO的底层通信是利用JAVA开源框架netty来实现的，相对于超文本传输协议(Hyper Text Transfer Protocol，HTTP)实现数据包传输，无请求行信息，数据在服务消费端和服务提供端传输时，服务提供端必须先读取整个DUBBO的请求包内容，再反编译整个请求包的包体部分信息，获取消费的服务信息后再确定该服务的转发路由路径，不仅效率很低，而且还对负载均衡设备或软件的服务器资源消耗很大，进而影响其吞吐量。

为了解决上述问题，避免路由转发中心成为整个微服务架构的性能瓶颈，本发明修改了DUBBO组件的编解码功能，在DUBBO服务的服务消费请求的数据包的包头中增加了被消费的服务的编码和版本号等服务特征码信息。

具体实施方法为步骤120、获取所述服务消费请求中的包头信息具体包括以下步骤：

S121、将所述服务消费请求按照第一预设规则进行解码，获得所述服务消费请求的包头和包体；所述包头包括包头信息和包体的特征信息。

S122、将所述包头按照第二预设规则进行解码，得到包头信息。

具体地，如图3所示，图3是服务消费请求的数据格式示意图；服务消费请求包含TCP/IP协议和数据包两部分，Dubbo网络通讯协议的数据包又分为两部分，分别是包头(Header)和包体(Body)，Header部分采用Codec编码和解码，Body部分使用序列化。

服务提供端发起服务消费请求时，对服务消费请求进行编码：将被消费服务的请求信息序列化成一个字节流，放在Body中。将被消费的服务信息、序列化标志和消息类型、序列化后的请求消息Body长度信息、请求ID等信息，则通过Codec编码成为定长的字节数组，放入Header中。在网络传输时，该数据包又会添加TCP/IP协议形成服务消费请求。

解码时，首先，根据第一预设规则对服务消费请求进行解码，例如，先根据TCP/IP协议得到服务消费请求，对服务消费请求进行解码，得到包头和包体；然后，将所述包头按照第二预设规则进行解码，得到包头信息，例如，得到包头之后，再利用Codec对包头进行解码，得到定长的字节数组。

由此可见包头包含了包头信息和包体的特征信息、请求ID等，所述包头信息除了包含序列化标志和消息类型、序列化后的消息Body长度信息、请求ID等信息，还包括消费的服务的编码和版本号等被消费的服务信息。

包体的特征信息包括但不限于序列化标志和消息类型、序列化后的消息Body长度信息。

包头信息还可以包含其他可以代表服务以及服务提供端身份和特征的信息，比如提前预设的具有映射关系的服务提供端的特征与标号等，在此不做限制。

在本方案的一些实施例中，步骤S130根据所述包头信息将所述服务消费请求转发给与所述服务消费请求对应的服务提供端，具体包括：

S131、将所述服务特征码信息与预设的路由配置信息进行匹配，找到与所述服务消费请求对应的服务提供端；

S132、将所述服务消费请求根据负载均衡策略发送给所述对应的服务提供端。

上述路由配置信息包括但不限于调用服务的路由路径、服务的类型以及服务编码、服务的版本号、服务提供端的地址列表、路由策略、路由转发中心路由设备的地址列表以及路由设备的转发路径、服务消费端的地址列表等，路由配置信息以映射关系缓存在路由转发中心，方便查询和调阅。

具体地，在获取到包含了消费的服务的编码和版本号的消费信息之后，利用该消费信息与缓存在路由转发中心的路由配置信息进行比对，路由转发中心根据被消费的服务的编码和服务版本号确认服务提供端需要的服务，在以服务为单位的服务提供端的地址列表中找出提供与服务提供端所需服务对应的服务提供端。路由转发中心再根据负载均衡策略，包括但不限于随机、轮训策略、基于一致性hash的负载均衡策略、基于最少活跃数的轮询负载均衡策略等，将服务消费请求转发给对应的服务提供端。服务提供端收到该请求之后，处理该请求，并将返回包通过路由转换中心返回给服务提供端。

所述处理该请求包括但不限于解析请求，获得服务的信息和服务提供端的身份信息，验证服务的合法性、确认该服务的服务提供端提供是否正确等。

返回包的内容包括但不限于服务提供端请求获得的消费数据。

上述随机策略是指从已有的后端路径列表中随机选择一个路径出来提供服务，随机策略的缺点是随机性比较强，增加了两个服务请求在同一界面上发生碰撞的概率，在非对等集群组网，或者硬件配置差异较大时，各节点负载不均匀，可以通过加权随机进行提升。

上述轮训策略的优点为实现简单，容易水平扩展，且比较均衡分发到所有路径。缺点为无法知道所有的路径的情况。

轮训策略又分为轮询选择和带权重的轮询选择，其中轮询选择指的是从已有的后端路径列表中按顺序依次选择一个路径出来提供服务。一种轮询选择的方法是把所有的路径比做一个一个的点，并把这些点连起来组成一个圆，轮询选择就是在这个圆上按顺时针选择一个点，即选择一条提供服务的路径，可以通过用请求次数取模来实现这个顺时针选择的功能。

带权重的轮询选择是指在使用中各个路劲往往都带有不同的权重，所以一般都需要实现带权重的轮询选择。权重高的被选中的次数多，权重低的被选中的次数少。

可以把带权重信息的节点排成一个圆，不过根据不同的权重把对应的节点重复不同的次数，即将不同权重的路径重复不同的次数。然后还是顺时针选择一个点，每个节点根据权重重复了相应的次数，所以不同权重的节点被选中的次数也不一样并且选中的次数跟它本身的权重有关，这样就简单实现了带权重的轮询选择。

本发明实施例还提供了一种服务数据传输方法，如图4所示，图4是注册中心为服务提供端提供注册的流程图；该方法应用于注册中心，包括以下步骤：

S210、获取所有服务提供端的注册信息，根据所述注册信息确定所有服务的服务提供端地址列表；所述注册信息包括服务特征码信息；

S230、将所述服务提供端地址列表按照预设格式封装成同步文件，并将所述同步文件发送给路由转发中心，以使所述路由转发中心根据所述同步文件更新路由配置信息。

本发明提供的一些实施例在注册中心和路由转发中心之间，增加了路由配置信息自动同步功能。如图5所示，图5是注册中心与路由转发中心信息同步功能的流程示意图；在注册中心接收到服务提供端的注册信息之后，注册中心以服务为单位，收集每个服务的服务提供端地址列表等注册信息，更新本地的服务和对应于该服务的提供者注册信息；会将注册变动的服务及该服务的所有服务提供端注册信息，生成一个同步文件，发送给路由转发中心，路由转发中心在接收到该同步文件之后，就会读取里面的转发策略信息，与本地缓存的转发策略信息进行比对，如果不一致，就会用新同步过来的转发策略更新本地缓存，实现了路由转发中心的策略自动更新功能。

其中，与本地缓存的转发策略信息进行比对的方法可以但不限于包括：将所述服务提供端的第一地址列表与缓存在所述路由转发中心的第二地址列表进行匹配，当所述第一地址列表与所述第二地址列表匹配失败时，根据所述注册信息更新所述路由配置信息。

所述注册信息包括所述服务提供端的第一地址列表，第一地址列表包含了服务提供端的版本型号、ID、地址以及所能提供的服务、服务的服务编码、版本等信息。

上述第一地址列表为注册中心接收到服务提供端注册信息后，根据注册信息更新缓存在注册中心上原有的地址列表得到的包含了所有提供服务的服务提供端的地址列表。

上述第二地址列表指的是未接收注册中心发送的同步文件之前存储在路由转发中心的服务提供端的地址列表，该第二地址列表包含了所有在先注册过的服务提供端的地址列表，但不包括新注册的服务提供端的地址列表。

上述的服务数据传输方法在步骤S230之前还包括：

S220、根据所述注册信息校验所述服务提供端的合法性；若合法性校验通过，将服务提供端的注册信息进行封装；否则，放弃将服务提供端的注册信息进行封装。

注册中心可以通过验证服务提供端注册信息是否正确，注册信息是否完整来验证服务提供端的合法性，可以通过在注册请求中添加特定的标识，注册中心可以通过标识来验证服务提供端的合法性。

如图6所示，图6为服务提供端向注册中心注册的流程图。在本发明提供的一些实施例中所述方法的步骤S220还可以包括：校验通过时，将服务提供端的注册信息缓存在注册中心；当校验不通过时，注册中心分析校验失败的原因，返回注册失败信息给服务提供端，所述注册失败信息包括失败原因、服务提供端的注册信息等。

在通过校验时，将服务提供端的注册信息缓存在注册中心有助于避更新注册中心的注册信息，也可以避免服务提供端重复注册。

在本方案的一些实施例中，服务数据传输方法还包括服务提供端向注册中心订阅服务，服务提供端向注册中心订阅服务包括：

S240、接收服务消费端发送的订阅服务请求；

S260、根据所述服务信息和服务提供端地址列表确定服务提供端的地址；

S270、根据服务提供端的地址和服务消费端的地址确定路由转发中心地址；

S280、将所述路由转发中心地址发送给服务消费端。

所述订阅服务请求包括服务信息和服务消费端的地址；

具体地，在步骤S260之前，所述服务提供端向注册中心订阅服务还包括：

S250、根据所述订阅请求校验所述订阅服务的合法性，若校验通过，根据所述订阅服务查询对应的服务提供端；根据所述对应的服务提供端和服务提供端确定完成服务需要经过的路由转发中心地址；将所述需要经过的路由转发中心地址推送给服务提供端。

上述路由转发中心的地址包括路由路径和路由设备的地址，具体可以根据服务提供端和服务提供端的的地址、ID、型号、版本等信息综合选择。

在注册中心以服务为单位缓存服务提供端的地址列表，通过订阅请求中要求订阅的服务找到对应服务单位下的服务提供端。在根据所述订阅服务查询对应的服务提供端时，判断是否有提供满足服务提供端需求的服务的服务提供端，若有，则将所述需要经过的路由转发中心地址推送给服务提供端。

在本技术方案中DUBBO组件支持的注册中心包括：Multicast注册中心、Zookeeper注册中心、Redis注册中心、Simple注册中心。

注册中心负责服务地址的注册与查找，相当于目录服务，注册中心不转发请求，也不负责调用服务，压力较小。

注册中心为对等集群，可动态增加机器部署实例，所有服务提供端和服务提供端将自动发现新的注册中心；服务提供端无状态，可动态增加机器部署实例，新增的服务提供端在注册中心注册成功后，注册中心将推送新的服务提供端信息给消费者。

如图7所示，图7是注册中心接受服务提供端订阅服务的流程图；在本发明提供的一些实施例中，所述方法的步骤250还可以包括：若校验不通过，注册中心向服务提供端返回订阅失败信息，提示服务提供端订阅失败。

步骤260还可以包括：判断是否有对应的服务提供端，若有，开始根据服务提供端的地址和服务消费端的地址确定路由转发中心地址；若没有，返回订阅失败信息给服务提供端，提示消费者订阅失败。

订阅失败的信息可以包括但不限于失败提醒、订阅失败的原因以及解决办法。

在本方案一些实施例中，本方案提供一种服务数据传输方法，该所述方法应用于一种包括服务提供端、路由转发中心和服务提供端的系统，包括：

S310、服务消费者向路由转发中心发送服务消费请求。

S320、路由转发中心接收所述服务消费请求，获取所述服务消费请求中的包头信息。

S330、路由转发中心根据所述包头信息将所述服务消费请求转发给与服务消费请求对应的服务提供者。

S340、所述服务提供者接收并处理所述服务消费请求，根据所述服务消费请求将返回包通过所述路由转发中心发送给所述服务消费者。

如图8所示，图8为路由转发中心处理数据的示意图；路由转发中心在收到服务消费端向路由转发中心发送服务消费请求之后，先读取包头信息，从包头信息的指定位置获取服务消费请求所请求服务的服务编码和服务版本，例如从图8所示的位置读取到一项服务的服务编码为XXX.2.XX和服务版本为V2，将读取到的服务编码XXX.2.XX和服务版本V2与注册中心同步过来的服务注册信息进行匹配，前述服务注册信息缓存在如图8所示的表格中。在找到该请求的提供者列表之后，路由转发中心再根据负载均衡策略，如随机、轮训策略等，将服务消费请求转发给对应的服务提供端。服务提供端收到该请求之后，处理该请求，并将返回包按原路返回给消费端。

上述负载均衡策略、注册信息等技术名词与前述一些实施例的技术名词解释相同，在此不再赘述。

为了解决上述问题之一，本方案一些实施例提供了一种服务数据传输系统，用于实现一些实施例所述的方法，如图9所示，图9是基于DUBBO组件的服务数据传输系统的结构示意图。

所述系统包括：消费服务端、路由转发中心、服务提供端、注册中心、监控中心。

服务消费端，用于发送服务消费请求；还用于接收返回包。

路由转发中心，用于接收所述服务消费请求，并获取所述服务消费请求中的包头信息；根据所述包头信息将所述服务消费请求转发给服务消费端中与服务消费请求对应的服务提供端。

服务提供端，用于接收并处理所述服务消费请求得到返回包，将返回包通过所述路由转发中心发送给所述服务消费端。

上述服务消费端包括至少两个以上的服务提供端，服务提供端包括至少两个以上的服务提供端，路由转发中心可以包括至少一个路由转发设备，所述路由转发设备包括硬件设备和软件设备。

在本方案的一些实施例中，路由转发中心具体用于解析数据包获得所述包头信息，从包头信息中获得服务信息，将所述服务信息与存储在所述路由转发中心的所述服务提供端的路由配置信息进行匹配，找到与所述服务消费请求对应的服务提供端中具体的服务提供端；

路由转发中心具体用于将所述服务消费请求根据负载均衡策略发送给所述对应的服务提供段端。

在本方案提供的一些实施例中，注册中心用于获取所述提供端注册信息，将所述注册信息发送给所述路由转发中心。

所述路由转发中心还用于根据所述注册信息更新路由配置信息。

注册中心具体用于接收所述服务提供端发送的注册请求，根据所述注册请求校验所述服务提供端的合法性；校验通过时，将所述服务提供端的注册信息封装为一个同步文件，所述注册中心将所述同步文件发送给所述路由转发中心。注册中心具体还用于验证消费提供端的合法性，校验通过时，将来自于服务提供端的注册信息缓存在注册中心；校验不通过时，注册中心还用于分析校验失败的原因，返回注册失败信息给服务提供端。

路由转发中心具体用于接收并解析所述同步文件得到所述注册信息，将所述服务提供端的第一地址列表与缓存在路由转发中心的第二地址列表进行匹配，当所述第一地址列表与所述第二地址列表匹配失败时，根据所述注册信息更新所述路由配置信息。

在本方案提供的一些实施例中，注册中心还用于向消费服务端提供订阅服务功能，根据服务消费端订阅的服务将完成所述服务的路由转发中心地址推送给所述服务消费端。

注册中心具体用于接收所述服务消费端的订阅请求；根据所述订阅请求校验所述订阅服务的合法性，若校验通过，根据所述订阅服务在服务提供端中查询的服务提供端；若校验不通过，注册中心向服务消费端返回订阅失败信息，提示服务提供端订阅失败。

注册中心具体用于查询服务提供端所订阅的服务的服务提供端，判断是否有对应的服务提供端，若有，确定完成服务所需要经过的路由转发中心的地址，将路由转发中心的地址发送给服务提供端；若没有，返回订阅失败信息给服务提供端，提示消费者订阅失败。

在本方案提供的一些实施例中，注册中心还用于向所述服务消费端提供订阅服务，根据所述订阅服务将服务地址推送给所述服务消费端。

具体所实现的方法和相关的名词解释与前述具体阐述相同，在此不再赘述。

在本方案提供的一些实施例中，监控中心用于统计各服务调用次数，调用时间等。

上述注册中心和监控中心可以部署在同一台服务器上，也可以更改配置，部署在不同的服务器上。

所述服务消费端、服务提供端和注册中心实行动态连接和动态加入的原则，服务提供端的具体的服务提供端通过注册中心可以动态地把自己暴露给其他服务消费端的需要服务的服务提供端，无须服务提供端逐个去更新配置文件，寻找服务提供端。

服务消费端实行发现动态发现原则，服务提供端可以动态地搜索新的配置、路由配置规则和新的服务提供端，无须重启服务使之生效。

注册中心支持参数的动态调整，新参数自动更新到所有相关服务节点。

为了解决上述问题之一，本发明一些实施例提供了一种电子设备，如图10所示，图10是一种电子设备的结构示意图，所述电子设备包括1000存储器和2000处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现本发明上述任一种方法。

为了解决上述问题之一，本发明一些实施例提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序或计算机指令，当所述计算机程序或计算机指令被处理器运行时，实现本发明上述方法。

为了验证上述方法的可行性，本发明对本方案的技术方案进行性能测试，测试环境说明：测试服务器均为4C8G的虚机，提供者和消费者数量都是1个，并处于同一个千兆局域网内。

表1为该方案的测试结果，从表格可以看出相对于服务提供端与服务提供端直接进行长连接完成服务，在服务提供端和服务提供端之间增加路由转发中心，由路由转发中心在二者之间完成服务的调用，在数据包和返回包大小相同的情况下，可以降低服务器的吞吐量。

表1

/>

表格中的nginx是一个高性能的HTTP和反向代理web服务器。

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

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、设备中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。

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

应当理解，在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。

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

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

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

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

以上参照附图说明了本申请实施例的优选实施例，并非因此局限本申请实施例的权利范围。本领域技术人员不脱离本申请实施例的范围和实质内所作的任何修改、等同替换和改进，均应在本申请实施例的权利范围之内。

Claims (10)

1.一种服务数据传输方法，其特征在于，应用于路由转发中心，包括：

接收服务消费端发送的服务消费请求，获取所述服务消费请求中的包头信息；所述包头信息包括服务特征码信息；

根据所述包头信息将所述服务消费请求转发给与所述服务消费请求对应的服务提供端，以使服务提供端处理接收的所述服务消费请求得到返回包并将所述返回包反馈给路由转发中心；

接收所述返回包，并将所述返回包发送给所述服务消费端。

2.根据权利要求1所述的方法，其特征在于，所述服务消费请求包括包头和包体，所述获取所述服务消费请求中的包头信息，具体包括：

将所述服务消费请求按照第一预设规则进行解码，获得所述服务消费请求的包头和包体；

将所述包头按照第二预设规则进行解码，得到包头信息；所述包头包括包头信息和包体的特征信息。

3.根据权利要求1所述的方法，其特征在于，所述根据所述包头信息将所述服务消费请求转发给与所述服务消费请求对应的服务提供端，具体包括：

将所述服务特征码信息与预设的路由配置信息进行匹配，找到与所述服务消费请求对应的服务提供端；

将所述服务消费请求根据负载均衡策略发送给所述对应的服务提供端；

其中，所述路由配置信息包括所有服务提供端提供服务的服务特征码信息。

4.一种服务数据传输方法，其特征在于，应用于注册中心，包括：

获取所有服务提供端的注册信息，根据所述注册信息确定所有服务的服务提供端地址列表；所述注册信息包括服务特征码信息；

将所述服务提供端地址列表按照预设格式封装成同步文件，并将所述同步文件发送给路由转发中心，以使所述路由转发中心根据所述同步文件更新路由配置信息。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

根据所述注册信息校验所述服务提供端的合法性；

若合法性校验通过，将服务提供端的注册信息进行封装；

否则，放弃将服务提供端的注册信息进行封装。

6.根据权利要求4所述的方法，其特征在于，所述方法还包括：

接收服务消费端发送的订阅服务请求；所述订阅服务请求包括服务信息和服务消费端的地址；

根据所述服务信息和服务提供端地址列表确定服务提供端的地址；

根据服务提供端的地址和服务消费端的地址确定路由转发中心地址；

将所述路由转发中心地址发送给服务消费端。

7.根据权利要求4所述的方法，其特征在于，所述方法还包括：

根据所述订阅服务请求校验所述服务消费端服务的合法性；

若合法性校验通过，开始执行确定服务提供端的地址。

8.一种服务数据传输系统，其特征在于，包括路由转发中心以及与所述路由转发中心连接的服务消费端和服务提供端，其中：

服务消费端，用于发送服务消费请求，以及接收返回包；

路由转发中心，用于接收所述服务消费请求，并获取所述服务消费请求中的包头信息，根据所述包头信息将所述服务消费请求转发给服务消费端中与服务消费请求对应的服务提供端；

服务提供端，用于接收并处理所述服务消费请求得到返回包，将返回包通过所述路由转发中心发送给所述服务消费端。

9.一种电子设备，其特征在于，所述电子设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现权利要求1-7任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序或计算机指令，当所述计算机程序或计算机指令被处理器运行时，实现如权利要求1-7任一项所述的方法。