Micro-service system, full-link gray release method and full-link gray implementation method

Abstract

The invention provides a micro-service system, a full-link gray release method and a full-link gray implementation method, and belongs to the field of cloud computing. The system comprises a micro-service management and control platform, a registration center and a target service node, the micro-service management and control platform is used for creating a target gray scale micro-service instance corresponding to a target micro-service on a target service node in response to a gray scale release instruction for the target micro-service, creating a target gray scale service agent for the target gray scale micro-service instance, and providing gray scale scheduling strategy information for the target gray scale service agent; the target gray scale micro-service instance is used for sending a gray scale registration request to the registration center through the target gray scale service agent after restarting; and the registration center is used for registering the target gray scale micro-service instance based on the gray scale scheduling strategy information and the service metadata in response to the gray scale registration request, and adding a gray scale label for the target gray scale micro-service instance so as to realize gray scale release of the target micro-service. According to the invention, full-link gray release can be realized.

Description

Technical Field

[0001] The present application relates to the field of cloud computing technology, and in particular to a microservice system, a full-link grayscale publishing method, and a full-link grayscale implementation method. Background Art

[0002] In a microservice system, the relationships between microservices are complex, and the implementation of a certain function often depends on multiple microservices, which requires the release of new versions of multiple microservices. In order to more comprehensively evaluate the compatibility and stability of the new version with the system, the new versions of these microservices can be released in full-link grayscale, that is, the new version of the microservice is first grayscale verified with a small amount of traffic, and when the new version of the microservice passes the verification, it is deployed on the entire system.

[0003] However, how to implement full-link grayscale release in a microservice system so that the new version can be used as a grayscale version and accept a smaller proportion of traffic has become an urgent problem that needs to be solved. Summary of the invention

[0004] The embodiments of the present application provide a microservice system, a full-link grayscale publishing method, and a full-link grayscale implementation method, which can provide a full-link grayscale publishing method. The technical solution is as follows: In a first aspect, a microservice system is provided, the system comprising: a microservice management and control platform, a registration center, and a target service node, wherein microservice instances of different versions capable of providing a target microservice run on the target service node; The microservice management and control platform is used to receive a grayscale release instruction for the target microservice, wherein the grayscale release instruction includes a grayscale version and grayscale scheduling policy information of the target microservice; in response to the grayscale release instruction, based on the grayscale version, create a target grayscale microservice instance corresponding to the target microservice on the target service node, create a target grayscale service proxy for the target grayscale microservice instance, and provide the grayscale scheduling policy information to the target grayscale service proxy; The target grayscale microservice instance is used to send a grayscale registration request to the registration center through the target grayscale service agent after restarting, wherein the grayscale registration request includes the grayscale scheduling policy information and the service metadata of the grayscale version; The registration center is used to respond to the grayscale registration request, register the target grayscale microservice instance based on the grayscale scheduling policy information and the service metadata, and add a grayscale label to the target grayscale microservice instance to achieve grayscale release of the target microservice.

[0005] In a second aspect, a full-link grayscale release method is provided, the method is applied to the microservice system described in the first aspect, and the method includes: The microservice management and control platform receives a grayscale release instruction for the target microservice, wherein the grayscale release instruction includes a grayscale version and grayscale scheduling policy information of the target microservice; in response to the grayscale release instruction, based on the grayscale version, creates a target grayscale microservice instance corresponding to the target microservice on the target service node, creates a target grayscale service proxy for the target grayscale microservice instance, and provides the grayscale scheduling policy information to the target grayscale service proxy; After restarting, the target grayscale microservice instance sends a grayscale registration request to the registration center through the target grayscale service agent, where the grayscale registration request includes the grayscale scheduling policy information and the service metadata of the grayscale version; The registration center responds to the grayscale registration request, registers the target grayscale microservice instance based on the grayscale scheduling policy information and the service metadata, and adds a grayscale label to the target grayscale microservice instance to achieve grayscale release of the target microservice.

[0006] In a third aspect, a full-link grayscale implementation method is provided, the method being applied to the microservice system described in the first aspect, the method comprising: The microservice gateway receives a first external access request, wherein the service path corresponding to the first external access request includes the target service node; obtains the grayscale scheduling policy information from the registration center, identifies the type of the first external access request based on the grayscale scheduling policy information, and when the type of the first external access request is identified as a grayscale request, adds a grayscale identifier to the first external access request to obtain a second external access request, and sends the second external access request to a first grayscale microservice instance on a first service node, wherein the first service node is the first service node included in the service path; The first grayscale microservice instance receives the second external access request through the first grayscale service agent, and provides a corresponding microservice in response to the second access request.

[0007] In a fourth aspect, a full-link grayscale implementation method is provided, the method being applied to the microservice system described in the first aspect, the method comprising: The microservice gateway receives a first external access request, wherein the service path corresponding to the first external access request includes the target service node; obtains the grayscale scheduling policy information from the registration center, identifies the type of the first external access request based on the grayscale scheduling policy information, and when the type of the first external access request is identified as a grayscale request, adds a grayscale identifier to the first external access request to obtain a second external access request, and sends the second external access request to a first grayscale microservice instance on a first service node, wherein the first service node is the first service node included in the service path; The first grayscale microservice instance receives the second external access request through the first grayscale service agent, adds a grayscale identifier to the second external access request, obtains a third external access request, and provides a corresponding microservice in response to the third external access request.

[0008] In a fifth aspect, a full-link grayscale implementation method is provided, the method being applied to the microservice system described in the first aspect, the method comprising: When the execution time of the scheduled grayscale task is reached, the distributed scheduling platform generates a scheduled access request; During the transmission of the timed access request, for any service node on the service path corresponding to the timed access request, the distributed scheduling platform receives a first heartbeat message sent by the microservice instance running on the service node through the corresponding service agent, where the first heartbeat message includes a label and grayscale scheduling strategy information of the corresponding microservice instance; When it is determined that there is a grayscale microservice instance on the service node based on the label of the microservice instance running on the service node, and the grayscale microservice instance on the service node meets the grayscale scheduling conditions indicated by the corresponding grayscale scheduling policy information, the distributed scheduling platform controls the previous node of the service node to send the timed access request to the grayscale microservice instance on the service node.

[0009] In the sixth aspect, a computer-readable storage medium is provided, in which at least one computer program is stored. When the at least one computer program is executed by a processor, it can implement the full-link grayscale publishing method described in the first aspect, or the full-link grayscale implementation method described in the second aspect, or the full-link grayscale implementation method described in the third aspect, or the full-link grayscale implementation method described in the fourth aspect.

[0010] In the seventh aspect, a computer program product is provided, which includes a computer program. When the computer program is executed by a processor, it can implement the full-link grayscale publishing method described in the first aspect, or the full-link grayscale implementation method described in the second aspect, or the full-link grayscale implementation method described in the third aspect, or the full-link grayscale implementation method described in the fourth aspect.

[0011] The beneficial effects of the technical solution provided by the embodiment of the present application are: The present application provides a microservice system, which includes a microservice management and control platform, a registration center, and a target service node, etc., on which a microservice instance capable of providing different versions of a target microservice runs. When a new version of a target microservice needs to be released, a user can send a grayscale release instruction for the target microservice to the microservice management and control platform, and the grayscale release instruction includes the grayscale version of the target microservice and grayscale scheduling strategy information, and the grayscale scheduling strategy information is used to indicate the grayscale scheduling conditions for the grayscale version of the target microservice. When the grayscale scheduling conditions are met, the grayscale version of the target microservice can be called. The microservice management and control platform receives the grayscale release instruction for the target microservice, and in response to the grayscale release instruction, creates a target grayscale microservice instance corresponding to the target microservice on the target service node based on the grayscale version of the target microservice, and then creates a target grayscale service proxy in the target grayscale microservice instance. The grayscale scheduling policy information is then provided to the target grayscale service proxy. The target grayscale service proxy sends the grayscale scheduling policy information and the grayscale version of the service metadata to the registration center, and then registers the target grayscale microservice instance in the registration center. After the registration is completed, a grayscale label is added to the target grayscale microservice instance, thereby realizing the full-link grayscale release of the new version of the target microservice. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0013] Figure 1 This is an architecture diagram of a microservice system provided in an embodiment of the present application; Figure 2 It is a flowchart of a full-link grayscale publishing method provided by an embodiment of the present application; Figure 3 It is a flowchart of another full-link grayscale publishing method provided by an embodiment of the present application; Figure 4It is a flow chart of a full-link grayscale implementation method provided by an embodiment of the present application; Figure 5 is a flowchart of another full-link grayscale implementation method provided by an embodiment of the present application; Figure 6 is a flowchart of another full-link grayscale implementation method provided by an embodiment of the present application; Figure 7 is a flowchart of another full-link grayscale implementation method provided by an embodiment of the present application; Figure 8 is a flowchart of another full-link grayscale implementation method provided by an embodiment of the present application; Fig. 9 A structural block diagram of an electronic device provided by an exemplary embodiment of the present application is shown. DETAILED DESCRIPTION

[0014] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0015] It can be understood that the terms "each", "multiple", and "any" used in the embodiments of the present application include two or more, each refers to each of the corresponding multiple, and any refers to any one of the corresponding multiple. For example, the multiple words include 10 words, and each word refers to each of the 10 words, and any word refers to any one of the 10 words.

