CN114296880A - 基于大规模集群的服务请求处理方法、装置、设备及介质 - Google Patents

Abstract

本申请涉及云计算技术领域，揭露一种基于大规模集群的服务请求处理方法、装置、设备及介质，其中方法包括接收和解析客户端的服务请求，以获取服务请求标识、请求端信息以及目标端信息；判断服务请求对应的请求路径；若判断为集群内服务请求，则将请求端信息以及目标端信息注入头部信息中，以在服务注册中心获取服务请求对应的目标应用域和目标服务，以及在目标应用域中调用目标服务，并通过目标服务处理服务请求；若判断为跨集群服务请求，则将请求端信息以及目标端信息注入头部信息中，并通过服务网关，将头部信息注入到集群关系信息中，获取目标服务处理服务请求。本发明降低了集群下服务的管理难度，有利于提高服务请求处理的效率。

Description

基于大规模集群的服务请求处理方法、装置、设备及介质

技术领域

本申请涉及云计算技术领域，尤其涉及一种基于大规模集群的服务请求处理方法、装置、设备及介质。

背景技术

微服务架构将复杂系统切分若干小服务，每个服务可以被独立地开发、部署和伸缩；微服务架构和容器(Docker/Kubernetes)是天作之合，可以进一步简化微服务交付，加强整体系统的弹性和健壮性。然而由大量的微服务构成的分布式应用架构也会增加运维、调试、和安全管理的复杂性。

在实现面向大规模系统应用时，存在大量的微服务，微服务之间的调用关系复杂，然而随着服务数量增多，通过服务网格进行管理也存在交互关系以指数方式进行增长，带来服务管理粒度过细和服务治理复杂的问题，从而导致服务请求处理的效率较低。

发明内容

本申请实施例的目的在于提出一种基于大规模集群的服务请求处理方法、装置、设备及介质，以提高服务请求处理的效率。

为了解决上述技术问题，本申请实施例提供一种基于大规模集群的服务请求处理方法，包括：

接收客户端的服务请求，并对所述服务请求进行解析，以获取服务请求标识、请求端信息以及目标端信息；

基于所述服务请求标识，判断所述服务请求对应的请求路径，得到判断结果，其中，所述请求路径包括集群内服务请求和跨集群服务请求；

若所述判断结果为所述集群内服务请求，则将所述请求端信息以及所述目标端信息注入头部信息中，以在服务注册中心获取所述服务请求对应的目标应用域和目标服务，以及在所述目标应用域中调用所述目标服务，并通过所述目标服务处理所述服务请求；

若所述判断结果为所述跨集群服务请求，则将所述请求端信息以及所述目标端信息注入所述头部信息中，并通过服务网关，将所述头部信息注入到集群关系信息中，以获取所述目标服务，并通过所述目标服务处理所述服务请求。

为了解决上述技术问题，本申请实施例提供一种基于大规模集群的服务请求处理装置，包括：

服务请求接收模块，用于接收客户端的服务请求，并对所述服务请求进行解析，以获取服务请求标识、请求端信息以及目标端信息；

请求路径判断模块，用于基于所述服务请求标识，判断所述服务请求对应的请求路径，得到判断结果，其中，所述请求路径包括集群内服务请求和跨集群服务请求；

集群内请求处理模块，用于若所述判断结果为所述集群内服务请求，则将所述请求端信息以及所述目标端信息注入头部信息中，以在服务注册中心获取所述服务请求对应的目标应用域和目标服务，以及在所述目标应用域中调用所述目标服务，并通过所述目标服务处理所述服务请求；

跨集群请求处理模块，用于若所述判断结果为所述跨集群服务请求，则将所述请求端信息以及所述目标端信息注入所述头部信息中，并通过服务网关，将所述头部信息注入到集群关系信息中，以获取所述目标服务，并通过所述目标服务处理所述服务请求。

为解决上述技术问题，本发明采用的一个技术方案是：提供一种计算机设备，包括，一个或多个处理器；存储器，用于存储一个或多个程序，使得一个或多个处理器实现上述任意一项所述的基于大规模集群的服务请求处理方法。

为解决上述技术问题，本发明采用的一个技术方案是：一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一项所述的基于大规模集群的服务请求处理方法。

