CN114205342B - 服务调试的路由方法、电子设备及介质 - Google Patents

Abstract

本申请涉及云计算技术领域，公开了一种服务调试的路由方法、电子设备、介质及程序产品。本申请提供的服务调试的路由方法，通过在服务器端增加调试注册服务，并将待调试的服务注册到调试注册服务中，使得服务器端在接收到服务访问请求后，服务代理可以根据服务访问请求中的头部信息检查服务是否在调试注册服务中注册，并在服务已经注册的情况下将服务访问请求转发至相应客户端的待调试的服务，使得可以在客户端上对服务进行本地调试，无需为部署在服务端的服务增加路由到本地服务的代码，避免了对服务代码的侵入式修改，降低了服务维护的复杂性，以简便的方式实现了服务端中服务对本地待调试的服务的访问路由，提高了对服务进行调试的效率。

Description

服务调试的路由方法、电子设备及介质

技术领域

本申请涉及云计算技术领域，特别涉及一种服务调试的路由方法、电子设备、介质及程序产品。

背景技术

当前，软件应用服务通常部署在软件应用容器组成的集群中，软件应用服务的容器化部署使得软件开发人员能够以简单快速方式的方式发布和更新服务，无需停止服务器的运行。虽然服务的容器化部署方便了服务的运行和维护，但是对服务的开发和调试制造了较大的麻烦。服务的容器作为独立的服务运行环境，是一个相对封闭的空间，容器通过内部的命名空间和域名解析实现内部服务的调用，容器外部的服务既难以访问容器内部的服务，也难以被容器内部的服务所调用。而为了实现服务在本地设备上的调试，需要实现本地服务对集群中容器化服务的调用和集群中容器化服务对本地服务的调用。虽然有一些工具能够支持本地服务对集群中容器化服务的调用，但是集群中容器化服务对本地服务的调用仍然较难解决，导致难以对本地服务进行调试。

发明内容

本申请实施例提供了一种服务调试的路由方法、电子设备、介质及程序产品，用于解决现有技术下由容器管理的远程服务难以对本地设备上待调试的服务进行调用的问题。

第一方面，本申请实施例提供了一种服务调试的路由方法，用于包括服务器端和客户端的系统，该方法包括：

客户端将待调试的第一服务的识别信息发送至服务器端，并由服务器端保存在调试注册信息库中，识别信息至少包括待调试的第一服务的服务标识和客户端的设备标识，待调试的第一服务部署在客户端上，服务器端上部署有与待调试的第一服务具有相同服务标识的第二服务；

服务器端上第二服务对应的服务代理接收其它外部服务或内部服务对第二服务的访问请求，并将访问请求中的预设信息与调试注册信息库中的识别信息进行匹配；

确定存在匹配结果，服务代理将访问请求转发至匹配的客户端上部署的待调试的第一服务。

在上述第一方面的一种可能的实现中，服务器端部署有Kubernetes系统，第二服务部署在Kubernetes系统的软件应用容器中。

在上述第一方面的一种可能的实现中，对第二服务的访问请求为HTTP请求。

在上述第一方面的一种可能的实现中，将访问请求中的预设信息与调试注册信息库中的识别信息进行匹配，包括：

将访问请求中的服务标识和设备标识与调试注册信息库中的识别信息进行匹配，服务标识和设备标识位于访问请求的头部信息中。

在上述第一方面的一种可能的实现中，服务标识至少包括如下一种：服务名称、服务的统一资源标识符，设备标识至少包括如下一种：设备的统一资源标识符、设备的网络地址、设备的硬件识别码。

在上述第一方面的一种可能的实现中，设备标识记录在访问请求的头部信息的X-Forwarded-For参数中。

在上述第一方面的一种可能的实现中，服务代理将访问请求转发至匹配的客户端上部署的待调试的第一服务，包括：

服务代理根据访问请求中的设备标识确定匹配的客户端对应的网络地址；

服务代理根据确定的网络地址，将访问请求转发至网络地址对应的客户端上部署的待调试的第一服务。在上述第一方面的一种可能的实现中，确定存在匹配结果，还包括：

在不存在匹配结果的情况下，服务代理将访问请求转发至服务器端部署的第二服务的服务实例。

第二方面，本申请实施例提供了一种服务调试的路由系统，包括客户端和服务器端，

客户端包括调试注册模块，调试注册模块将待调试的第一服务的识别信息发送至服务器端，识别信息至少包括待调试的第一服务的服务标识和客户端的设备标识，待调试的第一服务部署在客户端上；

