Full-link gray scale control method, device, equipment, storage medium and program product

Abstract

The application relates to a full-link gray-scale control method, device, equipment, storage medium and program product. The method comprises the following steps: obtaining a target rule and a virtual service rule of a target service architecture; performing gray-scale control on a first target service based on the target rule, the virtual service rule and a proxy layer of the first target service, wherein the target service architecture comprises an entrance gateway, applications corresponding to services and proxy layers corresponding to the services; obtaining gray-scale control information of the first target service; generating a unique identifier of a calling link of the target service architecture; and transmitting the gray-scale control information to remaining services on the calling link based on the unique identifier, so as to realize gray-scale control of all services in the target service architecture. The method can flexibly perform gray-scale control on the full link without modifying the business.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a method, apparatus, device, storage medium, and program product for end-to-end grayscale control. Background Technology

[0002] With the widespread adoption of microservice architecture, the number of services in a system is increasing, and the call relationships are becoming more complex, leading to higher demands for canary release control capabilities during business iterations. Traditional service governance typically focuses only on canary release control for individual services. However, in a microservice architecture, the need for unified canary release control across multiple services in the microservice call chain is becoming increasingly strong. Current technologies usually achieve end-to-end canary release capabilities by physically isolating the environment or modifying the business logic to achieve logical environment isolation. However, these technologies perform poorly in terms of resource consumption, configuration difficulty, business intrusion, and maintenance costs. Summary of the Invention

[0003] Therefore, it is necessary to provide a method, apparatus, device, storage medium, and program product that can extend grayscale control to the entire link in a non-intrusive and easily configurable manner to address the above-mentioned technical problems.

[0004] Firstly, this application provides a full-link grayscale control method, including:

[0005] Obtain the target rules and virtual service rules of the target service architecture, and perform gray-scale control on the first target service based on the target rules, the virtual service rules and the proxy layer of the first target service. The target service architecture includes an entry gateway, applications corresponding to each service and proxy layers corresponding to each service.

[0006] Obtain the grayscale control information of the first target service;

[0007] A unique identifier is generated for the call chain of the target service architecture. Based on the unique identifier, the grayscale control information is passed through to the remaining services on the call chain to realize grayscale control of all services in the target service architecture.

[0008] In one embodiment, the implementation of grayscale control of the first target service based on the target rule, the virtual service rule, and the proxy layer of the first target service includes:

[0009] When the first target service needs to receive the first grayscale control request, the access version of the first grayscale control request is determined based on the target rules and the virtual service rules.

[0010] Based on the proxy layer, the first grayscale control request is forwarded to the application corresponding to the first target service of the corresponding access version, so as to realize the grayscale control of the first target service.

[0011] In one embodiment, when the first grayscale control request matches the target rule, the access version includes a baseline version or a test version; when the first grayscale control request matches the virtual service rule, the access version includes a test version.

[0012] In one embodiment, obtaining the grayscale control information of the first target service includes:

[0013] Before the first grayscale control request is forwarded to the application corresponding to the first target service, the first grayscale control request is intercepted by the proxy layer, and the grayscale control information of the first grayscale control request is cached.

[0014] In one embodiment, the proxy layer includes a caching plugin, wherein caching the grayscale control information of the first grayscale control request includes:

[0015] Generate a link tracing header value based on the unique identifier;

[0016] The cache identifier is determined based on the link tracing header value, and the grayscale control information is cached based on the cache identifier.

[0017] In one embodiment, the step of passing the grayscale control information to the remaining services on the call chain based on the unique identifier includes:

[0018] When the first target service sends a new request to the second target service on the call chain, the link tracing header value and the grayscale control information are obtained based on the proxy layer of the second target service, wherein the second target service is one of the remaining services on the call chain;

[0019] A second grayscale control request is formed based on the link tracing header value, the grayscale control information, and the new request;

[0020] Based on the proxy layer of the second target service, the second grayscale control request is forwarded to the application corresponding to the second target service to realize the grayscale control of the second target service.

[0021] Secondly, this application also provides a full-link grayscale control device, comprising:

[0022] The first control module is used to obtain the target rules and virtual service rules of the target service architecture, and to perform gray-scale control on the first target service based on the target rules, the virtual service rules and the proxy layer of the first target service. The target service architecture includes an entry gateway, applications corresponding to each service and proxy layers corresponding to each service.

