CN114706655A

CN114706655A - Request processing method, computing device and computer storage medium

Info

Publication number: CN114706655A
Application number: CN202210295550.5A
Authority: CN
Inventors: 邱世达
Original assignee: Alibaba China Co Ltd
Current assignee: Alibaba China Co Ltd
Priority date: 2022-03-23
Filing date: 2022-03-23
Publication date: 2022-07-05

Abstract

The embodiment of the invention provides a request processing method, computing equipment and a computer storage medium. The request processing method comprises the following steps: acquiring a first request sent by a first service; searching a conversion rule which is configured as a self-defined resource in a resource definition file of the container arrangement system, and determining a target conversion rule matched with a first access parameter in the first request; according to the target conversion rule, adjusting a first access parameter in the first request to be a second access parameter to obtain a second request; and sending the second request to a second service corresponding to the second access parameter. The technical scheme provided by the embodiment of the invention realizes the technical effect that the first service can still initiate access to the second service by utilizing the first access parameter when the access parameter of the second service is changed.

Description

Request processing method, computing device and computer storage medium

Technical Field

The embodiment of the invention relates to the technical field of cloud computing, in particular to a request processing method, computing equipment and a computer storage medium.

Background

The micro-service is a new service architecture, and the original single application is divided into a plurality of small functional blocks, also called services, and the services are independent from one another, so that a large application program for realizing complex functions is combined in a modularized mode. Multiple services of the microservice architecture may run in a container orchestration system such as kubernets, such that containers managed by the container orchestration system provide the resources needed to run the multiple services.

In the micro-service architecture, there is an access requirement for one service to access another service, and at present, one service generally accesses another service by using an access parameter pre-agreed with another service.

In the related art, if the access parameter of a service is modified, other services cannot continue to access the service by using the original access parameter agreed in advance.

Disclosure of Invention

The embodiment of the invention provides a request processing method, computing equipment and a computer storage medium.

In a first aspect, an embodiment of the present invention provides a request processing method, applied to an application system including a first service and a second service, including:

acquiring a first request sent by a first service;

searching a conversion rule configured as a self-defined resource in a resource definition file of a container arrangement system, and determining a target conversion rule matched with a first access parameter in the first request;

according to the target conversion rule, adjusting a first access parameter in the first request to be a second access parameter to obtain a second request;

and sending the second request to a second service corresponding to the second access parameter.

In a second aspect, an embodiment of the present invention provides a request processing method, including:

receiving a conversion rule configured according to a resource definition mode aiming at any service;

configuring the conversion rule as a self-defined resource in a resource definition file; the resource definition file is used for searching a matched target conversion rule from a first request of a first service by a service gateway, wherein the target conversion rule is used for indicating that a first access parameter in the first request is modified into a second access parameter to obtain a second request.

In a third aspect, an embodiment of the present invention provides a request processing method, applied to a first service, where the method includes:

sending a first request based on a first access parameter to a service gateway so that the service gateway searches a conversion rule configured as a self-defined resource in a resource definition file of a container arrangement system and determines a target conversion rule matched with the first access parameter in the first request; according to the target conversion rule, adjusting a first access parameter in the first request to be a second access parameter to obtain a second request; and sending the second request to a second service corresponding to the second access parameter.

In a fourth aspect, an embodiment of the present invention provides a request processing method, which is applied to a second service, and the method includes:

sending a conversion rule to a container arrangement system so that the container arrangement system can configure the conversion rule as a self-defined resource in a resource definition file, wherein the conversion rule is used for converting a first access parameter originally supported by a second service to a second access parameter currently supported by the second service;

receiving a second request based on the second access parameter and sent by a service gateway, wherein the second request is generated by adjusting the first access parameter in the first request to the second access parameter by using a target conversion rule, and the target conversion rule is determined by determining the matching relationship between the first access parameter in the first request and a conversion rule which is used as a custom resource configuration in a resource definition file searched by the container arrangement system.

In a fifth aspect, an embodiment of the present invention provides a service gateway, including:

the first obtaining module is used for obtaining a first request sent by a first service;

the rule matching module is used for searching a conversion rule configured as a self-defined resource in a resource definition file of the container arrangement system and determining a target conversion rule matched with a first access parameter in the first request;

the parameter adjusting module is used for adjusting a first access parameter in the first request to be a second access parameter according to the target conversion rule to obtain a second request;

and the request processing module is used for sending the second request to a second service corresponding to the second access parameter.

In a sixth aspect, an embodiment of the present invention provides a container arrangement system, including:

the rule receiving module is used for receiving a conversion rule configured according to a resource definition mode aiming at any service;

the resource allocation module is used for allocating the conversion rule as a self-defined resource in a resource definition file; the resource definition file is used for searching a matched target conversion rule from a first request of a first service by a service gateway, wherein the target conversion rule is used for indicating that a first access parameter in the first request is modified into a second access parameter to obtain a second request.

In a seventh aspect, an embodiment of the present invention provides a service, including:

the request sending module is used for sending a first request based on a first access parameter to a service gateway so that the service gateway can search a conversion rule configured as a self-defined resource in a resource definition file of a container arrangement system and determine a target conversion rule matched with the first access parameter in the first request; according to the target conversion rule, adjusting a first access parameter in the first request to be a second access parameter to obtain a second request; and sending the second request to a second service corresponding to the second access parameter.