本发明实施例提供了一种基于大规模集群的服务请求处理方法、装置、设备及介质。其中，方法包括：接收客户端的服务请求，并对服务请求进行解析，以获取服务请求标识、请求端信息以及目标端信息；基于服务请求标识，判断服务请求对应的请求路径，得到判断结果，其中，请求路径包括集群内服务请求和跨集群服务请求；若判断结果为集群内服务请求，则将请求端信息以及目标端信息注入头部信息中，以在服务注册中心获取服务请求对应的目标应用域和目标服务，以及在目标应用域中调用目标服务，并通过目标服务处理服务请求；若判断结果为跨集群服务请求，则将请求端信息以及目标端信息注入头部信息中，并通过服务网关，将头部信息注入到集群关系信息中，以获取目标服务，并通过目标服务处理服务请求。本发明实施例通过判断服务请求对应的请求路径，若请求路径为集群内服务请求，则利用注入头部信息的方式，调用目标服务，以及若请求路径为跨集群服务请求，利用服务网关的方式，进行调用目标服务，实现降低了集群下服务粒度细、服务数量多带来的管理难度，同时避免了原生的服务实例的侵入，从而有利于提高服务请求处理的效率。

附图说明

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

图1是本申请实施例提供的基于大规模集群的服务请求处理方法中子流程的一实现流程图；

图2是本申请实施例提供的基于大规模集群的服务请求处理方法中子流程的又一实现流程图；

图3是本申请实施例提供的基于大规模集群的服务请求处理方法中子流程的又一实现流程图；

图4是本申请实施例提供的基于大规模集群的服务请求处理方法中子流程的又一实现流程图；

图5是本申请实施例提供的基于大规模集群的服务请求处理方法中子流程的又一实现流程图；

图6是本申请实施例提供的基于大规模集群的服务请求处理方法中子流程的又一实现流程图；

图7是本申请实施例提供的基于大规模集群的服务请求处理方法中子流程的又一实现流程图；

图8是本申请实施例提供的基于大规模集群的服务请求处理装置示意图；

图9是本申请实施例提供的计算机设备的示意图。

具体实施方式

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同；本文中在申请的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请；本申请的说明书和权利要求书及上述附图说明中的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。本申请的说明书和权利要求书或上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

为了使本技术领域的人员更好地理解本申请方案，下面将结合附图，对本申请实施例中的技术方案进行清楚、完整地描述。

下面结合附图和实施方式对本发明进行详细说明。

需要说明的是，本申请实施例所提供的基于大规模集群的服务请求处理方法一般由服务器执行，相应地，基于大规模集群的服务请求处理装置一般配置于服务器中。

请参阅图1，图1示出了基于大规模集群的服务请求处理方法的一种具体实施方式。

需注意的是，若有实质上相同的结果，本发明的方法并不以图1所示的流程顺序为限，该方法包括如下步骤：

S1：接收客户端的服务请求，并对服务请求进行解析，以获取服务请求标识、请求端信息以及目标端信息。

具体的，在客户端需要进行调用相关服务时，客户端则生成服务请求，并将服务请求发送到服务器，服务器接收到服务请求后，将该服务请求进行解析，以获取服务请求标识、请求端信息以及目标端信息。其中，服务请求标识为需要调用的目标服务对应的标识，用以判断服务所处于的服务集群。请求端信息为基于客户端生成的信息，其中，请求端信息包括客户端的IP地址信息和账户信息等。目标端信息为基于所请求的目标服务生成的信息，其中，目标端信息包括目标服务名称等。

请参阅图2，图2示出了步骤S1之后的一种具体实施方式，详叙如下：

S1A：记录客户端对服务请求的发起时间和响应时间，以及记录服务器对服务请求的接收时间和响应返回时间。

S1B：基于发起时间、响应时间、接收时间、响应返回时间以及头部信息，生成日志信息。

具体的，在上述步骤S1之后，本实施例通过在服务交互过程中，记录客户端对服务请求的发起时间和响应时间，以及记录服务器对服务请求的接收时间和响应返回时间，并从收集头部信息(Header)，例如收集以下头部信息：x-request-id、x-b3-traceid、x-b3-spanid、x-b3-parentspanid、x-b3-sampled、x-b3-flags以及x-ot-span-context等，再基于发起时间、响应时间、接收时间、响应返回时间以及头部信息，生成日志信息。进一步的，将日志信息注入并转发到服务提供方，便于进行服务的追溯。其中，服务提供方为生成和提供相关服务的客户端。其中，头部信息也即标头(header)，该头部信息是服务器以HTTP协议传HTML资料到浏览器前所送出的字串，在头部信息与HTML文件之间尚需空一行分隔。