服务器端包括信息存储模块、服务检查模块和服务转发模块，服务器端上部署有与待调试的第一服务具有相同服务标识的第二服务；信息存储模块，接收客户端发送的待调试的第一服务的识别信息，并将识别信息保存在调试注册信息库中；服务检查模块，用于第二服务对应的服务代理接收其它外部服务或内部服务对第二服务的访问请求，并将访问请求中的预设信息与调试注册信息库中的识别信息进行匹配；服务转发模块，用于确定存在匹配结果，服务代理将访问请求转发至匹配的客户端上部署的待调试的第一服务。

在上述第二方面的一种可能的实现中，服务器端部署有Kubernetes系统，第二服务部署在Kubernetes系统的软件应用容器中。

在上述第二方面的一种可能的实现中，服务检查模块中对第二服务的访问请求为HTTP请求。

在上述第二方面的一种可能的实现中，服务检查模块，用于：

将访问请求中的服务标识和设备标识与调试注册信息库中的识别信息进行匹配，服务标识和设备标识位于访问请求的头部信息中。

在上述第二方面的一种可能的实现中，服务标识至少包括如下一种：服务名称、服务的统一资源标识符，设备标识至少包括如下一种：设备的统一资源标识符、设备的网络地址、设备的硬件识别码。

在上述第二方面的一种可能的实现中，设备标识记录在访问请求的头部信息的X-Forwarded-For参数中。

在上述第二方面的一种可能的实现中，服务转发模块用于服务代理根据访问请求中的设备标识确定匹配的客户端对应的网络地址；服务代理根据确定的网络地址，将访问请求转发至网络地址对应的客户端上部署的待调试的第一服务。

在上述第二方面的一种可能的实现中，服务转发模块还用于在不存在匹配结果的情况下，服务代理将访问请求转发至服务器端部署的第二服务的服务实例。

第三方面，本申请实施例提供了一种电子设备，该电子设备包括：

存储器，用于存储由电子设备的一个或多个处理器执行的指令，以及

处理器，是电子设备的处理器之一，用于执行上述第一方面以及第一方面的各种可能实现中的任意一种服务调试的路由方法。

第四方面，本申请实施例提供了一种可读存储介质，可读存储介质上存储有指令，该指令在电子设备上执行时使电子设备执行上述第一方面以及第一方面的各种可能实现中的任意一种服务调试的路由方法。

第五方面，本申请实施例提供了一种计算机程序产品，包括计算机程序/指令，其特征在于，该计算机程序/指令被处理器执行时实现上述第一方面以及第一方面的各种可能实现中的任意一种服务调试的路由方法。

本申请实施例中提供了用于包括服务器端和客户端的系统的服务调试的路由方法，该方法通过在服务器端增加调试注册服务，并将待调试的服务注册到调试注册服务中，使得服务器端在接收到服务访问请求后，服务代理可以根据服务访问请求中的头部信息检查服务是否在调试注册服务中注册，并在服务已经注册的情况下将服务访问请求转发至相应客户端的待调试的服务，使得可以在客户端上对服务进行本地调试，无需为部署在服务端的服务增加路由到本地服务的代码，避免了对服务代码的侵入式修改，降低了服务维护的复杂性，以简便的方式实现了服务端中服务对本地待调试的服务的访问路由，提高了对服务进行调试的效率。

附图说明

图1根据本申请的一些实施例，示出了一种服务调试的路由过程的场景示意图。

图2根据本申请的一些实施例，示出了一种电子设备的硬件结构图。

图3根据本申请的一些实施例，示出了一种服务调试的路由方法的流程图。

图4根据本申请的一些实施例，示出了一种服务集群中服务调用本地设备上待调试的服务的场景示意图。。

图5根据本申请的一些实施例，示出了多人进行服务调试时一种情况的示意图。

图6根据本申请的一些实施例，示出了多人进行服务调试时另一种情况的示意图。

图7根据本申请的一些实施例，示出了一种本地设备上待调试的服务调用服务集群中服务的场景示意图。

图8根据本申请的一些实施例，示出了一种服务调试的路由系统的结构示意图。

具体实施方式

本申请的说明性实施例包括但不限于服务调试的路由方法、电子设备、介质及程序产品。

可以理解，本申请的服务调试的路由方法适用于对由远程服务和待调试的本地服务所组成的服务调用链进行调试时进行路由的场景。

下面将结合附图对本申请的实施例作进一步地详细描述。