[0023] The acquisition module is used to acquire the grayscale control information of the first target service;

[0024] The second control module is used to generate a unique identifier for the call chain of the target service architecture, and based on the unique identifier, to pass the grayscale control information to the remaining services on the call chain, so as to realize grayscale control of all services in the target service architecture.

[0025] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0026] Obtain the target rules and virtual service rules of the target service architecture, and perform gray-scale control on the first target service based on the target rules, the virtual service rules and the proxy layer of the first target service. The target service architecture includes an entry gateway, applications corresponding to each service and proxy layers corresponding to each service.

[0027] Obtain the grayscale control information of the first target service;

[0028] A unique identifier is generated for the call chain of the target service architecture. Based on the unique identifier, the grayscale control information is passed through to the remaining services on the call chain to realize grayscale control of all services in the target service architecture.

[0029] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0030] Obtain the target rules and virtual service rules of the target service architecture, and perform gray-scale control on the first target service based on the target rules, the virtual service rules and the proxy layer of the first target service. The target service architecture includes an entry gateway, applications corresponding to each service and proxy layers corresponding to each service.

[0031] Obtain the grayscale control information of the first target service;

[0032] A unique identifier is generated for the call chain of the target service architecture. Based on the unique identifier, the grayscale control information is passed through to the remaining services on the call chain to realize grayscale control of all services in the target service architecture.

[0033] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0034] Obtain the target rules and virtual service rules of the target service architecture, and perform gray-scale control on the first target service based on the target rules, the virtual service rules and the proxy layer of the first target service. The target service architecture includes an entry gateway, applications corresponding to each service and proxy layers corresponding to each service.

[0035] Obtain the grayscale control information of the first target service;

[0036] A unique identifier is generated for the call chain of the target service architecture. Based on the unique identifier, the grayscale control information is passed through to the remaining services on the call chain to realize grayscale control of all services in the target service architecture.

[0037] The aforementioned end-to-end grayscale control method, apparatus, computer equipment, computer-readable storage medium, and computer program product configure a proxy layer for each application in the target service architecture, and achieve grayscale control of a single service based on virtual service rules and target rules; grayscale control information is transparently transmitted in the call chain through a unique identifier, thereby realizing end-to-end grayscale control. This application achieves version control information transparently in the call chain through a unique identifier, which is completely transparent to the business, requires no independent resource deployment, and can achieve grayscale control without business modification, making it more business-friendly. Attached Figure Description

[0038] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0039] Figure 1 This is a flowchart illustrating the end-to-end grayscale control method in one embodiment;

[0040] Figure 2 This is a schematic diagram of an existing technology;

[0041] Figure 3 This is a schematic diagram of another existing technology;

[0042] Figure 4 This is yet another schematic diagram of existing technology;

[0043] Figure 5 This is one of the flowcharts illustrating the sub-steps of a full-link grayscale control method;

[0044] Figure 6 This is the second flowchart illustrating the sub-steps of a full-link grayscale control method.

[0045] Figure 7 This is the third step in a flowchart illustrating the sub-steps of a full-link grayscale control method.

[0046] Figure 8 This is the fourth step in a flowchart illustrating the sub-steps of a full-link grayscale control method.

[0047] Figure 9 This is the fifth step in a flowchart illustrating the sub-steps of a full-link grayscale control method.

[0048] Figure 10 This is a flowchart illustrating the end-to-end grayscale control method in a specific embodiment;

[0049] Figure 11 This is a structural block diagram of a full-link grayscale control device in one embodiment;

[0050] Figure 12 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0051] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0052] In a microservice architecture, there are typically multiple microservices, and an ingress gateway exposes the entry point for these microservices, enabling external access. The architecture is as follows: Figure 2 As shown, external requests enter the microservice through the entry gateway. The request chain includes three applications (APP1, APP2, APP3), and also includes a registry center for service discovery between microservices.

[0053] In the business iteration process of a microservice architecture, more than one service is often involved. To ensure the stability of iteration updates, it is usually necessary to conduct canary releases before deployment. This involves first using a portion of traffic in a canary environment to verify whether the business functionality is working properly, and then redirecting all traffic to the new version of the service. There are some common requirements when conducting canary releases of microservices:

[0054] It needs to support unified canary release control for services across the entire access chain; it also needs to support partial canary release capabilities, allowing some services to access the production environment version without participating in the canary release. For monolithic services, this is relatively simple; a canary release policy can be configured at the ingress gateway (the ingress gateway is typically a Layer 7 HTTP proxy with canary release control capabilities), such as... Figure 3 The request shown is forwarded to the production version by default. Requests with headers matching the grayscale version are forwarded to the grayscale version.

[0055] For scenarios involving multiple microservices, the industry generally employs the following methods to achieve end-to-end canary deployment capabilities for microservices:

[0056] Resource isolation: such as Figure 4 As shown, production and canary environments are completely isolated at the resource deployment level (independent service deployment and registry centers). Applications are routed to different environments at the ingress gateway by including different environment selection headers; traffic from each environment is only accessed within that environment. This solution requires the complete deployment of a microservice, including the microservice application itself and surrounding supporting components, which consumes a lot of resources, is complex to deploy, has high maintenance costs, and does not support some canary deployment capabilities (some microservices do not participate in canary deployments and access the production environment version).

[0057] Or such as Figure 5 The logical isolation shown is as follows: production and canary deployment environments reuse the same application deployment resources and registry center. To achieve service access isolation between different environments, the application needs to be modified. Services need to be tagged during deployment (whether they belong to production or canary environments), and service registration and discovery need to be modified to only register and discover within the environment corresponding to the service. This solution requires the registry center to support multi-environment isolation, is intrusive to business logic (supporting multi-environment registration), and does not support some canary deployment capabilities (some microservices do not participate in canary deployments and access the production environment version).

[0058] In one embodiment, such as Figure 1 As shown, a full-link grayscale control method is provided. This embodiment illustrates the method applied to a terminal. It is understood that this method can also be applied to a server, and further to a system including both a terminal and a server, and is implemented through interaction between the terminal and the server. In this embodiment, the method includes the following steps:

[0059] Step 101: Obtain the target rules and virtual service rules of the target service architecture. Based on the target rules, virtual service rules and the proxy layer of the first target service, perform gray-scale control on the first target service. The target service architecture includes the entry gateway, the application corresponding to each service and the proxy layer corresponding to each service.

[0060] Step 102: Obtain the grayscale control information of the first target service;

[0061] Step 103: Generate a unique identifier for the call chain of the target service architecture, and based on the unique identifier, pass the grayscale control information to the remaining services on the call chain to achieve grayscale control of all services in the target service architecture.

[0062] Based on the aforementioned shortcomings of existing technologies, this embodiment introduces service mesh technology. Service mesh technology is a non-intrusive service governance technology that achieves service governance by adding a proxy to the application. A microservice architecture using service mesh technology is as follows: Figure 6 As shown.

[0063] By employing Sidecar Pattern automatic injection technology and traffic interception technology, service governance capabilities are achieved without the business's awareness. When multiple services using service mesh technology communicate, requests entering the target service are intercepted at the target service's local proxy layer and then forwarded to the corresponding local application. When the application needs to access the remaining services in the chain, the traffic is also first intercepted at the local proxy layer and then forwarded to the target application. On the target application side, the traffic is again intercepted at the local proxy layer, and so on.

[0064] For example, this application implements the construction of the proxy layer through the sidecar pattern. The sidecar pattern is an architectural pattern that adds an abstraction layer on top of the original business logic. It is often used in microservices and containerization scenarios.

[0065] Please see Figure 7 As microservice architectures become increasingly complex, the calls generated by a single request become numerous and intricate, making it difficult to pinpoint problems when exceptions occur. Distributed tracing technology was developed to address this issue. Distributed tracing uses the same unique identifier (traceid) across a call chain. Each microservice uses this unique identifier to report observation data, which is then aggregated on a distributed tracing observation platform. Through this unique identifier and other information, the topology of the call chain can be fully reconstructed, revealing information such as the time consumption and exceptions at each stage of the chain.

[0066] In the aforementioned end-to-end canary release control method, a proxy layer is configured for each application in the target service architecture. Based on virtual service rules and target rules, canary release control of a single service is achieved. A unique identifier is used to transmit canary release control information transparently in the call chain, thus realizing end-to-end canary release control. This application uses a unique identifier to transmit version control information transparently in the call chain, which is completely transparent to the business. Canary release control can be achieved without independent resource deployment or business modification, making it more business-friendly.