[0016] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0017] Before executing the embodiments of the present application, the terms involved in the present application are first explained.

[0018] Microservices refer to small services that can be independently developed, deployed, and maintained. Each microservice can play two roles in a microservice system: a provider and a consumer. When a microservice acts as a provider, it can provide a service interface for other microservices to call the service interface to obtain the microservice; when a microservice acts as a consumer, it can use the service interface provided by other microservices to obtain other microservices.

[0019] The microservice system consists of multiple microservices. Different microservices collaborate with each other through network communication mechanisms to jointly complete service functions.

[0020] Sidecar is a design pattern commonly used in microservice architecture, which allows the core functions of an application to be separated from auxiliary functions (for example, logging, configuration management, network communication, etc.). In this design pattern, there is a "sidecar" container running auxiliary functions next to each microservice main container, just like a sidecar next to a motorcycle. The Sidecar container and the main container share the same life cycle and network space.

[0021] Grayscale release, also known as canary release, is a release method that can smoothly transition between black and white. A / B testing can be performed on it, that is, some users continue to use product feature A, while some users start using product feature B. If users have no objection to B, then gradually expand the scope and migrate all users to B. Grayscale release can ensure the stability of the overall system. Problems can be discovered and adjusted during the initial grayscale to ensure their impact.

[0022] Call chain: When an external request enters the microservice system, it will trigger a series of inter-service calls. This complete call chain is called a call chain.

[0023] The service path of a microservice usually refers to the call path between services in a microservice architecture. In a microservice architecture, the definition and management of service paths are implemented through a configuration center, of which Spring Cloud Config is a commonly used configuration center tool.

[0024] Full-link grayscale: If an access request is marked as a grayscale request, all calls in the call chain generated by the access request will be called to the grayscale version of the corresponding component (if a grayscale version exists).

[0025] Service metadata refers to the meta-information used to describe services, including the service name, version, description, interface definition, security policy, etc. Service metadata is key information for realizing automatic service discovery, service registration, and service invocation, which can help service consumers find and invoke service providers more easily.

[0026] Cloud computing refers to the delivery and use model of IT infrastructure, which means obtaining required resources through the network in an on-demand and easily scalable manner; in a broad sense, cloud computing refers to the delivery and use model of services, which means obtaining required services through the network in an on-demand and easily scalable manner. This service can be related to IT and software, the Internet, or other services. Cloud computing is the product of the development and integration of traditional computer and network technologies such as grid computing, distributed computing, parallel computing, utility computing, network storage technologies, virtualization, and load balancing.

[0027] With the development of the Internet, real-time data streams, and the diversification of connected devices, as well as the demand for search services, social networks, mobile commerce, and open collaboration, cloud computing has developed rapidly. Different from the previous parallel distributed computing, the emergence of cloud computing will promote revolutionary changes in the entire Internet model and enterprise management model from a conceptual perspective.

[0028] With the development of cloud computing technology, microservice systems have been widely used due to their loose coupling, flexibility and scalability. For security, compliance, performance and user needs, it is necessary to update the functions in the microservice system. However, the relationship between the microservices in the microservice system is complex, and the implementation of a certain function often depends on multiple microservices, which requires full-link grayscale release of new versions of multiple microservices. Full-link grayscale release not only considers the grayscale release at the application level, but also covers all components and services in the entire link of the microservice system. Through full-link grayscale release, it can be ensured that the new version is gradually verified and deployed in the entire link of the microservice system, so as to more comprehensively evaluate the compatibility and stability of the new version with the existing system. In order to better evaluate the compatibility and stability of the new version with the existing system, it is necessary to perform full-link grayscale calls in the microservice system, that is, for an access request, if a grayscale version of the microservice is running on any service node on the service path corresponding to the access request, the grayscale version needs to be called to ensure that all calls in the call chain generated by the same access request can be called on the grayscale version of the corresponding microservice, thereby achieving full-link grayscale.

[0029] For example, a microservice system includes multiple microservices such as microservice A, microservice B, and microservice C. Among them, microservice A and microservice C have grayscale versions A-gray and C-gray in addition to normal versions. For an external access request, its service path (i.e., access link) in the microservice system is microservice A->microservice B->microservice C. If the external access request is identified as a grayscale request, it is hoped that the external access request will generate a call link of microservice A-gray->microservice B->microservice C-gray, that is, during the call process, if the microservice to be called has a grayscale version, the grayscale version of the microservice is called, and if the microservice to be called does not have a grayscale version, the grayscale version of the microservice is called.

[0030] However, microservice systems are relatively complex, with multiple components such as gateways, service nodes, and middleware. These components will call each other to form a call chain. It is difficult to ensure that all calls in the call chain generated by the same access request can be called on the grayscale version of the corresponding microservice. To achieve full-link grayscale, the following two problems need to be solved: The first problem: The access request needs to carry a grayscale identifier so that the access request can be identified as a grayscale request during the subsequent transmission process. Even if the access request carries a grayscale identifier, it is necessary to ensure that the grayscale identifier is always carried in all subsequent calls triggered by the access request in the microservice system.

[0031] The second difficulty: Even if the grayscale identifier can be carried all the time, all components need to be able to recognize the grayscale identifier when making service calls, and then select and call the service based on the grayscale identifier.

[0032] To solve the above two problems and achieve full-link grayscale, it is necessary to modify and adapt the code of all components in the microservice system. However, for a complex microservice system that has already been launched, changing the code of all components is an operation with extremely high risks and costs.

[0033] To this end, this application provides a microservice system that adopts the form of a microservice management and control platform + service agent. There is no need to modify the code of each component in the system. The microservice management and control platform can manage each service node and middleware in the microservice system, so as to perform one-click full-link grayscale release. In addition, the microservice management and control platform will create a service agent for each microservice instance of a microservice, and the full-link grayscale can be achieved through the service agent.

[0034] Please refer to Figure 1, which shows a microservice system provided by an embodiment of the present application, the microservice system includes components such as a microservice management and control platform, a registration center, and a target service node. The target service node runs microservice instances of different versions that can provide target microservices, and the microservice instances of different versions include grayscale versions of microservice instances and normal versions of microservice instances. For the convenience of subsequent description, the present application refers to the grayscale version of the microservice instance running on the target service node as the target grayscale microservice instance, and the service provided by the target grayscale microservice instance as the target grayscale service; the normal version of the microservice instance running on the target service node is called the target normal microservice instance, and the service provided by the target normal microservice instance is called the target normal service.

[0035] Among them, the microservice management and control platform is used for users to manage each microservice and middleware in the microservice system. To facilitate user management, the microservice management and control platform can provide a management interface, which can display management controls for each microservice, including new version upload controls, grayscale scheduling policy setting controls and release controls. Based on the new version upload control, users can upload the grayscale version of the target microservice. Based on the grayscale scheduling policy setting control, users can set grayscale scheduling policy information, which is used to indicate the grayscale scheduling conditions that are met when scheduling the grayscale version of the target microservice. The scheduling policies indicated by the grayscale scheduling policy information include but are not limited to scheduling policies based on traffic or scheduling policies based on request characteristics.

[0036] Among them, the scheduling strategy according to traffic means that the user can input a preset ratio, and when receiving an access request for the target microservice, the access request for the target microservice is scheduled according to the preset ratio, and the preset ratio can be 10%, 15%, etc. Assuming that the preset ratio set by the user is 10%, after receiving the access request for the target microservice, the consumer of the target microservice will schedule 10% of the access requests for the target microservice to the target grayscale microservice instance according to the preset ratio set by the user, so as to provide the target microservice through the target grayscale microservice instance, and schedule 90% of the access requests for the target microservice to the target normal microservice instance, so as to provide the target microservice through the target normal microservice instance.

[0037] Among them, the scheduling strategy according to request characteristics means that the user can input a specific request header, which can be a request header including a specific field. After receiving an access request for a target microservice, it is identified whether the request header of the access request includes the specific field. If the request header of the access request includes the specific field, the access request is scheduled to the target grayscale microservice instance to provide the target microservice through the target grayscale microservice instance; if the request header of the access request does not include the specific field, the access request is scheduled to the target normal microservice instance to provide the target microservice through the target normal microservice instance.

[0038] One thing that needs to be explained here is that the above takes the release of the grayscale version of the target microservice as an example. If there are multiple microservices in the microservice system that need to release grayscale versions at the same time, the user can set the same grayscale scheduling policy information for multiple microservices, or set different grayscale scheduling policy information for multiple microservices. The specific decision can be made by the user.