In an eighth aspect, an embodiment of the present invention provides a service, including:

the system comprises a rule sending module, a container arrangement system and a storage module, wherein the rule sending module is used for sending a conversion rule to the container arrangement system so that the container arrangement system can configure the conversion rule as a self-defined resource in a resource definition file, and the conversion rule is used for converting a first access parameter originally supported by a second service to a second access parameter currently supported by the second service;

a request receiving module, configured to receive a second request based on the second access parameter, where the second request is generated by adjusting a first access parameter in a first request to a second access parameter by using a target transformation rule, and the target transformation rule is determined by determining a matching relationship between the first access parameter in the first request and a transformation rule configured as a custom resource in a resource definition file found by the container arrangement system.

In a ninth aspect, an embodiment of the present invention provides a computing device, including a processing component and a storage component;

the storage component stores one or more computer instructions; the one or more computer instructions are used for being called and executed by the processing component to realize the request processing method provided by the embodiment of the invention.

In a tenth aspect, an embodiment of the present invention provides a computer storage medium, which stores a computer program, and when the computer program is executed by a computer, the computer program implements the request processing method provided in the embodiment of the present invention.

In the embodiment of the invention, by adopting the technical scheme that after a first request initiated by a first service based on a first access parameter is obtained, a conversion rule which is used as a self-defined resource configuration in a resource definition file of a container arrangement system is searched, a target conversion rule matched with the first access parameter is determined, then the first access parameter is adjusted to be a second access parameter according to the target conversion rule to obtain a second request, and the second request is sent to a second service corresponding to the second access parameter, when the second service is upgraded and the access parameter of the second service is changed, the first service can still initiate access to the second service by using the first access parameter which is agreed with the second service in advance.

These and other aspects of the invention are apparent from and will be elucidated with reference to the embodiments described hereinafter.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present invention, and those skilled in the art can also obtain other drawings according to the drawings without creative efforts.

FIG. 1 is a schematic diagram of a microservice framework suitable for use in the request processing method provided by the embodiments of the present invention;

FIG. 2 schematically illustrates a general architecture diagram of a container organization system kubernets;

fig. 3 is a flowchart of an embodiment of a request processing method according to an embodiment of the present invention;

fig. 4 is a schematic diagram schematically illustrating a request processing method provided in an embodiment of the present invention;

FIG. 5 is a schematic diagram that schematically illustrates a transformation rule provided by an embodiment of the present invention;

fig. 6 is a flowchart of an embodiment of a request processing method according to another embodiment of the present invention;

FIG. 7 is a flowchart of a request processing method according to another embodiment of the present invention;

fig. 8 is a schematic structural diagram of an embodiment of a service gateway according to the present invention;

FIG. 9 is a schematic structural diagram of an embodiment of a container arrangement system according to the present invention;

FIG. 10 is a block diagram illustrating an embodiment of a service provided by an embodiment of the invention;

fig. 11 is a schematic structural diagram of an embodiment of a computing device according to an embodiment of the present invention.

Detailed Description

In order to make the technical solutions of the present invention better understood, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention.

In some of the flows described in the present specification and claims and in the above figures, a number of operations are included that occur in a particular order, but it should be clearly understood that these operations may be performed out of order or in parallel as they occur herein, with the order of the operations being indicated as 101, 102, etc. merely to distinguish between the various operations, and the order of the operations by themselves does not represent any order of performance. Additionally, the flows may include more or fewer operations, and the operations may be performed sequentially or in parallel. It should be noted that, the descriptions of "first", "second", etc. in this document are used for distinguishing different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit the types of "first" and "second".

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

The details of implementation of the technical solution of the embodiments of the present application are set forth in the following.

Fig. 1 schematically shows a schematic diagram of a microservice framework suitable for the request processing method provided by the embodiment of the present invention.

Microservices are an architectural and organizational method of developing applications. In the microservice architecture, applications consist of small, stand-alone services that communicate through well-defined APIs (Application Programming Interface). The microservice model enables each small individual service to be developed by independently selecting its own programming language and technology stack for independent evolution, deployment, operation, and management and maintenance by different teams.

As shown in fig. 1, a microservice framework provided by an embodiment of the present invention may include microservice a and microservice B. When a user needs to call the micro-service, the user can call the micro-service through an interactive interface provided by the console, and the console can send a call request to the micro-service A in response to the call operation. Because the micro service is usually a small functional block, that is, usually, one micro service can only provide a single service function for the user, the micro service a can remotely initiate a call to the micro service B through the API interface to obtain the function that the micro service B can provide, in order to meet the call requirement of the user.

In the related art, the micro service a generally initiates a call to the micro service B based on the API interface agreed in advance with the micro service B, and if the micro service B modifies the API interface agreed in advance due to interface upgrade and the like, the micro service a may fail to successfully initiate a call to the micro service B based on the API interface agreed in advance.

In order to at least partially solve the technical problems in the related art, an embodiment of the present invention provides a request processing method, including obtaining a first request sent by a first service, searching a conversion rule configured as a custom resource in a resource definition file of a container arrangement system, determining a target conversion rule matched with a first access parameter in the first request, adjusting a first access parameter in the first request to a second access parameter according to the target conversion rule to obtain a second request, and sending the second request to a second service corresponding to the second access parameter.

