CN114938396A

CN114938396A - Routing method of service call request, method and device for creating service

Info

Publication number: CN114938396A
Application number: CN202210499122.4A
Authority: CN
Inventors: 泮圣伟; 肖京; 张乎兴
Original assignee: Alibaba China Co Ltd
Current assignee: Alibaba China Co Ltd
Priority date: 2022-05-09
Filing date: 2022-05-09
Publication date: 2022-08-23

Abstract

The application provides a routing method of a service call request, a method and a device for creating a service and electronic equipment. The routing method comprises the following steps: receiving a first service calling request, wherein the first service calling request carries environment indication information and a first domain name and is used for calling a first service based on the first domain name, and the environment indication information is used for indicating the environment to which the first service calling request belongs; determining whether the first service calling request belongs to a second environment according to the environment indication information, and determining whether the second environment is deployed with a second service according to a second domain name; and under the condition that the first service invoking request belongs to a second environment and the second environment is provided with a second service, routing the second service invoking request to the second service based on a second domain name, wherein the second service invoking request carries a second domain name and is used for invoking the second service based on the second domain name. According to the technical scheme, the micro-service treatment capability of the cloud computing platform can be realized at a lower cost.

Description

Routing method of service call request, method and device for creating service

Technical Field

The invention relates to the technical field of cloud computing, in particular to a service call request routing method, a service creating method and device and electronic equipment.

Background

With the development of Cloud computing technology, the concept of Cloud Native (Cloud Native) comes. Cloud-native is a set of cloud technology product systems established based on technologies such as container, micro-service, Development and Operation and maintenance (developers). The cloud computing platform may provide containers for users to run micro-services using container technology, and create and manage containers using a container management platform (e.g., kubernets, K8s for short).

With the rapid increase of the number of micro services, more complex micro service governance capabilities need to be implemented, such as full link pressure testing, full link grayscale, environmental isolation, etc., and these scenarios need to implement routing of service invocation requests on links composed of multiple services. However, the current routing scheme usually needs to rely on a registry to implement service discovery, or implement service discovery based on a service grid mode, and the implementation cost and the operation and maintenance cost are high.

Disclosure of Invention

In view of this, embodiments of the present application aim to provide a routing method for a service invocation request, a method and an apparatus for creating a service, and an electronic device, which can implement a micro-service governance capability of a cloud computing platform at a lower cost.

In a first aspect, an embodiment of the present application provides a method for routing a service invocation request, including: receiving a first service calling request, wherein the first service calling request carries environment indication information and a first domain name and is used for calling a first service based on the first domain name, and the environment indication information is used for indicating the environment to which the first service calling request belongs; determining whether the first service calling request belongs to a second environment according to the environment indication information, and determining whether the second environment is provided with a second service according to a second domain name, wherein the second service is a new version of a third service provided in the first environment, and the second domain name is the domain name of the second service; and under the condition that the first service invoking request belongs to a second environment and the second environment is provided with a second service, routing the second service invoking request to the second service based on a second domain name, wherein the second service invoking request carries a second domain name and is used for invoking the second service based on the second domain name.

In a second aspect, an embodiment of the present application further provides a method for creating a service, including: creating a first service and a third service in the first environment according to the first profile of the first service and a third profile of the third service, wherein the third service is configured downstream of the first service; determining environment indication information according to a second configuration file, wherein the second configuration file comprises the environment indication information, and the environment indication information is used for indicating the flow of a second service calling request belonging to a second environment; determining a second domain name based on the environment indication information and the third domain name; a second service is created based on the second domain name, wherein the second service is configured downstream from the first service, wherein the second service is a new version of a third service deployed in the first environment.

In a third aspect, an embodiment of the present application provides a routing apparatus for a service invocation request, including: the receiving module is used for receiving a first service calling request, the first service calling request carries environment indication information and a first domain name and is used for calling a first service based on the first domain name, and the environment indication information is used for indicating the environment to which the service calling request belongs; the determining module is used for determining whether the first service calling request belongs to a second environment according to the environment indication information, and determining whether the second environment is provided with a second service according to a second domain name, wherein the second service is a new version of a third service provided in the first environment, and the second domain name is the domain name of the second service; and the routing module is used for routing the second service calling request to a second service based on a second domain name under the condition that the first service calling request belongs to the second environment and the second environment is provided with the second service, and the second service calling request carries the second domain name and is used for calling the second service based on the second domain name.

In a fourth aspect, an embodiment of the present application provides an apparatus for creating a service, including: a creation module to create a first service and a third service in a first environment according to a first profile of the first service and a third profile of the third service, wherein the third service is configured downstream of the first service; the creating module is further configured to create a second service based on the second domain name, wherein the second service is configured downstream of the first service, and the second service is a new version of a third service deployed in the first environment.

In a fifth aspect, an embodiment of the present application provides an electronic device, including: a processor; a memory for storing processor executable instructions, wherein the processor is configured to perform the routing method of the first aspect.

In a sixth aspect, an embodiment of the present application provides a computer-readable storage medium, where a computer program is stored, and the computer program is configured to execute the routing method of the first aspect.

In a seventh aspect, an embodiment of the present application provides a computer program product, where the computer program product includes instructions, and the instructions, when executed by a processor of a computer device, enable the computer device to perform the method steps in the foregoing implementation manner.

The embodiment of the application provides a routing method for a service invocation request, which is characterized in that under the condition that a received first service invocation request is the flow of a second environment and the second environment is provided with a second service (namely a new version service corresponding to a formal service of the first environment), the second service invocation request is preferentially routed to the second service, so that the flow belonging to the second environment is preferentially routed in the second environment. Because the routing of the service invocation request in the second environment can be realized based on the domain name of the second service only by judging whether the first service invocation request belongs to the flow of the second environment or not, the dynamic routing of the service invocation request in different environments can be realized without depending on the registration center for service discovery, and thus the complex micro-service administration capability can be realized at lower cost.

Drawings

Fig. 1 is a schematic diagram illustrating an architecture of a cloud computing system according to an exemplary embodiment of the present application;

fig. 2 is a schematic diagram illustrating a system architecture of a K8s cluster according to an exemplary embodiment of the present application;

FIG. 3 is a flow chart illustrating a method for creating a service provided by an exemplary embodiment of the present application;

FIG. 4 is a schematic diagram illustrating a routing environment for a service invocation request provided by an exemplary embodiment of the present application;

fig. 5 is a flowchart illustrating a method for routing a service invocation request according to an exemplary embodiment of the present application;

fig. 6 is a flowchart illustrating a method for routing a service invocation request according to another exemplary embodiment of the present application;

fig. 7 is a flowchart illustrating a method for routing a service invocation request according to another exemplary embodiment of the present application;

FIG. 8 is a diagram illustrating an inter-service invocation process provided by an exemplary embodiment of the present application;

FIG. 9 is a diagram illustrating an inter-service invocation process provided by another exemplary embodiment of the present application;

FIG. 10 is a diagram illustrating an inter-service invocation process provided by another exemplary embodiment of the present application;

FIG. 11 is a schematic diagram illustrating a gray scale service capacity reduction process according to another exemplary embodiment of the present application;

fig. 12 is a schematic structural diagram of a routing apparatus for a service invocation request according to an exemplary embodiment of the present application;

FIG. 13 is a block diagram illustrating an apparatus for creating a service according to another exemplary embodiment of the present application;