[0039] After the user uploads the grayscale version of the target microservice through the new version of the upload control, and sets the grayscale scheduling policy information of the target microservice through the grayscale scheduling policy setting control, the release control can be touched. In response to the user's touch operation on the release control, the microservice management platform can generate and receive a grayscale release instruction for the target microservice, which includes the grayscale version of the target microservice and the grayscale scheduling policy information. In response to the grayscale release instruction, the microservice management platform can perform the creation operation of the target grayscale service on the target service node. Specifically, the microservice management platform can create a target grayscale microservice instance corresponding to the target microservice on the target service node based on the grayscale version of the target microservice (since the microservice can be regarded as an application, the creation process of the grayscale microservice instance corresponding to the grayscale version of the microservice can be understood as the installation process of the application). After the target grayscale microservice instance is successfully created on the target service node, a target grayscale service proxy can be created for the target grayscale microservice instance (since the service proxy is a piece of code, the creation process of the service proxy can be understood as the process of injecting the code corresponding to the service proxy into the code corresponding to the microservice instance). In this application, the service agents created by the microservice management and control platform on different service nodes and different types of microservice instances have the same functions, and can monitor the status of the service itself, and can also interact with components such as the microservice management and control platform and the registration center. There are many ways to implement the service agent created by the microservice management and control platform. If the microservice instance is a Java microservice instance, the service agent created can be a Java agent, which is bound to the service process of the microservice and executed simultaneously with the service process of the microservice; if the microservice instance is a non-Java microservice instance, the service agent created can be a Sidecar agent, and the process of the Sidecar agent is a separate process, sharing computing resources, storage resources and other resources with the process of the microservice. In order to facilitate the distinction between the service agents corresponding to different versions of microservices on the same service node, the service agent corresponding to the normal version can be called a normal service agent, and the service agent corresponding to the gray version can be called a gray service agent. In this way, the service agent corresponding to the target normal microservice instance on the target service node is called a target normal service agent, and the service agent corresponding to the target gray microservice instance is called a target gray service agent. For the target grayscale microservice instance, when the target grayscale microservice instance is a Java microservice instance, the created grayscale service proxy is a Java proxy; when the target grayscale microservice instance is a non-Java microservice instance, the created grayscale service proxy is a Sidecar proxy.

[0040] Furthermore, after successfully creating a target grayscale service agent for the target grayscale microservice instance, the microservice management and control platform also provides the grayscale scheduling policy information to the target grayscale service agent, so that the target grayscale service agent adds the grayscale scheduling policy information to the grayscale version of the service metadata, thereby registering the target grayscale microservice instance in the registration center.

[0041] Among them, the target grayscale microservice instance is a grayscale microservice instance created by the microservice management and control platform on the target service node to provide the target microservice. After the target grayscale microservice instance is successfully created, it will also restart to activate the target grayscale service. After the target grayscale microservice instance restarts, it can send a grayscale registration request to the registration center through the target grayscale service agent. The grayscale registration request includes grayscale scheduling policy information and grayscale version of service metadata, etc. The service metadata may include the name, version, description, interface definition, security policy, etc. of the service. For different implementation methods of the service agent, the target grayscale microservice instance sends a grayscale registration request to the registration center through the target grayscale service agent, including but not limited to the following two methods: The first method: the target grayscale microservice instance is a Java microservice instance, and the target grayscale service agent is a Java agent For the first method, after restarting, the Java microservice instance can load the grayscale scheduling policy information code into the service metadata code through the Java agent to obtain the changed service metadata, and then send a grayscale registration request including the changed service metadata to the registration center. This method changes the code logic of the internal registration of the service, and by adding the grayscale scheduling policy information code to the service metadata code, the grayscale scheduling policy information is sent to the registration center for registration.

[0042] The second method: the target grayscale microservice instance is a non-Java microservice instance, and the target grayscale service proxy is a Sidercar proxy For the second method, after the non-Java microservice instance is restarted, the Sidercar proxy intercepts the grayscale registration request including the service metadata sent to the registration center, adds the grayscale scheduling policy information to the grayscale registration request, and sends the grayscale registration request including the grayscale scheduling policy information and service metadata to the registration center. This method does not change the code logic of the internal registration of the service. By intercepting the grayscale registration request, adding the grayscale scheduling policy information to the grayscale registration request, and then sending the grayscale registration request with the grayscale scheduling policy information added to the registration center, the purpose of sending the grayscale scheduling policy information to the registration center is achieved.

[0043] Among them, the registration center is one of the most basic and important components in the microservice system. It is equivalent to an address book between microservices, recording the addresses of all microservices, providing service discovery and registration, and enabling mutual calls between microservices. In this application, the registration center receives a registration request sent by a target grayscale microservice instance through a target grayscale service agent. In response to the grayscale registration request, the target grayscale microservice instance can be registered based on the grayscale scheduling policy information and service metadata. After the registration is completed, a grayscale label is added to the target grayscale microservice instance, thereby realizing the grayscale release of the target microservice.

[0044] Further, after the target grayscale microservice instance is registered, the consumer of the target microservice can obtain grayscale information such as grayscale scheduling strategy information and grayscale label of the target grayscale microservice instance on the target service node from the registration center before calling the target microservice based on the access request. The consumer saves the grayscale information of the target grayscale microservice instance, so that it can judge whether the target microservice is called normally or grayscale based on the grayscale information. Among them, there are many ways for the consumer of the target microservice to obtain the target grayscale microservice instance on the target service node from the registration center. The registration center can actively push the grayscale information to the consumer of the target microservice, or the consumer of the target microservice can actively pull the grayscale information from the registration center. After the consumer of the target microservice obtains the grayscale information of the target microservice from the registration center, the service agent corresponding to the consumer of the target microservice saves the grayscale information, and then judges whether the current call to the target microservice is a normal call or a grayscale call based on the grayscale scheduling strategy information included in the grayscale information. If it is a normal call, the access request is sent to the target normal microservice instance, and if it is a grayscale call, the access request is sent to the target grayscale microservice instance.

[0045] The above description takes the full-link grayscale release of the target microservice as an example. The full-link grayscale release process for other microservices is the same as the grayscale release process for the target microservice. For details, please refer to the grayscale release process for the target microservice above, which will not be repeated here.

[0046] Taking the microservice on any service node as an example, after the registration of the grayscale microservice instance of the microservice is completed through the above process, the consumer who requests to call the microservice can obtain the grayscale information of the microservice to be called from the registration center through the corresponding service agent before calling the microservice, and then judge whether the call is a normal call or a grayscale call according to the grayscale scheduling policy information in the grayscale information. When judging whether the call is a normal call or a grayscale call, the service agent can make a judgment according to the grayscale calling strategy indicated by the grayscale scheduling policy information. If the grayscale calling strategy is a scheduling strategy according to the traffic, the service agent sends the preset proportion of access requests to the grayscale microservice instance of the microservice to be called according to the preset proportion set by the user, and sends the rest of the access requests to the normal microservice instance of the microservice to be called; if the grayscale calling strategy is a scheduling strategy according to the request feature, when the service agent receives the access request, it identifies whether the request header of the access request includes the specified feature. If it includes the user-specified feature, the access request is sent to the grayscale microservice instance of the microservice to be called; if it does not include the user-specified feature, the access request is sent to the normal microservice instance of the microservice to be called.

[0047] Furthermore, after identifying that the microservice currently to be called is a grayscale service, that is, the access request is a grayscale request, the service agent also adds a grayscale identifier to the access request, and then calls the grayscale service, thereby ensuring that the access request is always identified as a grayscale request to achieve full-link grayscale.

[0048] In a microservice system, each microservice not only has a version update requirement, but also has a configuration information update requirement, which includes port numbers, database connection information, etc. As the number of microservices increases, it becomes more difficult to manage these configuration information. In order to simplify the difficulty of managing configuration information in a microservice system, the microservice system provided in an embodiment of the present application also includes a configuration center. The configuration center can be a centralized management platform that can separate the configuration information of microservices from the application of microservices, thereby reducing operation and maintenance costs and improving the scalability and flexibility of the system.

[0049] The functions of the configuration center include but are not limited to the following: Centralized management: The configuration information of each microservice can be stored centrally for unified management and maintenance.

[0050] Dynamic update: When configuration information needs to be updated, there is no need to restart the service. You only need to make changes in the configuration center to take effect in real time, which greatly improves the availability and flexibility of the system.

[0051] Permission management: The configuration center provides a permission configuration function that can limit different users' access and modification permissions to configuration information to ensure the security of configuration information.

[0052] Version management: Supports configuration version control, making it easy to roll back to an old version or perform multi-version testing.

[0053] Monitoring and warning: The configuration usage can be monitored in real time and warnings will be issued when the configuration is abnormal.

[0054] In the embodiment of the present application, when the user wants to change the target configuration of the target microservice in the microservice system, the target configuration of the target microservice can be changed in the configuration center. Generally speaking, the new configuration information will overwrite the old configuration information. If the new configuration information is pushed in full, once the configuration information is wrong, it may cause the system to fail to operate normally, which is a high risk. Therefore, the new configuration information can be grayed out. After there is no abnormality in the new configuration information, the new configuration information will be gradually updated until it is fully released. If an abnormality is found during the gray release process, the gray release can be stopped to achieve configuration rollback.

[0055] In order to facilitate users to manage the configuration information of the microservice system, the configuration center can provide a configuration interface, which includes multiple controls. Based on these controls, users can set new configuration information for the target configuration and set a grayscale distribution strategy. The grayscale distribution strategy can be to give priority to updating the new configuration information to the microservice instance with grayscale labels. Then the user triggers the configuration center to generate a configuration update instruction, which includes the new configuration information of the target configuration and the configuration grayscale distribution strategy. The configuration center receives the configuration update instruction for the target configuration of the target microservice. In response to the configuration update instruction, the configuration center obtains the labels of each microservice instance corresponding to the target microservice, and then based on the configuration grayscale distribution strategy, updates the configuration information of the target configuration in the microservice instance corresponding to the grayscale label to the new configuration information. The present application performs grayscale updates on the configuration information by the configuration center, which simplifies the difficulty of managing the configuration information in the microservice system and reduces the update risk.