图1根据本申请的一些实施例，提供了一种对服务集群中的服务和本地设备中的服务组成的服务调用链进行调试时进行路由的场景。如图1所示，软件开发人员需要对服务B在本地进行调试，这里服务B是由服务A、服务B和服务C组成的服务调用链中的一个服务，服务调用链的调用顺序为服务A调用服务B，服务B调用服务C。其中服务A和服务C部署在服务集群100上，由服务集群100通过容器化方式进行管理，服务A和服务C分别位于容器1和容器2中，服务B部署在本地设备200上，从而软件开发人员可以对服务B中的软件代码进行逐行调试来确定服务B中存在的问题。

在实际的调试过程中，仍然通过实际运行服务调用链的方式来对服务B进行调用，使得服务B能够根据服务A提供的实际数据进行调试，无需创建调试数据。在运行服务调用链的过程中，先将对服务A的访问请求发送至服务A，再由服务A向服务B发送访问请求，服务B再向服务C发送访问请求。

这里，服务集群100是提供多种服务的计算机集群，可以理解，服务集群100可以是物理服务器组成的集群，也可以是虚拟服务器组成的集群，本申请实施例对此不做具体限制。服务集群100中的服务以容器化方式进行部署，即其中的服务部署在容器中，由容器进行控制和管理，例如由容器实现服务的负载均衡、服务的启动和故障恢复等功能。

软件应用容器(Container)是一种轻量级、可移植、并将软件应用程序进行打包的技术，使得软件应用程序可以在几乎任何环境中以相同的方式运行。容器技术很好地解决了软件环境部署复杂的问题，避免软件应用因为运行环境不兼容导致的各种问题，容器为软件应用提供了一致的运行环境，从而简化了软件运行环境的配置过程。常见的容器实现例如Docker。Docker建立在Linux容器等技术之上，实现了轻量级的操作系统虚拟化解决方案，直接使用本地主机的操作系统，基本不消耗额外的系统资源，使得应用的性能很高，Docker通过打包镜像、启动容器即可创建一个服务。

服务集群100使用基于容器技术的集群管理系统，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能。例如，服务集群100可以使用Kubernetes系统来管理服务集群，Kubernetes是可移植容器的编排管理工具，具备完整的集群管理能力，还提供了集群管理工具，涵盖了包括开发、部署测试和运维监控在内的多个环节。

本地设备200是软件开发人员用于对服务进行调试的电子设备，软件开发人员通过将待调试的服务B部署在本地设备200上从而实现对服务B的运行过程的跟踪和监控，能够实时检测服务B的内部状态，进而根据状态数据分析定位到服务B中存在问题的代码。

本申请技术方案提供的方法，通过将待调试的服务注册到服务集群100中，并在相应服务的服务代理接收到服务访问请求时检查服务访问请求的头部信息，如果头部信息表明请求的服务已经进行了调试注册，则将该服务访问请求转发至头部信息中指定的本地设备200，由本地设备200上待调试的服务进行处理，从而实现了服务集群100中服务对部署在本地设备200上的待调试服务的访问，无需为部署在服务集群100上的服务增加路由到本地服务的代码，避免了对服务代码的侵入式修改，降低了服务维护的复杂性，以简便的方式实现了服务集群100中服务对本地待调试的服务的访问路由，提高了对服务进行调试的效率。

图2根据本申请的一些实施例，示出了一种用于实现服务调试的路由方法的电子设备30的硬件结构框图。在图2所示的实施例中，电子设备30可以包括一个或多个处理器301，与处理器301中的至少一个连接的系统控制逻辑302，与系统控制逻辑302连接的系统内存303，与系统控制逻辑302连接的非易失性存储器(Non-Volatile Memory,NVM)304，以及与系统控制逻辑302连接的网络接口306。

在一些实施例中，处理器301可以包括一个或多个单核或多核处理器。在一些实施例中，处理器301可以包括通用处理器和专用处理器(例如，图形处理器，应用处理器，基带处理器等)的任意组合。在电子设备30采用增强型基站(Evolved Node B，eNB)或无线接入网(Radio Access Network，RAN)控制器的实施例中，处理器301可以被配置为执行各种符合的实施例。例如，处理器301可以用于执行服务调试的路由方法。

在一些实施例中，系统控制逻辑302可以包括任意合适的接口控制器，以向处理器301中的至少一个和/或与系统控制逻辑302通信的任意合适的设备或组件提供任意合适的接口。