本实施例中，通过记录客户端对服务请求的发起时间和响应时间，以及记录服务器对服务请求的接收时间和响应返回时间，再基于发起时间、响应时间、接收时间、响应返回时间以及头部信息，生成日志信息，便于根据所生成的日志信息，对服务调用过程的分析和溯源。

S2：基于服务请求标识，判断服务请求对应的请求路径，得到判断结果，其中，请求路径包括集群内服务请求和跨集群服务请求。

具体的，由于服务的交互过程可能发生在客户端与同一集群内，也有可能发生在客户端与不同的集群内，所以通过服务请求标识，判断所要调用的目标服务是与客户端处于同一集群内，还是与客户端处于不同的集群内。若是判断结果为所要调用的目标服务是与客户端处于同一集群内，则是集群内服务请求，若否，则是属于跨集群服务请求。

S3：若判断结果为集群内服务请求，则将请求端信息以及目标端信息注入头部信息中，以在服务注册中心获取服务请求对应的目标应用域和目标服务，以及在目标应用域中调用目标服务，并通过目标服务处理服务请求。

请参阅图3，图3示出了步骤S3的一种具体实施方式，详叙如下：

S31：若判断结果为集群内服务请求，则将请求端信息以及目标端信息注入头部信息中，生成链路追踪日志标识。

S32：基于链路追踪日志标识，遍历服务注册中心，获取服务请求对应的目标应用域和目标服务。

S33：解析目标应用域对应的域名，以调用目标服务，并通过目标服务处理服务请求。

具体的，若判断结果为集群内服务请求，则将请求端信息以及目标端信息注入头部信息中，生成链路追踪日志标识，此时的请求端信息以及目标端信息可以作为Span消息，也即将Span消息注入头部信息中，生成链路追踪日志标识，再通过链路追踪日志标识去服务注册中心追踪到对应的目标应用域和目标服务，再解析目标应用域对应的域名，以调用目标服务，并通过目标服务处理服务请求。

进一步的，采用服务网格技术，每当服务发起外部调用时，客户端会创建一个新的Span消息。一个Span消息的注入可以实现一组完整服务的交互过程，也即从客户端发出请求开始到接收到服务方的响应为止。运用多级服务网格下，在跨集群服务调用时，在服务网关中注入服务集群的信息，以展示整体集群的调用信息和追溯关系。利用采用服务网格技术实现了大颗粒下的服务集群的划分和独立自治，降低单一集群下服务粒度细、服务数量多带来的管理难度。

本实施例中，若判断结果为集群内服务请求，则将请求端信息以及目标端信息注入头部信息中，生成链路追踪日志标识，再基于链路追踪日志标识，遍历服务注册中心，获取服务请求对应的目标应用域和目标服务，然后解析目标应用域对应的域名，以调用目标服务，并通过目标服务处理服务请求，使得在集群内服务请求，实现服务的请求调用，避免原生的服务实例的侵入，有效提高了服务请求处理的效率。

请参阅图4，图4示出了步骤S33的一种具体实施方式，详叙如下：

S331：通过CoreDNS解析方式，解析目标应用域对应的域名，得到目标服务部署单元Pod的IP地址。

S332：基于目标服务部署单元Pod的IP地址，调用目标服务，并通过目标服务处理服务请求。

具体的，CoreDNS作为CNCF中托管的一个域名发现的项目，原生集成Kubernetes，它的目标是成为云原生的DNS服务器和服务发现的参考解决方案；而CoreDNS解析方式是通过CoreDNS配置域名解析的方式，其能够对应用域进行解析，获取到真实的服务部署单元Pod的IP地址。其中，服务部署单元Pod是指Kubernetes为部署、管理、编排容器化应用提出的概念，也是Kubernetes中的最小部署单元。在本申请实施例中，通过CoreDNS解析方式，解析目标应用域对应的域名，得到目标服务部署单元Pod的IP地址，再基于目标服务部署单元Pod的IP地址，调用目标服务，并通过目标服务处理服务请求，实现集群内部间的服务调用，有利于提高服务请求处理的效率。