[0056] Generally speaking, there are two types of access requests for microservices in a microservice system: one is an external access request, and the other is a scheduled access request triggered by a scheduled task. This application configures different components for the two types of access requests to identify and process the access requests at the traffic entrance.

[0057] In order to identify and process external access requests, the microservice system also includes a microservice gateway. As a traffic entrance, the microservice gateway has the ability to identify the type of external access requests and forward them upstream. Therefore, grayscale requests (i.e., grayscale traffic) can be generated at the microservice gateway as needed.

[0058] In one possible implementation, a front-end user (such as a browser, mobile client, or other front-end) sends an external access request with a specific request header. The microservice gateway can obtain the grayscale scheduling policy information from the registration center, identify the specific request header based on the grayscale scheduling policy information, determine that the external access request is a grayscale request, and then add a grayscale identifier to the external access request, and then send the external access request with the grayscale identifier to the grayscale microservice instance of the microservice to be called.

[0059] In another possible implementation, in some cases, it is inconvenient for the front-end user to produce grayscale requests. After receiving the external access request, the microservice gateway can obtain the grayscale scheduling policy information from the registration center, and based on the grayscale scheduling policy information, determine the received preset proportion of external access requests as grayscale requests, and then add the grayscale identifier to the external access request, and then send the external access request with the grayscale identifier to the grayscale microservice instance of the microservice to be called. For example, if the preset ratio is 10%, the microservice gateway can determine 10% of the received external access requests as grayscale requests, and then add the grayscale identifier to the grayscale request, and then send the external access request with the grayscale identifier to the grayscale microservice instance.

[0060] In the present application, since the microservice gateway has added a grayscale identifier to the external access request after receiving the external access request and identifying the external access request as a grayscale request, during the subsequent transmission of the external access request, each component located on the service path of the external access request can directly call the corresponding grayscale service after receiving the external access request and identifying the grayscale identifier, or can add a grayscale identifier to the external access request and then call the corresponding grayscale service. The embodiments of the present application do not make specific limitations on this.

[0061] Taking the first external access request as an example, the service path corresponding to the first external access request includes the target service node. After receiving the first external access request, the microservice gateway obtains the grayscale scheduling policy information of the target microservice from the registration center, and identifies the type of the first external access request based on the grayscale scheduling policy information. When the type of the first external access request is identified as a grayscale request, a grayscale identifier is added to the first external access request to obtain a second external access request, and then the second external access request is sent to the corresponding microservice instance on the first service node. Among them, the first service node is the first service node included in the service path, and the grayscale version of the first grayscale microservice instance and the normal version of the first normal microservice instance are running on the first service node. The service agent corresponding to the first grayscale microservice instance is the first grayscale service agent, and the service agent corresponding to the first normal microservice instance is the first normal service agent.

[0062] In a possible implementation, when it is determined that there is a grayscale microservice instance on the first service node, the microservice gateway can send a second external access request to the first grayscale microservice instance on the first service node, and the first grayscale microservice instance receives the second external access request sent by the microservice gateway through the first grayscale service agent. In response to the second access request, the first grayscale microservice instance provides the corresponding microservice. After providing the corresponding microservice, the first grayscale microservice instance sends the second access request to the next node on the service path.

[0063] In another possible implementation, when it is determined that there is a grayscale microservice instance on the first service node, the microservice gateway can send a second external access request to the first grayscale microservice instance on the first service node. The first grayscale microservice instance receives the second external access request sent by the microservice gateway through the first grayscale service agent, and then adds a grayscale identifier to the second external access request to obtain a third external access request. In response to the third external access request, the first grayscale microservice instance provides the corresponding microservice. After providing the corresponding microservice, the first grayscale microservice instance sends the third access request to the next node on the service path.

[0064] In an embodiment of the present application, the target service node may be any service node on the service path. When the target service node is the first service node on the service path, the target service node receives external access requests, provides target microservices, and forwards external access requests. Please refer to the relevant description of the first service node mentioned above; when the target service node is a service node other than the first service node on the service path, the target service node receives external access requests, provides target microservices, and forwards external access requests. Please refer to the following content. Taking the next node of the target service node as the second service node as an example, the second service node runs a grayscale version of the second grayscale microservice instance and a normal version of the second normal microservice instance. The service agent corresponding to the second grayscale microservice instance is the second grayscale service agent, and the service agent corresponding to the second normal microservice instance is the second normal service agent. As a consumer of the microservice provided by the second service node, the target service node receives external access requests, provides target microservices, and forwards external access requests in the following two ways: In the first mode, the target grayscale microservice instance receives a fourth external access request through the target grayscale service agent, and the fourth access request is obtained by adding at least one grayscale identifier in the first access request. In response to the fourth external access request, the target grayscale microservice instance provides the target microservice. After the target microservice is provided, the target grayscale microservice instance obtains the registration information (including labels and grayscale scheduling policy information) of each microservice instance running on the second service node from the registration center, and determines whether there is a second grayscale microservice instance on the second service node based on the registration information of each microservice instance. When it is determined that the second grayscale microservice instance exists on the second service node, the fourth external access request is sent to the second grayscale microservice instance; when it is determined that the second grayscale microservice instance does not exist on the second service node, the fourth external access request is sent to the second normal microservice instance.

[0065] In the second method, the target grayscale microservice instance receives the fourth external access request through the target grayscale service agent, and then adds the grayscale identifier to the fourth external access request to obtain the fifth external access request. In response to the fifth external access request, the target grayscale microservice instance provides the target microservice. After the target microservice is provided, the target grayscale microservice instance obtains the registration information (including labels and grayscale scheduling policy information) of each microservice instance running on the second service node from the registration center, and determines whether there is a second grayscale microservice instance on the second service node based on the registration information of each microservice instance. When it is determined that the second grayscale microservice instance exists on the second service node, the fifth external access request is sent to the second grayscale microservice instance; when it is determined that the second grayscale microservice instance does not exist on the second service node, the fifth external access request is sent to the second normal microservice instance.

[0066] In order to realize the identification and processing of the timed access request triggered by the timed task, the microservice system also includes a distributed scheduling platform. The distributed scheduling platform can generate a timed access request when the execution time of the timed grayscale task is reached. In the process of transmitting the timed access request, for any service node on the service path corresponding to the timed access request, the distributed scheduling platform receives the first heartbeat message sent by each microservice instance running on the service node through the corresponding service agent, and the first heartbeat message includes the registration information of the corresponding microservice instance (including the label and the grayscale scheduling policy information). The distributed scheduling platform determines whether there is a grayscale microservice instance on the service node based on the label of the microservice instance running on the service node. When it is determined that there is a grayscale microservice instance on the service node based on the label of the microservice instance running on the service node, it is determined whether the grayscale microservice instance meets the grayscale scheduling condition indicated by the grayscale scheduling policy information based on the grayscale scheduling policy information. When it is determined that the grayscale microservice instance on the service node meets the grayscale scheduling condition, the previous node of the service node is controlled to send the timed access request to the grayscale microservice instance on the service node.

[0067] Usually, a microservice system will include some middleware, such as message middleware, cache middleware, etc. As an indispensable component in a microservice system, middleware can provide some general, service-independent capabilities. For example, message middleware can provide asynchronous, decoupled, and peak-shaving capabilities; cache middleware can provide distributed locks, configuration storage and acquisition capabilities, etc. In the access request call process of a microservice system, if the access request passes through the middleware, not only does it need to add the grayscale identifier to the access request, but the middleware also needs to identify the grayscale identifier. This application divides the middleware into two types, namely, the first type of middleware and the second type of middleware, according to whether the grayscale identifier can be identified. Among them, the first type of middleware is also called self-routing middleware, which refers to middleware that can identify grayscale identifiers, such as message middleware. The second type of middleware is also called non-self-routing middleware, which refers to middleware that cannot identify grayscale identifiers, such as cache middleware. For different types of middleware, this application provides different processing methods, specifically including the following two situations: Case 1, Type 1 Middleware For the first type of middleware, the microservice instance of the previous service node can send an access request to the first type of middleware. The access request can be an external access request or a scheduled access request. The service agent corresponding to the microservice instance intercepts the access request and identifies the access request. If the access request is identified as a grayscale request, a grayscale mark is added to the access request, and then the access request with the grayscale mark is sent to the first type of middleware. Since the first type of middleware has the ability to identify the grayscale mark, after receiving the access request, the first type of middleware will identify whether the access request carries the grayscale mark. If it is identified that the access request carries the grayscale mark and there is a grayscale microservice instance on the next service node, the access request is sent to the grayscale microservice instance on the next service node; if it is identified that the access request carries the grayscale mark and there is no grayscale microservice instance on the next service node, the access request is sent to the normal microservice instance on the next service node. Of course, if the service agent corresponding to the microservice instance of the previous service node recognizes that the intercepted access request is a normal request, it will not add a grayscale identifier to the access request, but directly send the access request to the first type of middleware. The first type of middleware receives the access request and recognizes that the access request does not carry a grayscale identifier, then sends the access request to the normal microservice instance on the next service node.

