Full-link gray release and implementation method, and micro-service system applying full-link gray release and implementation method

Abstract

One or more embodiments of the invention provide a full-link gray release and implementation method and a micro-service system using the same. The micro-service system comprises a service hosting platform and a service operation platform. A service hosting platform can execute the full-link gray release method, and proxy configuration information, service attribute information and the like are added into service configuration files corresponding to micro-services; and a preset gray scale rule can be issued to the gateway in the service operation platform. Correspondingly, when the service operation platform creates the micro-service instance based on the service configuration file, a service agent component can be set in the micro-service instance based on the agent configuration information, and service attribute information such as the name and version of the micro-service and a lane to which the micro-service belongs is set as metadata of the micro-service instance. And then performing a preset proxy function based on the service proxy component, such as service registration, request routing and request dyeing, so that each micro-service instance automatically realizes request keeping, rollback and delivery according to a lane.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of cloud computing technology, and in particular, to a full-link gray release and implementation method, and a microservice system using the same. Background Art

[0002] A system based on a microservice architecture consists of a large number of independent microservices. Different microservices have different corresponding deployment environments, development teams, etc., and the relationships between microservices are also intricate. Therefore, when implementing full-link gray release, problems such as service scheduling across clusters and gateways, and collaboration between different development and operation and maintenance teams may be faced, which is difficult to implement, increases the system operation and maintenance cost, and affects the microservice update efficiency.

[0003] Therefore, there is an urgent need for a full-link gray release and implementation solution that can adapt to complex microservice systems. Summary of the Invention

[0004] In order to reduce the implementation difficulty of full-link gray release, improve the microservice risk efficiency, and reduce the operation and maintenance cost, one or more embodiments of this specification provide a full-link gray release and implementation method, and a microservice system using the same.

[0005] In a first aspect, one or more embodiments of this specification provide a full-link gray release method, which is applied to a service hosting platform;

[0006] The full-link gray release method includes:

[0007] In response to the current release instruction, for at least one microservice related to the current release task, generate a corresponding service configuration file, and add proxy configuration information to the service configuration file;

[0008] Send a service deployment instruction including the service configuration file to the service running platform, so that the service running platform creates a microservice instance of the corresponding microservice according to the service configuration file, and sets a service proxy component in the microservice instance according to the proxy configuration information;

[0009] Wherein, the service proxy component is used to execute a preset proxy function after the microservice instance is started, and the preset proxy function includes at least one of service registration, request routing, and request coloring related to the microservice instance.

[0010] In a possible implementation manner, when generating the service configuration file, the full-link gray release method further includes:

[0011] Obtain the current release information; the current release information includes the association relationship between the cluster, lane, microservice name, and microservice version number related to the current release task;

[0012] Determine the service attribute information corresponding to each of the microservices according to the current release information; the service attribute information includes at least one of the microservice name, microservice version number, and the swimlane to which it belongs of the corresponding microservice.

[0013] Use the service attribute information as environment variables and add them to the service configuration file of the corresponding microservice, so that when the service operation platform creates a corresponding microservice instance according to the service configuration file, the service attribute information recorded in the form of environment variables in the service configuration file is configured as the metadata of the corresponding microservice instance.

[0014] In a possible implementation, the full-link gray release method further includes:

[0015] Determine the target cluster corresponding to each of the microservices according to the current release information;

[0016] The sending a service deployment instruction including the service configuration file to the service operation platform includes:

[0017] Send a service deployment instruction including the corresponding service configuration file to the target cluster in the service operation platform, so that the service operation platform creates a corresponding microservice instance in the target cluster according to the service configuration file.

[0018] In a possible implementation, the current release information further includes: a preset gray rule corresponding to at least one gateway related to the current release task;

[0019] The full-link gray release method further includes:

[0020] Send the preset gray rule to the corresponding gateway, so that after receiving the request information, the gateway routes the request information according to the preset gray rule.

[0021] In a second aspect, one or more embodiments of this specification provide a full-link gray implementation method, which is applied to a service operation platform;

[0022] The full-link gray implementation method includes:

[0023] In response to a service deployment instruction including a service configuration file sent by a service hosting platform, create a microservice instance according to the service configuration file, and set a service proxy component in the microservice instance according to the proxy configuration information in the service configuration file.

[0024] After the microservice instance is started, execute a preset proxy function through the service proxy component; the preset proxy function includes at least one of service registration, request routing, and request coloring related to the microservice instance.

[0025] In a possible implementation, the microservice instance is a containerized instance; creating a microservice instance according to the service configuration file and setting a service proxy component in the microservice instance according to the proxy configuration information in the service configuration file includes:

[0026] Create a corresponding service container group according to the service configuration file, and the service container group includes at least one sub-container for executing various functions of the corresponding microservice.

[0027] Add a proxy sub-container to the service container group; the proxy sub-container contains the program file of the service proxy component; the type of the proxy sub-container includes an initialization container.

[0028] Copy the program file of the preset proxy component stored in the proxy sub-container to a preset data volume.

[0029] Mount the preset data volume to a preset directory of the service container group to call the program file of the service proxy component by accessing the preset data volume.

[0030] In a possible implementation, the service operation platform includes at least one target cluster related to the current release task.

[0031] Responding to a service deployment instruction including a service configuration file sent by the service hosting platform, creating a microservice instance according to the service configuration file includes:

[0032] Respond to a service deployment instruction including a service configuration file sent by the service hosting platform to any target cluster, and create a microservice instance in the corresponding target cluster according to the service configuration file.

[0033] In a possible implementation, the service configuration file further includes service attribute information of the corresponding microservice recorded in the form of environment variables; the service attribute information includes at least one of the microservice name, microservice version number, and the lane to which the microservice belongs of the corresponding microservice.

[0034] The full-link gray implementation method further includes:

[0035] When creating a microservice instance according to the service configuration file, configure the service attribute information recorded in the form of environment variables in the service configuration file as metadata of the microservice instance.

[0036] In a possible implementation, the service operation platform further includes a registration center; performing service registration in the preset proxy function through the service proxy component includes:

[0037] The service proxy component adds the metadata to a service registration request and sends the service registration request to the registration center; the metadata includes the service attribute information;

[0038] The registration center performs service registration on the corresponding microservice instance according to the service registration request, so as to store the service attribute information corresponding to the corresponding microservice instance in the registration center.

[0039] In a possible implementation, performing request routing in the preset proxy function through the service proxy component includes:

[0040] After the microservice instance receives a first request, the service proxy component in the microservice instance obtains first target lane information corresponding to the first request, and filters the list of next-hop microservice instances according to the first target lane information, so as to filter out the microservice instances in the list of next-hop microservice instances that do not match the first target lane information;

[0041] The microservice instance determines a first target microservice instance according to the filtered list of next-hop microservice instances;

[0042] The microservice instance generates a second request and sends the second request to the first target microservice instance.

[0043] In a possible implementation, the service proxy component obtaining the first target lane information corresponding to the first request includes:

[0044] Obtaining the first lane information recorded in the context information corresponding to the first request as the first target lane information;

[0045] In the case where the first lane information does not exist in the context information, obtaining the second lane information recorded in the request header of the first request as the first target lane information;

[0046] In the case where the second lane information does not exist in the request header of the first request, obtaining the third lane information recorded in the environment variables or metadata corresponding to the current microservice instance as the first target lane information;

[0047] In the case where the third lane information does not exist in the environment variables and metadata corresponding to the current microservice instance, using the default lane information as the first target lane information.

[0048] In one possible implementation, performing request coloring in the preset proxy function through the service proxy component includes:

[0049] The service proxy component injects the first target lane information into the system trace information, and when the microservice instance generates the second request, adds the first target lane information recorded in the system trace information to the second request.

[0050] In one possible implementation, the service operation platform further includes at least one gateway;

[0051] The full-link grayscale implementation method further includes:

[0052] The gateway receives the preset grayscale rule sent by the service hosting platform;

[0053] After receiving the third request, the gateway routes the third request according to the preset grayscale rule.

[0054] In one possible implementation, after receiving the third request, the gateway routes the third request according to the preset grayscale rule, including:

[0055] The gateway determines the second target microservice instance corresponding to the third request and the second target lane information corresponding to the second target microservice instance according to the preset grayscale rule;

[0056] The gateway adds the second target lane information to the third request to obtain a fourth request, and sends the fourth request to the second target microservice instance.

[0057] In a third aspect, one or more embodiments of this specification further provide a microservice system, including: a service hosting platform and a service operation platform;

[0058] The service hosting platform is configured to, in response to the current release instruction, generate corresponding service configuration files for at least one microservice related to the current release task, add proxy configuration information to the service configuration files, and send a service deployment instruction including the service configuration files to the service operation platform;

[0059] The service operation platform is configured to create microservice instances of corresponding microservices according to the service configuration files, and set service proxy components in the microservice instances according to the proxy configuration information;

[0060] Wherein, the service proxy component is configured to execute a preset proxy function after the microservice instance is started, and the preset proxy function includes at least one of service registration, request routing, and request coloring related to the microservice instance.

[0061] In a possible implementation, the microservice instance is a containerized instance;

[0062] To create a microservice instance according to the service configuration file and set a service proxy component in the microservice instance according to the proxy configuration information in the service configuration file, the service operation platform is further configured to perform the following operations:

[0063] Create a corresponding service container group according to the service configuration file, where the service container group includes at least one sub-container for executing various functions of the corresponding microservice;

[0064] Add a proxy sub-container to the service container group; the proxy sub-container contains the program file of the service proxy component; the type of the proxy sub-container includes an initialization container;

[0065] Copy the program file of the preset proxy component stored in the proxy sub-container to a preset data volume;

[0066] Mount the preset data volume to a preset directory of the service container group to call the program file of the service proxy component by accessing the preset data volume.

[0067] In a possible implementation, the service hosting platform is further configured to perform the following operations when generating the service configuration file:

[0068] Obtain the current release information; the current release information includes the association relationship between the cluster, lane, microservice name, and microservice version number related to the current release task;

[0069] Determine the service attribute information corresponding to each microservice according to the current release information; the service attribute information includes at least one of the microservice name, microservice version number, and the lane to which the microservice belongs;

[0070] Add the service attribute information as an environment variable to the service configuration file of the corresponding microservice;

[0071] When creating a microservice instance of the corresponding microservice according to the service configuration file, the service operation platform is further configured to configure the service attribute information recorded in the form of an environment variable in the service configuration file as the metadata of the corresponding microservice instance.

[0072] In a possible implementation, the service operation platform includes at least one cluster;

[0073] The service hosting platform is also used to determine the target cluster corresponding to each microservice according to the current release information, and after generating the service configuration file corresponding to the microservice, send a service deployment instruction including the service configuration file to the target cluster in the service operation platform;

[0074] The service operation platform is also used to, in response to the service deployment instruction including the service configuration file sent by the service hosting platform to the target cluster, create a microservice instance in the target cluster according to the service configuration file.

[0075] In a possible implementation, the service operation platform includes at least one gateway;

[0076] The current release information further includes: a preset gray rule corresponding to at least one gateway related to the current release task;

[0077] The service hosting platform is also used to send the preset gray rule to the corresponding gateway;

[0078] The gateway is used to receive the preset gray rule sent by the service hosting platform, and route the third request according to the preset gray rule after receiving the third request.

[0079] In a possible implementation, to route the third request according to the preset gray rule after receiving the third request, the gateway is further used to perform the following operations:

[0080] According to the preset gray rule, determine the second target microservice instance corresponding to the third request, and the second target lane information corresponding to the second target microservice instance;

[0081] Add the second target lane information to the third request to obtain a fourth request, and send the fourth request to the second target microservice instance.

[0082] In a possible implementation, the service operation platform further includes a registration center;

[0083] To implement service registration in the preset proxy function, the service proxy component is used to, after the corresponding microservice instance is started, add the metadata of the microservice instance to a service registration request, and send the service registration request to the registration center; the metadata includes the service attribute information;

[0084] The registration center is used to perform service registration on the corresponding microservice instance according to the service registration request, so as to store the service attribute information corresponding to the corresponding microservice instance in the registration center.

[0085] In a possible implementation, to implement request routing in the preset proxy function, the service proxy component is further configured to: after the corresponding microservice instance receives a first request, obtain first target lane information corresponding to the first request, and filter a list of next-hop microservice instances according to the first target lane information to filter out microservice instances in the list of next-hop microservice instances that do not match the first target lane information;

[0086] The microservice instance is configured to determine a first target microservice instance according to the filtered list of next-hop microservice instances, and generate a second request and send the second request to the first target microservice instance.

[0087] In a possible implementation, to implement obtaining the first target lane information corresponding to the first request, the service proxy component is further configured to perform the following operations:

[0088] Obtain the first lane information recorded in the context information corresponding to the first request as the first target lane information;

[0089] In the case where the first lane information does not exist in the context information, obtain the second lane information recorded in the request header of the first request as the first target lane information;

[0090] In the case where the second lane information does not exist in the request header of the first request, obtain the third lane information recorded in the environment variables or metadata corresponding to the current microservice instance as the first target lane information;

[0091] In the case where the third lane information does not exist in the environment variables and metadata corresponding to the current microservice instance, use the default lane information as the first target lane information.

[0092] In a possible implementation, to implement request coloring in the preset proxy function, the service proxy component is further configured to: inject the first target lane information into the system trace information, and when the microservice instance generates the second request, add the first target lane information recorded in the system trace information to the second request.

[0093] In a fourth aspect, one or more embodiments of this specification further provide a computer-readable storage medium storing computer program instructions, which when executed, implement the method in the first aspect or the second aspect above.

[0094] Fifth aspect, one or more embodiments of this specification further provide a computer program product, characterized in that the computer program product includes: a computer program or instruction, when the computer program or instruction runs on a computer, enabling the computer to implement the method of the first aspect or the second aspect above.

[0095] First of all, in the above embodiments, the service hosting platform adds proxy configuration information to the service configuration file, so that when the service running platform creates a microservice instance according to the service configuration file, it can set a service proxy component in the microservice instance according to the proxy configuration information. Thus, after each microservice instance is started, it can implement preset proxy functions such as service registration, request routing, and request coloring through its service proxy component, thereby assisting each microservice instance to accurately discover the gray version of the next-hop microservice and ensuring the implementation of full-link gray scale. And since the discovery of the gray version of the next-hop microservice is implemented through the service proxy component and there is no need to modify the source code of each microservice version, the above embodiments can achieve non-invasive enhancement of the service discovery logic and meet the non-intrusive requirements of existing services.

[0096] Secondly, in the above embodiments, service registration is implemented through the service proxy component, and the microservice name, microservice version number, and the lane to which each microservice instance belongs can be stored in the registration center. Thus, when other microservices perform service discovery, the list of next-hop microservice instances pulled also includes the lane information corresponding to each microservice instance. Further, request routing can be further implemented through the service proxy component to filter out microservice instances in the list of next-hop microservice instances that do not match the target lane information, ensuring that the finally determined next-hop microservice instance (i.e., the target microservice instance corresponding to the current microservice embodiment) matches the target lane information. At the same time, request coloring can also be further implemented through the service proxy component to ensure that the target lane information is sent to the next-hop microservice instance along with the access request, thereby expanding the dimension of the link in gray release from a single cluster to multiple clusters, realizing cross-service transfer and full-link transfer of the target lane information, and avoiding the situation where the access request cannot be redelivered to the original gray lane after retreating from the gray lane to the default lane, ensuring the implementation of full-link gray scale.

[0097] In addition, the above embodiments centralize the management of gateways, clusters, lanes, and microservices through the service hosting platform, reducing the collaboration cost of service development teams corresponding to different microservices, and thus improving the efficiency of microservice release and update. Description of the Drawings

[0098] To more clearly illustrate the technical solutions of one or more embodiments of this specification, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of one or more embodiments of this specification. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0099] Figure 1 Schematic diagram of a call chain in a microservice architecture provided for one or more embodiments of this specification;