fig. 14 is a block diagram illustrating an electronic device for performing the method of the above embodiment according to an exemplary embodiment of the present application.

Detailed Description

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 technical scheme of the embodiment of the application can be applied to a cloud computing scene for providing the container operation service.

In order to facilitate understanding of the technical aspects of the embodiments of the present application, technical terms appearing in the specification are first explained in detail below.

Micro-service architecture: is an architecture concept aiming at realizing the decoupling of the solution by decomposing the functions of the application into discrete services and enabling each service to have own process and run in a container to play the role of isolating the service.

K8s Cluster (Cluster): the method is an open-source container management platform and is used for managing containers on a cloud computing platform. The K8s Service is a group of Pod external access interfaces providing the same Service, and by means of the K8s Service, Service discovery and load balancing can be conveniently realized. The K8s Service provides each Pod with its own Internet Protocol (IP) address and provides the same Domain Name System (DNS) for a group of pods, each Pod in the group of pods running the same Service and load balancing among the pods. The K8s Service is responsible for establishing and maintaining the mapping relation between the Service and the Pod.

Full link gray scale: when a service which is running stably has a new version and needs to be released online, a small part of flow is guided to the new version service, so that problems can be found in time. Sometimes, a new function needs to be upgraded online by a plurality of services at the same time, and full link gray level is used for carrying out small-flow gray level verification on a plurality of different versions of services by constructing environment isolation from a service gateway to the whole back-end service.

And (3) testing the full link pressure: the method is used for simulating massive service call requests and data to perform pressure test on the whole service chain based on actual production service scenes and system environments.

And (3) environment isolation test: the method realizes the differentiation of distributed call services of a test environment and a production environment through a request routing technology so as to prevent mutual interference among different environments.

HttpClient: is a toolkit used to provide client programming and supports the latest version and recommendations of the hypertext Transfer Protocol (HTTP). Java applications can access network resources directly through the HTTP protocol.

Java agent (agent) technology: also known as Java probes or byte-instrumentation, is a technique that can intercept and modify bytecode when it is loaded and can modify the bytecode that is already loaded during the virtual machine's execution. For example, the bytecode of the Java agent and the bytecode of the main program can be loaded into the virtual machine to run, that is, the Java class is modified by means of bytecode enhancement to realize the desired function.

Spring Boot: the Spring framework is an open source application framework on the Java platform. The Spring Boot inherits the original excellent characteristics of the Spring framework, and the whole building and developing process of the Spring application is further simplified by simplifying configuration.

With the popularization of cloud originality, the Spring Boot application can use a simple HttpClient tool to call K8sService to realize the intercommunication among services. Http parent is becoming increasingly popular with some small and medium-sized businesses because of its simplicity and convenience in use in conjunction with K8 s. However, only by using the http client to call the K8s Service, it is difficult to meet the requirement of the enterprise for Service management after the increase of the number of micro services, for example, the method can only realize Service discovery, and cannot perform routing, so that it is difficult to realize micro Service management capabilities such as gray scale distribution, full link gray scale, full link pressure test, and environmental isolation test.

A micro-service administration scheme requires a user to access a Spring Boot application to a service grid system, and needs to add a side car (Sidecar) on a Pod of the Spring Boot application, that is, a service administration function is stripped from the application itself to be used as an independent process, the independent process and a main application program are placed in a Host (Host) together and are deployed in respective processes or containers, meanwhile, a full link needs to be matched with sdk to perform link tracking (Trace) transparent transmission, performance loss exists (one hop is needed for each call), in addition, the improvement of a micro-service architecture also causes the increase of operation and maintenance cost, and the technical threshold is raised for the user.

In another micro-service management scheme, a user needs to access the Spring Boot application to the Spring Cloud, and a registration center needs to be additionally arranged for service discovery, so that the cost is increased.

In view of the above technical problems, the embodiment of the present application may implement, through a Java agent and a Microservice Engine (MSE) of K8s, a dynamic routing capability under a scenario of combining http client and K8s Service without intruding, and may not need to access a Service grid system, or depend on a registry, and aims to implement a complex Microservice governance capability at a lower cost.

Exemplary System

Fig. 1 is a schematic architecture diagram of a cloud computing system 100 according to an exemplary embodiment of the present application, which illustrates an application scenario for routing a service invocation request. Cloud computing system 100 may include user terminals 110, service gateway 120, API interface 130, and services 140.

User terminal 110 is communicatively coupled to service gateway 120. The user terminal 110 may be a terminal device such as a mobile phone, a tablet, a notebook, etc. The service gateway 120 is communicatively coupled to services 140 deployed in a cloud (e.g., a K8s cluster) via an API interface 130.

The user terminal 110 may invoke a service deployed in the cloud through, for example, a Web browser. In particular, the user may access a certain service, e.g. an order service, on a user interface of the user terminal 110. A client on the user terminal 110 may issue a service invocation request to the service gateway 120 according to the user's access operation.

The service gateway 120, also called Ingress Controller, is configured to forward traffic of the service invocation request according to the load distribution rule by the service gateway 120. For example, after receiving the service invocation request, the service gateway 120 may send the service invocation request to a group of Pod corresponding to the service 140 according to the load distribution rule, so that the service 140 provides a service response. In addition, in one embodiment, the service gateway may also distribute the traffic of different environments according to the attribute information carried by the service invocation request, for example, distribute the traffic of the formal ring to the service of the formal environment, and distribute the traffic of the grayscale environment to the service of the grayscale environment.

In some cases, multiple services 140 may invoke each other, i.e., one service may invoke another service by sending a service invocation request to another service, e.g., an order service may also invoke a payment service, which in turn may invoke a logistics service, etc. After the call and response among the services, the service gateway finally makes a service response to the user terminal.

Fig. 2 is a schematic diagram of a system architecture of a K8s cluster 200 according to an exemplary embodiment of the present application. The K8s cluster 200, also referred to as a K8s container management platform, may include a master node (master node)210, a plurality of nodes 220, and an Etcd database 230. Master node 210 is used to run the management control modules of the cluster. Node 220 is used to run containers. The Etcd database 230 is used to store state information for the cluster. Alternatively, the Etcd database 230 may be contained within the primary node 210.

Master node 210 may include management control modules such as scheduler 211, micro service engine component 213, DNS 214, and API server 212. The scheduler 211 is used to select a node for the newly established Pod, and is responsible for resource scheduling of the K8s cluster. The API server 212 serves as a portal to the K8s system to provide service calls to external clients and internal components in an API interface manner. The microservice engine component is used to provide microservice management capabilities, for example, the microservice engine component may be the MSE pilot component in K8s, which may monitor the Yaml profile uploaded by the user and automatically create microservices from the Yaml profile. The DNS 214 is used to provide a mapping relationship between a domain name of a service and an IP address of a corresponding Pod.

Node 220, also referred to as a worker node, may include a Kubelet221, a Kube proxy 222, and a plurality of Pod 223. At least one container 224 is disposed in each Pod 223. Kubelet221 is used to manage and control the container, monitor the container's operational status and report to API server 212. The Kube proxy 222 is configured to obtain a mapping relationship between a domain name of a service and an IP address of a corresponding Pod from the API server 212, and implement routing from the service to the Pod according to the mapping relationship.

It should be understood that, on the K8s container management platform, besides the Pod running the service, functional modules such as Kubelet221, Kube proxy 222 and the like can also be implemented by Pod.