[0068] Case 2, Type 2 Middleware The microservice instance of the previous service node can send an access request to the second type of middleware. The access request can be an external access request or a scheduled access request. The service agent corresponding to the microservice instance intercepts the access request and identifies the access request. If the access request is identified as a grayscale request, a grayscale mark is added to the access request, and then the access request with the grayscale mark is sent to the second type of middleware. Since the second type of middleware does not have the ability to identify the grayscale mark, the second type of middleware cannot identify whether the access request carries the grayscale mark after receiving the access request, so it cannot support the full-link grayscale on the second type of middleware itself. At this time, the service agent on the consumer side interacts with the second type of middleware to identify whether it is in a normal environment or a grayscale environment, and then the service agent matching the environment actively obtains the access request from the second type of middleware, that is, for the second type of middleware, the access request is actively pulled by the service agent on the consumer side, rather than actively sent by the second type of middleware. The interaction process between the service agent on the consumer side and the second type of middleware may include: the microservice instance of the previous service node sends a notification message to the designated microservice instance running on the next service node of the second type of middleware, and the notification message carries environmental data, such as a grayscale identifier. The designated microservice instance can be a microservice instance of the same type as the access request running on the next service node. For example, if the access request is a grayscale request, the designated microservice instance can be a grayscale microservice instance. Of course, if the access request is a grayscale request, but the grayscale microservice instance is not running on the next service node, the designated microservice instance is a normal microservice instance. The designated microservice instance identifies the environment in which it is located, and then sends a data acquisition request to the second type of middleware. When the data acquisition request is received, the second type of middleware sends the access request to the designated microservice instance. Of course, if the service agent corresponding to the microservice instance of the previous service node identifies that the intercepted access request is a normal request, the grayscale identifier will not be added to the access request, but the access request will be directly sent to the second type of middleware. Accordingly, the environment data carried in the notification message sent by the microservice instance of the previous service node to the normal microservice instance on the next service node is a normal identifier, not a grayscale identifier.

[0069] The microservice system of the present application proposes the same control scheme for the traffic accessing different types of middleware, and proposes different solutions for middleware that supports self-routing and middleware that does not support self-routing, thereby being able to adapt to the access of various types of middleware in the microservice system.

[0070] In this application, after the grayscale version of the target microservice has been running for a period of time, if the user feedback is good, the user can send a full release instruction for the grayscale version of the target microservice to the microservice management and control platform. In response to the full release instruction for the grayscale version of the target microservice, the microservice management and control platform sends a type change instruction to the target grayscale microservice instance. The target grayscale microservice instance receives the type change instruction through the target grayscale service agent, and then sends a second heartbeat message to the registration center. When the second heartbeat message is received, the registration center changes the grayscale label of the target grayscale microservice instance to a normal label, thereby realizing dynamic adjustment of the environment in which the created service instance is located. Since there is no need to restart, the modification method is more flexible.

[0071] The microservice management and control platform of this application will configure a service agent for each microservice. Through the form of microservice management and control platform + service agent, users can manage each microservice and middleware in the microservice system on the microservice management and control platform without modifying the code, thereby realizing one-click grayscale release. After the grayscale release, the full-link grayscale can be realized through the service agent, thus solving the problem that it is difficult to realize the full-link grayscale in the microservice system.

[0072] In addition, the microservice management and control platform of the present application can dynamically adjust the grayscale environment where the created microservice instance is located without restarting the microservice itself.

[0073] In addition, this application controls the traffic of microservice applications accessing middleware, and proposes corresponding solutions for middleware that supports self-routing and middleware that does not support self-routing, which can adapt to the access of various types of middleware in microservice systems.

[0074] All the above optional technical solutions can be arbitrarily combined to form optional embodiments of the present application, which will not be described one by one here.

[0075] The present application embodiment provides a full-link grayscale publishing method, which is applied to Figure 1 The microservice system shown in Figure 2 , the method flow provided in the embodiment of the present application includes: 201. The microservice management and control platform receives a grayscale release instruction for a target microservice.

[0076] Among them, the grayscale release instructions include the grayscale version of the target microservice and the grayscale scheduling strategy information.

[0077] 202. In response to the grayscale release instruction, the microservice management and control platform creates a target grayscale microservice instance corresponding to the target microservice on the target service node based on the grayscale version, creates a target grayscale service agent for the target grayscale microservice instance, and provides the grayscale scheduling policy information to the target grayscale service agent.

[0078] There are many ways to implement the target grayscale microservice instance. When the target microservice is a Java application, the target grayscale microservice instance is a Java microservice instance, and accordingly, the grayscale service agent is a Java agent; when the target microservice is a non-Java application, the target grayscale microservice instance is a non-Java microservice instance, and accordingly, the service agent is a Sidercar agent.

[0079] 203. After restarting, the target grayscale microservice instance sends a grayscale registration request to the registration center through the target grayscale service agent.

[0080] The grayscale registration request includes grayscale scheduling policy information and grayscale version service metadata. For different implementation methods of the target grayscale microservice instance, the microservice management and control platform provides the grayscale scheduling policy information to the target grayscale service agent, including but not limited to the following two situations: In the first case, the target grayscale microservice instance is a Java microservice instance, and the grayscale service agent is a Java agent For the first case, after the Java microservice instance is restarted, the code of the grayscale scheduling policy information is loaded into the code of the service metadata through the Java agent, the changed service metadata is obtained, and then a grayscale registration request including the changed service metadata is sent to the registration center.

[0081] In the second case, the target grayscale microservice instance is a non-Java microservice instance, and the service proxy is a Sidercar proxy For the second case, after the non-Java microservice instance is restarted, it intercepts the grayscale registration request including service metadata sent to the registration center through the Sidercar agent, then adds the grayscale scheduling policy information to the grayscale registration request, and sends the grayscale registration request including the grayscale scheduling policy information and service metadata to the registration center.

[0082] 204. The registration center responds to the grayscale registration request, registers the target grayscale microservice instance based on the grayscale scheduling policy information and service metadata, and adds a grayscale label to the target grayscale microservice instance to achieve grayscale release of the target microservice.

[0083] So far, the grayscale release of the target microservice has been completed through the above steps 201 to 204.

[0084] In a microservice system, each microservice not only has version update requirements, but also configuration information update requirements, which include port numbers, database connection information, etc. The target configuration update process of a target microservice includes: the configuration center receives a configuration update instruction for the target configuration of the target microservice, the configuration update instruction includes new configuration information of the target configuration and a configuration grayscale delivery strategy, and in response to the configuration update instruction, the configuration center obtains the labels of each microservice instance corresponding to the target microservice, and then updates the configuration information of the target configuration in the microservice instance corresponding to the grayscale label to the new configuration information based on the configuration grayscale delivery strategy.

[0085] Figure 3 The full-link grayscale release process is shown in Figure 3 , the process includes the following steps: 1. Execute grayscale release instructions.

[0086] Users can execute grayscale release commands on the microservice management and control platform. At the same time, users need to upload grayscale service products (i.e. grayscale versions) and the way grayscale services are called (i.e. grayscale scheduling policy information). There are usually two ways to call grayscale services: The first is to call by traffic. The user can enter a ratio, such as 10%. After the consumer gets the grayscale information, the call will be made according to the ratio specified by the user.

[0087] The first is calling by request features. For example, a user can enter a specific request header. When the access request received by the consumer contains this header, the consumer will consider the access request to be a grayscale request, and then call the grayscale service.

[0088] 2. Create a grayscale service and inject a service proxy After receiving the grayscale release instruction sent by the user, the microservice control platform will execute the operation of creating a grayscale service in the application cluster, and inject a service agent into the grayscale service. The service agent can monitor the status of the service itself and interact with components such as the microservice control platform and the service registration center. Then, the microservice control platform will also inject grayscale information such as the grayscale service call method set by the user into the service agent, so that the service agent can add the grayscale information to the service metadata in the subsequent steps.

[0089] 3. The service agent of Grayscale service registers in the registration center After the grayscale service is started, the service agent of the grayscale service will inject the grayscale information into the service metadata, and then send a registration request to register.

[0090] 4. Consumers obtain grayscale services Consumers will obtain grayscale services and the grayscale information they carry from the registration center. The way consumers obtain grayscale services and the grayscale information they carry from the registration center varies depending on the specific implementation of the registration center. The registration center can actively push information to consumers, or consumers can pull service information from the registration center in a pull manner.

[0091] 5. Normal call and grayscale call When a consumer obtains a grayscale service, the service agent corresponding to the consumer will save the grayscale information and identify the grayscale information carried in the grayscale service. When the consumer needs to call the above service, the service agent corresponding to the consumer will decide whether to make a normal call or a grayscale call based on the grayscale information.

[0092] The present invention provides a method for implementing a full-link grayscale. Figure 1 The microservice system shown in Figure 4 , the method flow provided in the embodiment of the present application includes: 401. The microservice gateway receives a first external access request.

[0093] The service path corresponding to the first external access request includes a target service node.

[0094] 402. The microservice gateway obtains grayscale scheduling policy information from the registration center, and identifies the type of the first external access request based on the grayscale scheduling policy information.

[0095] 403. When it is identified that the type of the first external access request is a grayscale request, the microservice gateway adds a grayscale identifier to the first external access request, obtains a second external access request, and sends the second external access request to the first grayscale microservice instance on the first service node.

[0096] The first service node is the first service node included in the service path.