[0100] Figure 2 Schematic diagram of the architecture of a microservice system provided for one or more embodiments of this specification;

[0101] Figure 3 Schematic diagram of the process of a full-link gray release method provided for one or more embodiments of this specification;

[0102] Figure 4 Schematic diagram of the process of a full-link gray implementation method provided for one or more embodiments of this specification;

[0103] Figure 5 Signaling diagram of a microservice system executing a full-link gray release and implementation method provided for one or more embodiments of this specification;

[0104] Figure 6 Schematic diagram of the process of a full-link gray implementation method provided for one or more embodiments of this specification;

[0105] Figure 7 Schematic diagram of the process of a full-link gray implementation method provided for one or more embodiments of this specification;

[0106] Figure 8 Schematic diagram of the principle of setting up a service proxy component in a microservice instance during the process of a full-link gray implementation method provided for one or more embodiments of this specification;

[0107] Figure 9 Schematic diagram of the process of a full-link gray release method provided for one or more embodiments of this specification;

[0108] Figure 10 Schematic diagram of the principle of deploying microservice instances based on lanes in a full-link gray implementation method provided for one or more embodiments of this specification;

[0109] Figure 11 Schematic diagram of the principle of request routing in a full-link gray implementation method provided for one or more embodiments of this specification;

[0110] Figure 12 In a full - link grayscale implementation method provided for one or more embodiments of this specification, service registration and request routing are performed based on a service proxy component. Specific embodiments

[0111] The following further details one or more embodiments of this specification through the accompanying drawings and embodiments. Through these descriptions, the features and advantages of one or more embodiments of this specification will become clearer and more distinct.

[0112] The special term "exemplary" here means "serving as an example, an embodiment, or illustrative". Any embodiment described as "exemplary" here does not have to be construed as superior to or better than other embodiments. Although various aspects of the embodiments are shown in the drawings, unless otherwise specified, the drawings do not have to be drawn to scale.

[0113] In addition, the technical features involved in different embodiments of one or more embodiments of this specification described below can be combined with each other as long as they do not conflict with each other.

[0114] For ease of understanding, the following first explains the terms and application scenarios related to the technical solutions provided by one or more embodiments of this specification.

[0115] Microservice: A small - scale service that can be developed, deployed, and operated independently. A microservice can be a provider or a consumer. When a microservice is a provider, it can provide a service interface, and other microservices can obtain this microservice by calling this service interface; when a microservice is a consumer, it can call the service interfaces provided by other microservices to obtain other microservices.

[0116] An application based on a microservice architecture includes multiple microservices; each microservice respectively implements a specific function; different microservices cooperate and call each other through a network communication mechanism to implement the functions corresponding to this application. Since each microservice can be developed and deployed independently, the maintainability, scalability, and flexibility of the entire application can be improved.

[0117] Gray release: Also known as canary release, it refers to a release method that can achieve a smooth transition between the official version and the gray version of a microservice to be released. That is, a part of the access requests are continuously routed to the official version of the microservice, such as version V1.0, and another part of the access requests are routed to the gray version of the microservice, such as version V2.0. If the gray version of the microservice can respond to requests normally, the proportion of traffic received by the gray version is gradually increased until all traffic is routed to the gray version, which means the transition of the microservice from the official version to the gray version is completed, and this gray version can be used as the new official version. Gray release conducts small-scale traffic tests to promptly discover and adjust problems existing in the gray version, avoiding potential problems in the gray version from causing large-scale failures and ensuring the overall stability of related applications or systems.

[0118] Call chain: After an external request enters the microservice system, it will cause a series of inter-service calls, and this complete call link is called a call chain.

[0119] Full-link gray release: If an access request is marked as a gray request, all calls in the call chain generated by this access request will be made to the gray version of the corresponding microservice (if there is a gray version).

[0120] With the development of cloud computing technology, applications based on the microservice architecture have been widely used due to their loose coupling, flexibility, and scalability. Due to security, compliance, performance, and user requirements, etc., it may be necessary to update some microservices in the application.

[0121] The relationships between various microservices in an application are intricate, and the implementation of a certain function often depends on multiple microservices. To better evaluate the compatibility and stability between the new version and the existing system, it is necessary to conduct full-link gray release for the new versions of multiple microservices, which requires full-link gray calls in the microservice system, that is: for an access request marked as a gray request, if there is a gray version running on any node on the service path corresponding to this access request, then this gray version needs to be called.

[0122] For example, referring to Figure 1 , an application includes multiple microservices such as microservice A, microservice B, and microservice C, and the service path for implementing a certain function is: microservice A -> microservice B -> microservice C; among them, in addition to the official versions, there are also gray versions A_gray and C_gray for microservice A and microservice C. For an external access request, if it is an official request, it is expected to generate the following call chain L1: microservice A -> microservice B -> microservice C; if it is a gray request, it is expected to generate the following call chain L2: microservice A_gray -> microservice B -> microservice C_gray.

[0123] The above call chain L2 implements full-link gray scale, that is, during the call process, if there is a gray-scale version of the microservice to be called, the gray-scale version of the microservice is called; if there is no gray-scale version of the microservice to be called, the official version of the microservice is called.

[0124] However, the dependency relationships between microservices are complex, and it is difficult to ensure that all calls in the call chain generated by the same access request can be made to the gray-scale version. For example, the following call chain may be generated: microservice A_gray -> microservice B -> microservice C. Even more, multiple microservices of the same application may be deployed in different clusters, and cross-cluster calls further increase the difficulty of implementing full-link gray scale.

[0125] In view of this, a full-link gray-scale release and implementation method provided by one or more embodiments of this specification, and a microservice system applying the same, can reduce the implementation difficulty of full-link gray-scale release, improve the microservice risk efficiency, and reduce the operation and maintenance costs.

[0126] Figure 2 shows an architecture diagram of a microservice system provided by one or more embodiments of this specification. Refer to Figure 2 , this microservice system includes a three-layer architecture, namely a development platform 10, a service hosting platform 20, and a service hosting platform 30.

[0127] Among them, the development platform 10 may include a variety of development tool products. Relevant personnel can select different development tool products according to needs to develop relevant microservices, and push the generated microservice versions to the service hosting platform 20.

[0128] As an intermediate layer, the service hosting platform 20 can, on the one hand, be associated with the development platform 10 to receive the microservice versions pushed by the development platform 10 and perform release and operation and maintenance; on the other hand, it can also be associated with the service operation platform 30 to uniformly manage and comprehensively utilize the various infrastructures in the service operation platform 30 to meet different levels of service operation and maintenance requirements.

[0129] The service operation platform 30 provides the various infrastructures required for microservice operation, such as clusters, gateways, middleware, etc. Under the management of the service hosting platform 20, the release, operation, monitoring, etc. of each microservice version are realized.

[0130] In some embodiments, the service hosting platform 20 may include a variety of logical modules for implementing different management functions.

[0131] Exemplarily, the service hosting platform 20 may include a full-link release module for implementing full-link gray-scale release.

[0132] Exemplarily, the service hosting platform 20 may further include other publishing modules for implementing other publishing methods, such as single-batch publishing, batch-by-batch publishing, etc. In addition, the service hosting platform 20 may further include a service full life cycle management module, a version management module, etc., for performing full life cycle management, version management, etc. on each microservice.

[0133] Regarding the technical problems to be solved by the technical solution of this specification, the following focuses on the specific implementation manner in which the service hosting platform 20 implements full-link gray publishing based on its full-link publishing module.

[0134] In some embodiments, the service hosting platform 20 may interact with the user through a preset user interface to receive the publishing information of the microservice publishing task from the user, and then implement full-link gray publishing of the relevant microservice according to the publishing information.

[0135] Figure 3 FIG. shows a schematic flowchart of a full-link gray publishing method provided by one or more embodiments of this specification. This full-link gray publishing method may be applied to the above-mentioned service hosting platform 20. Figure 4 FIG. shows a schematic flowchart of a full-link gray implementation method provided by one or more embodiments of this specification. This full-link gray implementation method may be applied to the above-mentioned service running platform 30. Figure 5 FIG. shows a signaling diagram of the interaction between the above-mentioned service hosting platform 20 and service running platform 30 to implement full-link gray publishing.