It should be noted that the above application scenarios are only presented to facilitate understanding of the spirit and principles of the present application, and the embodiments of the present application are not limited thereto. Rather, embodiments of the present application may be applied to any scenario where it may be applicable.

Exemplary method

For convenience of understanding the technical solution of the embodiment of the present application, the following describes a service creation process by taking a K8s scenario as an example, with reference to fig. 3 and fig. 4. It should be understood that the embodiments of the present application are not limited to the K8s scenario, and may also be applied in other scenarios where service discovery is performed based on a domain name.

Fig. 3 is a flowchart illustrating a method for creating a service according to an exemplary embodiment of the present application. Fig. 4 is a schematic diagram illustrating a routing environment of a service invocation request according to an exemplary embodiment of the present application. The method of fig. 3 may be performed by a server, such as a master node in a container management platform of the K8s cluster of fig. 2. As shown in fig. 3, the method includes the following.

310: a first configuration file of a first service and a third configuration file of a third service are obtained.

In particular, the MSE microservice engine component on the K8s container management platform may obtain a profile of the service entered by the user to create the service from the profile. For example, the configuration file may be a Yaml configuration file, including a Deployment (Deployment) portion and a Service (Service) portion, which may be written manually by a user.

320: a first service and a third service are created according to the first profile and the third profile, the third service being configured downstream of the first service.

Specifically, the Kubelet221 of the K8s container management platform may create a Deployment resource, that is, a Pod including the container, according to the Deployment part of the Yaml configuration file, and create a Service resource, that is, a Service running in the container, for the Deployment resource according to the Service part of the Yaml configuration file. Each service corresponds to a group of Pod, and each Pod in the group of Pod can offload a portion of traffic and run the same service. The first service and the third service may be services that are running stably, hereinafter also referred to as regular services, normal services, or stable services.

Every time a new service is created, the DNS server of the K8s cluster adds a mapping relationship between the domain name of the service and the IP address of the Pod running the service, so that the service can be provided by the IP address inside the K8s cluster.

For example, in the K8s scenario, each service has a unique domain name that is shared by a group of Pod running the service, so the service can be invoked based on the domain name. Downstream services for each service may be configured as each service is created. For example, referring to FIG. 4, assuming an implementation of service A is to invoke service B and an implementation of service B is to invoke service C, service A may be configured with downstream service B when it is created and downstream service C when it is created. When a user wants to access a service A, a service calling request can be sent to a service gateway through a user terminal, the service gateway sends the service calling request to the service A, the service A sends the service calling request to a service B, the service B sends the service calling request to a service C, each service carries out service response after executing respective task, and finally the service gateway carries out service response to the user terminal, so that a link comprising a plurality of services is formed, and the routing of the service calling request on the whole service link is realized.

330: a second configuration file for a second service is obtained.

In order to implement microservice management, an informal environment (also referred to as an abnormal environment, a test environment, or a grayscale environment) corresponding to a formal environment may be established, that is, an informal service corresponding to a formal service, hereinafter also referred to as a new version service, may be created as necessary. The second profile may be generated manually by the user, similar to the first profile.

Alternatively, the second configuration file may only carry the Deployment part, and the Service part may be automatically generated by the microservice engine component of K8s, for example, the MSE pilot component, based on the Deployment part, so that the workload of manually writing code may be reduced, and the user experience may be improved.

340: determining environmental indication information according to the second configuration file.

The process of creating the new version service is similar to the process of creating the formal service, except that the Yaml configuration file of the new version service may further carry environment indication information (e.g., gray scale environment indication information gray), which may also be referred to as an environment tag, an environment variable, or an environment parameter. For example, in the K8s container management platform, the MSE Pilot component may be utilized to identify the environmental indication information in the second configuration file.

350: the second domain name is determined based on the context indication information and the third domain name.

As an example, the domain name of the new version service may be formed by automatically splicing the domain name of the corresponding formal service and the environment indication information by the MSE component 213, that is, the second domain name is formed by splicing the third domain name and the environment indication information. The DNS server may add a mapping of the second domain name to the IP address of the corresponding Pod.

For example, referring to fig. 2, when a Deployment of a Deployment resource is required, the MSE component 213 receives a Yaml file uploaded by a user, reads the environment indication information from the Yaml file, and generates a domain name of a second Service according to the environment indication information, and parameters such as a port in a Service part may be extracted from the Deployment part, and the MSE component 213 generates a Service part of the Yaml file according to the domain name and the parameters, and in addition, the MSE component 213 may also inject installation logic of a Java agent program into the Yaml file, and finally sends the Yaml file to the Api server 212 for subsequent creation of the Deployment resource and a corresponding Service.

360: a second service is created based on the second domain name, the second service configured downstream of the first service as a new version of a third service, wherein the second service is the new version of the third service deployed in the first environment.

When creating a Deployment resource, the K8s container management platform may first create an initialization container and a main container according to the installation logic of the Java agent in the Yaml file, may first run the initialization container, download the Java agent from the initialization container, and install the Java agent in the main container.

The second service and the third service are downstream services of the first service, wherein one part of traffic of the first service is routed to the second service, and the other part of traffic is routed to the third service.

For example, referring again to FIG. 4, service D is a new version of service A and service E is a new version of service C. Service D and service E constitute an abnormal environment. Thus, traffic for the formal version is sent by the user equipment and sequentially passes through the service gateway, the service a, the service B and the service C, while traffic for the new version is sent by the user equipment and sequentially passes through the service gateway, the service D, the service B and the service E.

The embodiment of the application provides a method for creating service, which determines environment indication information according to a configuration file carrying the environment indication information, determines a domain name of a new version service based on the environment indication information and the domain name of formal service, and creates the new version service based on the domain name of the new version service, so that service discovery can be performed through the incidence relation of the domain names of the formal service and the new version service without depending on a registration center, and further, the dynamic routing of a service calling request is realized, and the complex micro-service governing capability can be realized at lower cost.

Taking full link grayscale as an example, a new version service may be implemented by another group of Pod, where each Pod in the group of pods is deployed with the new version service to shunt a part of traffic of the formal service to perform full link grayscale, for example, after the new version service passes verification, all traffic of the formal service may be switched to the new version service. Therefore, the implementation process of the full link gray scale is also a process of gradually establishing a new Pod to run a new version service and gradually destroying the Pod of the formal service until all the traffic is switched to the new version service, and the new version service becomes the formal service.

The above describes a service creation process, and after the service creation, the relevant service can be called according to the service invocation request sent by the user terminal, so as to implement dynamic routing of the service invocation request in different environments.

For convenience of understanding the technical solution of the embodiment of the present application, a routing method of a service invocation request according to the embodiment of the present application is described below with reference to fig. 5 to 6.

Fig. 5 is a flowchart illustrating a method for routing a service invocation request according to an exemplary embodiment of the present application. The method of fig. 5 may be performed by a computing device. Taking the K8s scenario as an example, the computing device may be a working node in fig. 2, and specifically, the working node may act as a client when the service it runs calls other services, and may act as a server when the service it runs is called by other services. It should be understood that the service of the embodiment of the present application may be created based on the method of the embodiment of fig. 3. After the service creation is complete, each service may implement dynamic routing of service invocation requests as follows, as shown in FIG. 5.

510: receiving a first service call request, wherein the first service call request carries environment indication information and a first domain name and is used for calling a first service based on the first domain name, and the environment indication information is used for indicating the environment to which the service call request belongs.