[0097] 404. The first grayscale microservice instance receives a second external access request through the first grayscale service agent, and provides a corresponding microservice in response to the second access request.

[0098] After the microservice gateway obtains the second access request by adding the grayscale identifier to the first access request, the service agent on each service node included in the service path will not add the grayscale identifier to the second access request, and the second access request will be transmitted at different nodes of the service path, thereby providing the corresponding microservice. Assuming that the target service node is a service node other than the first service node on the service path, and the next node of the target service node is the second service node, the transmission process of the second external access request between the target service node and the second service node is: the target grayscale microservice instance receives the fourth external access request through the target grayscale service agent, and the fourth access request is obtained by adding at least one grayscale identifier to the first access request. Since this embodiment only adds the grayscale identifier to the first access request on the microservice gateway side, the fourth access request is actually the second access request. The target grayscale microservice instance responds to the fourth external access request to provide the target microservice, and after the target microservice is provided, obtains the registration information of each microservice instance running on the second service node from the registration center to determine whether there is a second grayscale microservice instance on the second service node. When it is determined that there is a second grayscale microservice instance, the fourth external access request is sent to the second grayscale microservice instance.

[0099] Assuming that the target service node is a service node other than the first service node on the service path, and the next node of the target service node is the first type of middleware, the transmission process of the second external access request between the target service node and the second service node is: the target grayscale microservice instance sends the second access request to the first type of middleware. After receiving the second access request, the first type of middleware identifies whether the second access request carries a grayscale identifier. When it is identified that the second access request carries a grayscale identifier and a grayscale microservice instance is running on the next service node, the second access request is sent to the grayscale microservice instance on the next service node.

[0100] Assuming that the target service node is a service node other than the first service node on the service path, and the next node of the target service node is the second type of middleware, the transmission process of the second external access request between the target service node and the second service node is: the target grayscale microservice instance sends the second access request to the second type of middleware, and sends a notification message carrying environmental data to each microservice instance running on the next service node. The environmental data of each microservice instance running on the next service node determines its own environment. When it is identified as a grayscale environment, the grayscale microservice instance on the next service node sends a data acquisition request to the second type of middleware. In response to the data acquisition request, the second type of middleware sends the second access request to the grayscale microservice instance on the next service node.

[0101] The present invention provides a method for implementing a full-link grayscale. Figure 1 The microservice system shown in Figure 5 , the method flow provided in the embodiment of the present application includes: 501. The microservice gateway receives a first external access request.

[0102] The service path corresponding to the first external access request includes a target service node.

[0103] 502. The microservice gateway obtains grayscale scheduling policy information from the registration center, and identifies the type of the first external access request based on the grayscale scheduling policy information.

[0104] 503. When it is identified that the type of the first external access request is a grayscale request, the microservice gateway adds a grayscale identifier to the first external access request, obtains a second external access request, and sends the second external access request to the first grayscale microservice instance on the first service node.

[0105] The first service node is the first service node included in the service path.

[0106] 504. The first grayscale microservice instance receives the second external access request through the first grayscale service agent, adds the grayscale identifier to the second external access request, obtains a third external access request, and provides a corresponding microservice in response to the third external access request.

[0107] After the microservice gateway adds the grayscale identifier to the first access request to obtain the second external access request, the service agent on each service node included in the service path will also add the grayscale identifier to the received external access request, and then provide the corresponding microservice. Assuming that the target service node is a service node other than the first service node on the service path, and the next node of the target service node is the second service node, the transmission process of the external access request between the target service node and the second service node is: the target grayscale microservice instance receives the fourth external access request through the target grayscale service agent, and the fourth access request is obtained by adding the grayscale identifier at least once in the first access request, and then the target grayscale microservice instance adds the grayscale identifier to the fourth external access request to obtain the fifth external access request. The target grayscale microservice instance provides the target microservice in response to the fifth external access request, and after the target microservice is provided, obtains the labels of each microservice instance running on the second service node from the registration center to determine whether there is a second grayscale microservice instance on the second service node. When it is determined that the second grayscale microservice instance exists, the fifth external access request is sent to the second grayscale microservice instance.

[0108] Assuming that the target service node is a service node other than the first service node on the service path, and the next node of the target service node is the first type of middleware, the transmission process of the external access request between the target service node and the second service node is as follows: the target grayscale microservice instance receives the fourth external access request through the target grayscale service agent, and then adds the grayscale identifier to the fourth external access request to obtain the fifth external access request. The target grayscale microservice instance sends the fifth external access request to the first type of middleware, and the first type of middleware recognizes the grayscale identifier and sends the fifth external access request to the grayscale microservice instance on the next service node.

[0109] Assuming that the target service node is a service node other than the first service node on the service path, and the next node of the target service node is the second type of middleware, the transmission process of the external access request between the target service node and the second service node is: the target grayscale microservice instance receives the fourth external access request through the target grayscale service agent, and then adds the grayscale identifier to the fourth external access request to obtain the fifth external access request. The target grayscale microservice instance sends the fifth access request to the second type of middleware, and sends a notification message carrying environmental data to the microservice instance running on the next service node. The microservice instance running on the next service node determines its own environment based on the environmental data. When it is identified as a grayscale environment, the grayscale microservice instance on the next service node sends a data acquisition request to the second type of middleware. In response to the data acquisition request, the second type of middleware sends the fifth external access request to the grayscale microservice instance on the next service node.

[0110] Figure 6 The full-link grayscale release process is shown in Figure 6 , Assume that the service path corresponding to the external access request is: Service A-Service B-Service C-Middleware-Service D, where Service A includes normal service A and grayscale service A, Service C includes normal service C and grayscale service C, and Service D includes normal service D and grayscale service D. When the external access request enters the microservice system, the microservice gateway, as the traffic entrance of the microservice system, will identify whether the external access request is a grayscale request. If it is identified as a normal request, the microservice gateway calls normal service A, normal service A calls normal service B, normal service B calls normal service C, normal service C calls middleware, and middleware calls normal service D; if it is identified as a grayscale request, the microservice gateway calls grayscale service A, grayscale service A calls normal service B, normal service B calls grayscale service C, grayscale service C calls middleware, and middleware calls grayscale service D.

[0111] The present invention provides a method for implementing a full-link grayscale. Figure 1 The microservice system shown in Figure 7 , the method flow provided in the embodiment of the present application includes: 701. When the execution time of the scheduled grayscale task is reached, the distributed scheduling platform generates a scheduled access request.

[0112] 702. During the transmission of the scheduled access request, for any service node on the service path corresponding to the scheduled access request, the distributed scheduling platform receives a first heartbeat message sent by the microservice instance running on the service node through the corresponding service agent.

[0113] The first heartbeat message includes the label of the corresponding microservice instance and the grayscale scheduling strategy information.

[0114] 703. When it is determined that there is a grayscale microservice instance on the service node based on the label of the microservice instance running on the service node, and the grayscale microservice instance on the service node meets the grayscale scheduling conditions indicated by the corresponding grayscale scheduling policy information, the distributed scheduling platform controls the previous node of the service node to send a timed access request to the grayscale microservice instance on the service node.

[0115] Assuming that the target service node is any service node on the service path corresponding to the timed access request, and the next node of the target service node is the second service node, the process of the distributed scheduling platform controlling the target grayscale microservice instance to send the timed access request to the microservice instance on the second service node is as follows: the target grayscale microservice instance receives the timed access request through the target grayscale service agent, and provides the target microservice in response to the timed access request. After the target microservice is provided, the distributed scheduling platform receives the first heartbeat message sent by the microservice instance running on the second service node through the corresponding service agent, and the first heartbeat message includes the label of the corresponding microservice instance, etc. When it is determined that there is a grayscale microservice instance on the service node based on the label of the microservice instance running on the second service node, and the grayscale microservice instance on the service node meets the grayscale scheduling condition indicated by the corresponding grayscale scheduling policy information, the target grayscale microservice instance is controlled to send the timed access request to the grayscale microservice instance on the second service node through the target grayscale service agent.

[0116] Assuming that the target service node is any service node on the service path corresponding to the timed access request, and the next node of the target service node is the first type of middleware, the process of the distributed scheduling platform controlling the target grayscale microservice instance to send the timed access request to the first type of middleware is as follows: the target grayscale microservice instance receives the timed access request through the target grayscale service agent, and provides the target microservice in response to the timed access request. After the target microservice is provided, the distributed scheduling platform controls the target grayscale microservice instance to send the timed access request to the first type of middleware.

[0117] Assuming that the target service node is any service node on the service path corresponding to the timed access request, and the next node of the target service node is the second type of middleware, the process of the distributed scheduling platform controlling the target grayscale microservice instance to send the timed access request to the first type of middleware is as follows: the target grayscale microservice instance receives the timed access request through the target grayscale service agent, and provides the target microservice in response to the timed access request. After the target microservice is provided, the distributed scheduling platform controls the target grayscale microservice instance to send the timed access request to the second type of middleware.