[0136] Refer to together Figures 3 to 5 In step S12, in response to this publishing instruction, the service hosting platform 20 generates a corresponding service configuration file for at least one microservice related to this publishing task corresponding to this publishing instruction, and adds proxy configuration information to the service configuration file.

[0137] Exemplarily, the above-mentioned this publishing instruction may be an instruction triggered by the user received by the service hosting platform 20 through its preset user interface, or may be a publishing instruction automatically triggered and generated after meeting the user's preset publishing conditions (such as time conditions).

[0138] In step S14, the service hosting platform 20 sends a service deployment instruction including the service configuration file to the service running platform 30.

[0139] Correspondingly, in step S22, in response to the service deployment instruction including the service configuration file sent by the service hosting platform 20, the service running platform 30 creates a microservice instance according to the service configuration file, and sets a service proxy component in the created microservice instance according to the proxy configuration information in the service configuration file.

[0140] Exemplarily, a management center may be set up in the service operation platform 30 to receive and respond to instructions sent by the service hosting platform 20, such as the aforementioned service deployment instruction.

[0141] In step S24, after the created microservice instance is started, the service operation platform 30 executes a preset proxy function through the service proxy component in the microservice instance.

[0142] Exemplarily, the preset proxy function includes at least one of service registration, request routing, and request coloring related to the microservice instance.

[0143] The following is an example to illustrate the processes of generating service configuration files, creating microservice instances, etc. described in the above embodiments. As Figure 6 shown, assume that based on this release instruction, the microservices related to this release task may include microservice A, microservice B, and microservice C, etc.; microservice A includes three versions A1, A2, and A3, microservice B includes two versions B1 and B2, and microservice C includes two versions C1 and C2. Among them, A1, B1, and C1 may be the official versions of the corresponding microservices respectively, and A2, A3, B2, and C2 are the gray-scale versions of the corresponding microservices to be released this time.

[0144] After receiving this release instruction, the service hosting platform 20 can generate corresponding service configuration files based on each version of the above-mentioned microservices respectively. As Figure 6 shown, for the three versions A1, A2, and A3 of microservice A, corresponding service configuration files F_A1, F_A2, and F_A3 are generated respectively; for the two versions B1 and B2 of microservice B, corresponding service configuration files F_B1 and F_B2 are generated respectively; for the two versions C1 and C2 of microservice C, corresponding service configuration files F_C1 and F_C2 are generated respectively. Then, the service hosting platform 20 can send a service deployment instruction to the service operation platform 30, and the service deployment instruction carries the above-mentioned service configuration files F_A1, etc.

[0145] After receiving the above service deployment instruction, the service operation platform 30 creates corresponding microservice instances according to the service configuration files F_A1, F_A2, F_A3, F_B1, F_B2, F_C1, and F_C2, etc. carried therein, as Figure 6 shown.

[0146] Among them, since A1, B1, and C1 are the official versions of the corresponding microservices, there may already be corresponding microservice instances A1, B1, and C1 in the service operation platform 30. In this regard, the service operation platform 30 can update the corresponding microservice instances A1, B1, and C1 through the service configuration files F_A1, F_B1, and F_C1, or create copies of the corresponding microservice instances to ensure that the new microservice instances corresponding to the three microservice versions A1, B1, and C1 all include service proxy components. For the newly added gray versions A2, A3, B2, and C2, the service operation platform 30 can directly create microservice instances according to the corresponding service configuration files.

[0147] In the above embodiments, the service hosting platform adds proxy configuration information to the service configuration file, so that when the service operation platform creates a microservice instance according to the service configuration file, it can set a service proxy component in the microservice instance according to the proxy configuration information. Thus, after each microservice instance is started, the preset proxy functions such as service registration, request routing, and request coloring can be implemented through its service proxy component, thereby assisting each microservice instance to accurately discover the gray version of the next-hop microservice and ensuring the implementation of full-link gray scale.

[0148] Since the discovery of the gray version of the next-hop microservice is implemented through the service proxy component and there is no need to modify the source code of each microservice version, the above embodiments can achieve non-intrusive enhancement of the service discovery logic and meet the non-intrusive requirements of existing services.

[0149] In some embodiments, the microservice instances created in the service operation platform 30 can be containerized instances. Correspondingly, referring to Figure 7 , to implement setting the service proxy component in the microservice instance according to the proxy configuration information in the service configuration file in step S22, the service operation platform 30 performs the following steps:

[0150] Step S2202: Create a corresponding service container group according to the service configuration file. The service container group includes at least one sub-container for executing various functions of the corresponding microservice.

[0151] Step S2204: Add a proxy sub-container to the service container group. The proxy sub-container contains the program file of the service proxy component. The type of the proxy sub-container includes an initialization container, that is, an init Container.

[0152] Step S2206: Copy the program file of the service proxy component stored in the proxy sub-container to a preset data volume.

[0153] Step S2208: Mount the preset data volume to the preset directory of the service container group, so as to call the program file of the service proxy component by accessing the preset data volume.

[0154] In some embodiments, the proxy configuration information added by the service hosting platform 20 to the service configuration file through Step S12 may specifically be instruction codes for setting the service proxy component in the microservice instance. Thus, the service operation platform 30 can implement the above Steps S2202 to S2208 by executing these instruction codes, that is, implement setting the service proxy component in the microservice instance according to the proxy configuration information in the service configuration file.

[0155] The service container group created in the above Step S2202 is the specific manifestation form of the containerized instance. Specifically, a microservice instance can be implemented by a Pod, and each Pod corresponds to an IP address; a Pod can include one or more containers, and these containers share the IP address of the Pod.

[0156] In some embodiments, the above service proxy component may be a proxy component based on the Java language (JavaAgent). Figure 8 The schematic diagram showing the principle of setting the service proxy component in the microservice instance is shown.

[0157] Refer to Figure 8 After creating the service container group (Pod) corresponding to the microservice instance through Step S2202, an initialization container, that is, an init Container, can be added thereto through Step S2204 as a proxy sub-container and store the program file of the service proxy component.

[0158] In some embodiments, the program file of the service proxy component can be directly added to the service configuration file by the service hosting platform 20, so that the service operation platform 30 can directly obtain the program file from the service configuration file. In other embodiments, the program file of the service proxy component can also be stored at a preset address, and only the preset address can be recorded in the service configuration file, so that the service operation platform 30 can obtain the program file through the preset address.

[0159] Continue to refer to Figure 8, in step S2206, the program files of the service proxy component stored in the initialization container can be copied to a preset data volume (Volume) by means of file copying (Copy); then, in step S2208, the preset data volume is mounted under a preset directory of the above-mentioned service container group (Pod) through volume mounting (Mount) technology; furthermore, the program files of the service proxy component can be called by accessing the preset data volume to implement the preset proxy function of the service proxy component.

[0160] Among them, the above-mentioned preset directory can be the working directory " / app" of the service container group, and the Java program corresponding to the service container group is stored under this working directory. Mounting the preset data volume under this working directory facilitates the collaborative work of the Java program corresponding to the service container group and the service proxy component based on the Java language. In addition, through volume mounting technology, the above-mentioned service proxy component can be called, and the logs of the service proxy component can be persistently stored through the preset data volume, so that these logs will not disappear with the deletion of the service container group, which is convenient for long-term monitoring and analysis of each microservice.

[0161] In some embodiments, referring to Figure 9 , when the service hosting platform 20 generates service configuration files for each microservice version through step S12, the following steps can also be executed:

[0162] Step S1202, obtain the current release information; the current release information includes the association relationship between the cluster, lane, microservice name, and microservice version number related to the current release task;

[0163] Step S1204, determine the service attribute information corresponding to each microservice according to the current release information; the service attribute information includes at least one of the microservice name, microservice version number, and the lane to which the microservice belongs;

[0164] Step S1206, add the service attribute information as an environment variable to the service configuration file of the corresponding microservice.