Specifically, the first service may be a service created in the first environment, or may be a service created in the second environment. The first domain name is a domain name set for the first service when the first service is created, and is used as a target domain name of the first service invocation request when the first service is invoked. The first domain name may be preconfigured according to a configuration file provided by a user when creating the first service. Different from the mode of service discovery by adopting IP, the method of service discovery by adopting the domain name does not depend on a registration center, thereby realizing the complex micro-service governing capability with lower cost.

The first environment may refer to a formal environment (also referred to as a normal environment or a stable environment) in which the service is stably operating, and the second environment may be an informal environment (also referred to as an informal environment or an unstable environment) for development or testing, for example, a grayscale environment, an isolation environment, or a pressure test environment.

The environment indication information may be set in a header attribute in the service invocation request or may be set in a reserved field other than the header attribute in the service invocation request. The environment indication information may be an attribute inherent in the service invocation request, or may be information additionally added to indicate the environment to which the service invocation request belongs. For example, the environment indication information may be an environment tag (e.g., a grayscale tag) for indicating that the service invocation request is a second environment (e.g., a grayscale environment).

The first service Call request may be a request message generated using a Remote Procedure Call (RPC) Protocol of an application layer, for example, a request message generated using an Http Protocol, an RPC Protocol, or a dubbo Protocol.

Taking the Http protocol as an example, the first service invocation request may be a Http request. The Http request may carry a first domain name as a destination address to implement routing.

In an embodiment, when the first service is the first accessed service on the service link, the first service invocation request may be a service invocation request from the service gateway. For example, when a user wishes to access a first service, a service invocation request may be sent by the Web browser on the user terminal to the service gateway, which sends the first service invocation request to the first service in response to the service invocation request.

In another embodiment, the first service invocation request may also be a service invocation request from a client of another service. For example, the other service sends the first service invocation request to the first service in response to the service invocation request sent by the service gateway.

520: and determining whether the first service calling request belongs to a second environment according to the environment indication information, and determining whether the second environment is deployed with a second service according to a second domain name, wherein the second service is a new version of a third service deployed in the first environment, and the second domain name is the domain name of the second service.

Specifically, when the environment indication information meets a preset condition, it is determined that the first service invocation request belongs to the traffic of the second environment. In an embodiment, whether the first service invocation request belongs to the traffic of the second environment may be determined according to the attribute information carried in the first service invocation request. The environment indication information may be request feature information or traffic feature information carried in the service invocation request itself, and is used to indicate traffic having a certain commonality, for example, traffic belonging to a certain network segment or a machine room is traffic of a second environment. As another embodiment, it may be determined whether the first service invocation request belongs to traffic of the second environment according to the environment tag carried in the first service invocation request.

The third service (formal service) is a service of the first environment (formal environment), and the second service (grayscale service) is a new version service of the second environment.

It should be understood that, the embodiment of the present application does not limit the execution sequence of the step of determining whether the first request belongs to the second environment and the step of determining whether the second environment is deployed with the second service.

530: and under the condition that the first service invoking request belongs to a second environment and the second environment is provided with a second service, routing the second service invoking request to the second service based on a second domain name, wherein the second service invoking request carries a second domain name and is used for invoking the second service based on the second domain name.

In an embodiment, if the first service invocation request belongs to the second environment, it may be further determined whether the second environment is deployed with the second service, for example, it is determined whether a new version service corresponding to a formal service to be invoked is deployed in the grayscale environment, if the second environment is deployed with the second service, the second service invocation request carrying the environment indication information is generated, and the second service invocation request is routed to the second service based on the second domain name of the second service, so that it is ensured that traffic belonging to the second environment is preferentially routed in the second environment.

In an embodiment, a third service invocation request may be generated first, and then the environment indication information is added to the third service invocation request to obtain the second service invocation request. The third service invoking request is used for invoking the third service based on a third domain name, and the third domain name is a domain name of the third service.

In an embodiment, a third service invocation request may also be generated first, and then a third domain name in the third service invocation request is modified into the second domain name, so as to obtain the second service invocation request.

Optionally, as another embodiment, the routing method in fig. 5 further includes: and under the condition that the first service invoking request belongs to the second environment and the second environment is not deployed with the second service, routing the third service invoking request to the third service based on a third domain name, wherein the third domain name is the domain name of the third service.

Specifically, in some cases, although the first service invocation request belongs to traffic of the second environment, a service of the second environment is not deployed by a service downstream of the first service, and in this case, the third service invocation request may be routed to the third service based on the third domain name of the third service. For example, the first service invocation request belongs to gray-scale traffic, the third service belongs to formal service, and because the third service does not run simultaneously with the gray-scale service, the first service invocation request can be routed to the third service, so that degradation processing can be realized to ensure normal running of the whole service link.

Optionally, as another embodiment, the routing method in fig. 5 further includes: in a case where the first service invocation request belongs to traffic of the first environment, the fourth service invocation request is routed to the third service based on the third domain name.

Specifically, if the first service invocation request belongs to traffic of the formal environment, the first service invocation request may be directly routed to a third service also belonging to the formal environment, so that the formal service can be routed in the formal environment.

Optionally, as another embodiment, in 520, a domain name system of the container management platform may be utilized to perform domain name resolution on the second domain name, and in a case that the domain name resolution is successful, it is determined that the second service is deployed in the second environment.

For example, in K8s, the client of the first service may send a PING command to the DNS server to detect the presence of the second domain name and determine from the DNS server's response whether the second domain name is present. If the DNS service returns a successful response, it can be determined that the second environment has the second service deployed.

The mapping relation between the domain name of the second service and the corresponding Pod is set on the DNS when the second service is created, and whether the domain name exists is determined through DNS detection to determine whether the second service is deployed in the second environment, so that the second service can be discovered without a registration center, and the routing of the second service calling request can be realized at lower cost.

Optionally, as another embodiment, the routing method in fig. 5 further includes: and before the second service calling request is routed to the second service based on the second domain name, generating a third service calling request, and adding environment indication information in the third service calling request to obtain the second service calling request.

In order to realize the function of link tracing, environment indication information can be added in the service invocation request, so that the environment indication information can be transmitted on the service link along with the service invocation request, and various functions related to link tracing can be realized. In addition, whether the service calling request belongs to the second environment or not can be determined according to the environment indication information carried in the service calling request, so that the environment to which the flow belongs can be determined without analyzing other attribute information of the service calling request, and the processing flow is simplified.

Specifically, the bytecode of the Java agent may be added to the bytecode of the main program of the first service, the bytecode of the main program may be used to generate the third service call request, and the bytecode of the Java agent may be used to add the environment indication information in the third service call request. Here, the main program refers to a source code that implements the first service.

For example, the second service call request may be an Http request generated by an Http client tool on the client of the first service, and the bytecode of the Java agent may be added to the bytecode of the main program of the first service in a bytecode-enhanced manner, and the environment indication information may be added to the Http request by using the bytecode of the Java agent running in the client of the first service.

Specifically, in the Http client, the bytecode formed after Java class compilation may be loaded and executed by a Java Virtual Machine (JVM), and the bytecode may be acquired before the bytecode is executed by using Java proxy technology, and the bytecode may be modified to complete the function of adding the grayscale environment indication information for the Http request by running the bytecode in the Virtual Machine. Since the interception and modification of the bytecode can be performed without modifying the source code of the service, the function of adding the environment indication information can be realized in a non-intrusive way, thereby realizing link tracing (trace).