[0067] In an exemplary embodiment, grayscale control of the first target service is implemented based on target rules, virtual service rules, and a proxy layer of the first target service. This includes: when the first target service needs to receive a first grayscale control request, determining the access version of the first grayscale control request based on the target rules and virtual service rules; and forwarding the first grayscale control request to the application corresponding to the access version of the first target service based on the proxy layer, so as to implement grayscale control of the first target service.

[0068] In an exemplary embodiment, if the first grayscale control request matches the target rule, the accessed version includes either the baseline version or the test version; if the first grayscale control request matches the virtual service rule, the accessed version includes the test version.

[0069] Please see Figure 8 Using a service mesh, versioning and traffic control can be implemented for individual microservices. For example, if app1 has two versions, base and test, a destination rule needs to be defined for app1, which defines the base and test versions. Then, a virtual service rule needs to be defined for app1. When the request header matches the virtual service rule, it will be routed to the test version.

[0070] Configure the DestinationRule and VirtualService rules for services that require end-to-end canary release control, enabling canary release control for individual services. See also... Figure 9 As shown in the diagram, the microservices are deployed with a baseline version (base) and a gray version (grey). The goal is to ensure that a single request only accesses either the gray or base version. Isolation deployment or the use of a separate registry for the base and gray versions is not required.

[0071] When accessing the application individually, including a header with the tag "base" will access the base version, while including a header with the tag "grey" will access the grey version. To achieve end-to-end canary release control, canary release control information needs to be transparently transmitted along the call chain. This canary release control information includes version control information. Transmission is defined as follows: in the call chain, the version control information (such as the version number) of a request is transparently passed from one stage to the next without being modified or ignored. This transmission mechanism ensures the consistency and integrity of version control information throughout the call chain, helping to track and manage the interaction between different versions of the application across various services.

[0072] In an exemplary embodiment, obtaining the grayscale control information of the first target service includes:

[0073] Before the first grayscale control request is forwarded to the application corresponding to the first target service, the first grayscale control request is intercepted by the proxy layer, and the grayscale control information of the first grayscale control request is cached.

[0074] In one exemplary embodiment, the proxy layer includes a caching plugin to cache the grayscale control information of the first grayscale control request, including: generating a link tracing header value based on a unique identifier; determining a cache identifier based on the link tracing header value; and caching the grayscale control information based on the cache identifier.

[0075] When the first grayscale control request reaches the application APP1 corresponding to the first target service, the traffic is first intercepted by the service layer of APP1. The custom plugin in APP1 will cache the version control information. The cache key is the value of the link tracing header (i.e., the unique identifier of the current call chain, which remains unchanged in this call, and the unique identifier is different for different calls). The cached value is the version control information, which is the value of the first grayscale control request header (base).

[0076] After being processed by custom plugins and other proxy layers, the request is forwarded to the application (APP1). The application will receive the tracing header value and the first canary control request header.

[0077] By configuring plugins on the proxy layer, canary control with end-to-end collaboration is achieved. Here, traffic labeling rules are configured for the service layer. These rules are used to enable the transparent transmission of canary control information in the upstream and downstream of the call chain.

[0078] In this embodiment, the above configuration enables canary control of a single microservice and transparent transmission of canary control headers in the call chain, ultimately achieving unified canary control across the entire chain.

[0079] In one exemplary embodiment, passing grayscale control information to the remaining services in the call chain based on a unique identifier includes:

[0080] When the first target service sends a new request to the second target service in the call chain, the proxy layer of the second target service obtains the link tracing header value and canary control information, where the second target service is one of the remaining services in the call chain; a second canary control request is formed based on the link tracing header value, canary control information and the new request; the proxy layer of the second target service forwards the second canary control request to the application corresponding to the second target service to realize the canary control of the second target service.

[0081] Because the business uses distributed tracing, when the first target service (such as APP1) sends a request to the outside, it will include the distributed tracing header, but it will not include the first canary control request header (this header is a custom header, which is unrelated to distributed tracing and the business does not need to pay attention to it, so it will not be passed through in the call chain).