[0118] Figure 8 The full-link grayscale release process is shown in Figure 8 , assume that the service path corresponding to the scheduled access request generated by the scheduled grayscale task is: service A-service B-service C-middleware-service D, where service A includes normal service A and grayscale service A, service C includes normal service C and grayscale service C, and service D includes normal service D and grayscale service D. When the execution time of the scheduled grayscale task is reached, the distributed scheduling platform generates a scheduled access request. Normal service A and grayscale service A send the labels of the microservice instances to the distributed scheduling platform through the corresponding service agents. The distributed scheduling platform sends the scheduled access request to the grayscale microservice instance corresponding to the grayscale service A. After the grayscale microservice instance corresponding to the grayscale service A provides the service, normal service B sends the label of the microservice instance to the distributed scheduling platform through the corresponding service agent. The distributed scheduling platform controls the grayscale microservice instance corresponding to the grayscale service A to send the scheduled access request to the normal microservice instance corresponding to the normal service B. The normal microservice instance corresponding to the normal service B provides the service. After the service is provided, normal service C and gray service C send the labels of the microservice instances to the distributed scheduling platform through the corresponding service agents. The distributed scheduling platform controls the normal microservice instance corresponding to normal service B to send the scheduled access request to the grayscale microservice instance corresponding to grayscale service C. After the grayscale microservice instance corresponding to grayscale service C provides the service, the distributed scheduling platform grayscale microservice instance corresponding to grayscale service C sends the scheduled access request to the middleware. Normal service D and gray service D send the labels of the microservice instances to the distributed scheduling platform through the corresponding service agents. The distributed scheduling platform controls the middleware to send the scheduled access request to the grayscale microservice instance corresponding to grayscale service D.

[0119] The related technology provides a method for implementing full-link grayscale, which includes: in response to a user request, obtaining an environment tag carried in the user request, wherein the environment tag includes a first environment tag or a second environment tag, and the second environment tag is a grayscale version tag corresponding to the first environment tag; according to the environment tag, routing the user request to a first database corresponding to the first environment tag or a second database corresponding to the second environment tag. By analyzing the solution and the solution of the present application, the following differences can be found: Disadvantage 1: The relevant technology is only applicable to a specific technical system (Java Agent) and cannot provide full-link grayscale support for multi-language heterogeneous microservice systems; As for the first disadvantage, the solution of this application proposes the concept of service proxy, which can be implemented in many ways, such as JavaAgent, Sidecar, etc. The service proxy can interact with the service itself, and can also communicate with components such as the microservice management and control platform and the registration center, thereby helping the microservice management and control platform to control the traffic between microservices, solving the microservice language limitation brought by the use of JavaAgent technology in existing solutions.

[0120] Disadvantage 2: The relevant technology is only applicable to calls between microservices and cannot be extended to full-link support for message middleware and other middleware.

[0121] For the second shortcoming, the solution of this application has modified and adapted the message middleware microservice instance in the service and the message middleware itself, so that the message middleware can identify grayscale requests, produce grayscale messages, and send grayscale messages to grayscale consumers. Users can perform white-screen management and control of all microservices and middleware on the microservice management and control platform to control the flow of the entire system and achieve the purpose of full-link grayscale.

[0122] The third disadvantage is that the relevant technology lacks the role of a microservice management and control platform, and it is impossible to perform grayscale release of services with one click, nor is it possible to manage the life cycle of services.

[0123] Regarding the third shortcoming, the solution of this application proposes the concept of a microservice control platform, which performs grayscale release and traffic management of services, allowing users to easily achieve one-click grayscale release and full-link grayscale configuration.

[0124] Disadvantage four: The relevant technology cannot dynamically adjust the grayscale environment of the service instance.

[0125] Regarding the fourth disadvantage, the solution of this application utilizes the registration center, microservice management and control platform, and service agent. By modifying the corresponding flags in the registration center, the environment of the created instance can be dynamically modified without restarting the service itself, and the modification method is more flexible.

[0126] Disadvantage five: The relevant technology is not applicable to more core scenarios of microservices, such as task scheduling, configuration grayscale, etc.

[0127] Regarding the fifth shortcoming, the solution of this application integrates the distributed task scheduling platform and the configuration center, integrates the full-link grayscale labels with the relevant microservice platforms, and realizes the systematic grayscale capabilities of tasks and configurations based on label routing and configuration distribution according to labels.

[0128] Fig. 9 The structure block diagram of an electronic device 900 provided by an exemplary embodiment of the present application is shown. Generally, the electronic device 900 includes: a processor 901 and a memory 902 .

[0129] The processor 901 can be implemented in at least one of the following hardware forms: DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 901 may also include a main processor and a coprocessor, wherein the main processor is a processor for processing data in an awake state; and the coprocessor is a low-power processor for processing data in a standby state. In some embodiments, the processor 901 may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 901 may also include an artificial intelligence processor, which is used to process computing operations related to machine learning.

[0130] The memory 902 may include one or more computer-readable storage media, which may be non-temporary computer-readable storage media, for example, the non-temporary computer-readable storage media may be CD-ROM (Compact Disc Read-Only Memory), ROM, RAM (Random Access Memory), magnetic tape, floppy disk, optical data storage device, etc. The computer-readable storage medium stores at least one computer program, which can implement the above-mentioned full-link grayscale publishing method or full-link grayscale implementation method when executed.

[0131] Of course, the above electronic device may also include other components, such as input / output interface, communication component, etc. The input / output interface provides an interface between the processor and the peripheral interface module, and the above peripheral interface module may be an output device, an input device, etc. The communication component is configured to facilitate wired or wireless communication between the electronic device and other devices.

[0132] Those skilled in the art will understand that Fig. 9 The structure shown in the figure does not constitute a limitation on the electronic device 900, and may include more or less components than those shown in the figure, or combine some components, or adopt a different component arrangement.

[0133] An embodiment of the present application provides a computer-readable storage medium, in which at least one computer program is stored. When the at least one computer program is executed by a processor, it can implement the above-mentioned full-link grayscale publishing method, or the above-mentioned full-link grayscale implementation method.

[0134] An embodiment of the present application provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it can implement the above-mentioned full-link grayscale publishing method, or the above-mentioned full-link grayscale implementation method.

[0135] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0136] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A microservice system, characterized in that: The system includes: a microservice management and control platform, a registration center and a target service node, wherein the target service node runs microservice instances of different versions capable of providing target microservices; The microservice management and control platform is used to receive a grayscale release instruction for the target microservice, wherein the grayscale release instruction includes a grayscale version and grayscale scheduling policy information of the target microservice; in response to the grayscale release instruction, based on the grayscale version, create a target grayscale microservice instance corresponding to the target microservice on the target service node, create a target grayscale service proxy for the target grayscale microservice instance, and provide the grayscale scheduling policy information to the target grayscale service proxy; The target grayscale microservice instance is used to send a grayscale registration request to the registration center through the target grayscale service agent after restarting, wherein the grayscale registration request includes the grayscale scheduling policy information and the service metadata of the grayscale version; The registration center is used to respond to the grayscale registration request, register the target grayscale microservice instance based on the grayscale scheduling policy information and the service metadata, and add a grayscale label to the target grayscale microservice instance to achieve grayscale release of the target microservice.

2. The system according to claim 1, characterized in that The target grayscale microservice instance is a Java microservice instance, and the target grayscale service agent is a Java agent; The Java microservice instance is used to load the code of the grayscale scheduling policy information into the code of the service metadata through the Java agent after restart, obtain the changed service metadata, and send a grayscale registration request including the changed service metadata to the registration center.

3. The system according to claim 1, characterized in that The target grayscale microservice instance is a non-Java microservice instance, and the target grayscale service agent is a Sidercar agent; The non-Java microservice instance is used to intercept, through the Sidercar agent, the grayscale registration request including the service metadata sent to the registration center after restart, add the grayscale scheduling policy information to the grayscale registration request, and send the grayscale registration request including the grayscale scheduling policy information and the service metadata to the registration center.

4. The system according to claim 1, characterized in that The system also includes a configuration center; The configuration center is used to receive a configuration update instruction for the target configuration of the target microservice, wherein the configuration update instruction includes new configuration information of the target configuration and a configuration grayscale delivery strategy; In response to the configuration update instruction, the labels of each microservice instance corresponding to the target microservice are obtained, and based on the configuration grayscale delivery strategy, the configuration information of the target configuration in the microservice instance corresponding to the grayscale label is updated to the new configuration information.

5. The system according to claim 1, characterized in that The system also includes a microservices gateway; The microservice gateway is used to receive a first external access request, where the service path corresponding to the first external access request includes the target service node; Acquire the grayscale scheduling policy information from the registration center, identify the type of the first external access request based on the grayscale scheduling policy information, and when the type of the first external access request is identified as a grayscale request, add a grayscale identifier to the first external access request to obtain a second external access request, and send the second external access request to a first grayscale microservice instance on a first service node, where the first service node is a first service node included in the service path; The first grayscale microservice instance is used to receive the second external access request through the first grayscale service agent, and provide a corresponding microservice in response to the second access request; Alternatively, the second external access request is received through the first grayscale service agent, a grayscale identifier is added to the second external access request, a third external access request is obtained, and a corresponding microservice is provided in response to the third external access request.