[0165] Correspondingly, as Figure 7 shown, based on the service configuration file obtained in the above step S1206, when the service running platform 30 creates a microservice instance through step S22, in addition to executing steps S2202 to S2208, the following steps can also be executed:

[0166] Step S2210, configure the service attribute information recorded in the service configuration file in the form of an environment variable as the metadata of the corresponding microservice instance.

[0167] In some embodiments, the service hosting platform 20 may interact with users based on its preset user interface, receive configuration information of users for different release tasks, and store this configuration information in the form of release orders or the like. Correspondingly, in step S1022, the service hosting platform 20 may query and obtain the corresponding release information for this time based on this release instruction, such as querying and obtaining the corresponding release order.

[0168] The configuration information related to the release task recorded in the above release information for this time may at least include the microservice name, microservice version number of each microservice involved in the release task for this time, and information such as the cluster and lane to which these microservices belong.

[0169] A cluster is a server system composed of multiple independently working servers. Each server in the same cluster is configured with the same function, so as to increase the number of tasks processed per unit time and thus improve the processing efficiency.

[0170] For a microservices architecture, a cluster is the deployment destination of microservice instances. As Figure 2 shown, two clusters R1 and R2 are deployed in the service operation platform 30; among them, a microservice instance corresponding to a version A1 of microservice A and a microservice instance corresponding to a version B1 of microservice B are respectively deployed in cluster R1; a microservice instance corresponding to a version C1 of microservice C is deployed in cluster R2.

[0171] In addition, in other embodiments, microservice instances corresponding to different versions of the same microservice may be deployed in different clusters; the same version of the same microservice may also be different microservice instances deployed in different clusters respectively. For example, on the basis of Figure 2 shown, another cluster R3 may be set, and a microservice instance corresponding to a version A2 of microservice A may be deployed in this cluster R3, or another microservice instance corresponding to version A1 of microservice A may also be deployed in this cluster R3.

[0172] A lane is a mechanism used to solve the concurrency requirements and stability problems in the testing and deployment processes in a microservices environment. Different lanes may correspond to different running environments, deploy different microservice versions, and implement different call chains.

[0173] Figure 10 shows the logical relationship between different lanes and different versions of different microservices in some embodiments. Refer to Figure 10, three lanes, Lane1, Lane2, and Lane3, can be set for this release task. Among them, the three microservice versions A1, B1, and C1 can be deployed in Lane1; only the two microservice versions A2 and C2 can be deployed in Lane2; and only the two microservice versions A3 and B2 can be deployed in Lane2. Three different call chains can be achieved through the above three lanes. Additionally, as described in the previous embodiments, A1, B1, and C1 are the official versions of the corresponding microservices. Therefore, Lane1 can be configured as the default lane, while Lane2 and Lane3 can be configured as gray-scale lanes because they deploy gray-scale versions of microservices.

[0174] Of course, according to the actual scenario requirements, other gray-scale lanes can also be set. For example, A2 and B2 can be deployed in another lane, so as to verify the compatibility between different versions of different microservices at the same time and improve the efficiency of microservice release and online testing.

[0175] In the above embodiments, the service hosting platform 20 can receive the actual deployment requirements of the user for this release task through its preset user interface, including which cluster and which lane each version of each microservice is deployed in, and use it as the release information for this time. When the service hosting platform 20 executes the release task, it can generate a service configuration file by querying the release information for this time.

[0176] Furthermore, the service running platform 30 can create corresponding microservice instances in the clusters to which the corresponding microservices belong according to each service configuration file, and can obtain the service attribute information corresponding to the microservice (including microservice name, microservice version number, belonging lane, etc.) by identifying the environment variables in the service configuration file, and configure it as the metadata of the microservice instance.

[0177] It can be seen that in the above embodiments, the lane information corresponding to the microservice instance is recorded in the metadata of the finally created microservice instance. Therefore, in the subsequent service discovery process, according to the lane information, it can be ensured that the call chain actually generated by each access request can be consistent with the call chain corresponding to a certain lane, ensuring the implementation of full-link gray scale.

[0178] In some embodiments, as Figure 2 shown, the service running platform 30 may include one or more clusters.

[0179] After the service hosting platform 20 obtains the release information for this time through the above step S1202, the following steps can also be executed:

[0180] Determine the target cluster corresponding to each microservice according to the current release information, and in step S14, send a service deployment instruction including the service configuration file to the target cluster in the service operation platform 30.

[0181] Correspondingly, in step S22, the service operation platform 30 can specifically create microservice instances in the target cluster according to the service configuration file.

[0182] In the case of having multiple clusters, the service hosting platform 20 can send each service configuration file generated by it to the corresponding target cluster by switching sessions with different clusters.

[0183] The above embodiments realize the deployment of microservice instances of each microservice in different clusters and different lanes, which helps to implement the complex logic of related application programs.

[0184] In some embodiments, the service operation platform 30 may include at least one gateway, such as Figure 2 the shown gateways G1 and G2.

[0185] In some embodiments, in the current release information obtained in the above step S1202, it may further include: a preset gray rule corresponding to at least one gateway related to the current release task. Correspondingly, as Figure 5 shown, the service hosting platform 20 may further perform the following steps:

[0186] Step S16, send the preset gray rule recorded in the current release information to the corresponding gateway.

[0187] Furthermore, the service operation platform 30 can perform the following steps through its gateway:

[0188] Step S26, receive the preset gray rule sent by the service hosting platform, and route the third request according to the preset gray rule after receiving the third request.

[0189] An ingress controller is set in the gateway, and it can route the received access requests based on the preset gray rule.

[0190] According to the specific configuration of the ingress controller in the gateway, it may support gray rules based on one or more of the request header (Header), Cookie, and weight, etc.

[0191] Figure 11 Shows a schematic diagram of the principle of configuring the gateway by the service hosting platform 20 and performing request routing through the gateway in some embodiments of this specification.

[0192] Refer toFigure 11 , some gateways can act as "connectors" between the service operation platform 30 and the client, such as gateway G1. When the client sends an access request to the service operation platform 30, it does not need to care about the addresses of each node in the service operation platform 30, but only needs to send the access request to the gateway, and then the gateway routes the access request to the appropriate node (such as a microservice instance) in the service operation platform 30. In addition, some gateways can also act as "connectors" between different service domains (such as different clusters) in the service operation platform 30, such as gateway G2, to implement service calls across service domains (such as the service domains to which microservices A and B belong and the service domain to which microservice C belongs).

[0193] Referring to Figure 11 , the preset gray-scale rule issued by the service hosting platform 20 to gateway G1 can be a weight-based gray-scale rule; for example, for the next node corresponding to this gateway G1, that is, microservice A, based on the weight in the preset gray-scale rule, 80% of the access requests can be routed to the microservice instances corresponding to version A1 of microservice A, 10% of the access requests can be routed to the microservice instances corresponding to version A2 of microservice A, and 10% of the access requests can be routed to the microservice instances corresponding to version A3 of microservice A.

[0194] Continuing to refer to Figure 11 , the preset gray-scale rule issued by the service hosting platform 20 to gateway G2 can be a request-header-based gray-scale rule; that is, gateway G2 needs to perform routing according to the relevant information recorded in the request header of the received request, such as lane information. For example, the microservice instances corresponding to version C2 are deployed in lane Lane2. If the request header of the access request contains the lane information (such as lane ID) of this lane Lane2, gateway G2 will route the request to the microservice instances corresponding to version C2. In addition, version C1, as the official version of microservice C, can be used as the default version. When there is no relevant information in the request header, gateway G2 can route the corresponding request to the default node, that is, route it to the microservice instances corresponding to the default version C1.

[0195] In some embodiments, to implement the above step S26, the service operation platform 30 can perform the following operations through the gateway:

[0196] After receiving the third request, according to the preset gray-scale rule, determine the second target microservice instance corresponding to the third request and the second target lane information corresponding to the second target microservice instance;

[0197] Add the second target lane information to the third request to obtain a fourth request, and send the fourth request to the second target microservice instance.