请参阅图5，图5示出了步骤S3之前的一种具体实施方式，详叙如下：

S3A：获取多种服务，并将多种服务进行编译打包，生成服务镜像，并将服务镜像置入到服务镜像仓库中。

S3B：获取服务对应的应用域，并基于应用域，将服务配于对应的集群中。

S3C：在服务注册中心中，对集群中的应用域作为根节点并进行初始化处理，得到应用域对应的根节点。

具体的，集群中包括多种服务，每种服务都有其对应的业务功能，将每一种业务功能作为一种应用域集群，将其作为每一种应用域集群作为根节点进行注册，从而得到应用域集群对应的根节点。所以先获取到多种服务，再对多种服务进行编译打包成服务镜像，其中，镜像(Mirroring)是一种文件存储形式，是冗余的一种类型，一个磁盘上的数据在另一个磁盘上存在一个完全相同的副本即为镜像。然后再将其置入服务镜像仓库中，获取每一种服务的业务功能，也即获取服务的应用域，将其规划和配置到相应的集群中；然后在服务注册中心中，对集群中的应用域作为根节点并进行初始化处理，得到应用域对应的根节点。本实施例中，在服务部署发布时，根据应用域的划分，将相关的服务容器以应用域集群名作为根节点进行注册，在该节点下的服务可以自动发现根节点对应的服务，实现本应用域下的跨服务调用。

请参阅图6，图6示出了步骤S3C之后的一种具体实施方式，详叙如下：

S3D：若监听到服务发送变更，则在服务注册中心生成服务变更通知。

S3E：将服务变更通知发送到客户端，以使得客户端获取服务变更内容以及将服务变更内容存储于客户端本地中。

具体的，通过服务注册中心对服务进行监控，当监听到服务发送变更时，获取服务变更内容，并生成对应的服务变更通知，将该服务变更通知发送到客户端，客户端接收到服务变更通知后，获取对应的服务变更内容，再将其服务变更内容存储于客户端本地中。本实施例中，若监听到服务发送变更，则在服务注册中心生成服务变更通知，将服务变更通知发送到客户端，以使得客户端获取服务变更内容以及将服务变更内容存储于客户端本地中，实现对服务进行监听，在服务发生变更时，实时更新客户端本地的服务内容。

S4：若判断结果为跨集群服务请求，则将请求端信息以及目标端信息注入头部信息中，并通过服务网关，将头部信息注入到集群关系信息中，以获取目标服务，并通过目标服务处理服务请求。

请参阅图7，图7示出了步骤S4的一种具体实施方式，详叙如下：

S41：若判断结果为跨集群服务请求，则将请求端信息以及目标端信息注入头部信息中，得到目标头部信息。

S42：采用服务网关，将目标头部信息注入到集群关系信息中，生成集群信息。

S43：在集群关系信息中，通过对集群信息进行收集和转发处理，以获取目标服务，并通过目标服务处理服务请求。

具体的，若判断结果为跨集群服务请求，将请求端信息以及目标端信息注入头部信息，得到目标头部信息，然后本申请实施例通过服务网关向外部保留一个注册接口，能够将目标头部信息注入到集群关系信息中，生成集群信息，例如生成的集群消息为x-src-cluster-id和x-dst-cluster-id，然后在集群关系信息中，通过对集群信息进行收集和转发处理，以获取目标服务，并通过目标服务处理服务请求。

进一步的，跨集群的服务请求时，需要充分考虑其服务间的调用关系是否重要和是否对外暴露，本申请实施例根据应用域将集群进行区分隔离，并且本申请实施例还通过服务网关注册并暴露到外部，实现提供集群外的服务调用，减少集群域下的服务过度膨胀的可能，同时也降低服务间的耦合。在完成跨集群调用的服务后，将此类服务通过接口的方式注册到应用服务网关上，实现系统间的跨域交互。同时根据应用域将集群进行区分隔离，可以有效的降低单个集群内服务的数量，减少集群管理的复杂性，同时降低某个服务因异常停服或降质带来的对整体系统服务的影响。