在一些实施例中，系统控制逻辑302可以包括一个或多个存储器控制器，以提供连接到系统内存303的接口。系统内存303可以用于加载以及存储数据和/或指令。例如，系统内存303可以加载本申请实施例中解析服务访问请求的指令，也可以保存输入数据和配置数据等。

在一些实施例中电子设备30的系统内存303可以包括任意合适的易失性存储器，例如合适的动态随机存取存储器(Dynamic Random Access Memory，DRAM)。

NVM存储器304可以包括用于存储数据和/或指令的一个或多个有形的、非暂时性的计算机可读介质。在一些实施例中，NVM存储器304可以包括闪存等任意合适的非易失性存储器和/或任意合适的非易失性存储设备，例如硬盘驱动器(Hard Disk Drive，HDD)，光盘(Compact Disc，CD)驱动器，数字通用光盘(Digital Versatile Disc，DVD)驱动器中的至少一个。在本申请实施例中，NVM存储器304可以用于存储服务集群中容器化服务的镜像文件和服务使用的临时数据等。

NVM存储器304可以包括安装电子设备30的装置上的一部分存储资源，或者它可以由设备访问，但不一定是设备的一部分。例如，可以经由网络接口306通过网络访问NVM存储器304。

特别地，系统内存303和NVM存储器304可以分别包括：指令305的暂时副本和永久副本。指令305可以包括：由处理器301中的至少一个执行时导致电子设备30实施如图3所示的方法的指令。在一些实施例中，指令305、硬件、固件和/或其软件组件可另外地/替代地置于系统控制逻辑302，网络接口306和/或处理器301中。

网络接口306可以包括收发器，用于为电子设备30提供无线电接口，进而通过一个或多个网络与任意其他合适的设备(如前端模块，天线等)进行通信。在一些实施例中，网络接口306可以集成于电子设备30的其他组件。例如，网络接口306可以集成于处理器301的，系统内存303，NVM存储器304，和具有指令的固件设备(未示出)中的至少一种，当处理器301中的至少一个执行所述指令时，电子设备30实现如方法实施例中示出的方法。在本申请实施例中，网络接口306可以用于接收服务发送的服务访问请求数据和服务调用结果数据。

网络接口306可以进一步包括任意合适的硬件和/或固件，以提供多输入多输出无线电接口。例如，网络接口306可以是网络适配器，无线网络适配器，电话调制解调器和/或无线调制解调器。

在一些实施例中，处理器301中的至少一个可以与用于系统控制逻辑302的一个或多个控制器的逻辑封装在一起，以形成系统封装(System In a Package，SiP)。在一些实施例中，处理器301中的至少一个可以与用于系统控制逻辑302的一个或多个控制器的逻辑集成在同一管芯上，以形成片上系统(System on Chip,SoC)。

电子设备30可以进一步包括：输入/输出(I/O)设备307。I/O设备307可以包括用户界面，使得用户能够与电子设备30进行交互；外围组件接口的设计使得外围组件也能够与电子设备30交互。

可以理解的是，图2示意的结构并不构成对电子设备30的具体限定。在本申请另外一些实施例中电子设备30可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以由硬件或软件，或软件和硬件的组合实现。

下面结合上述图2所示的结构，根据图3并结合图4的具体场景，详细介绍本申请的技术方案。以下以Kubernetes集群为服务集群100，服务集群100中的服务A调用本地设备200中的待调试服务B的场景为例进行说明。如图3所示，本申请的一些实施例中服务调试的路由方法的技术方案包括：

S301：本地设备200将待调试的服务注册到Kubernetes集群100中的调试注册服务。在此，调试注册服务部署在Kubernetes集群100中，用于对准备进行本地调试的服务进行注册，调试注册服务将接收的待调试的服务的识别信息存储在Kubernetes集群100的调试注册信息库中，这里，待调试的服务部署在本地设备200上，本地设备200是软件开发人员用于进行软件开发和调试的设备。如图4所示，软件开发人员准备对服务B进行本地调试，则在进行调试之前，先将待调试的服务B注册到调试注册服务中。

本地设备200上待调试的服务向调试注册服务提供的识别信息可以包括但不限于服务的标识、本地设备200的设备标识等。可以理解，服务的标识是可以用于在同一命名空间中唯一识别服务的字符串，例如为服务的名称、服务的统一资源标识符(UniformResource Identifier，URI)等。类似地，本地设备200的设备标识是可以用于在同一命令空间中唯一识别本地设备的字符串，例如为设备的统一资源标识符、设备的网络地址、设备的硬件识别码等。