[0082] The request sent out by APP1 is first intercepted by the local proxy layer of the service. The custom plugin retrieves the grayscale control information from the cache based on the link tracing header value in the request, and then includes the grayscale control information in the request sent out. The local proxy layer will implement grayscale access to the next service APP2 based on the grayscale control information. The same processing will be performed when the request reaches APP2, and this process will be repeated in the entire call chain.

[0083] To illustrate the end-to-end grayscale control method of this application in detail, the following is a detailed embodiment:

[0084] For example, target rules and virtual service rules can be defined according to the following logic:

[0085] Destination Rule:

[0086] host:app1;

[0087] Subsets:

[0088] -name: base;

[0089] matchLabels;

[0090] version: base;

[0091] -name: test;

[0092] matchLabels;

[0093] version: test.

[0094] Virtual Service Rules (VirtualService):

[0095] host: app1;

[0096] routes:

[0097] -match: x-traffic-tag=test;

[0098] destination: test.

[0099] For services requiring end-to-end canary release control, configure the DestinationRule and VirtualService settings to implement canary release control for individual services. See [link to relevant documentation]. Figure 9 And the following logic:

[0100] Destination Rule:

[0101] host:APP1;

[0102] Subsets;

[0103] -name: base;

[0104] matchLabels;

[0105] version: base;

[0106] -name: grey;

[0107] matchLabels:

[0108] version: grey.

[0109] VirtualService:

[0110] host: APP1;

[0111] routes:

[0112] -match: x-traffic-tag=base;

[0113] destination: base;

[0114] routes:

[0115] match: x-traffic-tag=grey;

[0116] destination: grey.

[0117] Destination Rule:

[0118] host:APP2;

[0119] Subsets;

[0120] -name: base;

[0121] matchLabels;

[0122] version: base;

[0123] -name: grey;

[0124] matchLabels:

[0125] version: grey.

[0126] VirtualService:

[0127] host: APP1;

[0128] routes:

[0129] -match: x-traffic-tag=base;

[0130] destination: base;

[0131] routes:

[0132] match: x-traffic-tag=grey;

[0133] destination: grey.

[0134] Destination Rule:

[0135] host:APP3;

[0136] Subsets;

[0137] -name: base;

[0138] matchLabels;

[0139] version: base;

[0140] -name: grey;

[0141] matchLabels:

[0142] version: grey.

[0143] VirtualService:

[0144] host: APP1;

[0145] routes:

[0146] -match: x-traffic-tag=base;

[0147] destination: base;

[0148] routes:

[0149] match: x-traffic-tag=grey;

[0150] destination: grey.

[0151] When accessing APP1, APP2, and APP3 individually, the base version will be accessed when the x-traffic-tag=base header is included, and the grey version will be accessed when the x-traffic-tag=grey header is included. To achieve full-link grayscale control, we also need to pass grayscale control information through the call chain, which is where x-traffic-tag comes in.

[0152] We achieve end-to-end collaborative canary deployment control by configuring a self-developed plugin on the sidecar. Here, we configure traffic labeling rules for each sidecar. These rules are used to ensure the transparent transmission of the x-traffic-tag header in the upstream and downstream of the call chain. For details on traffic labeling rules, please refer to:

[0153] TrafficLabel:

[0154] host: APP1;

[0155] label:

[0156] header: x-traffic-tag;

[0157] trace-id:x-request-id.

[0158] TrafficLabel:

[0159] host: APP2;

[0160] label:

[0161] header: x-traffic-tag;

[0162] trace-id:x-request-id.

[0163] TrafficLabel:

[0164] host: APP3;

[0165] label:

[0166] header: x-traffic-tag;

[0167] trace-id: x-request-id.

[0168] As explained above, this configuration enables canary deployment control for a single microservice and allows canary deployment control headers to be passed through the call chain. The ultimate goal is to achieve unified canary deployment control across the entire service chain. For example, if a request includes the `x-traffic-tag=base` header, the request will flow within the `base` versions of APP1, APP2, and APP3. If the request includes the `x-traffic-tag=grey` header, the request will flow within the `grey` versions of APP1, APP2, and APP3.

[0169] Canary release control for individual microservices can be achieved through virtual service rules and target rules configuration. To achieve unified canary release control across the entire call chain, the core is to transparently transmit canary release control information along the call chain; this capability can be achieved through custom plugins combined with call chain tracing capabilities. The overall architecture is as follows: Figure 10 .