本实施例中，接收客户端的服务请求，并对服务请求进行解析，以获取服务请求标识、请求端信息以及目标端信息；基于服务请求标识，判断服务请求对应的请求路径，得到判断结果，其中，请求路径包括集群内服务请求和跨集群服务请求；若判断结果为集群内服务请求，则将请求端信息以及目标端信息注入头部信息中，以在服务注册中心获取服务请求对应的目标应用域和目标服务，以及在目标应用域中调用目标服务，并通过目标服务处理服务请求；若判断结果为跨集群服务请求，则将请求端信息以及目标端信息注入头部信息中，并通过服务网关，将头部信息注入到集群关系信息中，以获取目标服务，并通过目标服务处理服务请求。本发明实施例通过判断服务请求对应的请求路径，若请求路径为集群内服务请求，则利用注入头部信息的方式，调用目标服务，以及若请求路径为跨集群服务请求，利用服务网关的方式，进行调用目标服务，实现降低了集群下服务粒度细、服务数量多带来的管理难度，同时避免了原生的服务实例的侵入，从而有利于提高服务请求处理的效率。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，前述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)等非易失性存储介质，或随机存储记忆体(Random Access Memory，RAM)等。

请参考图8，作为对上述图1所示方法的实现，本申请提供了一种基于大规模集群的服务请求处理装置的一个实施例，该装置实施例与图1所示的方法实施例相对应，该装置具体可以应用于各种电子设备中。

如图8所示，本实施例的基于大规模集群的服务请求处理装置包括：服务请求接收模块51、请求路径判断模块52、集群内请求处理模块53、跨集群请求处理模块54，其中：

服务请求接收模块51，用于接收客户端的服务请求，并对服务请求进行解析，以获取服务请求标识、请求端信息以及目标端信息；

请求路径判断模块52，用于基于服务请求标识，判断服务请求对应的请求路径，得到判断结果，其中，请求路径包括集群内服务请求和跨集群服务请求；

集群内请求处理模块53，用于若判断结果为集群内服务请求，则将请求端信息以及目标端信息注入头部信息中，以在服务注册中心获取服务请求对应的目标应用域和目标服务，以及在目标应用域中调用目标服务，并通过目标服务处理服务请求；

跨集群请求处理模块54，用于若判断结果为跨集群服务请求，则将请求端信息以及目标端信息注入头部信息中，并通过服务网关，将头部信息注入到集群关系信息中，以获取目标服务，并通过目标服务处理服务请求。

进一步的，集群内请求处理模块53包括：

链路追踪日志标识生成单元，用于若判断结果为集群内服务请求，则将请求端信息以及目标端信息注入头部信息中，生成链路追踪日志标识；

服务注册中心遍历单元，用于基于链路追踪日志标识，遍历服务注册中心，获取服务请求对应的目标应用域和目标服务；

域名解析单元，用于解析目标应用域对应的域名，以调用目标服务，并通过目标服务处理服务请求。

进一步的，域名解析单元包括：

IP地址生成子单元，用于通过CoreDNS解析方式，解析目标应用域对应的域名，得到目标服务部署单元Pod的IP地址；

服务请求处理单元，用于基于目标服务部署单元Pod的IP地址，调用目标服务，并通过目标服务处理服务请求。

进一步的，集群内请求处理模块53之前还包括：

服务镜像存储模块，用于获取多种服务，并将多种服务进行编译打包，生成服务镜像，并将服务镜像置入到服务镜像仓库中；

应用域配置模块，用于获取服务对应的应用域，并基于应用域，将服务配于对应的集群中；

根节点生成模块，用于在服务注册中心中，对集群中的应用域作为根节点并进行初始化处理，得到应用域对应的根节点。

进一步的，根节点生成模块之后还包括：

服务变更通知生成模块，用于若监听到服务发送变更，则在服务注册中心生成服务变更通知；

服务变更内容存储模块，用于将服务变更通知发送到客户端，以使得客户端获取服务变更内容以及将服务变更内容存储于客户端本地中。

进一步的，服务请求接收模块51之后还包括：

时间记录模块，用于记录客户端对服务请求的发起时间和响应时间，以及记录服务器对服务请求的接收时间和响应返回时间；

日志信息生成模块，用于基于发起时间、响应时间、接收时间、响应返回时间以及头部信息，生成日志信息。

进一步的，跨集群请求处理模块54包括：

目标头部信息生成单元，用于若判断结果为跨集群服务请求，则将请求端信息以及目标端信息注入头部信息中，得到目标头部信息；

集群信息生成单元，用于采用服务网关，将目标头部信息注入到集群关系信息中，生成集群信息；