在一些实施例中，待调试的服务B将服务B的名称和本地设备200的网络地址作为识别信息提供给调试注册服务，调试注册服务将接收的识别信息存储在调试注册信息库中，供后续的服务检查使用。

S302：Kubernetes集群100接收对服务A的访问请求，并将访问请求发送至服务A。在此，为了完整地模拟待调试的服务B的调用过程，通过在实际环境中调用服务B的服务A发起对待调试的服务B的访问。软件开发人员首先调用服务A，服务A在运行过程调用待调试的服务B，从而软件开发人员可以对待调试的服务B的运行过程进行调试。

软件开发人员可以通过向Kubernetes集群100发送对服务A的访问请求来实现对服务A的调用，Kubernetes集群100通过网关接收来自集群外部的服务访问请求。在此，Kubernetes集群100中的网关用于接收外部的服务访问请求和发送服务访问结果数据，是数据进出Kubernetes集群100必须经过的网络关口。

网关接收到服务访问请求后，将服务访问请求转发至对应的服务。如图4所示，网关接收到对服务A的访问请求，则将该访问请求转发至服务A。

Kubernetes集群100中的服务A对应有多个服务实例，每个服务实例单独提供服务A的功能，多个服务A的服务实例例如podA-1和podA-2可以同时处理多个对服务A的访问请求，服务A对应的服务代理a用于将服务A的访问请求分发到不同的服务实例，可以实现对服务A的访问的负载均衡。如图4所示，服务A对应的服务代理a在接收到网关转发的对服务A的访问请求后，检查到服务A并没有在调试注册服务中注册，因此服务代理a将对服务A的访问请求转发给服务A的一个服务实例PodA-1进行处理。

S303：服务A向服务B发送访问请求。

在此，服务A的处理过程中需要调用服务B，因此服务A向服务B发送访问请求以获得服务B的返回数据。具体来说，如图4所示，服务A的一个服务实例PodA-1向服务B发送访问请求。服务A向服务B发送的服务访问请求中，用于对服务是否进行调试注册进行检查的头部信息保持不变。

S304：服务B对应的服务代理检查服务B是否在调试注册服务中注册。

类似地，Kubernetes集群100中的服务B同样可以有对应的多个服务实例，每个服务实例单独提供服务B的功能，服务B对应的服务代理b用于将服务B的访问请求分发到不同的服务实例以实现服务B的负载均衡。

在此，服务B与本地设备200中待调试的服务B是同一个服务，但是部署在Kubernetes集群100中的服务B难以进行调试，因此在本地设备200上部署同样的服务B，通过调试本地设备200上的服务B来确定Kubernetes集群100中同样的服务B可能存在的代码缺陷。

本申请的一些实施例中，Kubernetes集群100中的服务代理在对服务访问请求进行转发之前，首先检查对应服务是否在调试注册服务中进行了注册，即检查访问请求中对应服务的相关信息是否能与注册信息库中的识别信息进行匹配。在此，通过对Kubernetes集群100中的服务代理进行功能增强以实现对相应服务的检查。

具体来说，可通过Kubernetes集群100中的服务代理的userspace模式实现对服务是否在调试注册服务中注册进行检查。通过使用服务代理的userspace模式，软件开发人员可以为服务代理提供扩展的软件代码，从而可以让服务代理实现软件开发人员期望的功能。

本申请的一些实施例中，服务代理根据服务访问请求中预设的头部信息确定对应服务是否进行了注册。在此，服务访问请求的头部信息中可以包括服务标识和本地设备的标识，服务代理根据服务标识和本地设备的标识确定服务是否在调试注册服务中已经注册，即检查服务标识和本地设备的标识是否能与注册信息库中的识别信息匹配。

可以理解，服务代理可以根据服务标识检查服务是否在调试注册服务中注册，也可以根据本地设备的标识检查对应服务是否在调试注册服务中注册，还可以同时根据服务标识和本地设备的标识检查服务是否在调试注册服务中注册，本申请实施例对服务代理的检查方式不做具体限制。