The technical scheme that after a first request initiated by a first service based on a first access parameter is obtained, a conversion rule which is configured as a self-defined resource in a resource definition file of a container arrangement system is searched, a target conversion rule matched with the first access parameter is determined, then the first access parameter is adjusted to be a second access parameter according to the target conversion rule to obtain a second request, and the second request is sent to a second service corresponding to the second access parameter is adopted.

FIG. 1 is an illustration of a microservice framework including microservice A and microservice B. In some implementations, the microservice framework may also include other microservices.

In embodiments of the present invention, an application program may comprise a collection of computer programs written for some application purpose of a user. After the development of the services constituting the application is completed, the services can be deployed into a production environment (production environment) for users to use. The production environment refers to an environment in which a customer actually uses a service, and a process in which the service is deployed to the production environment may also be referred to as a process in which the service is brought online. After a service is deployed to a production environment, it can be formally invoked.

When a service is deployed to a physical or virtual machine, some updates to the operating system may corrupt the service. For example, an update of one operating system results in several dependent updates to the service, and some incompatible updates may even result in the service running abnormally. In addition, if two or more services share the same operating system and some of the same library files (library), updates to the library files of one or some of the services may affect other applications.

Based on this, the service may also be deployed into a container (container). One container contains the complete runtime environment. A runtime environment refers to all dependencies, class libraries, other binaries, configuration files, etc. required by this application, except for the service itself. These files are collectively packaged into a package called a container image, thereby forming a container.

Since the container encapsulates the relevant files necessary for running the service, such as the dependency and the operating system, the service deployed in the container is not affected by changes of the operating system or changes of the dependency, which ensures that the application can run without interruption. Moreover, migrating containerized applications from one environment to another is more flexible since operating system differences need not be considered.

In some implementations, a service may be deployed into a container group (pod) formed of one or more containers. A pod is a set of containers (including at least one container), and the containers inside the pod may share a network and/or storage). Multiple vessels in a pod typically deploy the same application, considering that the vessel applications in the pod have co-hability, i.e., start at the same time, and terminate at the same time. When an application includes multiple different services, a pod may be created for each of the multiple application programs, each pod being used to deploy one of the multiple services.

When the number of containers reaches a certain scale, the containers can be typically organized using a container organization system (e.g., a container organization engine) to achieve automated deployment, large-scale scalable, application containerization management. The container arrangement refers to arranging an interaction mode among a plurality of containers for deploying the application, so that the containers interact based on the set interaction mode to ensure the normal operation of the application.

Among them, the container arrangement tool includes various kinds such as docker swarm, docker composition, kubernets or apache media, etc. For ease of description, the container arrangement system is hereinafter illustrated as a kubernets system. The resource processing method provided by the embodiment of the invention comprises but is not limited to application in kubernets.

Fig. 2 schematically shows a general architecture diagram of a container organization system kubernets.

As shown in fig. 2, kubernets divide nodes in a cluster into a Master Node (Master) and at least one worker Node (Node). Master and Node may be physical or virtual machines in the cloud environment. A cloud environment is embodied as a computing cluster comprising at least one cloud computing device (e.g., a central server). In some implementations, the Master and Node may also be physical or virtual machines in the edge environment. An edge environment is embodied as a computing cluster comprising at least one edge computing device (e.g., an edge server). In other implementations, the Master and the Node may also be end devices or virtual machines on the end devices. It should be noted that the Master and the Node may be a physical machine or a virtual machine in the same environment, or may be a physical machine or a virtual machine in different environments, for example, the Master may be a physical machine in a cloud environment, and the Node may be a physical machine in an edge environment.

The Master runs a group of processes related to cluster management, such as processes of an interface server (club-adapter), a club-controller-manager (club-controller), a scheduler (club-scheduler) and a memory (etcd), and the club-adapter stores data depending on the etcd. Master can realize the management capabilities of resource management, pod scheduling, elastic expansion, safety control, system monitoring, error correction and the like of the whole cluster through the processes.

And running the process of the application program on the Node to provide the process of the application program with resources required by running. Wherein, the application program process is specifically operated in the pod. The Node also runs service processes, such as proxy (kubel), network proxy (kube-proxy) and other processes, and the Node realizes the creation, starting, monitoring, restarting, destroying and load balancing of the Pod through the service processes.

Fig. 2 is illustrated with a kubernets cluster including a Master and a Node. In some implementations, a kubernets cluster may include multiple nodes, and as such, applications may be deployed in multiple nodes in a distributed manner. Further, multiple masters may be included in the kubernets cluster, and when one Master fails, another Master may be enabled, thus ensuring high availability.

Fig. 3 is a flowchart of an embodiment of a request processing method according to an embodiment of the present invention, where the request processing method may be applied to an application system including a first service and a second service, and the application system may include, for example, a micro service system, and the method may be executed by a service gateway, and includes the following steps:

301, a first request sent by a first service is obtained.

According to an embodiment of the invention, the first service may be any one of the services in the microservice architecture.

According to an embodiment of the present invention, the first service may be deployed in a container orchestration system, so that at least one container in the container orchestration system provides resources required for running for the first service, where the resources may include CPU resources, GPU resources, storage resources, and the like.