When the Http client of the first service uses Java proxy technology to enhance Http client, when the bytecode of the main program is loaded, the bytecode of a Java proxy program having the following functions may be added: before a client of a first service calls a third service, the environment where the current flow is located is determined, if the current flow is in a gray level environment, DNS detection is carried out on the domain name of a second service, and if the DNS detection fails, the third service in a formal environment is called.

Specifically, a bytecode of a Java agent may be added to a bytecode of a main program of the first service, a third service invocation request is generated using the bytecode of the main program, and a third domain name in the third service invocation request is modified into the second domain name using the bytecode of the Java agent.

In an embodiment, the second domain name may be determined by a third domain name and an environment tag of a third service, that is, there is a corresponding relationship between the second domain name and the third domain name, specifically, there is a conversion relationship between the second domain name and the third domain name, for example, the second domain name may be formed by splicing the third domain name and the environment tag, that is, adding the second domain name to a position adjacent to the third domain name in the third service invocation request. For example, the third domain name is: http:// weeget-bulb-goods-rest-svc. namespace. svc. cluster. local:9390, and accordingly, after splicing the environmental label { tag } on the third domain name, the second domain name may be: http:// weeget-bulb-goods-rest-svc- { tag }. namespace. svc.

Specifically, the target address carried by the Http request may be modified from the third domain name to the second domain name by using the Java agent. That is, without changing the service source code, an Http request for calling a third service (i.e., a formal service) is first generated using the bytecode of the main program, wherein the Http request includes a third domain name as a destination address, and by running the bytecode of the Java agent, the context indication information is added at a location after the third domain name, so that routing of the service call request can be achieved in a non-intrusive manner without changing the service source code.

Specifically, the Http request may be modified in a manner of bytecode enhancement by a Java agent, so as to add the context indication information in the Http request and modify the domain name of the target service. Since the modification operation is realized by combining the compiled bytecode of the main program and the compiled bytecode of the Java agent, the source program code of the service is not modified, and thus routing and link tracing of Http requests in a grayscale environment can be realized noninvasively.

It should be understood that the environment indication information in the domain name of the second service and the environment indication information for indicating the traffic of the second environment may be set at different positions in the second service invocation request, and may be the same as or different from each other, which is not limited in this application.

In an embodiment, a flow distribution rule for determining the flow of the second environment may also be set, where the flow meeting the flow distribution rule enters a new version service for processing, and the flow not meeting the flow distribution rule enters a formal service for processing. The distribution rule may be deployed on a user terminal or a service gateway, or may be deployed on a client of each service, and if the device that deploys the traffic rule determines that the current traffic satisfies the traffic rule, the device may add the environment indication information to the service invocation request sent to the next hop.

Specifically, whether the first service invocation request belongs to the second environment traffic may be determined according to a preset offloading rule and User attribute information carried in the first service invocation request, for example, an attribute User-agent in a header (header) of the Http request may indicate a name and a version of an operating system and a browser used by the client, and an attribute Cookie may be used to identify a User identity, and therefore, a part of the User traffic may be determined to be the second environment traffic according to the User attribute information. And if the user attribute information carried in the first service invocation request meets a preset shunting rule, for example, a browser used by a user is a browser of a certain brand, considering that the first service invocation request is the flow of the second environment.

In another embodiment, if the service gateway or other service invoking the first service has added the environment indication information to the first service invocation request, for example, to the attribute information in the header of the first service invocation request, the client of the first service may determine that the first service invocation request belongs to the traffic of the second environment directly according to the environment indication information carried in the first service invocation request. For example, the environment indication information may be added to the bag attribute in the header. Since most of the RPC protocols support the bagge attribute, setting the storage location of the environmental indication information in this way can improve the universality of the embodiment of the present application.

The position of the environment indication information in the header is not limited in the embodiment of the present application, for example, the environment indication information may be set in a bagge attribute, or the environment indication information may be set in another attribute item. In addition, the form of the environment indication information is not limited in this embodiment, for example, whether the first service invocation request belongs to the second environment may be determined according to whether a certain reserved bit has information, the reserved bit has information indicating that the first service invocation request belongs to the second environment, the reserved bit has no information indicating that the first service invocation request does not belong to the first environment, and whether a certain position has specific information may be determined according to whether the certain position indicates that the first service invocation request belongs to the second environment, for example, whether the value of the specific information at the position is 1 or gray.

It should be understood that the first service and the second service may be created by the K8s container management platform, and the above routing method may be implemented, for example, by a Java agent running on a client that passes through the first service.

Optionally, as another embodiment, the routing method in fig. 5 may further include: receiving an online message sent by a first provider of a second service, wherein the online message comprises identification information of the first provider; adding identification information to a provider list, the provider list containing identification information of providers running the second service; receiving an offline message sent by a first provider, wherein the offline message contains identification information for indicating that the first provider is going to be offline; deleting the identification information from the provider list according to the information about going offline; and when the provider list is empty, stopping calling the second service, adding environment indication information in the fifth service calling request, and routing the fifth service calling request to the third service based on the third domain name of the third service.

The specific implementation manner of this embodiment may refer to the embodiment in fig. 11, and is not described herein again.

Fig. 6 is a flowchart illustrating a method for routing a service invocation request according to another exemplary embodiment of the present application. The routing method of fig. 6 is the example of fig. 5, and a detailed description thereof is omitted.

610: a first service invocation request sent by a service gateway or a client of a service based on a first domain name of a first service is received.

620: and analyzing the first service calling request to obtain an analysis result.

For example, when determining whether the first service invocation request belongs to the traffic of the second environment, the method may be implemented by parsing the attribute information of the first service invocation request.

In an embodiment, the parsing result may include environment indication information for indicating that the first service invocation request is traffic of the second environment. For example, in the first service invocation request, the environment indication information may be included in attribute information of the header of the first service invocation request.

In another embodiment, the resolution result may include user attribute information indicating which type of user the first service invocation request belongs to, e.g., a user using a certain type of browser, a user within a certain IP address range, etc., so that appropriate user traffic may be preferentially selected for testing or verification.

630: and judging whether the first service calling request belongs to the second environment or not according to the analysis result. If so, then 650 is performed, otherwise 640 is performed.

Specifically, the traffic of the first service invocation request belonging to the second environment may be determined according to the environment indication information, or the traffic of the first service invocation request belonging to the second environment may be determined when the user attribute information satisfies the preset condition.

640: a third service invocation request is generated and the fourth service invocation request is routed to the third service based on the third domain name.

It should be understood that step 640 is optional and may be implemented in other ways.

650: and judging whether the second environment is deployed with the second service. If so, 660 is performed, otherwise 680 is performed.

Specifically, whether the second environment is deployed with the second service may be detected based on the second domain name, and in a case that the second domain name is detected, it may be determined that the second environment is deployed with the second service, where the second domain name may be formed by splicing a domain name of the third service and the environment indication information.

660: and generating a third service calling request, and adding environment indication information in the third service calling request to obtain a second service calling request.

For example, in a case where the third service invocation request is an Http request, the environment indication information may be added to the attribute information of the header of the Http request by using a Java agent running in the client of the first service.

670: the second service invocation request is routed to the second service based on the second domain name of the second service.

Specifically, in the case where the first service invocation request belongs to traffic of the first environment, the second service invocation request is routed to the second service based on the second domain name.

Specifically, the target domain name carried in the second service invocation request may be modified from the third domain name to the second domain name by using a Java agent program running in the client of the first service.