在一些实施例中，服务访问请求是通过HTTP协议实现的网络请求，服务访问请求包括HTTP头部信息和HTTP正文信息，HTTP头部信息包括服务请求行和服务请求参数。服务请求行用于指明服务的访问方法和服务的统一资源定位符(Uniform Resource Locator，URL)等，访问方法例如为GET、POST等。服务请求参数用于指定服务访问中使用的参数及对应的参数值。服务代理在检查服务是否在调试注册服务中注册时，可以根据服务访问请求中服务的统一资源定位符来检查，也可以根据服务访问请求中头部信息的相关参数来检查，还可以结合统一资源定位符和相关参数来检查。服务代理在检查到服务的统一资源定位符和/或相关参数能与调试注册信息库中的识别信息匹配，则确定服务已经在调试注册服务中注册。

在此，注册检查使用的服务访问请求中头部信息的相关参数可以是预设的头部参数，也可以是自定义的头部参数。预设的头部参数是在HTTP头部信息的规范中定义的相关参数，可以直接根据头部信息中相关参数的参数值进行检查，可以使用的预设头部参数例如为X-Forwarded-For。X-Forwarded-For是HTTP头部信息的一个扩展参数，记载在RFC7239规范中，用于记录HTTP请求的发出设备和转发过程中经过的设备的网络地址，最多可以记录三个网络地址。

另外，自定义的头部参数是软件开发人员根据自身需要定义的个性化参数，用于传输个性化的数据，接收方在接收到包含自定义的头部参数的HTTP请求后，需要对自定义的头部参数进行个性化处理。这里，自定义的头部参数可以用于传递发送服务访问请求的本地设备的设备标识。

服务代理对服务B在调试注册服务中的注册情况进行检查后，根据检查结果对服务B的访问请求进行转发，如果检查到服务B已经注册，则执行步骤S305，如果检查到服务B没有注册，则执行步骤S306。

S305：服务代理将对服务B的访问请求转发至本地设备200上待调试的服务B。如图4所示，服务代理b检查到服务B已经在调试注册服务中注册，因此服务代理b需要将对服务B的访问请求转发至本地设备200，本地设备200的网络地址可以来自对服务B的访问请求中的头部参数，例如X-Forwarded-For参数，也可以是调试注册服务中记录的与服务B对应的本地设备200的网络地址。

S306：如果服务B没有在调试服务中注册，服务代理将对服务B的访问请求转发至集群中服务B的实例。

在此，在服务B没有在调试注册服务中注册的情形中，即当前没有对服务B的调试需求时，对服务B的访问请求是正常的服务访问请求，因此服务代理根据多个服务B的实例的负载情况确定一个负载较轻的服务B的实例，将对服务B的访问请求转发至该实例进行处理。

图5示出了本申请的一些实施例中多个软件开发人员同时对服务A进行调试的一种场景。如图5所示，本地设备X 200和本地设备Y 300上均部署有待调试的服务A，并分别将待调试的服务A注册到Kubernetes集群100中的调试注册服务中，本地设备X 200上待调试的服务A提供的注册信息包括本地设备X的网络地址172.0.0.101，本地设备Y 300上待调试的服务A提供的注册信息包括本地设备Y的网络地址172.0.0.102。在调试过程中，Kubernetes集群100接收到对服务A进行调用的HTTP请求，该HTTP请求可以由本地设备X200发起，也可以由其它调用服务A的设备发起。该HTTP请求的头部信息中预设头部参数X-Forwarded-For的值为172.0.0.101，即本地设备X 200对应的网络地址。网关接收到HTTP请求后，将其转发至服务A的服务代理a，服务代理a通过与调试注册服务的交互对服务A的注册情况进行检查，在确定服务A已经注册后服务代理a根据X-Forwarded-For的值172.0.0.101将该HTTP请求转发至对应的本地设备X 200上待调试的服务A进行处理。因此，通过在服务的访问请求的头部信息中设置不同的本地设备的标识，服务代理可以区分同时调试相同服务的本地设备，从而对服务的访问请求转发至正确的目的设备。

图6示出了本申请的一些实施例中多个软件开发人员同时对服务A进行调试的另一种场景。如图6所示，本地设备X 200和本地设备Y 300上均部署有待调试的服务A，并分别将待调试的服务A注册到Kubernetes集群100中的调试注册服务中，本地设备X 200上待调试的服务A提供的注册信息包括本地设备X的网络地址172.0.0.101，本地设备Y 300上待调试的服务A提供的注册信息包括本地设备Y的网络地址172.0.0.102。在调试过程中，Kubernetes集群100接收到对服务A进行调用的HTTP请求，该HTTP请求的头部信息中预设头部参数X-Forwarded-For的值为172.0.0.103。网关接收到HTTP请求后，将其转发至服务A的服务代理a，服务代理a通过与调试注册服务的交互对服务A的注册情况进行检查，确定服务A虽然已经注册，但是注册信息中的网络地址与HTTP请求中的参数值172.0.0.103不符，因此服务代理a将该HTTP请求转发至服务A的一个实例PodA-1进行处理。因此，通过在服务的访问请求的头部信息中设置与待调试的服务所在本地设备不同的标识或不对预设的头部参数进行设置，可以使服务代理区分待调试服务的访问请求和正常的访问请求，将正常的访问请求转发至集群中的服务实例进行处理。