According to an embodiment of the invention, the first request may be for requesting access to the second service. The second service may be another service in the microservice architecture having a bi-directional or unidirectional invocation relationship with the first service. The first service and the second service may be different services of the same application, but are not limited thereto, and may also be different services of different applications.

According to an embodiment of the invention, the first request may comprise a first access parameter. The first access parameter may be an access parameter agreed in advance between the first service and the second service. The first service may request access to the second service using the first access parameter.

303, searching the conversion rule configured as the self-defined resource in the resource definition file of the container arrangement system, and determining the target conversion rule matched with the first access parameter in the first request.

According to the embodiment of the present invention, in the micro service architecture, the service intermediates usually communicate through well-defined APIs, and thus, the first access parameter may be an interface parameter, such as a URL (uniform resource locator), of an API supported by the second service.

According to an embodiment of the present invention, the conversion rule may be generated by the second service when the access parameter of the second service is changed. The conversion rule may be used to indicate that a first access parameter initially supported by the second service is modified to a second access parameter currently supported by the second service.

According to the embodiment of the invention, since each service in the micro-service architecture is independently developed by each service developer, the development progress of each service is different. For example, when the second service is version 1.0, the access parameter agreed with the first service is the first access parameter. When the second service is upgraded to version 2.0, the access parameters typically need to be changed due to the upgrade of the interface.

Since the first service and the second service are developed independently, the first service is not aware after the second service is upgraded, and thus the first service still cannot normally access the second service by using the access parameters initially supported by the second service after the access parameters of the second service are changed, and in the related art, it is generally necessary that after the first service fails to access the second service, a developer of the first service interfaces with a developer of the second service, and modifies a code of the first service, so that the second service can be normally accessed.

Based on this, the inventor finds that the Client SDK (Software Development Kit) can be converted by writing rules for changing the access parameters, and the Client SDK avoids the difference of the access parameters, however, the method for writing the SDK has the problems of high Development cost, long adaptation period and difficulty in reuse. Secondly, various rules of the access parameter change can be configured manually by compiling configuration files according to the change of the access parameters based on agent software such as Nginx, however, firstly, the manual operation efficiency is low and the accuracy is insufficient, secondly, the configuration modes of the configuration files are not uniform and difficult to reuse, and finally, the non-cloud-native solution of the mode cannot well utilize the expansion capability of Kubernetes.

The inventor researches and discovers that after the access parameter of the second service is changed, the second service can generate a conversion rule for modifying the first access parameter into the second access parameter. After the second service generates the transformation rules, the transformation rules may be uploaded to the container orchestration system. After receiving the transformation rules, the container arrangement system may configure the transformation rules as Custom resources in a Resource definition file (CR).

Kubernets provides many default resource types, such as a series of resources like Pod, Deployment, Service, Volume, etc., and can meet the requirements of most daily system Deployment and management. However, in some special demand scenarios, these existing Resource types cannot be satisfied, so kubernets provide a mechanism for performing function extension on kubernets in a CRD (Custom Resource Definitions) based manner, and a lightweight mechanism is provided for Resource customization through CRD, so that the Custom Resource can be quickly abstracted into resources of kubernets without modifying codes or creating a Custom interface server, and a file configured through CRD may be referred to as a CR file.

It can be understood that, in the embodiment of the present invention, by means of the self-defining capability of the CRD, the conversion rule of the second service is abstracted into the CR file through the CRD, so that the management and expansion capability of kubernets is fully utilized.

By means of the CRD mechanism, the conversion rule can be abstracted into the CR file conveniently and quickly, and in the embodiment of the invention, the request conversion and transmission method provided by the embodiment of the invention can be adapted to different conversion rules only by writing the conversion rule and uploading the conversion rule to Kubernetess. Compared with the implementation mode of writing the client codes according to different conversion rules in the related technology, the development cost is low, and the adaptation period is short.

According to an embodiment of the present invention, a plurality of candidate conversion rules may be included in the CR file, and the plurality of candidate conversion rules may be generated and uploaded by at least one service.

According to an embodiment of the present invention, using the first access parameter, a target conversion rule corresponding to the first access parameter may be matched from a plurality of candidate conversion rules, thereby converting the first access parameter into a second access parameter supported by the second service.

303, according to the target conversion rule, adjusting the first access parameter in the first request to be the second access parameter to obtain the second request.

And 304, sending the second request to a second service corresponding to the second access parameter.

In the embodiment of the present invention, when an access parameter currently supported by the second service is changed, after receiving a first request sent by the first service based on the first access rule for requesting access to the second service, the conversion rule configured as a custom resource may be searched in a resource definition file of the container arrangement system, and a target conversion rule matching the first access parameter in the first request is determined, so that the first access parameter is converted into the second access parameter by using the target conversion rule, and the second request based on the second access parameter is sent to the second service. By the request processing method provided by the embodiment of the invention, under the condition that the access parameter currently supported by the second service is changed, the first service can still use the first access parameter to initiate access to the second service without code modification, and the process of changing the access parameter is insensitive to the first service, so that the convenience of initiating access to the second service by the first service is improved.

According to the embodiment of the present invention, determining the target transformation rule matching the first access parameter in the first request may specifically be implemented as:

acquiring first field information in a first access parameter;

determining whether a conversion rule declared by the second service is included in the resource definition file according to the first field information;