680: generating a third service invocation request, and adding the environment indication information in the third service invocation request.

690: and routing the third service invocation request carrying the environment indication information to the third service based on the third domain name of the third service.

Specifically, in the case where the first service invocation request belongs to traffic of the second environment and the second environment is not deployed with the second service, the environment indication information is added to the third service invocation request, and the third service invocation request is routed to the third service based on the third domain name of the third service.

It should be understood that

steps

680 and 690 are optional steps and may be implemented in other ways.

With reference to fig. 7 to fig. 11, a process of implementing full link grayscale capability by non-intrusively enhancing http client in the embodiment of the present application is described with an example of performing service invocation in http client + K8s service mode in a cloud native scene.

Specifically, when a Service a named as ServiceA needs to be created, the K8s may create a Pod according to the Deployment part in the Yaml configuration file of the Service a provided by the user, and create the Service a according to the Service part in the Yaml configuration file with the Deployment as a resource object.

When a user creates a gray level service B (i.e. a new version service B) for a service a in a formal environment, a gray level environment label gray can be added to a Yaml configuration file of the gray level service B, for example, a code is added to the Yaml configuration file: service tag gram. After receiving the Yaml configuration file, the micro service engine of K8s automatically identifies the gray-scale environment label through the mse pilot component, then splices the gray-scale environment label with the domain name of the formal service to obtain the domain name of the gray-scale service B, and creates the gray-scale service B according to the domain name.

For example, K8s may first create a new Pod according to the Yaml profile of the deployment of the grayscale service B provided by the user, and create a corresponding grayscale service B according to the Yaml profile of the grayscale service B with the new Pod as an object, where the name of the grayscale service B may be 'svcname' + 'environment indication information', and the Mse pilot may automatically create a corresponding K8s service 'svcname' + 'environment indication information', e.g., serviceA-gray, for the grayscale service B.

For example, the domain name for service a may be one of:

http:// weeget-bulb-goods-rest-svc. namespace. svc. cluster. local: 9390;

http:// weeget-pellet-goods-rest-svc. namespace 9390;

http://weeget-bullet-goods-rest-svc:9390。

according to the embodiment of the application, the domain name of the service a in the formal environment is spliced with the grayscale label, so that the domain name corresponding to the grayscale service B can be obtained, for example, the domain name of the grayscale service B may be one of the following:

http:// weeget-bulb-goods-rest-svc- { tag }. namespace. svc. cluster. local: 9390;

http:// weeget-bulb-goods-rest-svc- { tag }. namespace 9390;

http://weeget-bullet-goods-rest-svc-{tag}:9390。

fig. 7 is a flowchart illustrating a method for routing a service invocation request according to another exemplary embodiment of the present application. The routing method of fig. 7 is an example of the routing method of fig. 5. As shown in fig. 7, the routing method of the service invocation request includes the following.

710: the user terminal sends an Http request to the service gateway.

715: the service gateway sends an Http request to the first service.

720: and the first service resolves the new Http request to obtain an analysis result.

725: the first service determines whether the Http request belongs to a gray-scale environment according to the parsing result. If so, 740 is performed, otherwise 730 is performed.

730: the first service generates an Http request and adds a grayscale environment tag to the Http request.

Referring to fig. 8, the Http client may be, for example, an Ok Http client, an Apache Http client, or a JDK Http client. Specifically, the Http request may be generated by using a Http client (also referred to as a service consumer) Http client tool, for example, the bytecode obtained by compiling the main program is enhanced by the bytecode obtained by compiling the Java proxy program, when the bytecodes are loaded and run by the Java virtual machine, the Http request is generated by the bytecode of the main program, and then the grayscale environment tag is added to the Http request by using the bytecode of the Java proxy program.

As shown in fig. 8, the user attribute env ═ gray in the service invocation request indicates that the service invocation request is a gray-scale flow, and the user attribute env ═ base in the service invocation request indicates that the service invocation request is a regular flow. The bytecode of a main program of the Http client is loaded and operated in a virtual machine, an Http request for calling a third service is generated, wherein the Http request comprises a target domain name Http:// rest-svc:8080/sayHello of the third service (formal service), when a Java agent program is loaded and operated in the virtual machine, if the received Http request is gray scale flow, a gray label is added on an attribute in a header of the newly generated Http request, the target domain name and the gray environment label gray are spliced to obtain the domain name Http:// rest-svc-gy: 8080/sayHello, DNS detection is then carried out to determine whether the domain name hellt:// rest-svc-gray:8080/sayHello exists, if yes, the target domain name Http:// rest-svc-g/8080/sayHello of the Http request is modified, and routes the Http request to the provider of the second service in the gray-scale environment through a mapping relationship between the service provided by K8s and the IP address of the corresponding service provider (or Pod).

Referring to fig. 9, if a DNS error occurs, that is, it is found through DNS detection that there is no domain name Http:// rest-svc-gray:8080/sayHello, the Http request carrying the grayscale environment label may be routed to a third service provider in the formal environment through a mapping relationship between the service provided by K8s and an IP address of a provider (or Pod) of the corresponding service, thereby implementing automatic degradation of the service. In this way, the grayscale environment tag can be used as a tracking identifier (trace id) to be transmitted in the service link along with the Http request, thereby realizing the full link grayscale capability.

In addition, if the Http request is traffic of the formal environment, the Http request is routed to the provider of the third service in the formal environment directly through the above mapping provided by K8 s.

735: the first service sends an Http request to the third service.

740: the first service probes whether a domain name for the second service exists, if so, 755 is performed, otherwise 745 is performed.

745: the first service generates an Http request and routes the Http request to a third service.

750: the third service sends an Http response to the first service.

755: the first service adds a grayscale environment tag to the Http request and modifies the target address in the Http request from the third domain name to the second domain name.

760: the first service routes the Http request to the second service.

765: the second service makes a service response to the first service.

770: the first service sends an Http response to the service gateway.

775: the service gateway sends an Http response to the user terminal.

According to the embodiment of the application, based on the http client and the K8s Service discovery mechanism, the http client is enhanced by the Java agent technology without changing the existing architecture or changing the source code of the Service, so that the http client and the K8s Service discovery mechanism cooperate to realize the full link gray level capability and the like.

The following describes a capacity reduction process of the service of the grayscale environment according to the embodiment of the present application with reference to fig. 10 and 11.

Fig. 10 is a diagram illustrating a call procedure between services according to another exemplary embodiment of the present application.

According to the embodiment of the application, when the service is normally called, the client of the service follows the principle that the service of the formal environment is called by the service of the formal environment, and the service of the gray-scale environment preferentially calls the service of the gray-scale environment. In the case of pod (active service offline) in the service in the grayscale environment, the embodiment of the present application can ensure that the traffic is automatically switched back (or rolled back) to the service in the default formal environment through a lossless offline mechanism.

Fig. 11 is a schematic diagram illustrating a capacity reduction process of a service of a grayscale environment according to another exemplary embodiment of the present application. The capacity reduction process of fig. 11 includes the following.

1110: the Http client of the first service sends a Http request to a provider of a second service of the grayscale environment to invoke the second service.

As described above, normally, the Http client of the first service may send an Http request to the provider of the second service to invoke the second service when receiving the Http request of the grayscale environment.

1120: the Http client of the first service may maintain and cache a list of addresses of the invoked service providers.