6. The system according to claim 5, characterized in that The target service node is a service node other than the first service node on the service path, and the next node of the target service node is a second service node; The target grayscale microservice instance is used to receive a fourth external access request through the target grayscale service agent, where the fourth access request is obtained by adding at least one grayscale identifier to the first access request; provide the target microservice in response to the fourth external access request, and after the target microservice is provided, obtain registration information of each microservice instance running on the second service node from the registration center to determine whether there is a second grayscale microservice instance on the second service node, and when it is determined that the second grayscale microservice instance exists, send the fourth external access request to the second grayscale microservice instance; or, The target grayscale microservice instance is used to receive the fourth external access request through the target grayscale service agent, add a grayscale identifier to the fourth external access request, obtain a fifth external access request, provide the target microservice in response to the fifth external access request, and after the target microservice is provided, obtain the labels of each microservice instance running on the second service node from the registration center to determine whether there is a second grayscale microservice instance on the second service node; when it is determined that the second grayscale microservice instance exists, send the fifth external access request to the second grayscale microservice instance.

7. The system according to claim 1, characterized in that The system also includes a distributed scheduling platform; The distributed scheduling platform is used to generate a scheduled access request when the execution time of the scheduled grayscale task is reached. During the transmission of the scheduled access request, for any service node on the service path corresponding to the scheduled access request, receive a first heartbeat message sent by the microservice instance running on the service node through the corresponding service agent, wherein the first heartbeat message includes a label of the corresponding microservice instance and grayscale scheduling policy information; When it is determined that there is a grayscale microservice instance on the service node based on the label of the microservice instance running on the service node, and the grayscale microservice instance on the service node meets the grayscale scheduling condition indicated by the corresponding grayscale scheduling policy information, the previous node of the service node is controlled to send the timed access request to the grayscale microservice instance on the service node.

8. The system according to any one of claims 1 to 7, characterized in that The system further includes a first type of middleware, wherein the first type of middleware refers to middleware capable of identifying grayscale identification; The first type of middleware is used to receive an access request sent by a microservice instance on a previous service node, where the access request is a scheduled access request or an external access request, and identify whether the access request carries a grayscale identifier. When it is identified that the access request carries a grayscale identifier and a grayscale microservice instance is running on the next service node, the access request is sent to the grayscale microservice instance on the next service node.

9. The system according to any one of claims 1 to 7, characterized in that The system further includes a second type of middleware, wherein the second type of middleware refers to middleware that cannot recognize the grayscale identifier; The second type of middleware is used to receive an access request sent by a microservice instance on a previous service node, where the access request is a scheduled access request or an external access request; Receive a data acquisition request sent by a designated microservice instance on a next service node, and send the access request to the designated microservice instance, where the designated microservice instance is a microservice instance running on the next service node and of the same type as the access request.

10. The system according to any one of claims 1 to 7, characterized in that: The microservice management and control platform is further configured to send a type change instruction to the target grayscale microservice instance in response to a full release instruction for the grayscale version of the target microservice; The target grayscale microservice instance receives the type change instruction through the target grayscale service agent, and sends a second heartbeat message to the registration center, where the second heartbeat message is used to instruct the registration center to change the grayscale label of the target grayscale microservice instance to a normal label.

11. A full-link grayscale release method, characterized in that: The method is applied to the microservice system according to any one of claims 1 to 10, and the method comprises: The microservice management and control platform receives a grayscale release instruction for the target microservice, wherein the grayscale release instruction includes a grayscale version and grayscale scheduling policy information of the target microservice; in response to the grayscale release instruction, based on the grayscale version, creates a target grayscale microservice instance corresponding to the target microservice on the target service node, creates a target grayscale service proxy for the target grayscale microservice instance, and provides the grayscale scheduling policy information to the target grayscale service proxy; After restarting, the target grayscale microservice instance sends a grayscale registration request to the registration center through the target grayscale service agent, where the grayscale registration request includes the grayscale scheduling policy information and the service metadata of the grayscale version; The registration center responds to the grayscale registration request, registers the target grayscale microservice instance based on the grayscale scheduling policy information and the service metadata, and adds a grayscale label to the target grayscale microservice instance to achieve grayscale release of the target microservice.

12. The method according to claim 11, characterized in that The target grayscale microservice instance is a Java microservice instance, and the target grayscale service agent is a Java agent; After the target grayscale microservice instance is restarted, the target grayscale service agent sends a grayscale registration request to the registration center, including: After restarting, the Java microservice instance loads the code of the grayscale scheduling policy information into the code of the service metadata through the Java agent, obtains the changed service metadata, and sends a grayscale registration request including the changed service metadata to the registration center.

13. The method according to claim 11, characterized in that The target grayscale microservice instance is a non-Java microservice instance, and the target grayscale service agent is a Sidercar agent; After the target grayscale microservice instance is restarted, the target grayscale service agent sends a grayscale registration request to the registration center, including: After restarting, the non-Java microservice instance intercepts the grayscale registration request including the service metadata sent to the registration center through the Sidercar agent, adds the grayscale scheduling policy information to the grayscale registration request, and sends the grayscale registration request including the grayscale scheduling policy information and service metadata to the registration center.

14. The method according to claim 11, characterized in that The method further comprises: The configuration center receives a configuration update instruction for a target configuration of the target microservice, wherein the configuration update instruction includes new configuration information of the target configuration and a configuration grayscale delivery strategy; in response to the configuration update instruction, obtains labels of each microservice instance corresponding to the target microservice, and based on the configuration grayscale delivery strategy, updates the configuration information of the target configuration in the microservice instance corresponding to the grayscale label to the new configuration information.

15. A full-link grayscale implementation method, characterized in that: The method is applied to the microservice system according to any one of claims 1 to 10, and the method comprises: The microservice gateway receives a first external access request, wherein the service path corresponding to the first external access request includes the target service node; obtains the grayscale scheduling policy information from the registration center, identifies the type of the first external access request based on the grayscale scheduling policy information, and when the type of the first external access request is identified as a grayscale request, adds a grayscale identifier to the first external access request to obtain a second external access request, and sends the second external access request to a first grayscale microservice instance on a first service node, wherein the first service node is the first service node included in the service path; The first grayscale microservice instance receives the second external access request through the first grayscale service agent, and provides a corresponding microservice in response to the second access request.

16. The method according to claim 15, characterized in that The target service node is a service node other than the first service node on the service path, and the second service node is a next node of the target service node. The method further includes: The target grayscale microservice instance receives a fourth external access request through the target grayscale service agent, where the fourth access request is obtained by adding at least one grayscale identifier to the first access request; provides the target microservice in response to the fourth external access request, and obtains registration information of each microservice instance running on the second service node from the registration center after the target microservice is provided, so as to determine whether there is a second grayscale microservice instance on the second service node; and when it is determined that the second grayscale microservice instance exists, sends the fourth external access request to the second grayscale microservice instance.

17. A full-link grayscale implementation method, characterized in that: The method is applied to the microservice system according to any one of claims 1 to 10, and the method comprises: The microservice gateway receives a first external access request, wherein the service path corresponding to the first external access request includes the target service node; obtains the grayscale scheduling policy information from the registration center, identifies the type of the first external access request based on the grayscale scheduling policy information, and when the type of the first external access request is identified as a grayscale request, adds a grayscale identifier to the first external access request to obtain a second external access request, and sends the second external access request to a first grayscale microservice instance on a first service node, wherein the first service node is the first service node included in the service path; The first grayscale microservice instance receives the second external access request through the first grayscale service agent, adds a grayscale identifier to the second external access request, obtains a third external access request, and provides a corresponding microservice in response to the third external access request.

18. The method according to claim 17, characterized in that The target service node is another service node on the service path except the first service node, and the second service node is a next node of the target service node. The method further includes: The target grayscale microservice instance receives a fourth external access request through the target grayscale service agent, where the fourth access request is obtained by adding a grayscale identifier at least once in the first access request; a grayscale identifier is added to the fourth external access request to obtain a fifth external access request; the target microservice is provided in response to the fifth external access request, and after the target microservice is provided, the label of each microservice instance running on the second service node is obtained from the registration center to determine whether there is a second grayscale microservice instance on the second service node; when it is determined that the second grayscale microservice instance exists, the fifth external access request is sent to the second grayscale microservice instance.

19. A full-link grayscale implementation method, characterized in that: The method is applied to the microservice system according to any one of claims 1 to 10, and the method comprises: When the execution time of the scheduled grayscale task is reached, the distributed scheduling platform generates a scheduled access request; During the transmission of the timed access request, for any service node on the service path corresponding to the timed access request, the distributed scheduling platform receives a first heartbeat message sent by the microservice instance running on the service node through the corresponding service agent, where the first heartbeat message includes a label and grayscale scheduling strategy information of the corresponding microservice instance; When it is determined that there is a grayscale microservice instance on the service node based on the label of the microservice instance running on the service node, and the grayscale microservice instance on the service node meets the grayscale scheduling conditions indicated by the corresponding grayscale scheduling policy information, the distributed scheduling platform controls the previous node of the service node to send the timed access request to the grayscale microservice instance on the service node.

20. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores at least one computer program, which, when executed by the processor, can implement the full-link grayscale publishing method described in any one of claims 11 to 14, or the full-link grayscale implementation method described in claim 15 or 16, or the full-link grayscale implementation method described in claim 17 or 18, or the full-link grayscale implementation method described in claim 19.

21. A computer program product, characterized in that The computer program product includes a computer program, which, when executed by a processor, can implement the full-link grayscale publishing method described in any one of claims 11 to 14, or the full-link grayscale implementation method described in claim 15 or 16, or the full-link grayscale implementation method described in claim 17 or 18, or the full-link grayscale implementation method described in claim 19.

Images