[0198] That is to say, before the gateway sends a request to the next node, it also colors the request; that is, it adds the corresponding second target lane information to the received third request to generate a fourth request and sends it to the next node, that is, the second target microservice instance.

[0199] In this way, the second target microservice instance can use the second target lane information recorded in the received fourth request as the routing basis to ensure that the access request remains in its corresponding target lane during the full-link call process, or after falling back to the default lane due to the lack of some microservice instances in its target lane, it can be redelivered to the target lane.

[0200] As Figure 11 shown, since there is no microservice instance of microservice B in lane Lane2, the microservice instance corresponding to version A2 routes its request to the microservice instance corresponding to the default version B1. Subsequently, when the request reaches gateway G2, gateway G2 can determine that the second target lane information corresponding to the request is Lane2, add it to the request, and deliver it to lane Lane2, that is, deliver it to the microservice instance corresponding to version C2, rather than the microservice instance corresponding to version C1, so that the call chain generated by the request is A2->B1->C2, which is consistent with the call chain corresponding to its target lane Lane2.

[0201] Figure 12 The signaling diagram shows the implementation of the preset proxy function described in step S24 based on the service proxy component.

[0202] In some embodiments, as Figure 2 and Figure 12 shown, the service operation platform 30 further includes a registration center; based on the service proxy components set in the microservice instances, the service registration of the corresponding microservice instances on the registration center can be realized.

[0203] In some embodiments, referring to Figure 12 , the specific steps for a microservice instance to perform service registration on the registration center through its service proxy component are as follows:

[0204] Step S2402, after the microservice instance is started, its service proxy component adds the metadata of the microservice instance to the service registration request; the metadata includes service attribute information such as microservice name, microservice version number, and the lane it belongs to;

[0205] Step S2404, the service proxy component sends the service registration request to the registration center.

[0206] Correspondingly, the registration center performs the following steps:

[0207] Step S2406: Perform service registration for the corresponding microservice instance according to the service registration request, so as to store the service attribute information corresponding to the corresponding microservice instance in the registration center.

[0208] Refer to together Figure 10 and Figure 12 Taking the service registration of microservice instance B2 as an example, after microservice instance B2 is started, its service proxy component obtains the metadata of microservice instance B2 and adds this metadata to the registration request, and sends it to the registration center, so that the metadata corresponding to this microservice instance B3 is stored in the registration center, including the microservice name (i.e., B) corresponding to microservice instance B2, the microservice version number (i.e., B2), the lane it belongs to (i.e., Lane3), etc.

[0209] In some embodiments, refer to Figure 12 The specific steps for a microservice instance to perform request routing through its service proxy component are as follows:

[0210] Step S2408: After the microservice instance receives the first request, determine the microservice name of the next-hop microservice it needs to call;

[0211] Step S2410: Based on the determined next-hop microservice name, the microservice instance queries and pulls the list of microservice instances corresponding to the next-hop microservice name from the registration center;

[0212] Step S2412: The service proxy component of the microservice instance obtains the first target lane information corresponding to the first request;

[0213] Step S2414: The service proxy component of the microservice instance intercepts the above list of next-hop microservice instances, and filters the list of next-hop microservice instances according to the first target lane information to filter out the microservice instances in the list of next-hop microservice instances that do not match the first target lane information;

[0214] Step S2416: The microservice instance determines the first target microservice instance according to the filtered list of next-hop microservice instances;

[0215] Step S2418: The microservice instance generates a second request and sends the second request to the first target microservice instance.

[0216] Continue to refer to Figure 10 and Figure 12, taking the request routing of microservice instance A3 as an example, after its main program receives the first request, it can determine that the next-hop microservice to be called is microservice B, and then query and pull the list of each microservice instance with the microservice name "B" from the registry, that is, obtain the next-hop microservice instance list. As shown in Table 1 below, the next-hop microservice instance list includes the metadata of each microservice instance of the next-hop microservice B corresponding to microservice instance A3, such as the microservice version number, the lane it belongs to, the network address, etc.

[0217] Table 1 Next-hop microservice instance list corresponding to microservice instance A3

[0218] Microservice Name Microservice Version Number Lane Information Network Address B B1 Lane1 IP_B1 B B2 Lane3 IP_B2

[0219] After the service proxy component in microservice instance A3 monitors that microservice instance A3 receives the first request, it can determine the first target lane information corresponding to the first request, assumed to be Lane3; then, the service proxy component intercepts the above-mentioned next-hop microservice instance list pulled in the main program and filters it, so as to filter out the microservice instances whose lane information is not Lane3, and obtain the filtered next-hop microservice instance list, as shown in Table 2 below.

[0220] Table 2 Filtered next-hop microservice instance list corresponding to microservice instance A3

[0221] Microservice Name Microservice Version Number Lane Information Network Address B B2 Lane3 IP_B2

[0222] Based on the filtered next-hop microservice instance list shown in Table 2 above, the main program of microservice instance A3 can determine that the first target microservice instance to be called is microservice instance B2, and thus can send the second request to it based on its network address being IP_B2.

[0223] In some embodiments, a load balancer can be provided for each microservice instance through a registry, etc., and the main program of the microservice instance can pull the next-hop microservice instance list from the registry through the load balancer. In addition, in the case where the filtered next-hop microservice instance list contains multiple microservice instances, load balancing can also be achieved among the multiple microservice instances based on the load balancer based on preset rules.

[0224] In some embodiments, in order to ensure that the routing information (at least including lane information) can be transmitted in the entire request link, it is necessary to dye the request before sending it to the next-hop microservice instance.

[0225] Refer to Figure 12 , the specific steps for a microservice instance to perform request dyeing through its service proxy component are as follows:

[0226] Step S2420: The service proxy component of the microservice instance injects the determined first target lane information into the system trace information;

[0227] Step S2422: When the microservice instance generates the above-mentioned second request, the service proxy component of the microservice instance adds the first target lane information recorded in the above-mentioned system trace information to the second request.

[0228] In some embodiments, request coloring can be implemented based on the Trace mechanism provided by the Skywalking framework. As Figure 12 shown, still taking the microservice instance A3 as an example, its service proxy component can inject the first target lane information (i.e., Lane3) determined in the above-mentioned step S2412 into the system trace information (i.e., Trace information), and then map the system trace information (i.e., Trace information) to the request header of the second request. Thus, after the second request is sent to the next-hop microservice instance B2, the first target lane information is also passed to the next-hop microservice instance B2.

[0229] It can be seen that in the above embodiments, by implementing service registration through the service proxy component, the microservice name, microservice version number, and the lane to which each microservice instance belongs can be stored in the registration center. Therefore, when other microservices perform service discovery, the list of next-hop microservice instances pulled also contains the lane information corresponding to each microservice instance.

[0230] Furthermore, request routing can be further implemented through the service proxy component to filter out microservice instances in the list of next-hop microservice instances that do not match the target lane information, ensuring that the finally determined next-hop microservice instance (i.e., the target microservice instance corresponding to the current microservice embodiment) matches the target lane information.

[0231] At the same time, request coloring can also be further implemented through the service proxy component to ensure that the target lane information is sent to the next-hop microservice instance along with the access request, thereby expanding the dimension of the link in the gray release from a single cluster to multiple clusters, realizing cross-cluster transfer and full-link transfer of the target lane information, and avoiding the situation where the access request cannot be redelivered to the original gray lane after reverting from the gray lane to the default lane.

[0232] Therefore, based on the service proxy component, the above embodiments can ensure the realization of full-link gray scale; and it is not necessary to modify the source code of the microservice instance, which can meet the non-intrusive requirements of existing services.

[0233] In some embodiments, to obtain the first target lane information corresponding to the first request described in step S2412 above, the service proxy component of the microservice instance may specifically attempt to obtain the above-mentioned first target lane information from different information according to a preset priority rule.

[0234] The sources for obtaining target lane information involved in the above-mentioned preset priority rule, in order of decreasing priority, may successively include: context information corresponding to the first request, the request header of the first request, environment variables or metadata corresponding to the current microservice instance, etc.

[0235] Correspondingly, the specific process for the service proxy component of the microservice instance to obtain the above-mentioned first target lane information is as follows:

[0236] First, obtain the first lane information recorded in the context information corresponding to the first request as the first target lane information;

[0237] In the case where the first lane information does not exist in the context information, obtain the second lane information recorded in the request header of the first request as the first target lane information;

[0238] In the case where the second lane information does not exist in the request header of the first request, obtain the third lane information recorded in the environment variables or metadata corresponding to the current microservice instance as the first target lane information;

[0239] In the case where the third lane information does not exist in the environment variables and metadata corresponding to the current microservice instance, use the default lane information as the first target lane information.

[0240] Combined with the request coloring process described above, it can be seen that the request header of the access request received by the current microservice instance will contain the target lane information added by the microservice instance of the previous node. Therefore, the service proxy component of the current microservice instance can obtain the first target lane information based on the above process, and at least can obtain the first target lane information from the request header of the access request received by the current microservice instance, thus realizing the cross-service transfer and full-link transfer of the target lane information and ensuring the realization of full-link gray scale.

[0241] In addition, through the service registration, request routing, and request coloring implemented based on the service proxy component, combined with Figure 11 and the request routing and request coloring implemented through the gateway described in the relevant embodiments above, it is possible to ensure the full-link transfer of the target lane information, thereby realizing service calls, request distribution, and maintenance across clusters and gateways, and ensuring the realization of full-link gray scale.

[0242] It is understandable that the above embodiments are only examples, and modifications can be made to the above embodiments during actual implementation. Those skilled in the art can understand that any modification method that does not require creative labor falls within the protection scope of one or more embodiments of this specification, and will not be elaborated in the embodiments.

[0243] One or more embodiments of this specification also provide a computer-readable storage medium capable of implementing all the steps in the full-link gray release method or the full-link gray implementation method in the above embodiments. A computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, all the steps in the full-link gray release method or the full-link gray implementation method in the above embodiments are implemented. The specific steps can be referred to the previous embodiments, and will not be elaborated here.

[0244] In addition, one or more embodiments of this specification also provide a computer program product capable of implementing all the steps in the full-link gray release method or the full-link gray implementation method in the above embodiments. The computer program product includes: a computer program or instruction, when the computer program or instruction runs on a computer, the computer is enabled to implement all the steps in the full-link gray release method or the full-link gray implementation method in the above embodiments. The specific steps can be referred to the previous embodiments, and will not be elaborated here.

[0245] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flowcharts, based on routine or non-creative labor, there may be more or fewer operation steps. The order of steps listed in the embodiments is only one way among the execution orders of numerous steps, and does not represent the only execution order. When an actual device or client product is executed, it can be executed in the order of the method shown in the embodiments or the drawings or executed in parallel (for example, in an environment of parallel processors or multi-threaded processing).

[0246] Those skilled in the art should understand that the embodiments of this specification can be provided as a method, a device (system), or a computer program product. Therefore, the embodiments of this specification can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memories, CD-ROMs, optical memories, etc.) containing computer-usable program codes.

[0247] One or more embodiments of the present specification are described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to one or more embodiments of the present specification. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate a device for implementing the functions specified in one process Figure 1 one process or multiple processes and / or blocks Figure 1 or multiple blocks.

[0248] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including an instruction device, and the instruction device implements the functions specified in one process Figure 1 one process or multiple processes and / or blocks Figure 1 or multiple blocks.

[0249] These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operating steps are executed on the computer or other programmable device to generate a computer-implemented process, and thus the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one process Figure 1 one process or multiple processes and / or blocks Figure 1 or multiple blocks.

[0250] Each embodiment in the present specification is described in a progressive manner. For the same or similar parts between each embodiment, reference can be made to each other. The key point of each embodiment is to illustrate the differences from other embodiments. In particular, for the apparatus and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and reference can be made to the corresponding parts of the method embodiments for the relevant content.

[0251] In this document, relational terms such as first and second are used solely to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Also, the terms "comprises," "comprising," or any other variation thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements that are inherent to such process, method, article, or apparatus. For those of ordinary skill in the art, the specific meanings of the above terms in one or more embodiments of this specification can be understood according to specific circumstances.

[0252] It should be noted that, without conflict, the features in one or more embodiments of this specification and the embodiments can be combined with each other. One or more embodiments of this specification are not limited to any single aspect, nor to any single embodiment, nor to any arbitrary combination and / or permutation of these aspects and / or embodiments. Moreover, each aspect and / or embodiment of one or more embodiments of this specification can be used alone or in combination with one or more other aspects and / or their embodiments.

[0253] The above has described one or more embodiments of this specification in combination with optional embodiments, but these embodiments are merely exemplary and only serve an illustrative purpose. On this basis, various substitutions and improvements can be made to one or more embodiments of this specification, and all of these fall within the protection scope of one or more embodiments of this specification.

Claims

1. A full-link grayscale publishing method, characterized in that: Applied to service hosting platforms; The method comprises: In response to the release instruction, generate a corresponding service configuration file for at least one microservice related to the release task, and add proxy configuration information to the service configuration file; Sending a service deployment instruction including the service configuration file to a service operation platform, so that the service operation platform creates a microservice instance of the corresponding microservice according to the service configuration file, and sets a service proxy component in the microservice instance according to the proxy configuration information; The service proxy component is used to execute a preset proxy function after the microservice instance is started, and the preset proxy function includes at least one of service registration, request routing and request coloring related to the microservice instance.

2. The method according to claim 1, characterized in that When generating the service configuration file, the method further includes: Obtain the release information; the release information includes the relationship between the cluster, lane, microservice name and microservice version number related to the release task; Determine the service attribute information corresponding to each of the microservices according to the currently released information; the service attribute information includes at least one of the microservice name, microservice version number and lane to which the corresponding microservice belongs; The service attribute information is added as an environment variable to the service configuration file of the corresponding microservice, so that when the service operation platform creates the corresponding microservice instance according to the service configuration file, the service attribute information recorded in the form of environment variables in the service configuration file is configured as metadata of the corresponding microservice instance.

3. The method according to claim 2, characterized in that Also includes: Determine the target cluster corresponding to each of the microservices according to the published information; The sending of the service deployment instruction containing the service configuration file to the service operation platform includes: A service deployment instruction including a corresponding service configuration file is sent to the target cluster in the service operation platform, so that the service operation platform creates a corresponding microservice instance in the target cluster according to the service configuration file.

4. The method according to claim 2, characterized in that: The current release information also includes: a preset grayscale rule corresponding to at least one gateway related to the current release task; The method further comprises: The preset grayscale rule is sent to a corresponding gateway, so that after receiving the request information, the gateway routes the request information according to the preset grayscale rule.

5. A full-link grayscale implementation method, characterized in that: Applied to the service operation platform; The method comprises: In response to a service deployment instruction including a service configuration file sent by a service hosting platform, a microservice instance is created according to the service configuration file, and a service proxy component is set in the microservice instance according to the proxy configuration information in the service configuration file; After the microservice instance is started, a preset proxy function is executed through the service proxy component; the preset proxy function includes at least one of service registration, request routing and request coloring related to the microservice instance.

6. The method according to claim 5, characterized in that The microservice instance is a containerized instance; creating the microservice instance according to the service configuration file, and setting a service proxy component in the microservice instance according to the proxy configuration information in the service configuration file, includes: Creating a corresponding service container group according to the service configuration file, wherein the service container group includes at least one sub-container for executing various functions of the corresponding microservice; Adding a proxy sub-container to the service container group; the proxy sub-container includes a program file of the service proxy component; the type of the proxy sub-container includes an initialization container; Copying the program file of the preset proxy component stored in the proxy sub-container to a preset data volume; The preset data volume is mounted to a preset directory of the service container group, so as to call the program file of the service proxy component by accessing the preset data volume.

7. The method according to claim 5, characterized in that The service operation platform includes at least one target cluster related to the current release task; The step of responding to a service deployment instruction including a service configuration file sent by a service hosting platform and creating a microservice instance according to the service configuration file comprises: In response to a service deployment instruction including a service configuration file sent by the service hosting platform to any target cluster, a microservice instance is created in the corresponding target cluster according to the service configuration file.