图7示出了本申请的一些实施例中本地设备上的待调试的服务对Kubernetes集群中服务进行访问的场景。如图7所示，本地设备200上待调试的服务B需要对Kubernetes集群100中的服务C进行调用，由于本地设备200上的服务不能直接访问Kubernetes集群100中的服务，因此待调试的服务B通过Kubernetes集群100中的影子服务实现对服务C的调用，这里的影子服务由软件开发人员在本地设备200上通过使用本地命令行工具在Kubernetes集群100上创建，本地命令行工具是由Kubernetes系统提供的命令行控制工具，通过本地命令行工具可以对Kubernetes集群100进行控制和管理。这里，通过本地命令行工具创建影子服务并建立代理通道后，待调试的服务B可以请求访问服务C，代理通道可以有多种形式，如VPN、SOCKS5等。另外，创建的影子服务可以被多个本地设备共享，即多个本地设备上待调试的服务可以通过一个影子服务对Kubernetes集群100中的服务进行访问，从而能够降低Kubernetes集群100的资源消耗。

另外，图8示出了一种服务调试的路由系统的结构示意图，可以理解，上述服务调试的路由方法中的具体技术细节，在该路由系统中也适用，为了避免重复，在此不再赘述。

如图8所示，该服务调试的路由系统800，包括客户端810和服务器端820，

客户端810包括调试注册模块811，调试注册模块811将待调试的第一服务的识别信息发送至服务器端820，识别信息至少包括待调试的第一服务的服务标识和客户端的设备标识，待调试的第一服务部署在客户端810上；

服务器端820包括信息存储模块821、服务检查模块822和服务转发模块823，服务器端820上部署有与待调试的第一服务具有相同服务标识的第二服务；

信息存储模块821，接收客户端发送的待调试的第一服务的识别信息，并将识别信息保存在调试注册信息库中；

服务检查模块822，用于第二服务对应的服务代理接收其它外部服务或内部服务对第二服务的访问请求，并将访问请求中的预设信息与调试注册信息库中的识别信息进行匹配；

服务转发模块823，用于确定存在匹配结果，服务代理将访问请求转发至匹配的客户端810上部署的待调试的第一服务。本申请公开的机制的各实施例可以被实现在硬件、软件、固件或这些实现方法的组合中。本申请的实施例可实现为在可编程系统上执行的计算机程序或程序代码，该可编程系统包括至少一个处理器、存储系统(包括易失性和非易失性存储器和/或存储元件)、至少一个输入设备以及至少一个输出设备。

可将程序代码应用于输入指令，以执行本申请描述的各功能并生成输出信息。可以按已知方式将输出信息应用于一个或多个输出设备。为了本申请的目的，处理系统包括具有诸如例如数字信号处理器(Digital Signal Processor，DSP)、微控制器、专用集成电路(Application Specific Integrated Circuit，ASIC)或微处理器之类的处理器的任何系统。

程序代码可以用高级程序化语言或面向对象的编程语言来实现，以便与处理系统通信。在需要时，也可用汇编语言或机器语言来实现程序代码。事实上，本申请中描述的机制不限于任何特定编程语言的范围。在任一情形下，该语言可以是编译语言或解释语言。

在一些情况下，所公开的实施例可以以硬件、固件、软件或其任何组合来实现。所公开的实施例还可以被实现为由一个或多个暂时或非暂时性机器可读(例如，计算机可读)存储介质承载或存储在其上的指令，其可以由一个或多个处理器读取和执行。例如，指令可以通过网络或通过其他计算机可读介质分发。因此，机器可读介质可以包括用于以机器(例如，计算机)可读的形式存储或传输信息的任何机制，包括但不限于，软盘、光盘、光碟、只读存储器(CD-ROMs)、磁光盘、只读存储器(Read Only Memory，ROM)、随机存取存储器(RandomAccess Memory，RAM)、可擦除可编程只读存储器(Erasable Programmable Read OnlyMemory，EPROM)、电可擦除可编程只读存储器(Electrically Erasable ProgrammableRead-Only Memory，EEPROM)、磁卡或光卡、闪存、或用于利用因特网以电、光、声或其他形式的传播信号来传输信息(例如，载波、红外信号数字信号等)的有形的机器可读存储器。因此，机器可读介质包括适合于以机器(例如计算机)可读的形式存储或传输电子指令或信息的任何类型的机器可读介质。