Specifically, the Http request carries an IP address of a provider (Pod) of the first service as a source address, and after receiving the Http request, the provider of the second service may send an online message to the provider of the first service, where the online message carries the IP address of the provider of the second service, and the IP address is cached in the address list.

1130: when the second service provider is ready to scale to 0, it is assumed that the last provider of the service is ready to go offline, at which point the pre-stop (prestop) phase is entered and the second service provider marks itself as being in-line.

1140: the provider of the second service can actively inform the Http client of the first service of the message about to be offline, and the Http client can actively refresh the cached address list after receiving the message about to be offline.

1150: and when the Http client finds that the address list is empty, stopping accessing the second service and actively accessing the service of the formal environment.

1160. And the second service provider starts to execute the offline flow when finding that the request processing is completed.

According to the embodiment of the application, if the Pod capacity corresponding to the service in the gray level environment is reduced, the flow can be ensured to be automatically switched back to the formal environment through a lossless offline mechanism, so that the normal operation of the service is ensured, and the user experience is improved.

It should be understood that, in a scenario of full link pressure measurement or environment isolation, the routing process and the service capacity reduction process of the service invocation request are similar to those in the full link grayscale scenario in the above embodiment, and are not described herein again. Different from the full link gray scale, in a full link pressure measurement or environment isolation scene, the user equipment may determine whether the service invocation request belongs to the second environment, and add the environment indication information to the service invocation request sent to the service gateway, and accordingly, after the service gateway receives the service invocation request, the service invocation request may be analyzed first to obtain the environment indication information, and the environment indication information is carried in the service invocation request sent to the downstream service, and each downstream service may route the service invocation request according to the routing method of the above embodiment.

Exemplary devices

Fig. 12 is a schematic structural diagram of a routing apparatus 1200 for a service invocation request according to an exemplary embodiment of the present application. As shown in fig. 12, the routing apparatus 1200 includes: a receiving module 1210, a determining module 1220, and a routing module 1230.

The receiving module 1210 is configured to receive a first service invocation request, where the first service invocation request carries environment indication information and a first domain name, and is used to invoke a first service based on the first domain name, and the environment indication information is used to indicate an environment to which the first service invocation request belongs.

The determining module 1220 is configured to determine whether the first service invocation request belongs to the second environment according to the environment indication information, and determine whether the second environment is deployed with the second service according to the second domain name, where the second service is a new version of a third service deployed in the first environment, and the second domain name is a domain name of the second service.

The routing module 1230 is configured to route the second service invocation request to the second service based on the second domain name when the first service invocation request belongs to the second environment and the second environment is deployed with the second service, where the second service invocation request carries the second domain name and is used to invoke the second service based on the second domain name.

The embodiment of the application provides a routing device for a service invocation request, which preferentially routes a second service invocation request to a second service under the condition that a received first service invocation request is the traffic of the second environment and the second environment is deployed with the second service (namely, a new version service corresponding to a formal service of a first environment), thereby ensuring that the traffic belonging to the second environment is preferentially routed in the second environment. The routing of the service invocation request in the second environment can be realized based on the domain name of the second service only by judging whether the first service invocation request belongs to the flow of the second environment, so that the dynamic routing of the service invocation request in different environments can be realized without depending on a registration center for service discovery, and the complex micro-service administration capability can be realized at lower cost.

Optionally, as another embodiment, the routing module 1230 is further configured to generate a third service invocation request before routing the second service invocation request to the second service based on the second domain name, where the third service invocation request is used for invoking a third service based on a third domain name, and the third domain name is a domain name of the third service; and adding environment indication information in the third service calling request to obtain a second service calling request.

Optionally, as another embodiment, the routing module 1230 is further configured to add the bytecode of the Java agent to the bytecode of the main program of the first service in a bytecode-enhanced manner. The routing module 1230 is configured to generate a third service call request by using the bytecode of the main program, and add the environment indication information in the third service call request by using the bytecode of the Java proxy.

Optionally, as another embodiment, the routing module 1230 is further configured to generate a third service invocation request before routing the second service invocation request to the second service based on the second domain name, where the third service invocation request is used to invoke a third service based on a third domain name, and the third domain name is a domain name of the third service; and modifying the third domain name in the third service calling request into the second domain name to obtain a second service calling request.

Optionally, as another embodiment, the routing module 1230 is further configured to add a bytecode of a Java agent program to a bytecode of a main program of the first service in a bytecode-enhanced manner, generate a third service invocation request by using the bytecode of the main program, where the third service invocation request is used to invoke a third service based on a third domain name, the third domain name is a domain name of the third service, and modify the third domain name in the third service invocation request into a second domain name by using the bytecode of the Java agent program, so as to obtain the second service invocation request.

In an embodiment, the determining module 1220 is configured to perform domain name resolution on the second domain name by using a domain name system of the container management platform, and determine that the second service is deployed in the second environment if the domain name resolution is successful.

Optionally, as another embodiment, the routing module 1230 is further configured to route the third service invocation request to the third service based on a third domain name when the first service invocation request belongs to the second environment and the second environment is not deployed with the second service, where the third domain name is a domain name of the third service.

In an embodiment, the context indication information includes a context tag indicating that the first service invocation request belongs to the second context, and the second domain name is determined by the domain name of the third service and the context indication information of the second context.

In an embodiment, the receiving module 1210 is configured to receive a first service invocation request sent by a service gateway or a client of a fourth service based on a first domain name, where the first service invocation request carries an environment tag of a second environment. The determining module 1220 is configured to parse the first service invocation request to obtain an environment tag, and determine, according to the environment tag, that the first service invocation request belongs to a traffic of the second environment.

In an embodiment, the receiving module 1210 is configured to receive a first service invocation request sent by a service gateway or a fourth service client based on a first domain name, analyze the first service invocation request to obtain attribute information, and determine that the first service invocation request belongs to a traffic of a second environment when the attribute information meets a preset condition.

Optionally, as another embodiment, the routing module 1230 is further configured to receive an online message sent by the first provider of the second service, where the online message includes identification information of the first provider; adding identification information to a provider list, the provider list containing identification information of providers running the second service; receiving an offline message sent by a first provider, wherein the offline message contains identification information for indicating that the first provider is going to be offline; deleting the identification information from the provider list according to the information about going offline; and when the provider list is empty, stopping calling the second service, adding environment indication information in the fifth service calling request, and routing the fifth service calling request to the third service based on the third domain name.

In one embodiment, the first environment is a formal environment, the second environment is a grayscale environment, an isolated environment, or a stress test environment, the first service invocation request is generated by an http client tool, and the first service is created by a K8s container management platform.

It should be understood that, for the operations and functions of the receiving module 1210, the determining module 1220, the routing module 1230 and the creating module 1240 in the foregoing embodiments, reference may be made to the description in the routing method provided in the foregoing embodiment of fig. 5 or fig. 6, and in order to avoid repetition, details are not repeated here.

Fig. 13 is a schematic structural diagram illustrating an apparatus 1300 for creating a service according to an exemplary embodiment of the present application. As shown in fig. 13, apparatus 1300 comprises: a creation module 1310 and a determination module 1320.

The creation module 1310 is configured to create the first service and a third service in the first environment according to the first profile of the first service and a third profile of the third service, wherein the third service is configured downstream of the first service.

The determining module 1320 is configured to determine environment indication information according to a second configuration file, where the second configuration file includes the environment indication information, and the environment indication information is used to indicate that the second service invocation request belongs to a traffic of a second environment, and determine a second domain name based on the environment indication information and a third domain name.