8. The method according to claim 5, characterized in that The service configuration file also includes service attribute information of the corresponding microservice recorded in the form of environment variables; the service attribute information includes at least one of the microservice name, microservice version number and lane to which the corresponding microservice belongs; The method further comprises: When a microservice instance is created according to a service configuration file, the service attribute information recorded in the service configuration file in the form of environment variables is configured as metadata of the microservice instance.

9. The method according to claim 8, characterized in that The service operation platform also includes a registration center; performing service registration in the preset proxy function through the service proxy component includes: The service proxy component adds the metadata to a service registration request and sends the service registration request to the registration center; the metadata includes the service attribute information; The registration center performs service registration for the corresponding microservice instance according to the service registration request, so as to store the service attribute information corresponding to the corresponding microservice instance in the registration center.

10. The method according to claim 9, characterized in that Executing the request routing in the preset proxy function through the service proxy component includes: After the microservice instance receives the first request, the service proxy component in the microservice instance obtains the first target lane information corresponding to the first request, and filters the next-hop microservice instance list according to the first target lane information to filter out the microservice instances in the next-hop microservice instance list that do not match the first target lane information; The microservice instance determines a first target microservice instance according to the filtered list of next-hop microservice instances; The microservice instance generates a second request, and sends the second request to the first target microservice instance.

11. The method according to claim 10, characterized in that The service proxy component obtains first target lane information corresponding to the first request, including: Acquire first lane information recorded in the context information corresponding to the first request as the first target lane information; When the first lane information does not exist in the context information, obtaining the second lane information recorded in the request header of the first request as the first target lane information; When the second lane information does not exist in the request header of the first request, obtaining the third lane information recorded in the environment variable or metadata corresponding to the current microservice instance as the first target lane information; When the third lane information does not exist in the environment variables and metadata corresponding to the current microservice instance, the default lane information is used as the first target lane information.

12. The method according to claim 10 or 11, characterized in that: Executing the request coloring in the preset proxy function by the service proxy component includes: The service proxy component injects the first target lane information into the system tracking information, and when the microservice instance generates the second request, adds the first target lane information recorded in the system tracking information to the second request.

13. The method according to claim 5, characterized in that The service operation platform also includes at least one gateway; The method further comprises: The gateway receives a preset grayscale rule sent by the service hosting platform; After receiving the third request, the gateway routes the third request according to the preset grayscale rule.

14. The method according to claim 13, characterized in that After receiving the third request, the gateway routes the third request according to the preset grayscale rule, including: The gateway determines, according to the preset grayscale rule, a second target microservice instance corresponding to the third request and second target lane information corresponding to the second target microservice instance; The gateway adds the second target lane information to the third request, obtains a fourth request, and sends the fourth request to the second target microservice instance.

15. A microservice system, characterized in that: include: Service hosting platform and service operation platform; The service hosting platform is used to, in response to the current publishing instruction, generate a corresponding service configuration file for at least one microservice related to the current publishing task, add proxy configuration information to the service configuration file, and send a service deployment instruction containing the service configuration file to the service operation platform; The service operation platform is used to create a microservice instance of the corresponding microservice according to the service configuration file, and set a service proxy component in the microservice instance according to the proxy configuration information; The service proxy component is used to execute a preset proxy function after the microservice instance is started, and the preset proxy function includes at least one of service registration, request routing and request coloring related to the microservice instance.

16. The system according to claim 15, characterized in that The microservice instance is a containerized instance; In order to create a microservice instance according to the service configuration file, and set a service proxy component in the microservice instance according to the proxy configuration information in the service configuration file, the service operation platform is also used to perform the following operations: Creating a corresponding service container group according to the service configuration file, wherein the service container group includes at least one sub-container for executing various functions of the corresponding microservice; Adding a proxy sub-container to the service container group; the proxy sub-container includes a program file of the service proxy component; the type of the proxy sub-container includes an initialization container; Copying the program file of the preset proxy component stored in the proxy sub-container to a preset data volume; The preset data volume is mounted to a preset directory of the service container group, so as to call the program file of the service proxy component by accessing the preset data volume.

17. The system according to claim 15, characterized in that The service hosting platform is further configured to perform the following operations when generating the service configuration file: Obtain the release information; the release information includes the relationship between the cluster, lane, microservice name and microservice version number related to the release task; Determine the service attribute information corresponding to each of the microservices according to the currently released information; The service attribute information includes at least one of the microservice name, microservice version number, and lane to which the corresponding microservice belongs; Add the service attribute information as an environment variable to the service configuration file of the corresponding microservice; The service operation platform is also used to configure the service attribute information recorded in the form of environment variables in the service configuration file as metadata of the corresponding microservice instance when creating a microservice instance of the corresponding microservice according to the service configuration file.

18. The system according to claim 17, characterized in that The service operation platform includes at least one cluster; The service hosting platform is further used to determine the target cluster corresponding to each of the microservices according to the currently released information, and after generating the service configuration file corresponding to the microservice, send a service deployment instruction containing the service configuration file to the target cluster in the service operation platform; The service operation platform is also used to create a microservice instance in the target cluster according to the service configuration file in response to a service deployment instruction containing the service configuration file sent by the service hosting platform to the target cluster.

19. The system according to claim 17, characterized in that The service operation platform includes at least one gateway; The current release information also includes: a preset grayscale rule corresponding to at least one gateway related to the current release task; The service hosting platform is also used to send the preset grayscale rules to the corresponding gateway; The gateway is used to receive the preset grayscale rule sent by the service hosting platform, and after receiving the third request, route the third request according to the preset grayscale rule.

20. The system according to claim 19, characterized in that In order to route the third request according to the preset grayscale rule after receiving the third request, the gateway is further configured to perform the following operations: According to the preset grayscale rule, determine the second target microservice instance corresponding to the third request, and the second target lane information corresponding to the second target microservice instance; The second target lane information is added to the third request to obtain a fourth request, and the fourth request is sent to the second target microservice instance.

21. The system according to claim 17, characterized in that The service operation platform also includes a registration center; To implement the service registration in the preset proxy function, the service proxy component is used to, after the corresponding microservice instance is started, add the metadata of the microservice instance to the service registration request, and send the service registration request to the registration center; The metadata includes the service attribute information; The registration center is used to perform service registration on the corresponding microservice instance according to the service registration request, so as to store the service attribute information corresponding to the corresponding microservice instance in the registration center.

22. The system according to claim 21, characterized in that To implement the request routing in the preset proxy function, the service proxy component is further used to: after the corresponding microservice instance receives the first request, obtain the first target lane information corresponding to the first request, and filter the next-hop microservice instance list according to the first target lane information to filter out the microservice instances in the next-hop microservice instance list that do not match the first target lane information; The microservice instance is used to determine a first target microservice instance according to the filtered next-hop microservice instance list, and to generate a second request and send the second request to the first target microservice instance.

23. The system according to claim 22, characterized in that To obtain the first target lane information corresponding to the first request, the service proxy component is further configured to perform the following operations: Acquire first lane information recorded in the context information corresponding to the first request as the first target lane information; When the first lane information does not exist in the context information, obtaining the second lane information recorded in the request header of the first request as the first target lane information; When the second lane information does not exist in the request header of the first request, obtaining the third lane information recorded in the environment variable or metadata corresponding to the current microservice instance as the first target lane information; When the third lane information does not exist in the environment variables and metadata corresponding to the current microservice instance, the default lane information is used as the first target lane information.

24. The system according to claim 22 or 23, characterized in that To implement request coloring in the preset proxy function, the service proxy component is also used to: inject the first target lane information into the system tracking information, and when the microservice instance generates the second request, add the first target lane information recorded in the system tracking information to the second request.

25. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer program instructions, which, when executed, implement the method described in any one of claims 1 to 14.

26. A computer program product, characterized in that The computer program product comprises: a computer program or instructions, and when the computer program or instructions are executed on a computer, the computer is caused to implement the method according to any one of claims 1 to 14.

Images