in a case where the conversion rule declared by the second service is included in the resource definition file, the conversion rule is determined as a target conversion rule.

According to the embodiment of the present invention, the first field information may be used to characterize the access object, the protocol type, the access method, the address, and other information of the first request.

According to the embodiment of the present invention, when the second service generates the conversion rule, the identification information of the second service and the type of the request adapted by the conversion rule may be configured in the conversion rule, where the type of the request may include a protocol type, an access method, an address, and the like adopted by the request.

After the first field information in the first access parameter is acquired, the first field information may be compared with the identification information pre-written in the conversion rule and the type of the request adapted to the conversion rule, so as to determine whether the CR file includes the conversion rule declared by the second service.

Optionally, the information characterizing the access object of the first request in the first field information may be obtained first, and then the candidate conversion rules stored in the CR file are filtered by using the information of the access object, so that the candidate conversion rule whose identification information matches the access object information is determined as the conversion rule declared by the second service.

After the conversion rule declared by the second service is determined, the information used for characterizing the adopted protocol type, the access method, the address and the like in the first field information may be matched with the conversion rule declared by the second service, so that the conversion rule declared by the second service having a matching relationship is determined as the target conversion rule.

According to the embodiment of the present invention, determining whether the resource definition file includes the conversion rule declared by the second service according to the first field information may specifically be implemented as:

determining whether the first field information matches second field information included in the conversion rule;

and determining the conversion rule of which the second field information has a matching relationship with the first field information as the conversion rule declared by the second service.

According to the embodiment of the invention, only the request type adapted to the conversion rule is defined in the conversion rule, that is, the request initiated by the request type defined by the conversion rule can be applicable to the conversion rule, that is, the access parameter carried by the access request initiated by any service to the second service based on the request type can be modified by using the conversion rule, so that the conversion rule has universality, and the specific service does not need to be written separately, thereby reducing the development cost.

According to an embodiment of the present invention, the request processing method further includes:

monitoring a conversion rule which is configured in a resource definition file as a self-defined resource from a container arranging system;

and saving the conversion rule obtained by monitoring.

According to the embodiment of the present invention, the service gateway may be deployed in kubernets, but is not limited thereto, and may also be deployed independently outside of kubernets and maintain communication with kubernets, thereby listening to kubernets.

According to the embodiment of the invention, after the second service generates the conversion rule, the conversion rule can be uploaded to the kube-apiserver of Kubernetes, so that the service gateway can monitor the kube-apiserver to obtain the conversion rule.

According to the embodiment of the invention, after the service gateway determines the second service uploading conversion rule by monitoring the kube-api server, the conversion rule can be downloaded to the local and stored in the local storage engine, so that the time consumption of request processing can be reduced.

The following description is given to the request processing method provided in the embodiment of the present invention with reference to a specific application scenario and a schematic diagram of the request processing method provided in the embodiment of the present invention shown in fig. 4, but it should be noted that the following example is only used to help those skilled in the art understand the technical solution provided in the embodiment of the present invention, and is not intended to make any undue limitation on the technical solution provided in the embodiment of the present invention.

In fig. 4, 401 may represent a first service, i.e., an initiator of a request, 402 may represent a service gateway, 403 may represent a kube-api ver, 404 may represent an etc d, and 405 may represent a second service, i.e., a recipient of the request.

For example, if there is a second service, an echo service, the access parameter initially supported by the second service may be 127.0.0.1: 8080/echo-bob, and other services may initiate access to the echo service by executing a GET request based on the access parameter. But for some reason the echo service modifies the access parameter, e.g. the name may be modified to nickname, without informing other services of the same modification to the access parameter. That is, the echo currently supports 127.0.0: 8080/echonickname ═ bob, and there will be an error in other services still initiating access to the echo based on the initial access parameters.

After the echo service modifies the supported access parameters, a conversion rule can be correspondingly generated and uploaded to Kubernets, so that the Kubernets abstract the conversion rule into a CR file.

Fig. 5 schematically shows a schematic diagram of a conversion rule provided by an embodiment of the present invention.

As shown in fig. 5, the source column may have the identification information of the echo service written in advance for the echo service and the type of the request adapted by the conversion rule. The scheme can represent the type of a Protocol used by the request, and in this example, the conversion rule is applicable to a request sent by using an HTTP (Hyper Text Transfer Protocol) Protocol; host can represent the destination address of the request access, wherein 127.0.0.1:2021 can be the address of the service gateway, that is, in the container management system, the request initiated by any service to other services is firstly sent to the service gateway, and then the request is forwarded by the gateway; path may be identification information of an echo service; method may characterize the access method of the request, in this example the conversion rule applies to requests initiated with the GET method.

In FIG. 5, a destination column is also included, and the destination column may also include a scheme, a host, a path, and a method corresponding to the source column. In the destination column, host can represent the destination address, that is, the final address to be forwarded by the service gateway after receiving the request, in this example, the final address is the address of the echo service.

In addition, the conversion rule further includes a rule column, and the rule column specifies a specific conversion method for the first access parameter after the service gateway receives the first request. In this example, the particular translation method modifies "name" in the access parameter to "nickname".