目标服务获取单元，用于在集群关系信息中，通过对集群信息进行收集和转发处理，以获取目标服务，并通过目标服务处理服务请求。

为解决上述技术问题，本申请实施例还提供计算机设备。具体请参阅图9，图9为本实施例计算机设备基本结构框图。

计算机设备6包括通过系统总线相互通信连接存储器61、处理器62、网络接口63。需要指出的是，图中仅示出了具有三种组件存储器61、处理器62、网络接口63的计算机设备6，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。其中，本技术领域技术人员可以理解，这里的计算机设备是一种能够按照事先设定或存储的指令，自动进行数值计算和/或信息处理的设备，其硬件包括但不限于微处理器、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程门阵列(Field－Programmable Gate Array，FPGA)、数字处理器(Digital SignalProcessor，DSP)、嵌入式设备等。

计算机设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。计算机设备可以与用户通过键盘、鼠标、遥控器、触摸板或声控设备等方式进行人机交互。

存储器61至少包括一种类型的可读存储介质，可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，存储器61可以是计算机设备6的内部存储单元，例如该计算机设备6的硬盘或内存。在另一些实施例中，存储器61也可以是计算机设备6的外部存储设备，例如该计算机设备6上配备的插接式硬盘，智能存储卡(SmartMedia Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。当然，存储器61还可以既包括计算机设备6的内部存储单元也包括其外部存储设备。本实施例中，存储器61通常用于存储安装于计算机设备6的操作系统和各类应用软件，例如基于大规模集群的服务请求处理方法的程序代码等。此外，存储器61还可以用于暂时地存储已经输出或者将要输出的各类数据。

处理器62在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器62通常用于控制计算机设备6的总体操作。本实施例中，处理器62用于运行存储器61中存储的程序代码或者处理数据，例如运行上述基于大规模集群的服务请求处理方法的程序代码，以实现基于大规模集群的服务请求处理方法的各种实施例。

网络接口63可包括无线网络接口或有线网络接口，该网络接口63通常用于在计算机设备6与其他电子设备之间建立通信连接。

本申请还提供了另一种实施方式，即提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序可被至少一个处理器执行，以使至少一个处理器执行如上述的一种基于大规模集群的服务请求处理方法的步骤。

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

本发明所指区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层等。

显然，以上所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例，附图中给出了本申请的较佳实施例，但并不限制本申请的专利范围。本申请可以以许多不同的形式来实现，相反地，提供这些实施例的目的是使对本申请的公开内容的理解更加透彻全面。尽管参照前述实施例对本申请进行了详细的说明，对于本领域的技术人员来而言，其依然可以对前述各具体实施方式所记载的技术方案进行修改，或者对其中部分技术特征进行等效替换。凡是利用本申请说明书及附图内容所做的等效结构，直接或间接运用在其他相关的技术领域，均同理在本申请专利保护范围之内。

Claims (10)

1.一种基于大规模集群的服务请求处理方法，其特征在于，包括：

接收客户端的服务请求，并对所述服务请求进行解析，以获取服务请求标识、请求端信息以及目标端信息；

基于所述服务请求标识，判断所述服务请求对应的请求路径，得到判断结果，其中，所述请求路径包括集群内服务请求和跨集群服务请求；

若所述判断结果为所述集群内服务请求，则将所述请求端信息以及所述目标端信息注入头部信息中，以在服务注册中心获取所述服务请求对应的目标应用域和目标服务，以及在所述目标应用域中调用所述目标服务，并通过所述目标服务处理所述服务请求；

若所述判断结果为所述跨集群服务请求，则将所述请求端信息以及所述目标端信息注入所述头部信息中，并通过服务网关，将所述头部信息注入到集群关系信息中，以获取所述目标服务，并通过所述目标服务处理所述服务请求。

2.根据权利要求1所述的基于大规模集群的服务请求处理方法，其特征在于，所述若所述判断结果为所述集群内服务请求，则将所述请求端信息以及所述目标端信息注入头部信息中，以在服务注册中心获取所述服务请求对应的目标应用域和目标服务，以及在所述目标应用域中调用所述目标服务，并通过所述目标服务处理所述服务请求，包括：

若所述判断结果为所述集群内服务请求，则将所述请求端信息以及所述目标端信息注入头部信息中，生成链路追踪日志标识；

基于所述链路追踪日志标识，遍历所述服务注册中心，获取所述服务请求对应的目标应用域和目标服务；

解析所述目标应用域对应的域名，以调用所述目标服务，并通过所述目标服务处理所述服务请求。

3.根据权利要求2所述的基于大规模集群的服务请求处理方法，其特征在于，所述解析所述目标应用域对应的域名，以调用所述目标服务，并通过所述目标服务处理所述服务请求，包括：

通过CoreDNS解析方式，解析所述目标应用域对应的域名，得到目标服务部署单元Pod的IP地址；

基于所述目标服务部署单元Pod的IP地址，调用所述目标服务，并通过所述目标服务处理所述服务请求。

4.根据权利要求1所述的基于大规模集群的服务请求处理方法，其特征在于，所述判断结果为所述集群内服务请求，则将所述请求端信息以及所述目标端信息注入头部信息中，以在服务注册中心获取所述服务请求对应的目标应用域和目标服务，以及在所述目标应用域中调用所述目标服务，并通过所述目标服务处理所述服务请求之前，所述方法还包括：

获取多种服务，并将多种所述服务进行编译打包，生成服务镜像，并将所述服务镜像置入到服务镜像仓库中；

获取所述服务对应的应用域，并基于所述应用域，将所述服务配于对应的集群中；

在所述服务注册中心中，对集群中的所述应用域作为根节点并进行初始化处理，得到应用域对应的根节点。

5.根据权利要求4所述的基于大规模集群的服务请求处理方法，其特征在于，所述在所述服务注册中心中，对集群中的所述应用域作为根节点并进行初始化处理，得到应用域对应的根节点之后，所述方法还包括：

若监听到所述服务发送变更，则在所述服务注册中心生成服务变更通知；

将所述服务变更通知发送到所述客户端，以使得所述客户端获取所述服务变更内容以及将所述服务变更内容存储于客户端本地中。

6.根据权利要求1所述的基于大规模集群的服务请求处理方法，其特征在于，所述接收客户端的服务请求，并对所述服务请求进行解析，以获取服务请求标识、请求端信息以及目标端信息之后，所述方法还包括：

记录所述客户端对所述服务请求的发起时间和响应时间，以及记录服务器对所述服务请求的接收时间和响应返回时间；

基于所述发起时间、所述响应时间、接收时间、响应返回时间以及所述头部信息，生成日志信息。

7.根据权利要求1至6任一项所述的基于大规模集群的服务请求处理方法，其特征在于，所述若所述判断结果为所述跨集群服务请求，则将所述请求端信息以及所述目标端信息注入所述头部信息中，并通过服务网关，将所述头部信息注入到集群关系信息中，以获取所述目标服务，并通过所述目标服务处理所述服务请求，包括：

若所述判断结果为所述跨集群服务请求，则将所述请求端信息以及所述目标端信息注入所述头部信息中，得到目标头部信息；

采用所述服务网关，将所述目标头部信息注入到集群关系信息中，生成集群信息；

在所述集群关系信息中，通过对所述集群信息进行收集和转发处理，以获取所述目标服务，并通过所述目标服务处理所述服务请求。

8.一种基于大规模集群的服务请求处理装置，其特征在于，包括：

服务请求接收模块，用于接收客户端的服务请求，并对所述服务请求进行解析，以获取服务请求标识、请求端信息以及目标端信息；

请求路径判断模块，用于基于所述服务请求标识，判断所述服务请求对应的请求路径，得到判断结果，其中，所述请求路径包括集群内服务请求和跨集群服务请求；

集群内请求处理模块，用于若所述判断结果为所述集群内服务请求，则将所述请求端信息以及所述目标端信息注入头部信息中，以在服务注册中心获取所述服务请求对应的目标应用域和目标服务，以及在所述目标应用域中调用所述目标服务，并通过所述目标服务处理所述服务请求；

跨集群请求处理模块，用于若所述判断结果为所述跨集群服务请求，则将所述请求端信息以及所述目标端信息注入所述头部信息中，并通过服务网关，将所述头部信息注入到集群关系信息中，以获取所述目标服务，并通过所述目标服务处理所述服务请求。

9.一种计算机设备，其特征在于，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器执行所述计算机程序时实现如权利要求1至7中任一项所述的基于大规模集群的服务请求处理方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述的基于大规模集群的服务请求处理方法。

Images