A micro-service-based full-link gray release method and device, and a storage medium
By parsing the APP identifier in a microservice architecture and utilizing load balancing and canary gateways, the problem that existing canary release schemes cannot meet the needs of complex business and microservices is solved. This achieves efficient forwarding of canary traffic and accurate differentiation of microservices, thereby improving system efficiency.
Patent Information
- Application Number
- CN202310112396.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-02-14
- Publication Date
- 2025-12-12
- Estimated Expiration
- 2043-02-14
AI Technical Summary
Existing canary release solutions cannot meet the complex business traffic splitting requirements and the version iteration requirements of microservice architectures, especially in microservice architectures where separate traffic splitting and canary traffic rollout are not possible.
By parsing the APP identifier of the client APP, and using the load balancing server and the grayscale gateway, it is determined whether the APP identifier meets the grayscale release rules, and the access request is forwarded to the grayscale microservice. Configuration files and grayscale gateway tags are used to achieve efficient traffic forwarding and microservice differentiation.
It achieves accurate separation of canary traffic and normal traffic in a microservice architecture, improves the efficiency of canary releases and system efficiency, and meets the canary release requirements of complex business needs and microservice architecture.
Smart Images

Figure CN116346893B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of distributed computing, in particular to a full-link gray release method and device based on microservices and a storage medium. BACKGROUND
[0002] Gray release refers to, when a software version is iterated, a small part of users use a new software version, and other users continue to use an old version. If the user has no objection to the use of the new version, then the use range is gradually expanded, and all users are migrated to the new software version.
[0003] Most of the current gray implementation schemes simply use nginx or haproxy and the like as a load balancer. Through the reverse proxy capability of the load balancer, user traffic is shunted. When version iteration occurs, the load balancer is configured to distribute traffic to the new version of the service in proportion. After waiting for the new service version to be verified to be correct, the traffic is gradually switched to the new service version.
[0004] The commonly used gray implementation scheme at present is to simply use nginx or haproxy and the like as a load balancer. The load balancer is placed at the upper layer of the application system, and when the user traffic passes through the load balancer, the operation and maintenance personnel set a small part of the traffic to pass through the gray version through the configuration file. When no one feeds back the problem of the gray version, the version of the formal environment is replaced with the new version one by one. The defects are:
[0005] 1. When gray release, the shunting of traffic can only be differentiated according to the percentage of traffic, and cannot be combined with business to do shunting. When a certain app needs to experience the function of changing the back-end service in advance, the APP client of the test version of the gray environment must be provided, and the corresponding users are notified to update the app software synchronously, resulting in poor user experience and weak controllability. In the face of a large number of requirements, this scheme becomes unexecutable.
[0006] 2. In the microservice architecture system, the application is split into multiple services for independent deployment. When a single service is iterated, the load balancer cannot shunt the traffic of the service alone, and the gray traffic under the microservice structure cannot be transmitted.
[0007] In summary, the traditional gray release function in the prior art is relatively single, that is, it cannot meet the complex business shunting requirements, and cannot meet the version iteration requirements of the microservice system. SUMMARY
[0008] The present application proposes the following technical solutions in view of one or more technical defects in the prior art.
[0009] A micro-service-based full-link gray release method, the method comprising:
[0010] A parsing step, the access request sent by the client APP is parsed to obtain the APP identifier of the client APP;
[0011] A load scheduling step, the load scheduling server judges whether the APP identifier meets the gray release rule, if yes, the access request is forwarded to the gray gateway;
[0012] A gray access step, the gray gateway determines at least one gray micro-service in the multiple micro-services accessed by the APP based on the APP identifier, and switches the traffic accessed by the APP to the at least one gray micro-service.
[0013] Further, the operation of parsing the access request is: using luajit to read the header file of the access request to obtain the APP identifier from the header file, if the APP identifier does not exist in the header file, the luajit records the access request in the log and alarms.
[0014] Further, the operation of judging whether the APP identifier meets the gray release rule is: using nginx as a load scheduling server, writing the APP identifier of the client APP needing to access the gray micro-service into a configuration file, and saving the configuration file in the nginx cache, the nginx judges whether the APP identifier of the access request is in the configuration file in the cache, if yes, the access request is forwarded to the gray gateway, otherwise, it is directly forwarded to the production gateway.
[0015] Further, the operation of determining at least one gray micro-service in the multiple micro-services accessed by the APP is: the gray gateway adds a gray gateway label to the access request based on the APP identifier, the gray gateway parses the access request to obtain the function to be implemented by the access request, determines the multiple micro-services to be called based on the function, judges whether there is at least one gray micro-service in the multiple micro-services, if yes, adds the gray label of the gray micro-service in the access request.
[0016] Further, in the access process, the gray micro-service saves the APP identifier as a thread local variable, so that the APP directly selects the gray micro-service when accessing the gray micro-service again based on the APP identifier.
[0017] The application further provides a micro-service-based full-link gray release device, the device comprising:
[0018] An analysis unit analyzes an access request sent by a client APP to obtain an APP identifier of the client APP;
[0019] A load scheduling unit judges whether the APP identifier meets a gray release rule based on the APP identifier, and if so, forwards the access request to the gray gateway;
[0020] A gray access unit determines at least one gray microservice in a plurality of microservices accessed by the APP based on the APP identifier, and switches traffic accessed by the APP to the at least one gray microservice.
[0021] Further, the operation of analyzing the access request is to read a header file of the access request using luajit to obtain the APP identifier from the header file, and if the APP identifier does not exist in the header file, the luajit records the access request in a log and alarms.
[0022] Further, the operation of judging whether the APP identifier meets the gray release rule is to use nginx as a load scheduling server, write an APP identifier of a client APP needing to access a gray microservice into a configuration file, save the configuration file in a cache of the nginx, and judge whether the APP identifier of the access request is in the configuration file in the cache, if so, the access request is forwarded to the gray gateway, otherwise, directly to a production gateway.
[0023] Further, the operation of determining the at least one gray microservice in the plurality of microservices accessed by the APP is to add a gray gateway label to the access request based on the APP identifier by the gray gateway, analyze the access request by the gray gateway to obtain a function to be implemented by the access request, determine a plurality of microservices to be called based on the function, judge whether there is at least one gray microservice in the plurality of microservices, and if so, add a gray label of the gray microservice to the access request.
[0024] Further, in the access process, the gray microservice saves the APP identifier as a thread local variable, so that the APP directly selects the gray microservice based on the APP identifier when the APP accesses the gray microservice again.
[0025] The application further provides a computer readable storage medium, wherein the storage medium stores computer program codes, and the computer program codes are executed by a computer to execute any one of the above methods.
[0026] The technical effect of the present application is that the micro-service-based full-link gray release method, device and storage medium of the present application, the method comprises: a parsing step, the access request sent by the client APP is parsed to obtain the APP identifier of the client APP; a load scheduling step, the load scheduling server judges whether the APP identifier meets the gray release rule, if yes, the access request is forwarded to the gray gateway; a gray access step, the gray gateway determines at least one gray micro-service in the APP access multiple micro-services based on the APP identifier, and switches the traffic accessed by the APP to the at least one gray micro-service. The present application sets the APP identifier in the APP, parses the access request of the APP after receiving the access request, obtains the APP identifier of the client APP, and then the load scheduling server judges whether the APP identifier meets the gray release rule, if yes, the access request is forwarded to the gray gateway, and the gray gateway determines at least one gray micro-service in the APP access multiple micro-services based on the APP identifier, and switches the traffic accessed by the APP to the at least one gray micro-service. Thus, the gray traffic and the normal traffic are separated by load scheduling, and in the subsequent specific access process, since one access may call multiple micro-services, the present application can accurately distinguish the gray released micro-service from the normal micro-service, solve the technical problem that the load balancer cannot perform separate traffic shunting for the service when a single service is iterated in the prior art, and the gray traffic under the micro-service structure cannot be transmitted, so as to meet the complex business requirements and the complex micro-service structure. The present application adopts the configuration file mode, that is, the operation and maintenance personnel directly write the AppCode attribute value of the APP needing to access the gray version into the configuration file, the system reads the content of the configuration file to the nginx cache, the service verifies each http request (that is, the access request), if the AppCode value exists in the cache, the request is transmitted to the gray environment, otherwise, it is directly transmitted to the production environment. In this way, the efficient forwarding of the APP gray traffic is improved, and the system efficiency is improved. BRIEF DESCRIPTION OF DRAWINGS
[0027] Other features, objects, and advantages of the present application will become more apparent from the following detailed description of non-limiting embodiments made with reference to the accompanying drawings.
[0028] Figure 1 is a flowchart of a micro-service-based full-link gray release method according to an embodiment of the present application.
[0029] Figure 2 is a structural diagram of a micro-service-based full-link gray release device according to an embodiment of the present application. DETAILED DESCRIPTION
[0030] The application will be described in further detail below with reference to the drawings and embodiments. It is to be understood that the specific embodiments described herein are merely illustrative of the application and are not intended to limit the scope of the application. In addition, it should be noted that only parts related to the application are shown in the drawings for ease of description.
[0031] It should be noted that the embodiments in the present application and the features in the embodiments can be combined with each other without conflict. The present application will be described in detail below with reference to the drawings and embodiments.
[0032] Figure 1 A micro-service-based full-link gray release method of the application is shown, which comprises:
[0033] In the parsing step S101, the access request sent by the client APP is parsed to obtain the APP identification of the client APP. The APP identification can be used to identify and mark the access request of the client APP of the application, for example, in the development process of the client APP, each APP can define its own unique AppCode (the meaning of appCode: one appCode represents a unique client APP in the system, and has a unique identification for the client APP). In the request process, the appCode will be transmitted in the access request header. If it is H5, the appCode will be used to generate a cookie, and the cookie will be transmitted to the server. The parsing operation can be performed on the load scheduling server, or a special parsing server can be set to perform the corresponding parsing operation.
[0034] In the load scheduling step S102, the load scheduling server determines whether the APP identification meets the gray release rule based on the APP identification. If yes, the access request is forwarded to the gray gateway.
[0035] In the gray access step S103, the gray gateway determines at least one gray micro-service in the multiple micro-services accessed by the APP based on the APP identification, and switches the traffic accessed by the APP to the at least one gray micro-service.
[0036] The application sets an APP identifier in the APP, parses the access request after receiving the access request of the APP to obtain the APP identifier of the client APP, and then the load scheduling server judges whether the APP identifier meets the gray release rule, if yes, the access request is forwarded to the gray gateway, the gray gateway determines at least one gray microservice in the APP access multiple microservices based on the APP identifier, and switches the traffic accessed by the APP to the at least one gray microservice. Thus, the gray traffic is separated from the normal traffic by load scheduling, and in the subsequent specific access process, since one access may call multiple microservices, the gray released microservice and the normal microservice can be accurately distinguished in the application, the technical problem that the load balancer cannot perform separate traffic shunting for the service when the single service is iterated in the prior art, and the gray traffic under the microservice structure cannot be transmitted is solved, so that the complex business requirements and the complex microservice structure can be met, which is an important embodiment of the application.
[0037] In one embodiment, the operation of parsing the access request is to read the header file of the access request using luajit to obtain the APP identifier from the header file, and if the APP identifier does not exist in the header file, the luajit records the access request in a log and alarms. In the application, luajit can be integrated in nginx as a load balancing server, luajit can realize the monitoring function of http request, the monitoring service reads all the headers of http request through nginx, the request transmitted by the client must contain AppCode attribute, when the AppCode does not exist in the header, the request is recorded in the specified log file. The alarm service detects the change of the log file, and notifies the added abnormal request through the form of email, short message and the like.
[0038] In one embodiment, the operation of judging whether to comply with the gray release rule is: using nginx as a load scheduling server, writing the APP identifier of the client APP needing to access the gray microservice into a configuration file, and saving the configuration file in the nginx cache, the nginx judges whether the APP identifier of the access request is in the configuration file in the cache, if yes, the access request is forwarded to the gray gateway, otherwise, it is directly forwarded to the production gateway. In the application, for how to proxy traffic to the gray version, the application adopts the configuration file mode, that is, the operation and maintenance personnel directly write the AppCode attribute value needing to access the gray version into the configuration file, the system reads the content of the configuration file to the nginx cache, the service verifies each http request (that is, access request), if the AppCode value exists in the cache, the request is transmitted to the gray environment, otherwise, it is directly transmitted to the production environment, in this way, the efficient forwarding of APP gray traffic is improved, the system efficiency is improved, which is an important application point of the application.
[0039] In one embodiment, the operation of determining that the APP accesses at least one gray microservice in the plurality of microservices is: the gray gateway adds a gray gateway label to the access request based on the APP identifier, the gray gateway parses the access request to obtain the function to be implemented by the access request, determines the plurality of microservices to be called based on the function, and judges whether there is at least one gray microservice in the plurality of microservices, if yes, adds the gray label of the gray microservice to the access request.
[0040] In the application, when the backend gateway (that is, the gateway connecting the server of the microservice, that is, the gray gateway) starts, the corresponding formal label (A) and gray label (B) are applied to the architecture parameter in the dubbo consumer application of the gateway, when the http request is proxied to the backend gateway, at this time, the same label microservice provider is selected by the custom dubbo gray load balancing according to the gateway label of the request, and then the label is transmitted to the microservice through the dubbo Attachment build label. In the application, the gray gateway parses the access request to obtain the function to be implemented by the access request, determines the plurality of microservices to be called based on the function, judges whether there is at least one gray microservice in the plurality of microservices, if yes, adds the gray label of the gray microservice to the access request, the gray microservice to be accessed can be accurately determined through the function to be called, so as to forward the traffic to the microservice to be accessed, save the system resources, and improve the gray release efficiency, which is an important application point of the application.
[0041] In one embodiment, during the access process, the gray microservice saves the APP identifier as a thread local variable, so that when the APP accesses the gray microservice again, the gray microservice is directly selected based on the APP identifier. That is, the microservice stores this identifier as a thread local variable, and the next time a dubbo request is initiated, it will go through the custom dubbo gray load balancing again to preferentially select the microservice with the same label. The access speed is improved.
[0042] Figure 2 The application shows a microservice-based full-link gray publishing device of the application, which comprises:
[0043] The analysis unit 201 analyzes the access request sent by the client APP to obtain the APP identifier of the client APP. The APP identifier can be used to identify and mark the access request of the client APP of the application. For example, during the development of the client APP, an AppCode (the meaning of appCode: one appCode represents a unique client APP in the system, and has a unique identifier for the client APP) specific to each APP is defined. During the request process, the appCode is transmitted in the access request header. If it is H5, the appCode is used to generate a cookie, and the cookie is transmitted to the server. The analysis operation can be performed on the load scheduling server, or a dedicated analysis server can be set up to perform the corresponding analysis operation.
[0044] The load scheduling unit 202 judges whether the APP identifier meets the gray publishing rule based on the APP identifier. If yes, the access request is forwarded to the gray gateway.
[0045] The gray access unit 203 determines at least one gray microservice in the multiple microservices accessed by the APP based on the APP identifier, and switches the traffic accessed by the APP to the at least one gray microservice.
[0046] The application sets an APP identifier in the APP, parses the access request after receiving the access request of the APP to obtain the APP identifier of the client APP, and then the load scheduling server judges whether the APP identifier meets the gray release rule, if yes, the access request is forwarded to the gray gateway, the gray gateway determines at least one gray microservice in the APP access multiple microservices based on the APP identifier, and switches the traffic accessed by the APP to the at least one gray microservice. Thus, the gray traffic is separated from the normal traffic by load scheduling, and in the subsequent specific access process, since one access may call multiple microservices, the gray released microservice and the normal microservice can be accurately distinguished in the application, the technical problem that the load balancer cannot perform separate traffic shunting for the service when the single service is iterated in the prior art, and the gray traffic under the microservice structure cannot be transmitted is solved, so that the complex business requirements and the complex microservice structure can be met, which is an important embodiment of the application.
[0047] In one embodiment, the operation of parsing the access request is to read the header file of the access request by using luajit to obtain the APP identifier from the header file, if the APP identifier does not exist in the header file, the luajit records the access request in a log and alarms. In the application, luajit can be integrated in nginx as a load balancing server, luajit can realize the monitoring function of http request, the monitoring service reads all the headers of http request through nginx, the request transmitted by the client must contain AppCode attribute, when the AppCode does not exist in the header, the request is recorded in the specified log file. The alarm service detects the change of the log file, and notifies the added abnormal request by mail, short message and the like.
[0048] In one embodiment, the operation of judging whether to comply with the gray release rule is: using nginx as a load scheduling server, writing the APP identifier of the client APP needing to access the gray microservice into a configuration file, and saving the configuration file in the nginx cache, the nginx judges whether the APP identifier of the access request is in the configuration file in the cache, if yes, the access request is forwarded to the gray gateway, otherwise, it is directly forwarded to the production gateway. In the application, for how to proxy traffic to the gray version, the application adopts the configuration file mode, that is, the operation and maintenance personnel directly write the AppCode attribute value needing to access the gray version into the configuration file, the system reads the content of the configuration file to the nginx cache, the service verifies each http request (that is, access request), if the AppCode value exists in the cache, the request is transmitted to the gray environment, otherwise, it is directly transmitted to the production environment, in this way, the efficient forwarding of APP gray traffic is improved, the system efficiency is improved, which is an important application point of the application.
[0049] In one embodiment, the operation of determining that the APP accesses at least one gray microservice in the plurality of microservices is: the gray gateway adds a gray gateway label to the access request based on the APP identifier, the gray gateway parses the access request to obtain the function to be implemented by the access request, determines the plurality of microservices to be called based on the function, and judges whether there is at least one gray microservice in the plurality of microservices, if yes, adds the gray label of the gray microservice to the access request.
[0050] In the application, when the backend gateway (that is, the gateway connecting the server of the microservice, that is, the gray gateway) starts, the corresponding formal label (A) and gray label (B) are applied to the architecture parameter in the dubbo consumer application of the gateway, when the http request is proxied to the backend gateway, at this time, the same label microservice provider is selected by the custom dubbo gray load balancing according to the gateway label of the request, and then the label is transmitted to the microservice through the dubbo Attachment build label. In the application, the gray gateway parses the access request to obtain the function to be implemented by the access request, determines the plurality of microservices to be called based on the function, judges whether there is at least one gray microservice in the plurality of microservices, if yes, adds the gray label of the gray microservice to the access request, the gray microservice to be accessed can be accurately determined through the function to be called, so as to forward the traffic to the microservice to be accessed, save the system resources, and improve the gray release efficiency, which is an important application point of the application.
[0051] In one embodiment, during the access process, the gray microservice saves the APP identifier as a thread local variable, so that when the APP accesses the gray microservice again, the gray microservice is directly selected based on the APP identifier. That is, the microservice stores this identifier as a thread local variable, and the next time a dubbo request is initiated, it will go through the custom dubbo gray load balancing again to preferentially select the microservice with the same label. The access speed is improved.
[0052] For the convenience of description, the above device is described as various units in function. Of course, the functions of each unit can be implemented in the same or multiple software and / or hardware when implementing the present application.
[0053] From the description of the above embodiments, those skilled in the art can clearly understand that the present application can be implemented by means of software and the necessary general hardware platform. Based on this understanding, the technical solutions of the present application can be embodied in the form of a software product, which can be stored in a storage medium such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the apparatus described in various embodiments or some parts of the embodiments of the present application.
[0054] Finally, it should be pointed out that: the above embodiments are only for illustration and not limitation of the technical solutions of the present application. Although the present application has been described in detail with reference to the above embodiments, those skilled in the art should understand that the present application can still be modified or replaced equivalently without departing from the spirit and scope of the present application. Any modification or partial replacement should be covered in the scope of the claims of the present application.
Claims
1. A method for full-link gray release based on microservices, characterized in that, The method comprises: The parsing step, the access request sent by the client APP is parsed to obtain the APP identification of the client APP; The load scheduling step, the load scheduling server judges whether the APP identification meets the gray release rule, if yes, the access request is forwarded to the gray gateway; The gray access step, the gray gateway determines at least one gray microservice in the APP access multiple microservices based on the APP identification, and switches the traffic accessed by the APP to the at least one gray microservice, wherein the operation of determining at least one gray microservice in the APP access multiple microservices based on the APP identification comprises: The gray gateway adds a gray gateway label to the access request based on the APP identification, and the gray gateway parses the access request to obtain the function required by the access request, determines the multiple microservices required to be called based on the function, specifically comprising: preferentially selecting the microservice provider with the same label through the gray load balancing of the custom dubbo according to the gray gateway label, and transmitting the label to the microservice through the Attachment of the dubbo; Determine whether there is at least one gray microservice in the multiple microservices, if yes, add the gray label of the gray microservice in the access request.
2. The method of claim 1, wherein, The operation of parsing the access request is to read the header file of the access request using luajit to obtain the APP identification from the header file, if there is no APP identification in the header file, the luajit records the access request in the log and alarms.
3. The method of claim 2, wherein, The operation of judging whether the gray release rule is met is to use nginx as a load scheduling server, write the APP identification of the client APP accessing the gray microservice into a configuration file, save the configuration file in the nginx cache, and the nginx judges whether the APP identification of the access request is in the configuration file in the cache, if yes, the access request is forwarded to the gray gateway, otherwise, it is directly forwarded to the production gateway.
4. The method of claim 1, wherein, In the access process, the gray microservice saves the APP identification as a thread local variable, so that the APP directly selects the gray microservice when accessing the gray microservice again based on the APP identification.
5. A micro-service-based full-link gray release device, characterized in that, The device comprises: The parsing unit parses the access request sent by the client APP to obtain the APP identification of the client APP; The load scheduling unit, the load scheduling server judges whether the APP identification meets the gray release rule based on the APP identification, if yes, the access request is forwarded to the gray gateway; The gray access unit, the gray gateway determines at least one gray microservice in the APP access multiple microservices based on the APP identification, and switches the traffic accessed by the APP to the at least one gray microservice, wherein the operation of determining at least one gray microservice in the APP access multiple microservices based on the APP identification comprises: The gray gateway adds a gray gateway label to the access request based on the APP identifier, parses the access request to obtain a function that needs to be implemented by the access request, determines a plurality of microservices that need to be called based on the function, and specifically comprises: preferentially selecting a microservice provider with the same label through gray load balancing of a custom dubbo according to the gray gateway label, and transmitting the label to the microservice through Attachment of the dubbo; It is judged whether there is at least one gray microservice in the plurality of microservices, and if so, a gray label of the gray microservice is added to the access request.
6. The apparatus of claim 5, wherein, The operation of parsing the access request is to read a header file of the access request using luajit to obtain the APP identifier from the header file, and if there is no APP identifier in the header file, the luajit records the access request in a log and alarms.
7. The apparatus of claim 6, wherein, The operation of judging whether it conforms to the gray release rule is to use nginx as a load scheduling server, write an APP identifier of a client APP that needs to access a gray microservice into a configuration file, save the configuration file in the nginx cache, and judge whether the APP identifier of the access request is in the configuration file in the cache. If yes, the access request is forwarded to the gray gateway, otherwise it is directly forwarded to the production gateway.
8. A computer-readable storage medium, the storage medium storing computer program code, when the computer program code is executed by a computer, the method of any one of claims 1-4 is executed.
Citation Information
Patent Citations
Stream cutting method and device based on gray release and storage medium
CN114443125A
Micro-service gray release method, device and system, storage medium and electronic equipment
CN115314547A