As shown in fig. 4, the first service 401 may send a first request for accessing the second service 405, which is initiated based on the first access parameter, to the service gateway 402, and after receiving the first request, the service gateway 402 may search a pre-created candidate conversion rule from a local storage or from a CR file in the kube-api server403, and determine a target conversion rule matching the first access parameter in the first request from the candidate conversion rules. After the target conversion rule is matched, the first access parameter may be converted by using a conversion method defined in the target conversion rule, so as to generate a second access parameter, and a second request based on the second conversion rule is sent to the second service 405.

According to the embodiment of the invention, after the kube-apiserver403 receives the conversion rule uploaded by the second service 405, the conversion rule may be sent to the ETCD404, so that the ETCD404 performs persistent storage on the conversion rule.

According to the embodiment of the present invention, the step of adjusting the first access parameter in the first request to be the second access parameter to obtain the second request may specifically be implemented as:

replacing the target parameter included in the first access parameter by using the parameter declared in the conversion rule;

or,

and generating a conversion parameter by using the parameter declared in the conversion rule and the target parameter included in the first access parameter, and replacing the target parameter by using the conversion parameter.

According to an embodiment of the present invention, the conversion manner defined in the conversion rule may include static conversion and dynamic conversion.

Static transitions may include, for example, From a to B, i.e., replacing parameter a in the first access parameter with parameter B; by replacing the parameter in the first access parameter, parameter addition to the first access parameter may also be implemented, for example, adding a fixed Request Header (Request Header) to the first access parameter, where the fixed Request Header may refer to a Request Header that is available without performing complex computation, and the Request Header may include, for example, "foo: bar ", and the like. In a specific example, when the service is subjected to gray-scale publishing, a parameter "version: 1.0 ", so that the receiver of the first request based on the first access parameter knows the version information of the sender of the first request, and accordingly, the corresponding flow control is made.

The dynamic transformation may be, for example, processing at least one of the first access parameters, generating a transformation parameter, and then replacing a target parameter in the first access parameter with the transformation parameter. By replacing the target parameter in the first access parameter with the conversion parameter, it is also possible to delete the target parameter or add a parameter to the first access parameter. For example, the transition parameter may be obtained by making the target parameter equal to null, so that when the target parameter is replaced by the transition parameter, the target parameter in the first access parameter may be deleted.

According to the embodiment of the invention, when the first access parameter is converted, the static conversion and the dynamic conversion are supported, so that the flexibility of request processing can be improved, and in addition, the request processing method provided by the embodiment of the invention can support a more complex rule conversion scene by supporting the dynamic conversion.

receiving a first response sent by the second service in response to the second request;

adding prompt information to the first response to generate a second response, wherein the prompt information is used for prompting the first service to initiate access to the second service by using the second access parameter;

the second reply is sent to the first service.

In some application scenarios, by using the request processing method provided by the embodiment of the present invention, after the second service is updated, the first service can still initiate access to the second service by using the first access parameter initially supported by the second service. However, with the continuous upgrade of the second service, the difference between the currently supported access parameter of the second service and the first access parameter may be large, and at this time, the first access parameter cannot be converted through the conversion rule, so that after the second service is upgraded, the service gateway monitors the conversion rule declared by the second service, and the prompt information may be added to the first response of the second service to the first request, so as to prompt the first service to perform the upgrade adapted to the second service as soon as possible, so as to normally access the second service.

Fig. 6 is a flowchart of an embodiment of a request processing method according to another embodiment of the present invention, which may be executed by a container arrangement system, and includes the following steps:

601, receiving a conversion rule configured according to a resource definition mode aiming at any service;

602, configuring the conversion rule as a self-defined resource in a resource definition file; the resource definition file is used for searching a matched target conversion rule from a first request of a first service by the service gateway, and the target conversion rule is used for indicating that a first access parameter in the first request is modified into a second access parameter to obtain a second request.

According to the embodiment of the present invention, configuring the conversion rule as a custom resource in the resource definition file may specifically be implemented as follows:

checking fields included in the conversion rules based on standard fields specified by the resource definition file;

and under the condition that the verification is passed, configuring the conversion rule as a self-defined resource in a resource definition file.

According to the embodiment of the invention, after the kube-apiserver receives the conversion rule, whether the conversion rule accords with the preset format can be checked by using the standard field specified in the CR file, and the conversion rule is configured in the resource definition file as the self-defined resource when the conversion rule accords with the preset format, so that the conversion rule can be effectively managed by using the resource management capability of the Kubernets system, the conversion rule is checked before the conversion rule is abstracted to the resource of the Kubernets, and the request processing method and the operation stability of the Kubernets are improved.

Another embodiment of the present invention further provides a request processing method applied to a first service, where the method includes:

sending a first request based on the first access parameter to a service gateway so that the service gateway searches a conversion rule configured as a self-defined resource in a resource definition file of a container arrangement system and determines a target conversion rule matched with the first access parameter in the first request; according to the target conversion rule, adjusting a first access parameter in the first request to be a second access parameter to obtain a second request; and sending the second request to a second service corresponding to the second access parameter.

acquiring a second response sent by the service gateway, wherein the second response carries prompt information which is used for prompting the first service to initiate access to the second service by using the second access parameter;

and outputting prompt information.

According to the embodiment of the present invention, the prompt message may be added to the first response sent by the second service in response to the second request after the service gateway receives the first response.