The creation module 1310 is further for creating a second service based on the second domain name, wherein the second service is configured downstream from the first service, wherein the second service is a new version of a third service deployed in the first environment.

It should be understood that the operations and functions of the creating module 1310 and the determining module 1320 in the above embodiments may refer to the description of the method for creating a service provided in the above embodiment in fig. 3, and are not described herein again to avoid repetition.

Fig. 14 is a block diagram of an electronic device 1400 for performing the method of the above embodiment according to an exemplary embodiment of the present application.

Referring to fig. 14, electronic device 1400 includes a processing component 1410 that further includes one or more processors and memory resources, represented by memory 1420, for storing instructions, such as application programs, that are executable by processing component 1410. The application programs stored in memory 1420 may include one or more modules that each correspond to a set of instructions. Further, the processing component 1410 is configured to execute instructions to perform the routing methods of the above embodiments.

The electronic device 1400 may also include a power component configured to perform power management of the electronic device 1400, a wired or wireless network interface configured to connect the electronic device 1400 to a network, and an input-output (I/O) interface. The electronic device 1400 may be operated based on an operating system, such as Windows Server, stored in the memory 1420 ^TM ，Mac OS X ^TM ，Unix ^TM ，Linux ^TM ，FreeBSD ^TM Or the like.

A non-transitory computer readable storage medium, wherein instructions in the storage medium, when executed by a processor of the electronic device 1400, enable the electronic device 1400 to perform the routing method of the above embodiment.

All the above optional technical solutions can be combined arbitrarily to form optional embodiments of the present application, and are not described herein again.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

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.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one type of logical functional division, and other divisions may be realized in practice, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

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 place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program check codes, such as a U disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk.

It should be noted that, in the description of the present application, the terms "first", "second", "third", etc. are used for descriptive purposes only and are not to be construed as indicating or implying relative importance. In addition, in the description of the present application, "a plurality" means two or more unless otherwise specified.

The above description is only exemplary of the present application and should not be taken as limiting the present application, as any modifications, equivalents and the like that are within the spirit and principle of the present application should be included in the scope of the present application.

Claims

1. A method for routing a service invocation request, comprising:

receiving a first service invocation request, wherein the first service invocation request carries environment indication information and a first domain name and is used for invoking the first service based on the first domain name, and the environment indication information is used for indicating the environment of the first service invocation request;

determining whether the first service calling request belongs to a second environment according to the environment indication information, and determining whether a second service is deployed in the second environment according to a second domain name, wherein the second service is a new version of a third service deployed in the first environment, and the second domain name is a domain name of the second service;

and under the condition that the first service invoking request belongs to a second environment and a second service is deployed in the second environment, routing a second service invoking request to the second service based on the second domain name, wherein the second service invoking request carries the second domain name and is used for invoking the second service based on the second domain name.

2. The routing method of claim 1, prior to said routing a second service invocation request to said second service based on said second domain name, further comprising:

generating a third service calling request, where the third service calling request is used to call a third service based on a third domain name, and the third domain name is a domain name of the third service;

and adding the environment indication information in the third service calling request to obtain the second service calling request.

3. The routing method according to claim 2, further comprising:

adding a bytecode of a Java agent program on a bytecode of a main program of the first service in a bytecode-enhanced manner;

wherein the generating the third service invocation request includes:

generating the third service calling request by using the byte code of the main program;

wherein the adding of the environment indication information of the second environment in the third service invocation request includes:

and adding the environment indication information in the third service calling request by utilizing the byte code of the Java agent program.

4. The routing method according to claim 1, further comprising, prior to said routing a second service invocation request to said second service based on said second domain name:

generating a third service calling request, where the third service calling request is used for calling a third service based on a third domain name, and the third domain name is a domain name of the third service;

and modifying the third domain name in the third service calling request into the second domain name to obtain the second service calling request.

5. The routing method according to claim 4, further comprising:

wherein the generating a third service invocation request includes:

generating a third service calling request by using the bytecode of the main program, wherein the third service calling request is used for calling a third service based on a third domain name, and the third domain name is the domain name of the third service;

wherein the modifying the third domain name in the third service invocation request into the second domain name comprises:

and modifying the third domain name in the third service calling request into the second domain name by using the byte code of the Java agent program to obtain the second service calling request.

6. The routing method according to claim 1, wherein the determining whether the second environment is deployed with the second service according to the second domain name comprises:

and performing domain name resolution on the second domain name by using a domain name system of a container management platform, and determining that the second service is deployed in the second environment under the condition that the domain name resolution is successful.

7. The routing method according to claim 1, further comprising:

and under the condition that the first service invocation request belongs to the second environment and the second environment is not deployed with the second service, routing the third service invocation request to the third service based on a third domain name, wherein the third domain name is the domain name of the third service.

8. The routing method according to claim 1, wherein the context indication information includes a context label indicating that the first service invocation request belongs to a second context, and the second domain name is determined by the domain name of the third service and the context indication information of the second context.

9. The routing method of claim 8, wherein receiving the first service invocation request comprises:

receiving the first service invocation request sent by a service gateway or a fourth service client based on the first domain name, wherein the first service invocation request carries an environment tag of the second environment,

wherein the determining whether the first service invocation request belongs to a second environment according to the environment indication information includes:

analyzing the first service calling request to obtain the environment label;

and determining the flow of the first service calling request belonging to the second environment according to the environment label.

10. The routing method according to claim 1, wherein the environment indication information includes attribute information of a first service invocation request, and wherein the receiving the first service invocation request includes:

receiving the first service calling request sent by a service gateway or a fourth service client based on the first domain name;

the determining whether the first service invocation request belongs to a second environment according to the environment indication information comprises:

analyzing the first service calling request to obtain the attribute information;

and when the attribute information meets a preset condition, determining that the first service invocation request belongs to the flow of a second environment.

11. The routing method according to claim 1, further comprising:

receiving an online message sent by a first provider of the second service, the online message including identification information of the first provider;

adding the identification information in a provider list, the provider list containing identification information of providers running the second service;

receiving an offline message sent by the first provider, wherein the offline message contains the identification information and is used for indicating that the first provider is to be offline;

deleting the identification information from the provider list according to the to-be-offline message;

and when the provider list is empty, stopping calling the second service, adding the environment indication information into a fifth service calling request, and routing the fifth service calling request to the third service based on a third domain name.

12. The routing method according to any one of claims 1 to 11, wherein the first environment is a formal environment, the second environment is a grey-scale environment, an isolated environment, or a stress test environment, the first service invocation request is generated by an http live tool, and the first service is created by a K8s container management platform.

13. A method of creating a service, comprising:

creating a first service and a third service in a first environment according to a first profile of the first service and a third profile of the third service, wherein the third service is configured downstream of the first service;

determining environment indication information according to a second configuration file, wherein the second configuration file comprises the environment indication information, and the environment indication information is used for indicating the flow of a second service call request belonging to a second environment;

determining a second domain name based on the environment indication information and a third domain name;

creating the second service based on the second domain name, wherein the second service is configured downstream from the first service, wherein the second service is a new version of a third service deployed in the first environment.

14. An electronic device, comprising:

a processor;

a memory for storing the processor-executable instructions,

wherein the processor is configured to execute the method for routing a service invocation request according to any of the preceding claims 1 to 12 or the method for creating a service according to claim 13.