在附图中，可以以特定布置和/或顺序示出一些结构或方法特征。然而，应该理解，可能不需要这样的特定布置和/或排序。而是，在一些实施例中，这些特征可以以不同于说明性附图中所示的方式和/或顺序来布置。另外，在特定图中包括结构或方法特征并不意味着暗示在所有实施例中都需要这样的特征，并且在一些实施例中，可以不包括这些特征或者可以与其他特征组合。

需要说明的是，本申请各设备实施例中提到的各单元/模块都是逻辑单元/模块，在物理上，一个逻辑单元/模块可以是一个物理单元/模块，也可以是一个物理单元/模块的一部分，还可以以多个物理单元/模块的组合实现，这些逻辑单元/模块本身的物理实现方式并不是最重要的，这些逻辑单元/模块所实现的功能的组合才是解决本申请所提出的技术问题的关键。此外，为了突出本申请的创新部分，本申请上述各设备实施例并没有将与解决本申请所提出的技术问题关系不太密切的单元/模块引入，这并不表明上述设备实施例并不存在其它的单元/模块。

需要说明的是，在本专利的示例和说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

虽然通过参照本申请的某些优选实施例，已经对本申请进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种改变，而不偏离本申请的精神和范围。

Claims (9)

1.一种服务调试的路由方法，用于包括服务器端和客户端的系统，其特征在于，包括：

所述客户端将待调试的第一服务的识别信息发送至所述服务器端，并由所述服务器端保存在调试注册信息库中，其中，所述识别信息至少包括所述待调试的第一服务的服务标识和所述客户端的设备标识，所述待调试的第一服务部署在所述客户端上，所述服务器端上部署有与所述待调试的第一服务具有相同服务标识的第二服务，

其中，所述服务器端部署有Kubernetes系统，所述第二服务部署在Kubernetes系统的软件应用容器中；

所述服务器端上第二服务对应的服务代理接收其它外部服务或内部服务对所述第二服务的访问请求，并将所述访问请求中的预设信息与所述调试注册信息库中的识别信息进行匹配；

确定存在匹配结果，所述服务代理将所述访问请求转发至匹配的所述客户端上部署的所述待调试的第一服务。

2.根据权利要求1所述的方法，其特征在于，对所述第二服务的访问请求为HTTP请求。

3.根据权利要求2所述的方法，其特征在于，将所述访问请求中的预设信息与所述调试注册信息库中的识别信息进行匹配，包括：

将所述访问请求中的服务标识和设备标识与所述调试注册信息库中的识别信息进行匹配，其中，所述服务标识和所述设备标识位于所述访问请求的头部信息中。

4.根据权利要求3所述的方法，其特征在于，所述服务标识至少包括如下一种：服务名称、服务的统一资源标识符，所述设备标识至少包括如下一种：设备的统一资源标识符、设备的网络地址、设备的硬件识别码。

5.根据权利要求4所述的方法，其特征在于，所述设备标识记录在所述访问请求的头部信息的X-Forwarded-For参数中。

6.根据权利要求2所述的方法，其特征在于，所述服务代理将所述访问请求转发至匹配的所述客户端上部署的所述待调试的第一服务，包括：

所述服务代理根据所述访问请求中的设备标识确定匹配的所述客户端对应的网络地址；

所述服务代理根据确定的网络地址，将所述访问请求转发至所述网络地址对应的所述客户端上部署的所述待调试的第一服务。

7.根据权利要求1所述的方法，其特征在于，确定存在匹配结果，还包括：

在不存在匹配结果的情况下，所述服务代理将所述访问请求转发至所述服务器端部署的所述第二服务的服务实例。

8.一种电子设备，其特征在于，包括：

存储器，用于存储由电子设备的一个或多个处理器执行的指令，以及

处理器，是电子设备的处理器之一，用于执行权利要求1-7中任一项所述的服务调试的路由方法。

9.一种可读存储介质，其特征在于，所述可读存储介质上存储有指令，该指令在电子设备上执行时使电子设备执行权利要求1-7中任一项所述的服务调试的路由方法。

Images