According to the embodiment of the present invention, the response obtained by the first service carries the prompt information, which indicates that the access initiated by the first service to the second service based on the first access parameter is changed and forwarded by the service gateway, that is, the second service cannot be normally accessed by using the first access parameter, and the access parameter is changed by the second service.

Therefore, after the prompt information is acquired, the prompt information can be output to the developer of the first service, so that the developer of the first service is in butt joint with the developer of the second service, and the first service is modified according to the second service.

Fig. 7 is a flowchart of an embodiment of a request processing method according to another embodiment of the present invention, applied to a second service, where the method may include the following steps:

701, sending the conversion rule to a container arrangement system so that the container arrangement system configures the conversion rule as a self-defined resource in a resource definition file, where the conversion rule is used to convert a first access parameter originally supported by a second service to a second access parameter currently supported by the second service.

According to the embodiment of the present invention, in the case where the access parameter of the second service is converted from the originally supported first access parameter to the currently supported second access parameter, the second service may generate the conversion rule according to the change information of the first access parameter and the second access parameter.

Optionally, the second service may further write identification information of the second service and request type information adapted to the conversion rule in the conversion rule, where the request type information may include information such as a protocol type, an access method, and an address. By writing the identification information of the second service and the request type information adapted to the conversion rule in the conversion rule, it is possible to filter the received request using the identification information and the request type information adapted to the conversion rule, and process the request matching the identification information and the request type information adapted to the conversion rule using the conversion rule.

And 702, receiving a second request based on a second access parameter, which is sent by the service gateway, wherein the second request is generated by adjusting the first access parameter in the first request to the second access parameter by using a target conversion rule, and the target conversion rule is determined by determining a matching relationship between the first access parameter in the first request and a conversion rule which is used as a custom resource configuration in a resource definition file searched by the container arrangement system.

For a specific generation manner of the second request, reference may be made to the request processing method provided in the embodiment shown in fig. 3, which is not described herein again.

Fig. 8 is a schematic structural diagram of an embodiment of a service gateway provided in an embodiment of the present invention, where the service gateway 800 may include:

a first obtaining module 801, configured to obtain a first request sent by a first service;

a rule matching module 802, configured to search a conversion rule configured as a user-defined resource in a resource definition file of the container arrangement system, and determine a target conversion rule matching a first access parameter in the first request;

a parameter adjusting module 803, configured to adjust a first access parameter in the first request to a second access parameter according to the target conversion rule to obtain a second request;

the request processing module 804 is configured to send the second request to a second service corresponding to the second access parameter.

According to an embodiment of the present invention, the rule matching module 802 includes a first obtaining sub-module, a first determining sub-module, and a second determining sub-module.

The first obtaining submodule is used for obtaining first field information in the first access parameter;

a first determining submodule, configured to determine, according to the first field information, whether a conversion rule declared by the second service is included in the resource definition file;

a second determining sub-module, configured to determine the conversion rule as a target conversion rule if the conversion rule declared by the second service is included in the resource definition file.

According to an embodiment of the present invention, the first determination submodule includes a first determination unit and a second determination unit.

A first determination unit configured to determine whether the first field information matches second field information included in the conversion rule;

a second determining unit, configured to determine the conversion rule having a matching relationship between second field information and the first field information as the conversion rule declared by the second service.

According to an embodiment of the present invention, the service gateway 800 further includes an answer receiving unit, an information adding unit, and an answer transmitting unit.

A response receiving unit, configured to receive a first response sent by the second service in response to the second request;

an information adding unit, configured to add prompt information to the first response to generate a second response, where the prompt information is used to prompt the first service to initiate access to the second service by using the second access parameter;

a response sending unit, configured to send the second response to the first service.

According to an embodiment of the present invention, the parameter adjusting module 803 includes a first adjusting unit or a second adjusting unit.

A first adjusting unit, configured to replace a target parameter included in the first access parameter with a parameter declared in the conversion rule;

and the second adjusting unit is used for generating a conversion parameter by using the parameter stated in the conversion rule and the target parameter included in the first access parameter, and replacing the target parameter by using the conversion parameter.

According to an embodiment of the present invention, the service gateway 800 further includes a listening unit and a rule holding unit.

The monitoring unit is used for monitoring a conversion rule which is configured in a resource definition file as a self-defined resource from the container arrangement system;

and the rule storage unit is used for storing the conversion rule obtained by monitoring.

Fig. 9 is a schematic structural diagram of an embodiment of a container arrangement system according to an embodiment of the present invention, where the container arrangement system 900 may include:

a rule receiving module 901, configured to receive a conversion rule configured according to a resource definition manner for any service;

a resource allocation module 902, configured to allocate the conversion rule as a custom resource in a resource definition file; the resource definition file is used for searching a matched target conversion rule from a first request of a first service by the service gateway, and the target conversion rule is used for indicating that a first access parameter in the first request is modified into a second access parameter to obtain a second request.

An embodiment of the present invention provides a service, including:

the request sending module is used for sending a first request based on the first access parameter to the service gateway so that the service gateway can search a conversion rule configured as a self-defined resource in a resource definition file of the container arrangement system and determine a target conversion rule matched with the first access parameter in the first request; according to the target conversion rule, adjusting a first access parameter in the first request to be a second access parameter to obtain a second request; and sending the second request to a second service corresponding to the second access parameter.

