[go: up one dir, main page]

CN111752681B - 请求处理方法、装置、服务器和计算机可读存储介质 - Google Patents

请求处理方法、装置、服务器和计算机可读存储介质 Download PDF

Info

Publication number
CN111752681B
CN111752681B CN202010601316.1A CN202010601316A CN111752681B CN 111752681 B CN111752681 B CN 111752681B CN 202010601316 A CN202010601316 A CN 202010601316A CN 111752681 B CN111752681 B CN 111752681B
Authority
CN
China
Prior art keywords
target
service
resource
external communication
deployed
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202010601316.1A
Other languages
English (en)
Other versions
CN111752681A (zh
Inventor
喻先兵
何庭耀
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guangzhou Huaduo Network Technology Co Ltd
Original Assignee
Guangzhou Huaduo Network Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Guangzhou Huaduo Network Technology Co Ltd filed Critical Guangzhou Huaduo Network Technology Co Ltd
Priority to CN202010601316.1A priority Critical patent/CN111752681B/zh
Publication of CN111752681A publication Critical patent/CN111752681A/zh
Application granted granted Critical
Publication of CN111752681B publication Critical patent/CN111752681B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请涉及一种请求处理方法、装置、服务器和计算机可读存储介质。所述方法包括：接收客户端发送的服务请求，所述服务请求携带有目标URI；基于所述目标URI查询配置文件，得到能够响应所述服务请求的多个目标服务的对外通信地址，其中，各所述目标服务部署于容器或者物理机中，所述配置文件包括URI与部署于容器或者物理机的服务的对外通信地址的对应关系；基于预设的负载均衡策略，从所述多个目标服务中确定标的服务，基于所述标的服务的对外通信地址将所述服务请求定向至所述标的服务。采用本方法能够基于Kubernetes让部署在物理机中的服务响应客户端的服务请求。

Description

请求处理方法、装置、服务器和计算机可读存储介质
技术领域
本申请涉及互联网技术领域，特别是涉及一种请求处理方法、装置、服务器和计算机可读存储介质。
背景技术
Kubernetes是一个开源的、用于管理容器化的服务的集群，Kubernetes的目标是让部署容器化的服务简单并且高效，Kubernetes提供了服务的应用部署，规划，更新，维护。
目前，很多企业的早期服务都是部署在物理机上的，在企业实现容器化、进行服务迁移的过程中，部分存在依赖关系的服务仍然需要继续部署在物理机中。
因此，如何基于Kubernetes让部署在物理机中的服务能够响应客户端的服务请求，成为目前亟待解决的问题。
发明内容
基于此，有必要针对上述技术问题，提供一种能够基于Kubernetes让部署在物理机中的服务响应客户端的服务请求的请求处理方法、装置、服务器和计算机可读存储介质。
第一方面，提供了一种请求处理方法，所述方法包括：
接收客户端发送的服务请求，所述服务请求携带有目标URI；
基于所述目标URI查询配置文件，得到能够响应所述服务请求的多个目标服务的对外通信地址，其中，各所述目标服务部署于容器或者物理机中，所述配置文件包括URI与部署于容器或者物理机的服务的对外通信地址的对应关系；
基于预设的负载均衡策略，从所述多个目标服务中确定标的服务，基于所述标的服务的对外通信地址将所述服务请求定向至所述标的服务。
在其中一个实施例中，所述基于所述目标URI查询配置文件之前，所述方法还包括：
获取至少一个Ingress资源，各所述Ingress资源包括URI和service资源名；
对于各所述Ingress资源，基于所述Ingress资源包括的service资源名查找目标service资源，基于所述目标service资源中的指示信息，获取与所述目标service资源相关联的部署于物理机或者容器的服务的对外通信地址，并建立所述Ingress资源包括的URI和与所述目标service资源相关联的服务的对外通信地址的对应关系；
基于各所述对应关系，创建所述配置文件。
在其中一个实施例中，所述指示信息包括自定义资源名，所述基于所述目标service资源中的指示信息，获取与所述目标service资源相关联的部署于物理机或者容器的服务的对外通信地址，包括：
基于所述自定义资源名查找目标自定义资源，所述目标自定义资源包括第一对外通信地址，所述第一对外通信地址为与所述目标service资源相关联的部署于物理机中的服务的对外通信地址；
从所述目标自定义资源中获取所述第一对外通信地址。
在其中一个实施例中，所述目标service资源包括注解字段，所述注解字段包括所述自定义资源名。
在其中一个实施例中，所述目标自定义资源包括spec字段，所述spec字段包括所述第一对外通信地址；
所述目标自定义资源还包括apiVersion字段、kind字段、metadata字段以及健康检查字段中的至少一个，其中，所述apiVersion字段包括所述目标自定义资源的版本信息，所述kind字段包括所述目标自定义资源的类型信息，所述metadata字段包括所述目标自定义资源的名称以及所述目标自定义资源的命名空间信息，所述健康检查字段包括健康检查地址，所述健康检查地址用于供所述服务器对与所述目标service资源相关联的部署于物理机中的服务进行健康检查。
在其中一个实施例中，在所述目标自定义资源包括所述健康检查字段的情况下，所述方法还包括：
基于所述健康检查地址和所述第一对外通信地址，生成目标地址；
向所述目标地址发送健康检查指令，得到返回结果，所述返回结果用于表征所述第一对外通信地址对应的部署于物理机中的服务存活或者不存活；
若根据所述返回结果确定所述第一对外通信地址对应的部署于物理机中的服务不存活，则将所述配置文件中的所述第一对外通信地址删除。
在其中一个实施例中，所述指示信息包括Pod资源标签以及第二对外通信地址的第一部分，所述第二对外通信地址为与所述目标service资源相关联的部署于容器中的服务的对外通信地址，所述基于所述目标service资源中的指示信息，获取与所述目标service资源相关联的部署于物理机或者容器的服务的对外通信地址，包括：
基于所述Pod资源标签查找目标Pod资源，所述目标Pod资源包括所述第二对外通信地址的第二部分；
从所述目标Pod资源中获取所述第二部分，并基于所述第一部分和所述第二部分生成所述第二对外通信地址。
第二方面，提供了一种请求处理装置，所述装置包括：
第一控制模块，用于接收客户端发送的服务请求，所述服务请求携带有目标URI；
第二控制模块，用于基于所述目标URI查询配置文件，得到能够响应所述服务请求的多个目标服务的对外通信地址，其中，各所述目标服务部署于容器或者物理机中，所述配置文件包括URI与部署于容器或者物理机的服务的对外通信地址的对应关系；
第三控制模块，用于基于预设的负载均衡策略，从所述多个目标服务中确定标的服务，基于所述标的服务的对外通信地址将所述服务请求定向至所述标的服务。
第三方面，提供了一种服务器，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现如上述第一方面所述的请求处理方法。
第四方面，提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时如上述第一方面所述的请求处理方法。
本申请实施例提供的技术方案带来的有益效果至少包括：
传统技术中，在企业实现容器化的过程中，企业早期部署在物理机中的服务将被迁移至Kubernetes的容器内。服务器可以将客户端发送的服务请求定向至某一个容器内的服务，由该服务响应该服务请求。但在实际的容器化过程中，由于一些企业担心容器不稳定可能会导致服务崩溃，或由于某些存在依赖关系的服务必须部署在物理机中，因此仍然会有部分服务继续部署在物理机中；但是，上述传统技术中服务器并不能将客户端的服务请求定向至部署在物理中的服务，这就无法满足实际的业务需求。
本申请实施例提供的技术方案，通过接收客户端发送的服务请求，其中，服务请求携带有目标URI；而后，基于该目标URI查询配置文件，得到能够响应该服务请求的多个目标服务的对外通信地址，其中，各目标服务部署于容器或者物理机中，配置文件包括URI与部署于容器或者物理机的服务的对外通信地址的对应关系；再基于预设的负载均衡策略，从该多个目标服务中确定标的服务，基于该标的服务的对外通信地址将服务请求定向至该标的服务。由于配置文件中包括部署于物理机的服务的对外通信地址，因此，服务器可以发现配置文件中包括的部署在物理机中的服务，从而能够将服务请求定向至部署在物理机中的标的服务，实现了基于Kubernetes让部署在物理机中的服务能够响应客户端的服务请求，可以更好地满足客户需求。
附图说明
图1为一个实施例中请求处理方法的应用环境图；
图2为一个实施例中请求处理方法的流程示意图；
图3-1为另一个实施例中请求处理方法的流程示意图；
图3-2为一种示例性的基于Kubernetes的服务架构示意图；
图4为另一个实施例中服务器进行健康检查的流程示意图；
图5为另一个实施例中请求处理方法的流程示意图；
图6为一个实施例中请求处理装置的结构框图；
图7为另一个实施例中请求处理装置的结构框图；
图8为一个实施例中服务器的内部结构图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
Kubernetes是一个用于管理容器化的服务的集群。在Kubernetes中，定义了各种各样的资源，例如，Service，Pod等。其中，Pod是Kubernetes中的最小部署单元，Pod是一个环境(包括容器、存储、ip地址:端口号、容器配置)，Pod中可以运行一个或多个容器，在一个Pod内部的容器共享所有资源，包括共享Pod的endpoint（ip地址:端口号）和磁盘；Service用于对部署于容器内的服务的自动发现。
Ingress也是Kubernetes中定义的一种资源，Ingress用于将Kubernetes中部署的服务对外暴露。它定义了一组可以供客户端访问的域名、URI、SSL以及Service资源名等，通过Ingress，可以供客户端访问部署在Kubernetes的容器中的服务。但是，Ingress本身并不能进行流量穿透，它仅仅是规则的集合，这些规则想要发挥作用则必须依靠Ingresscontroller来实现。
Ingress controller可以部署在服务器中，负责在Kubernetes实现Ingress。同时该服务器中还可以部署Nginx，Ingress controller通过与 Kubernetes API交互，动态地去感知Kubernetes 中Ingress的规则变化，然后读取该规则变化，按照模板生成Nginx的配置文件，并将该配置文件写入Nginx，Nginx则可以按照该配置文件将客户端的服务请求定向至某一个容器内的服务，由该服务响应该服务请求。
然而，Pod主要供服务所在集群的内部访问使用，对于集群外的客户端是不可见的，而Ingress只定义了外部流量到达Pod，即按照Ingress的定义，客户端的服务请求只能到达部署在容器内的服务。如果存在客户担心容器不稳定需要部分服务部署在物理机中，或由于某些存在依赖关系的服务必须部署在物理机中的情况，这就导致服务器并不能将客户端的服务请求定向至部署在物理中的服务，无法满足实际的业务需求。
考虑到以上情况，本申请实施例提供了一种请求处理方法、装置、服务器和计算机可读存储介质，在该方法中，服务器接收客户端发送的服务请求，其中，服务请求携带有目标URI；而后，基于该目标URI查询配置文件，查询后得到能够响应该服务请求的多个目标服务的对外通信地址，其中，各目标服务部署于容器或者物理机中，配置文件包括URI与部署于容器或者物理机的服务的对外通信地址的对应关系；再基于预设的负载均衡策略，从该多个目标服务中确定标的服务，基于该标的服务的对外通信地址将服务请求定向至该标的服务。这样，由于配置文件中包括部署于物理机的服务的对外通信地址，所以服务器能够将服务请求定向至部署在物理机中的标的服务，由此，实现了基于Kubernetes让部署在物理机中的服务能够响应客户端的服务请求，从而可以更好地满足客户需求。
下面，将对本申请实施例提供的请求处理方法所涉及到的实施环境进行简要说明。
如图1所示，该实施环境可以包括客户端101、服务器102、Kubernetes103以及物理机104。服务器102可以通过网络与客户端101通信，服务器102也可以通过网络与Kubernetes103和物理机104进行通信。
其中，服务器102可以是一台服务器，也可以是由多台服务器组成的服务器集群，服务器102可以是塔式服务器、机架服务器、刀片式服务器、高密度服务器、单路服务器、双路服务器或者多路服务器等，本申请实施例对服务器102的类型不作具体限定。其中，客户端101可以是个人计算机、笔记本电脑、媒体播放器、智能电视、智能手机、平板电脑和便携式可穿戴设备等，本申请实施例对客户端101的类型也不作具体限定。
在一个实施例中，如图2所示，提供了一种请求处理方法，以该方法应用于图1中的服务器为例进行说明，该方法包括步骤S100、步骤S200以及步骤S300：
步骤S100，服务器接收客户端发送的服务请求。
客户端需要获取某一服务时，客户端则发送服务请求，服务器接收客户端发送的服务请求。本申请实施例中，客户端发送的服务请求携带有目标URI。在一种可能的实施方式中，客户端需要的服务可以是访问某一网页，则该目标URI可以是客户端需要访问的网页的URI。
步骤S200，服务器基于目标URI查询配置文件，得到能够响应服务请求的多个目标服务的对外通信地址。
本申请实施例中，配置文件包括URI与部署于Kubernetes的容器或者物理机的服务的对外通信地址的对应关系。服务器基于目标URI查询配置文件，可以是在配置文件中查找与该目标URI对应的多个目标服务的对外通信地址，由此得到能够响应该服务请求的多个目标服务的对外通信地址，其中，各目标服务部署于容器或者物理机中。
本申请实施例中，配置文件可以是服务器通过服务器中部署的Ingresscontroller创建的。配置文件可以包括多个URI，每个URI在配置文件中可以对应多个服务的对外通信地址，每个URI对应的多个服务均可以响应携带对应URI的服务请求，每个URI在配置文件中对应的各服务可以部署在容器或者部署在物理机中。
作为一种实施方式，配置文件中的URI由域名部分和路径部分组成，例如，域名部分“**.com”和路径部分“/*”组成的URI为“http://**.com/*”，其中“http://”为协议标识。在一种可能的实施方式中，例如该URI在配置文件中对应有10个服务的对外通信地址，这10个服务中，其中6个服务部署在容器中，另外4个服务部署在物理机中，这10个服务中每个服务均可以提供客户端访问该URI“http://**.com/*”对应的网页。若客户端发送的服务请求携带的目标URI也为“http://**.com/*”，服务器则在配置文件中查找出与该目标URI“http://**.com/*”对应的10个目标服务（即上述的10个服务）的对外通信地址，这10个目标服务中有6个目标服务部署在容器中，另外4个目标服务部署在物理机中。
在一种可能的实施方式中，目标服务的对外通信地址可以包括IP地址和端口号。若目标服务是部署在物理机中的，则该IP地址为部署该目标服务的物理机的IP地址；若目标服务是部署在容器内的，则该IP地址为部署该容器的Pod的IP地址。
步骤S300，服务器基于预设的负载均衡策略，从多个目标服务中确定标的服务，基于标的服务的对外通信地址将服务请求定向至标的服务。
服务器从配置文件中查找出与该目标URI对应的多个目标服务的对外通信地址后，按照预设的负载均衡策略，从多个目标服务中确定标的服务，该标的服务用于响应该服务请求。
在一种可能的实施方式中，本申请实施例服务器中部署有Nginx，Nginx在Kubernetes中主要负责向外暴露服务，同时提供负载均衡等功能，服务器基于Nginx 对后端部署的服务提供反向代理。
本申请实施例中，配置文件为Nginx的配置文件，Nginx的配置文件中配置有URI与部署于容器或者物理机的服务的对外通信地址的对应关系；当客户端需要访问Kubernetes中部署的服务时，客户端只需要发送服务请求至服务器，服务器运行Nginx来选择部署于容器或者物理机的标的服务对该服务请求作出响应，由此，实现了Nginx的反向代理功能。
服务器运行Nginx，选择部署于容器或者物理机的标的服务对该服务请求作出响应时，需要基于预设的负载均衡策略，从多个目标服务中确定标的服务。本申请实施例中，预设的负载均衡策略可以是预先配置在Nginx中的，该负载均衡策略可以是轮询策略、随机策略或者最小连接策略。其中，轮询策略是将接收到的服务请求轮流分配至该服务请求对应的多个目标服务中；随机策略是将接收到的服务请求随机分配至该服务请求对应的多个目标服务中的任意一个中；最小连接策略是将接收到的服务请求分配给该服务请求对应的多个目标服务中，当前具有最小连接数的目标服务中。以预设的负载均衡策略是最小连接策略为例，服务器运行Nginx，从多个目标服务中确定当前具有最小连接数的目标服务作为标的服务，并将该服务请求转发至该标的服务的对外通信地址中，由该标的服务响应该服务请求，由此，实现了Nginx的负载均衡功能。
由此，若多个目标服务中某一个部署在物理机中的目标服务满足该预设的负载均衡策略，服务器则确定该目标服务为标的服务。
上述请求处理方法，服务器通过接收客户端发送的服务请求，其中，服务请求携带有目标URI；而后，基于该目标URI查询配置文件，查询后得到能够响应该服务请求的多个目标服务的对外通信地址，其中，各目标服务部署于容器或者物理机中，配置文件包括URI与部署于容器或者物理机的服务的对外通信地址的对应关系；再基于预设的负载均衡策略，从该多个目标服务中确定标的服务，基于该标的服务的对外通信地址将服务请求定向至该标的服务。这样，由于配置文件包括URI与部署于容器或者物理机的服务的对外通信地址的对应关系，因此，服务器可以发现配置文件中包括的部署在物理机中的服务，进而能够将服务请求定向至部署在物理机中的标的服务，实现了基于Kubernetes让部署在物理机中的服务能够响应客户端的服务请求，可以更好地满足客户需求。
可以理解的是，本申请实施例中，由于服务器可以发现配置文件中包括的部署在物理机中的服务，在容器不稳定的情况下，通过将服务请求定向至部署在物理机中的标的服务，可以避免由于容器不稳定造成的服务崩溃。因此，本申请实施例还可以提升服务可靠性，降低服务崩溃的风险。
在一个实施例中，基于上述图2所示的实施例，本实施例涉及的是服务器如何创建配置文件的过程。如图3-1所示，本实施例中，步骤S200之前还包括步骤S400、步骤S500和步骤S600：
步骤S400，服务器获取至少一个Ingress资源。
本申请实施例中，服务器以Nginx作为负载均衡器实现数据面，服务器通过运行Ingress controller程序实现控制面。服务器运行Ingress controller，则可以获取Kubernetes中创建的Ingress资源来生成Nginx的配置文件。
参见图3-2，其为一种示例性的基于Kubernetes的服务架构示意图。如图3-2所示，Kubernetes整个架构分为主节点（又称master节点）和子节点（又称node节点），主节点提供Kubernetes的集群控制，Pod部署在子节点中，一个Pod中可以部署多个容器。需要说明的是，图3-2中示出的结构，并不对本申请实施例在实际实施时，可以设置的子节点的数量、子节点中Pod的数量、物理机的数量以及部署在物理机中服务的数量构成限制。
请继续参见图3-2，服务器运行Ingress controller，通过Ingress controller与Kubernetes的主节点中的API-Server（API服务器）交互，在Ingress资源发生变化后，从APIServer获取至少一个Ingress资源，各Ingress资源包括URI和Service资源名，并根据该Ingress资源生成Nginx的配置文件。
步骤S500，对于各Ingress资源，服务器基于Ingress资源包括的Service资源名查找目标Service资源，基于目标Service资源中的指示信息，获取与目标Service资源相关联的部署于物理机或者容器的服务的对外通信地址，并建立Ingress资源包括的URI和与目标Service资源相关联的服务的对外通信地址的对应关系。
在一种可能的实施方式中，服务器通过Ingress controller从API-Server获取Ingress资源时，一并获取Service资源以及部署于物理机或者容器的服务的对外通信地址，并将获取的数据存入Ingress controller的缓存。
本申请实施例中，每个Ingress资源包括URI和Service资源名，作为一种实施方式，Ingress资源可以包括host字段和path字段，host字段包括的为域名部分，path字段包括的为路径部分，域名部分和路径部分则组成了该Ingress资源对应的URI。例如，一个Ingress资源包括的host字段为“host: **.com”，path字段为“path: /*”，则该Ingress资源对应的URI为“host://**.com/*”。
对于一个Ingress资源，服务器在缓存中查找该Ingress资源包括的Service资源名对应的目标Service资源，该目标Service资源的资源名与该Ingress资源包括的Service资源名一致。
本申请实施例中，目标Service资源包括指示信息，服务器从缓存中查找该指示信息对应的部署于物理机或者容器的服务的对外通信地址，得到与目标Service资源相关联的部署于物理机或者容器的服务的对外通信地址。
在一种可能的实施方式中，该指示信息包括自定义资源名。步骤S500中，服务器基于目标Service资源中的指示信息，获取与目标Service资源相关联的部署于物理机或者容器的服务的对外通信地址的过程，可以通过执行下述步骤A1和步骤A2实现：
步骤A1，服务器基于自定义资源名查找目标自定义资源。
服务器从缓存中查找资源名称为该自定义资源名的目标自定义资源。该目标自定义资源包括第一对外通信地址，该第一对外通信地址为与目标Service资源相关联的部署于物理机中的服务的对外通信地址。
步骤A2，服务器从目标自定义资源中获取第一对外通信地址。
在一种可能的实施方式中，目标Service资源包括annotations注解字段，该注解字段包括自定义资源名。
例如，目标自定义资源的自定义资源名为phyendpoint-sample，目标Service资源的注解字段可以采用如下方式表示：
“annotations:
aquaman.yy.com/physical.deployment.endpoints: phyendpoint-sample”
由此，利用目标Service资源的注解字段将目标Service资源与目标自定义资源关联。服务器基于目标Service资源中的注解字段包括的自定义资源名，可以在缓存中查找到目标自定义资源，避免了传统技术中Service资源仅包括用于发现Pod的字段，如果服务部署在物理机中，基于传统技术中的Service资源则无法发现部署于物理机中的服务的问题。
本申请实施例中，目标自定义资源定义了部署于物理机中的服务，在一种可能的实施方式中，目标自定义资源包括spec字段，spec字段包括第一对外通信地址。
本申请实施例中，目标自定义资源是利用Kubernetes的自定义资源功能实现的。以目标自定义资源定义部署在物理机10.21.2.49与10.21.2.48上且端口为8084的服务为例，则目标自定义资源的spec字段中可以包括：
“endpoints:10.21.2.49:8084，10.21.2.48:8084”
该endpoints则表示部署在物理机10.21.2.49上的服务的第一对外通信地址为10.21.2.49:8084、部署在物理机10.21.2.48上的服务的第一对外通信地址为10.21.2.48:8084。
作为一种实施方式，目标自定义资源还可以包括apiVersion字段、kind字段、metadata字段以及健康检查字段中的至少一个，其中，apiVersion字段包括目标自定义资源的版本信息，kind字段包括目标自定义资源的类型信息，metadata字段包括目标自定义资源的名称以及目标自定义资源的命名空间信息，健康检查字段包括健康检查地址，健康检查地址用于供服务器对与目标Service资源相关联的部署于物理机中的服务进行健康检查。
例如，apiVersion: thor.aquaman.io/v1beta1，可以表示目标自定义资源的版本为 thor.aquaman.io/v1beta1；kind: PhyEndpoint，可以表示目标自定义资源的类型为PhyEndpoint；name: phyendpoint-sample，可以表示目标自定义资源的名称为phyendpoint-sample；namespace: test，可以表示目标自定义资源的命名空间为test；健康检查字段http_check_path: /conf/以及Interval: 10中，/conf/可以表示健康检查地址，Interval: 10可以表示健康检查的时间周期，等等。
由此，通过将部署在物理机中的服务以目标自定义资源的方式定义，并利用目标Service资源的注解字段将目标Service资源与目标自定义资源关联，服务器基于目标Service资源则可以发现部署于物理机中的服务，并可以获取目标自定义资源包括的与目标Service资源相关联的部署于物理机中的服务的对外通信地址，即第一通信地址。
服务器从目标自定义资源中获取第一对外通信地址后，建立Ingress资源包括的URI和与目标Service资源相关联的服务的对外通信地址的对应关系，也即，将Ingress资源包括的URI与第一对外通信地址进行关联。
在另一种可能的实施方式中，指示信息包括Pod资源标签以及第二对外通信地址的第一部分，第二对外通信地址为与目标Service资源相关联的部署于容器中的服务的对外通信地址。上述步骤S500中，服务器基于目标Service资源中的指示信息，获取与目标Service资源相关联的部署于物理机或者容器的服务的对外通信地址的过程，可以通过执行下述步骤B1和步骤B2实现：
步骤B1，服务器基于Pod资源标签查找目标Pod资源，其中，目标Pod资源包括第二对外通信地址的第二部分。
服务器基于Pod资源标签在缓存中查找具有该Pod资源标签的目标Pod资源，该目标Pod资源包括第二对外通信地址的第二部分。
在一种可能的实施方式中，目标Service资源的“labels”部分包括的内容即为Pod资源标签，目标Service资源的“port”部分即为第二对外通信地址的第一部分，该第二对外通信地址为与目标Service资源相关联的部署于容器中的服务的对外通信地址。
本申请实施例通中，通过在目标Service资源的注解字段中添加部署于物理机中的服务的第一对外通信地址，同时，目标Service资源原有的功能可以关联到Pod资源标签对应的部署于容器中的服务。由此，本申请实施例通过改造传统Service资源中服务的发现逻辑，改造后的目标Service资源除了可以识别出Pod，即识别出部署在容器中的服务，同时还能发现物理机上部署的服务。
步骤B2，服务器从目标Pod资源中获取第二部分，并基于第一部分和第二部分生成第二对外通信地址。
在一个可能的实施方式中，第二对外通信地址包括IP地址和端口号，第一部分为端口号，第二部分为IP地址。服务器将获取的第一部分和第二部分以IP地址：端口号的形式组合，得到第二对外通信地址，该第二对外通信地址为与目标Service资源相关联的部署于容器中的服务的对外通信地址。
服务器生成第二对外通信地址后，通过运行Ingress controller建立Ingress资源包括的URI和与目标Service资源相关联的服务的对外通信地址的对应关系，也即，将Ingress资源包括的URI与第二对外通信地址进行关联。
步骤S600，服务器基于各对应关系，创建配置文件。
服务器基于URI与部署于物理机的服务的对外通信地址的对应关系以及URI与部署于容器的服务的对外通信地址的对应关系，创建Nginx的配置文件，创建的配置文件中包括URI与部署于容器以及物理机的服务的对外通信地址的对应关系，部署于容器以及物理机的服务均可以提供针对该URI的服务。
服务器将创建的配置文件刷新至Nginx中，这样，服务器接收到客户端发送的服务请求后（服务请求如图3-2所示的服务请求1、服务请求2或者服务请求3），则可以通过Nginx在刷新后的配置文件中查询服务请求携带的目标URI对应的多个目标服务的对外通信地址，各目标服务部署于容器或者物理机中，各目标服务均可以用于响应该服务请求；服务器运行Nginx，基于预设的负载均衡策略，从多个目标服务中确定标的服务，基于标的服务的对外通信地址将该服务请求定向至该标的服务，由该标的服务响应该服务请求。
在实际的应用中，对于需要服务同时部署在容器和物理机的应用场景，本申请实施例通过上述实施方式，将部署在容器中的服务和部署在物理机中的服务一起暴露给外部访问，可以更好地满足客户需求；同时，由于服务部署在容器以及物理机中，可以避免由于容器不稳定造成的服务崩溃，可以提升服务的稳定性，但是传统技术只能发现部署在容器中的服务，而不能发现部署在物理机中的服务，本申请实施例通过上述实施方式能够发现部署在物理机中的服务，相较于传统技术，本申请实施例还有利于提升服务的稳定性。
在上述图3-1所示实施例的基础上，参见图4，本实施例涉及的是服务器如何根据健康检查字段进行健康检查的过程。如图4所示，本实施例中，目标自定义资源包括健康检查字段，服务器根据健康检查字段进行健康检查的过程可以包括如下步骤：
步骤S710，基于健康检查地址和第一对外通信地址，生成目标地址。
本申请实施例中，对于配置文件中每个部署在物理机上的服务，服务器基于健康检查地址和每个部署在物理机上的服务的第一对外通信地址，生成每个部署在物理机上的服务的目标地址。
在一种可能的实施方式中，部署在物理机上的一个服务的第一对外通信地址为10.21.2.49:8084，部署在物理机上的另一个服务的第一对外通信地址为10.21.2.48:8084，服务器基于健康检查地址/conf/，生成这两个服务的目标地址：10.21.2.49:8084/conf/和10.21.2.48:8084/conf/。
步骤S720，向目标地址发送健康检查指令，得到返回结果。
服务器向生成的每个目标地址发送健康检查指令，得到每个目标地址返回的返回结果，该返回结果用于表征第一对外通信地址对应的部署于物理机中的服务存活或者不存活。
在一种可能的实施方式中，返回结果可以是HTTP码的形式，例如，若一个目标地址的返回结果是“200”，则表征该目标地址对应的部署在物理机中的服务存活；而若一个目标地址的返回结果是“405”，则表征该目标地址对应的部署在物理机中的服务不存活。
步骤S730，若根据返回结果确定第一对外通信地址对应的部署于物理机中的服务不存活，则将配置文件中的第一对外通信地址删除。
服务器若根据返回结果确定第一对外通信地址对应的部署于物理机中的服务不存活，则将配置文件中的第一对外通信地址删除。在一种可能的实施方式中，服务器可以按照目标自定义资源包括的Interval字段的指示，周期性地进行健康检查，例如，上述目标自定义资源的举例中Interval: 10，由此，服务器则可以每10秒进行一次健康检查，从而可以及时将不存活的服务从配置文件中删除，确保了配置文件中的服务能够正常提供服务，提升了服务的可靠性。
参见图5，其示出了本申请实施例提供的一种请求处理方法的流程图，该方法可以应用于图1所示实施环境中。如图5所示，该方法可以包括以下步骤：
步骤S1001，服务器获取至少一个Ingress资源。
步骤S1002，对于各Ingress资源，服务器基于Ingress资源包括的Service资源名查找目标Service资源，基于目标Service资源中的指示信息，获取与目标Service资源相关联的部署于物理机或者容器的服务的对外通信地址，并建立Ingress资源包括的URI和与目标Service资源相关联的服务的对外通信地址的对应关系。
在一种可能的实施方式中，指示信息包括自定义资源名，服务器基于目标Service资源中的指示信息，获取与目标Service资源相关联的部署于物理机或者容器的服务的对外通信地址可以通过以下步骤实现：服务器基于自定义资源名查找目标自定义资源，目标自定义资源包括第一对外通信地址，第一对外通信地址为与目标Service资源相关联的部署于物理机中的服务的对外通信地址；服务器从目标自定义资源中获取第一对外通信地址。
其中，目标Service资源包括注解字段，注解字段包括自定义资源名。目标自定义资源包括spec字段，spec字段包括第一对外通信地址；目标自定义资源还包括apiVersion字段、kind字段、metadata字段以及健康检查字段中的至少一个，其中，apiVersion字段包括目标自定义资源的版本信息，kind字段包括目标自定义资源的类型信息，metadata字段包括目标自定义资源的名称以及目标自定义资源的命名空间信息，健康检查字段包括健康检查地址，健康检查地址用于供服务器对与目标Service资源相关联的部署于物理机中的服务进行健康检查。
在一种可能的实施方式中，指示信息包括Pod资源标签以及第二对外通信地址的第一部分，第二对外通信地址为与目标Service资源相关联的部署于容器中的服务的对外通信地址，服务器基于目标Service资源中的指示信息，获取与目标Service资源相关联的部署于物理机或者容器的服务的对外通信地址可以通过如下步骤实现：服务器基于Pod资源标签查找目标Pod资源，目标Pod资源包括第二对外通信地址的第二部分；服务器从目标Pod资源中获取第二部分，并基于第一部分和第二部分生成第二对外通信地址。
其中，第二对外通信地址包括IP地址和端口号，第一部分为端口号，第二部分为IP地址。
步骤S1003，服务器基于各对应关系，创建配置文件。
步骤S1004，客户端发送服务请求，服务请求携带有目标URI。
步骤S1005，服务器接收客户端发送的该服务请求。
步骤S1006，服务器基于目标URI查询配置文件，得到能够响应服务请求的多个目标服务的对外通信地址。
其中，各目标服务部署于容器或者物理机中，配置文件包括URI与部署于容器或者物理机的服务的对外通信地址的对应关系。
步骤S1007，服务器基于预设的负载均衡策略，从多个目标服务中确定标的服务，基于标的服务的对外通信地址将服务请求定向至标的服务。
步骤S1008，服务器基于目标自定义资源包括的健康检查字段所包括的健康检查地址和第一对外通信地址，生成目标地址。
步骤S1009，向目标地址发送健康检查指令，得到返回结果，返回结果用于表征第一对外通信地址对应的部署于物理机中的服务存活或者不存活。
步骤S1010，若根据返回结果确定第一对外通信地址对应的部署于物理机中的服务不存活，则将配置文件中的第一对外通信地址删除。
应该理解的是，虽然图2-5的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2-5中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
在一个实施例中，如图6所示，提供了一种请求处理装置，所述装置包括：
第一控制模块10，用于接收客户端发送的服务请求，所述服务请求携带有目标URI；
第二控制模块20，用于基于所述目标URI查询配置文件，得到能够响应所述服务请求的多个目标服务的对外通信地址，其中，各所述目标服务部署于容器或者物理机中，所述配置文件包括URI与部署于容器或者物理机的服务的对外通信地址的对应关系；
第三控制模块30，用于基于预设的负载均衡策略，从所述多个目标服务中确定标的服务，基于所述标的服务的对外通信地址将所述服务请求定向至所述标的服务。
在图6所示实施例的基础上，参见图7，所述装置还包括：
第四控制模块40，用于获取至少一个Ingress资源，各所述Ingress资源包括URI和Service资源名；
第五控制模块50，用于对于各所述Ingress资源，基于所述Ingress资源包括的Service资源名查找目标Service资源，基于所述目标Service资源中的指示信息，获取与所述目标Service资源相关联的部署于物理机或者容器的服务的对外通信地址，并建立所述Ingress资源包括的URI和与所述目标Service资源相关联的服务的对外通信地址的对应关系；
第六控制模块60，用于基于各所述对应关系，创建所述配置文件。
可选地，所述指示信息包括自定义资源名，所述第五控制模块50具体用于：
基于所述自定义资源名查找目标自定义资源，所述目标自定义资源包括第一对外通信地址，所述第一对外通信地址为与所述目标Service资源相关联的部署于物理机中的服务的对外通信地址；
从所述目标自定义资源中获取所述第一对外通信地址。
可选地，所述目标Service资源包括注解字段，所述注解字段包括所述自定义资源名。
可选地，所述目标自定义资源包括spec字段，所述spec字段包括所述第一对外通信地址；
所述目标自定义资源还包括apiVersion字段、kind字段、metadata字段以及健康检查字段中的至少一个，其中，所述apiVersion字段包括所述目标自定义资源的版本信息，所述kind字段包括所述目标自定义资源的类型信息，所述metadata字段包括所述目标自定义资源的名称以及所述目标自定义资源的命名空间信息，所述健康检查字段包括健康检查地址，所述健康检查地址用于供所述服务器对与所述目标Service资源相关联的部署于物理机中的服务进行健康检查。
可选地，在所述目标自定义资源包括所述健康检查字段的情况下，所述装置还包括：
地址生成模块，用于基于所述健康检查地址和所述第一对外通信地址，生成目标地址；
健康检查模块，用于向所述目标地址发送健康检查指令，得到返回结果，所述返回结果用于表征所述第一对外通信地址对应的部署于物理机中的服务存活或者不存活；
结果确认模块，用于若根据所述返回结果确定所述第一对外通信地址对应的部署于物理机中的服务不存活，则将所述配置文件中的所述第一对外通信地址删除。
可选地，所述指示信息包括Pod资源标签以及第二对外通信地址的第一部分，所述第二对外通信地址为与所述目标Service资源相关联的部署于容器中的服务的对外通信地址，所述第五控制模块50具体用于：
基于所述Pod资源标签查找目标Pod资源，所述目标Pod资源包括所述第二对外通信地址的第二部分；
从所述目标Pod资源中获取所述第二部分，并基于所述第一部分和所述第二部分生成所述第二对外通信地址。
可选地，所述第二对外通信地址包括IP地址和端口号，所述第一部分为端口号，所述第二部分为IP地址。
关于请求处理装置的具体限定可以参见上文中对于请求处理方法的限定，在此不再赘述。上述请求处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于服务器中的处理器中，也可以以软件形式存储于服务器中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
在一个实施例中，提供了一种服务器，其内部结构图可以如图8所示。该服务器包括通过系统总线连接的处理器、存储器和网络接口。其中，该服务器的处理器用于提供计算和控制能力。该服务器的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该服务器的数据库用于存储请求处理数据。该服务器的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种请求处理方法。
本领域技术人员可以理解，图8中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的服务器的限定，具体的服务器可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
在一个实施例中，提供了一种服务器，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：
接收客户端发送的服务请求，所述服务请求携带有目标URI；
基于所述目标URI查询配置文件，得到能够响应所述服务请求的多个目标服务的对外通信地址，其中，各所述目标服务部署于容器或者物理机中，所述配置文件包括URI与部署于容器或者物理机的服务的对外通信地址的对应关系；
基于预设的负载均衡策略，从所述多个目标服务中确定标的服务，基于所述标的服务的对外通信地址将所述服务请求定向至所述标的服务。
在一个实施例中，处理器执行计算机程序时还实现以下步骤：
获取至少一个Ingress资源，各所述Ingress资源包括URI和Service资源名；
对于各所述Ingress资源，基于所述Ingress资源包括的Service资源名查找目标Service资源，基于所述目标Service资源中的指示信息，获取与所述目标Service资源相关联的部署于物理机或者容器的服务的对外通信地址，并建立所述Ingress资源包括的URI和与所述目标Service资源相关联的服务的对外通信地址的对应关系；
基于各所述对应关系，创建所述配置文件。
在一个实施例中，所述指示信息包括自定义资源名，处理器执行计算机程序时具体实现以下步骤：
基于所述自定义资源名查找目标自定义资源，所述目标自定义资源包括第一对外通信地址，所述第一对外通信地址为与所述目标Service资源相关联的部署于物理机中的服务的对外通信地址；
从所述目标自定义资源中获取所述第一对外通信地址。
在一个实施例中，所述目标Service资源包括注解字段，所述注解字段包括所述自定义资源名。
在一个实施例中，所述目标自定义资源包括spec字段，所述spec字段包括所述第一对外通信地址；
所述目标自定义资源还包括apiVersion字段、kind字段、metadata字段以及健康检查字段中的至少一个，其中，所述apiVersion字段包括所述目标自定义资源的版本信息，所述kind字段包括所述目标自定义资源的类型信息，所述metadata字段包括所述目标自定义资源的名称以及所述目标自定义资源的命名空间信息，所述健康检查字段包括健康检查地址，所述健康检查地址用于供所述服务器对与所述目标Service资源相关联的部署于物理机中的服务进行健康检查。
在一个实施例中，在所述目标自定义资源包括所述健康检查字段的情况下，处理器执行计算机程序时还实现以下步骤：
基于所述健康检查地址和所述第一对外通信地址，生成目标地址；
向所述目标地址发送健康检查指令，得到返回结果，所述返回结果用于表征所述第一对外通信地址对应的部署于物理机中的服务存活或者不存活；
若根据所述返回结果确定所述第一对外通信地址对应的部署于物理机中的服务不存活，则将所述配置文件中的所述第一对外通信地址删除。
在一个实施例中，所述指示信息包括Pod资源标签以及第二对外通信地址的第一部分，所述第二对外通信地址为与所述目标Service资源相关联的部署于容器中的服务的对外通信地址，处理器执行计算机程序时具体实现以下步骤：
基于所述Pod资源标签查找目标Pod资源，所述目标Pod资源包括所述第二对外通信地址的第二部分；
从所述目标Pod资源中获取所述第二部分，并基于所述第一部分和所述第二部分生成所述第二对外通信地址。
在一个实施例中，所述第二对外通信地址包括IP地址和端口号，所述第一部分为端口号，所述第二部分为IP地址。
在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：
接收客户端发送的服务请求，所述服务请求携带有目标URI；
基于所述目标URI查询配置文件，得到能够响应所述服务请求的多个目标服务的对外通信地址，其中，各所述目标服务部署于容器或者物理机中，所述配置文件包括URI与部署于容器或者物理机的服务的对外通信地址的对应关系；
基于预设的负载均衡策略，从所述多个目标服务中确定标的服务，基于所述标的服务的对外通信地址将所述服务请求定向至所述标的服务。
在一个实施例中，计算机程序被处理器执行时还实现以下步骤：
获取至少一个Ingress资源，各所述Ingress资源包括URI和Service资源名；
对于各所述Ingress资源，基于所述Ingress资源包括的Service资源名查找目标Service资源，基于所述目标Service资源中的指示信息，获取与所述目标Service资源相关联的部署于物理机或者容器的服务的对外通信地址，并建立所述Ingress资源包括的URI和与所述目标Service资源相关联的服务的对外通信地址的对应关系；
基于各所述对应关系，创建所述配置文件。
在一个实施例中，所述指示信息包括自定义资源名，计算机程序被处理器执行时具体实现以下步骤：
基于所述自定义资源名查找目标自定义资源，所述目标自定义资源包括第一对外通信地址，所述第一对外通信地址为与所述目标Service资源相关联的部署于物理机中的服务的对外通信地址；
从所述目标自定义资源中获取所述第一对外通信地址。
在一个实施例中，所述目标Service资源包括注解字段，所述注解字段包括所述自定义资源名。
在一个实施例中，所述目标自定义资源包括spec字段，所述spec字段包括所述第一对外通信地址；
所述目标自定义资源还包括apiVersion字段、kind字段、metadata字段以及健康检查字段中的至少一个，其中，所述apiVersion字段包括所述目标自定义资源的版本信息，所述kind字段包括所述目标自定义资源的类型信息，所述metadata字段包括所述目标自定义资源的名称以及所述目标自定义资源的命名空间信息，所述健康检查字段包括健康检查地址，所述健康检查地址用于供所述服务器对与所述目标Service资源相关联的部署于物理机中的服务进行健康检查。
在一个实施例中，在所述目标自定义资源包括所述健康检查字段的情况下，计算机程序被处理器执行时还实现以下步骤：
基于所述健康检查地址和所述第一对外通信地址，生成目标地址；
向所述目标地址发送健康检查指令，得到返回结果，所述返回结果用于表征所述第一对外通信地址对应的部署于物理机中的服务存活或者不存活；
若根据所述返回结果确定所述第一对外通信地址对应的部署于物理机中的服务不存活，则将所述配置文件中的所述第一对外通信地址删除。
在一个实施例中，所述指示信息包括Pod资源标签以及第二对外通信地址的第一部分，所述第二对外通信地址为与所述目标Service资源相关联的部署于容器中的服务的对外通信地址，计算机程序被处理器执行时具体实现以下步骤：
基于所述Pod资源标签查找目标Pod资源，所述目标Pod资源包括所述第二对外通信地址的第二部分；
从所述目标Pod资源中获取所述第二部分，并基于所述第一部分和所述第二部分生成所述第二对外通信地址。
在一个实施例中，所述第二对外通信地址包括IP地址和端口号，所述第一部分为端口号，所述第二部分为IP地址。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器（Read-Only Memory，ROM）、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器（Random Access Memory，RAM）或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器（Static Random Access Memory，SRAM）或动态随机存取存储器（Dynamic Random Access Memory，DRAM）等。
以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种请求处理方法，其特征在于，所述方法包括：
接收客户端发送的服务请求，所述服务请求携带有目标URI；
基于所述目标URI查询配置文件，得到能够响应所述服务请求的多个目标服务的对外通信地址，其中，各所述目标服务部署于容器或者物理机中，所述配置文件包括URI与部署于容器或者物理机的服务的对外通信地址的对应关系；
基于预设的负载均衡策略，从所述多个目标服务中确定标的服务，基于所述标的服务的对外通信地址将所述服务请求定向至所述标的服务；
所述基于所述目标URI查询配置文件之前，所述方法还包括：
获取至少一个Ingress资源，各所述Ingress资源包括URI和Service资源名；
对于各所述Ingress资源，基于所述Ingress资源包括的Service资源名查找目标Service资源，基于所述目标Service资源中的指示信息，获取与所述目标Service资源相关联的部署于物理机或者容器的服务的对外通信地址，并建立所述Ingress资源包括的URI和与所述目标Service资源相关联的服务的对外通信地址的对应关系；
基于各所述对应关系，创建所述配置文件。
2.根据权利要求1所述的方法，其特征在于，所述指示信息包括自定义资源名，所述基于所述目标Service资源中的指示信息，获取与所述目标Service资源相关联的部署于物理机或者容器的服务的对外通信地址，包括：
基于所述自定义资源名查找目标自定义资源，所述目标自定义资源包括第一对外通信地址，所述第一对外通信地址为与所述目标Service资源相关联的部署于物理机中的服务的对外通信地址；
从所述目标自定义资源中获取所述第一对外通信地址。
3.根据权利要求2所述的方法，其特征在于，所述目标Service资源包括注解字段，所述注解字段包括所述自定义资源名。
4.根据权利要求2所述的方法，其特征在于，所述目标自定义资源包括spec字段，所述spec字段包括所述第一对外通信地址；
所述目标自定义资源还包括apiVersion字段、kind字段、metadata字段以及健康检查字段中的至少一个，其中，所述apiVersion字段包括所述目标自定义资源的版本信息，所述kind字段包括所述目标自定义资源的类型信息，所述metadata字段包括所述目标自定义资源的名称以及所述目标自定义资源的命名空间信息，所述健康检查字段包括健康检查地址，所述健康检查地址用于供服务器对与所述目标Service资源相关联的部署于物理机中的服务进行健康检查。
5.根据权利要求4所述的方法，其特征在于，在所述目标自定义资源包括所述健康检查字段的情况下，所述方法还包括：
基于所述健康检查地址和所述第一对外通信地址，生成目标地址；
向所述目标地址发送健康检查指令，得到返回结果，所述返回结果用于表征所述第一对外通信地址对应的部署于物理机中的服务存活或者不存活；
若根据所述返回结果确定所述第一对外通信地址对应的部署于物理机中的服务不存活，则将所述配置文件中的所述第一对外通信地址删除。
6.根据权利要求1所述的方法，其特征在于，所述指示信息包括Pod资源标签以及第二对外通信地址的第一部分，所述第二对外通信地址为与所述目标Service资源相关联的部署于容器中的服务的对外通信地址，所述基于所述目标Service资源中的指示信息，获取与所述目标Service资源相关联的部署于物理机或者容器的服务的对外通信地址，包括：
基于所述Pod资源标签查找目标Pod资源，所述目标Pod资源包括所述第二对外通信地址的第二部分；
从所述目标Pod资源中获取所述第二部分，并基于所述第一部分和所述第二部分生成所述第二对外通信地址。
7.一种请求处理装置，其特征在于，所述装置包括：
第一控制模块，用于接收客户端发送的服务请求，所述服务请求携带有目标URI；
第二控制模块，用于基于所述目标URI查询配置文件，得到能够响应所述服务请求的多个目标服务的对外通信地址，其中，各所述目标服务部署于容器或者物理机中，所述配置文件包括URI与部署于容器或者物理机的服务的对外通信地址的对应关系；
第三控制模块，用于基于预设的负载均衡策略，从所述多个目标服务中确定标的服务，基于所述标的服务的对外通信地址将所述服务请求定向至所述标的服务；
所述装置还包括：
第四控制模块，用于获取至少一个Ingress资源，各所述Ingress资源包括URI和Service资源名；
第五控制模块，用于对于各所述Ingress资源，基于所述Ingress资源包括的Service资源名查找目标Service资源，基于所述目标Service资源中的指示信息，获取与所述目标Service资源相关联的部署于物理机或者容器的服务的对外通信地址，并建立所述Ingress资源包括的URI和与所述目标Service资源相关联的服务的对外通信地址的对应关系；
第六控制模块，用于基于各所述对应关系，创建所述配置文件。
8.根据权利要求7所述的装置，其特征在于，所述指示信息包括自定义资源名，所述第五控制模块，具体用于基于所述自定义资源名查找目标自定义资源，所述目标自定义资源包括第一对外通信地址，所述第一对外通信地址为与所述目标Service资源相关联的部署于物理机中的服务的对外通信地址；从所述目标自定义资源中获取所述第一对外通信地址。
9.一种服务器，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至6中任一项所述的方法的步骤。
10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至6中任一项所述的方法的步骤。
CN202010601316.1A 2020-06-29 2020-06-29 请求处理方法、装置、服务器和计算机可读存储介质 Active CN111752681B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010601316.1A CN111752681B (zh) 2020-06-29 2020-06-29 请求处理方法、装置、服务器和计算机可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010601316.1A CN111752681B (zh) 2020-06-29 2020-06-29 请求处理方法、装置、服务器和计算机可读存储介质

Publications (2)

Publication Number Publication Date
CN111752681A CN111752681A (zh) 2020-10-09
CN111752681B true CN111752681B (zh) 2024-12-17

Family

ID=72677751

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010601316.1A Active CN111752681B (zh) 2020-06-29 2020-06-29 请求处理方法、装置、服务器和计算机可读存储介质

Country Status (1)

Country Link
CN (1) CN111752681B (zh)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112468580A (zh) * 2020-11-25 2021-03-09 政采云有限公司 一种业务服务的调用方法、装置、设备及存储介质
CN113783922B (zh) * 2021-03-26 2024-11-26 北京沃东天骏信息技术有限公司 负载均衡的方法、系统和装置
CN113448594B (zh) * 2021-06-29 2024-06-18 京东科技控股股份有限公司 服务的处理方法、装置、计算机设备及存储介质
CN113608865A (zh) * 2021-07-13 2021-11-05 北京奇艺世纪科技有限公司 一种流量控制方法、装置、系统、电子设备及存储介质
US20230108778A1 (en) * 2021-09-28 2023-04-06 Citrix Systems, Inc. Automated Generation of Objects for Kubernetes Services
CN114048028A (zh) * 2021-11-01 2022-02-15 北京金山云网络技术有限公司 服务调用方法、装置、存储介质和电子设备
CN114490024A (zh) * 2021-12-20 2022-05-13 新浪网技术(中国)有限公司 一种Kubernetes后端服务的负载分配方法、配置方法及硬件
CN119743530B (zh) * 2024-12-16 2025-12-16 苏州元脑智能科技有限公司 服务访问方法、装置、通信设备及存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110730250A (zh) * 2019-09-06 2020-01-24 北京小米移动软件有限公司 信息处理方法及装置、服务系统、存储介质

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101610222A (zh) * 2009-07-20 2009-12-23 中兴通讯股份有限公司 基于客户端的服务器选择方法及装置
WO2018107382A1 (zh) * 2016-12-14 2018-06-21 华为技术有限公司 分布式负载均衡系统、健康检查方法和服务节点
CN108965381B (zh) * 2018-05-31 2023-03-21 康键信息技术（深圳）有限公司 基于Nginx的负载均衡实现方法、装置、计算机设备和介质

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110730250A (zh) * 2019-09-06 2020-01-24 北京小米移动软件有限公司 信息处理方法及装置、服务系统、存储介质

Also Published As

Publication number Publication date
CN111752681A (zh) 2020-10-09

Similar Documents

Publication Publication Date Title
CN111752681B (zh) 请求处理方法、装置、服务器和计算机可读存储介质
KR102199403B1 (ko) 도메인 네임 분석 방법, 서버 및 저장 매체
CN102299954B (zh) 用于分布式服务的上下文专用网络资源寻址系统及方法
CN108370391B (zh) 用于虚拟网络的共享多租户域名系统(dns)服务器
CN106982236B (zh) 一种信息处理方法、装置和系统
CN114153626B (zh) 一种服务集成过程抽象的方法、装置和计算机设备
CN112995273B (zh) 网络打通方案生成方法、装置、计算机设备和存储介质
CN111786984B (zh) Pod通信连接方法、装置及电子设备、存储介质
CN107196982A (zh) 一种用户请求的处理方法和装置
US20180041604A1 (en) Encoded uri references in restful requests to facilitate proxy aggregation
CN114172853A (zh) 流量转发及裸机服务器的配置方法、装置
CN109710223B (zh) 基于分布式kv存储系统的api网关热插拔系统
CN113507475B (zh) 跨域访问方法和装置
CN116521668A (zh) 用于数据存储的方法、设备和计算机程序产品
CN113395340A (zh) 一种信息更新方法、装置、设备、系统和可读存储介质
CN112073212A (zh) 参数配置方法、装置、终端设备和存储介质
CN115687294A (zh) 数据库部署方法、域名解析方法及相关装置
CN119557055A (zh) 跨Kubernetes集群服务访问方法、装置、计算机设备和存储介质
CN114995833B (zh) 一种数据分发方法及装置
US9876677B1 (en) System and method for connection efficiency
CN113222565A (zh) 交易系统、交易方法、装置、计算机设备和存储介质
CN116915770A (zh) 服务的部署方法、装置、电子设备及存储介质
US10958580B2 (en) System and method of performing load balancing over an overlay network
CN111782428A (zh) 数据调用系统以及方法
CN116346778B (zh) 地址获取方法、装置、计算机设备和存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
EE01 Entry into force of recordation of patent licensing contract
EE01 Entry into force of recordation of patent licensing contract

Application publication date: 20201009

Assignee: GUANGZHOU CUBESILI INFORMATION TECHNOLOGY Co.,Ltd.

Assignor: GUANGZHOU HUADUO NETWORK TECHNOLOGY Co.,Ltd.

Contract record no.: X2021440000031

Denomination of invention: Request processing method, apparatus, server and computer readable storage medium

License type: Common License

Record date: 20210125

GR01 Patent grant
GR01 Patent grant