[0170] The request steps are explained below:

[0171] When a client makes a request, it includes a version control header, such as x-traffic-tag in this case, and accesses the microservice through the Ingress gateway.

[0172] When the Ingress gateway accesses APP1, it combines the target rules and virtual service configuration of APP1 to implement canary release control of access to APP1. In the diagram above, it will access the base version of APP1. At the same time, the Ingress gateway, as a gateway, will forward the user request header, including x-traffic-tag, and will also add the x-request-id header for tracing the network.

[0173] When a request arrives at APP1, the traffic is first intercepted by APP1's sidecar. The custom plugin in APP1 caches version control information, with the cache key being the value of the x-request-id header (i.e., the traceid of the current call chain, which remains unchanged in this call, but different calls have different traceids). The cached value is the version control information, which in this case is the value of the x-traffic-tag header (base).

[0174] After being processed by custom plugins and other sidecars, the request is forwarded to the application (APP1). The application will receive the x-request-id and the x-traffic-tag, which includes canary control information.

[0175] Because the business uses distributed tracing, when APP1 sends a request to the outside, it will include the x-request-id header, but will not include the x-traffic-tag (this header is a custom header, which is unrelated to distributed tracing and the business does not need to pay attention to it, so it will not be passed through in the call chain).

[0176] The request sent out by APP1 is first intercepted by the local sidecar. The custom plugin retrieves the value of x-traffic-tag from the cache based on the x-request-id header value in the request, and then includes the canary control information in the request sent out, which is x-traffic-tag: base. The local sidecar will use this header to implement canary access to the next service APP2, that is, access the base version of APP2.

[0177] When the request reaches APP2, it will be processed in the same way, and this process will continue in a loop throughout the entire call chain.

[0178] The benefit of this embodiment is that it enables the ability to pass version control information through the call chain in a non-intrusive manner within the service mesh, and achieves unified grayscale control across the entire chain by combining the service mesh's native grayscale control capability for individual services.

[0179] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0180] Based on the same inventive concept, this application also provides a full-link grayscale control device for implementing the full-link grayscale control method described above. The solution provided by this device is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more full-link grayscale control device embodiments provided below can be found in the limitations of the full-link grayscale control method described above, and will not be repeated here.

[0181] In one exemplary embodiment, such as Figure 11 As shown, a full-link grayscale control device 200 is provided, including: a first control module 201, an acquisition module 202, and a second control module 203, wherein:

[0182] The first control module 201 is used to obtain the target rules and virtual service rules of the target service architecture, and to perform gray-scale control on the first target service based on the target rules, virtual service rules and the proxy layer of the first target service. The target service architecture includes an entry gateway, applications corresponding to each service and proxy layers corresponding to each service.

[0183] The acquisition module 202 is used to acquire the grayscale control information of the first target service;

[0184] The second control module 203 is used to generate a unique identifier for the call chain of the target service architecture, and based on the unique identifier, to pass the grayscale control information to the remaining services on the call chain, so as to realize the grayscale control of all services in the target service architecture.

[0185] The first control module 201 is also used for:

[0186] If the first target service needs to receive the first grayscale control request, the access version of the first grayscale control request is determined based on the target rules and virtual service rules.

[0187] Based on the proxy layer, the first grayscale control request is forwarded to the application corresponding to the first target service of the corresponding access version, so as to realize the grayscale control of the first target service.

[0188] The first control module 201 is also used for:

[0189] Before the first grayscale control request is forwarded to the application corresponding to the first target service, the first grayscale control request is intercepted by the proxy layer, and the grayscale control information of the first grayscale control request is cached.

[0190] The first control module 201 is also used for:

[0191] Generate link tracing header values ​​based on unique identifiers;

[0192] The cache identifier is determined based on the link tracing header value, and the grayscale control information is cached based on the cache identifier.

[0193] The first control module 201 is also used for:

[0194] When the first target service sends a new request to the second target service in the call chain, the proxy layer based on the second target service obtains the link tracing header value and canary control information, wherein the second target service is one of the remaining services in the call chain;

[0195] A second grayscale control request is formed based on the link tracing header value, grayscale control information, and the new request;