Fig. 10 is a schematic structural diagram of an embodiment of a service according to an embodiment of the present invention, where the service 1000 may include:

a rule sending module 1001, configured to send a conversion rule to a container arrangement system, so that the container arrangement system configures the conversion rule as a custom resource in a resource definition file, where the conversion rule is used to convert a first access parameter originally supported by a second service to a second access parameter currently supported by the second service;

a request receiving module 1002, configured to receive a second request sent by the service gateway and based on a second access parameter, where the second request is generated by adjusting a first access parameter in the first request to the second access parameter by using a target transformation rule, and the target transformation rule is determined by determining a matching relationship between the first access parameter in the first request and a transformation rule, which is configured as a custom resource, in a resource definition file found by the container arrangement system.

The service gateway illustrated in fig. 8 may execute the request processing method described in the embodiment illustrated in fig. 3, and the container scheduling system illustrated in fig. 9 may execute the request processing method described in the embodiment illustrated in fig. 6, and the implementation principle and the technical effect thereof are not described again. The specific manner in which each module and unit of the service gateway and container orchestration system in the above embodiments perform operations has been described in detail in the embodiments related to the method, and will not be described in detail herein.

In one possible design, the virtual appliance provided by the embodiment of the present invention may be implemented as a computing device, as shown in fig. 11, which may include a storage component 1101 and a processing component 1102;

the storage component 1101 stores one or more computer instructions, wherein the one or more computer instructions are invoked by the processing component 1102 for execution, so as to implement the request processing method provided by the embodiment of the present invention.

Of course, a computing device may also necessarily include other components, such as input/output interfaces, communication components, and so forth. The input/output interface provides an interface between the processing components and peripheral interface modules, which may be output devices, input devices, etc. The communication component is configured to facilitate wired or wireless communication between the computing device and other devices, and the like.

The computing device may be a physical device or an elastic computing host provided by a cloud computing platform, and the computing device may be a cloud server, and the processing component, the storage component, and the like may be a basic server resource rented or purchased from the cloud computing platform.

When the computing device is a physical device, the computing device may be implemented as a distributed cluster consisting of a plurality of servers or terminal devices, or may be implemented as a single server or a single terminal device.

In practical application, the computing device may specifically deploy a node in the message queue system, and implement the node as a producer, a consumer, a transit server, a naming server, or the like in the message queue system.

The embodiment of the present invention further provides a computer-readable storage medium, which stores a computer program, and the computer program, when executed by a computer, can implement the request processing method provided by the embodiment of the present invention.

The embodiment of the present invention further provides a computer program product, which includes a computer program, and when the computer program is executed by a computer, the request processing method provided by the embodiment of the present invention can be implemented.

The processing components in the respective embodiments above may include one or more processors executing computer instructions to perform all or part of the steps of the above methods. Of course, the processing elements may also be implemented as one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), controllers, micro-controllers, microprocessors or other electronic components configured to perform the above-described methods.

The storage component is configured to store various types of data to support operations in the device. The memory components may be implemented by any type or combination of volatile and non-volatile memory devices such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disks.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one position, or may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.

Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware. With this understanding in mind, the above-described technical solutions may be embodied in the form of a software product, which can be stored in a computer-readable storage medium such as ROM/RAM, magnetic disk, optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments.

Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions in the embodiments of the present application.

Claims

1. A request processing method is applied to an application system comprising a first service and a second service, and is characterized by comprising the following steps:

acquiring a first request sent by a first service;

2. The method of claim 1, wherein determining a target translation rule that matches a first access parameter in the first request comprises:

acquiring first field information in the first access parameter;

determining the conversion rule as a target conversion rule in case that the conversion rule declared by the second service is included in the resource definition file.

3. The method of claim 2, wherein the determining whether the conversion rule declared by the second service is included in the resource definition file according to the first field information comprises:

determining the conversion rule having a matching relationship of second field information and the first field information as the conversion rule declared by the second service.

4. The method of claim 1, further comprising:

sending the second reply to the first service.

5. The method of claim 1, wherein the adjusting the first access parameter in the first request to obtain the second request as the second access parameter comprises:

replacing a target parameter included in the first access parameter with a parameter declared in the conversion rule;

or,

and generating a conversion parameter by using the parameters stated in the conversion rule and the target parameter included by the first access parameter, and replacing the target parameter by using the conversion parameter.

6. The method of claim 1, further comprising:

monitoring a conversion rule configured in a resource definition file as a self-defined resource from the container arrangement system;

and saving the conversion rule obtained by monitoring.

7. A method for processing a request, comprising:

8. The method of claim 7, wherein configuring the transformation rules as custom resources in a resource definition file comprises:

checking fields included in the conversion rule based on standard fields specified by the resource definition file;

9. A method for processing a request, comprising:

10. A request processing method, comprising:

11. A computing device comprising a processing component and a storage component;

the storage component stores one or more computer instructions; the one or more computer instructions are for execution by the processing component to invoke, implement the request processing method of any one of claims 1 to 6, or implement the request processing method of claim 7, or implement the request processing method of claim 9, or implement the request processing method of claim 10.

12. A computer storage medium, characterized in that a computer program is stored which, when executed by a computer, implements the request processing method of any one of claims 1 to 6, or implements the request processing method of claim 7, or implements the request processing method of claim 9, or implements the request processing method of claim 10.