[0196] Based on the proxy layer of the second target service, the second canary control request is forwarded to the application corresponding to the second target service to realize the canary control of the second target service.

[0197] Each module in the aforementioned end-to-end grayscale control device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0198] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 12As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a full-link grayscale control method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0199] Those skilled in the art will understand that Figure 12 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0200] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0201] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0202] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0203] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0204] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0205] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A full link gray scale control method, characterized by, The method includes: Obtain the target rules and virtual service rules of the target service architecture. Based on the target rules, the virtual service rules, and the proxy layer of the first target service, perform canary deployment control on the first target service. The target service architecture includes an entry gateway, applications corresponding to each service, and proxy layers corresponding to each service. The proxy layer includes a caching plugin. Obtain the grayscale control information of the first target service; Generate a unique identifier for the call chain of the target service architecture; wherein, obtaining the grayscale control information of the first target service includes: intercepting the first grayscale control request based on the proxy layer of the first target service before the first grayscale control request is forwarded to the application corresponding to the first target service; generating a link tracing header value based on the unique identifier; determining a cache identifier based on the link tracing header value; and caching the grayscale control information of the first grayscale control request based on the cache identifier. Based on the unique identifier, the grayscale control information is transparently transmitted to the remaining services on the call chain to achieve grayscale control of all services in the target service architecture. This includes: when the first target service sends a new request to the second target service on the call chain, obtaining the link tracing header value and the grayscale control information based on the proxy layer of the second target service, wherein the second target service is one of the remaining services on the call chain; forming a second grayscale control request based on the link tracing header value, the grayscale control information, and the new request; and forwarding the second grayscale control request to the application corresponding to the second target service based on the proxy layer of the second target service to achieve grayscale control of the second target service.

2. The method of claim 1, wherein, The implementation of grayscale control of the first target service based on the target rule, the virtual service rule, and the proxy layer of the first target service includes: When the first target service needs to receive the first grayscale control request, the access version of the first grayscale control request is determined based on the target rules and the virtual service rules. Based on the proxy layer of the first target service, the first grayscale control request is forwarded to the application corresponding to the first target service of the corresponding access version, so as to realize the grayscale control of the first target service.

3. The method of claim 2, wherein, When the first grayscale control request matches the target rule, the access version includes the baseline version or the test version; when the first grayscale control request matches the virtual service rule, the access version includes the test version.

4. An all-link gray scale control device characterized by comprising: The device includes: The first control module is used to obtain the target rules and virtual service rules of the target service architecture, and to perform gray-scale control on the first target service based on the target rules, the virtual service rules and the proxy layer of the first target service. The target service architecture includes an entry gateway, applications corresponding to each service and proxy layers corresponding to each service; the proxy layer includes a caching plugin. The acquisition module is used to acquire the grayscale control information of the first target service; The second control module is used to generate a unique identifier for the call chain of the target service architecture, and based on the unique identifier, to pass the grayscale control information to the remaining services on the call chain, so as to realize grayscale control of all services in the target service architecture. The acquisition module is further configured to: intercept the first grayscale control request based on the proxy layer of the first target service before forwarding the first grayscale control request to the application corresponding to the first target service; generate a link tracing header value based on the unique identifier; determine a cache identifier based on the link tracing header value; and cache the grayscale control information of the first grayscale control request based on the cache identifier. The second control module is further configured to, when the first target service sends a new request to the second target service on the call chain, obtain the link tracing header value and the grayscale control information based on the proxy layer of the second target service, wherein the second target service is one of the remaining services on the call chain; form a second grayscale control request based on the link tracing header value, the grayscale control information and the new request; and forward the second grayscale control request to the application corresponding to the second target service based on the proxy layer of the second target service, so as to realize the grayscale control of the second target service.

5. The apparatus of claim 4, wherein, The first control module is further configured to determine the access version of the first grayscale control request based on the target rules and the virtual service rules when the first target service needs to receive the first grayscale control request. Based on the proxy layer of the first target service, the first grayscale control request is forwarded to the application corresponding to the first target service of the corresponding access version, so as to realize the grayscale control of the first target service.

6. The apparatus according to claim 5, characterized in that, When the first grayscale control request matches the target rule, the access version includes the baseline version or the test version; when the first grayscale control request matches the virtual service rule, the access version includes the test version.

7. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 3.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 3.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 3.

Images