Service gray release method, system and device and readable storage medium

Abstract

The invention relates to the technical field of gray release, in particular to a service gray release method, system and device and a readable storage medium, and the method comprises the steps: receiving a service request from a user, and obtaining a service identifier through analyzing the service request, the service identifier being used for identifying a background service for processing the service request; a service routing identifier is obtained from user configuration, the service routing identifier is a set of version identifiers preset based on user attributes, and the version identifiers are used for indicating a to-be-called service version; and searching routing information corresponding to a target service instance according to the service identifier and the service routing identifier, and forwarding the service request to the target service instance according to the routing information. According to the method, service gray release with controllable granularity is realized, the client operation is not influenced, and the user experience is improved.

Description

Technical Field

[0001] The present invention relates to the field of grayscale publishing technology, and in particular to a service grayscale publishing method, system, device and readable storage medium. Background Art

[0002] The civil aviation industry is one of the earliest fields to apply information technology. Airlines, agents, and airports around the world access the civil aviation information system through various front-end systems to process their business. With the rapid development of the civil aviation industry and the rapid growth of civil aviation passengers, the civil aviation information system has developed into a distributed system composed of various front-end and back-end services, and the various components of the civil aviation information system have developed independently while maintaining the basic stability of the interface.

[0003] Due to the development and progress of computer technology, many civil aviation information systems that use old technology and old equipment need to be transformed into new version systems that use new technology and new equipment. There are also many legacy systems that need to be replaced by completely rebuilt new version systems. Or, due to new business needs, old version systems also need to be upgraded to new version systems that support new functions or enhance the original functions.

[0004] The main technologies for replacing the old version system with the new version system are:

[0005] Full release: Through a single change, all users can use the services of the new version system. If there are problems with the new version system, it may affect all users.

[0006] Full upgrade: All components of the system are upgraded from the old version to the new version at one time by upgrading in place. If the new version system has problems that seriously affect users, the new version system needs to be rolled back to the old version before the upgrade. The advantage of a full upgrade is that if the upgrade is successful, the system can be upgraded to the new version at one time, and no additional software and hardware resources are required to deploy the new version system. However, a full upgrade requires system downtime, and the recovery time required when the system fails is long. Users are affected in a wide range and for a long time. A full upgrade is the most risky release method and is usually not used in the actual production environment of large systems that require 7*24 hours of continuous operation;

[0007] Full switch: also known as blue-green release, it is to directly deploy the new version system by preparing another set of software and hardware resources, and use the cutover method to migrate all users and user traffic from the old version system to the new version system. While the old version system remains running, if the new version system has problems that seriously affect users, all users and user traffic can be quickly migrated back to the old version system. Full switch improves service availability. The recovery time required when the system fails is shorter than that of a full upgrade, and users are affected for a shorter time, but the scope of users affected is still wide. Since there is an old version system as a backup, the risk of full switch is significantly lower than that of a full upgrade. However, after all, it involves all users, and there is still the problem of a large user impact range. In addition, full switch requires additional software and hardware resource investment, and the cost can be up to twice that of a full upgrade;

[0008] Grayscale release: The system is gradually upgraded from the old version to the new version in a smooth transition. During the transition period, some users use the new system, while the rest of the users still use the old system. By gradually expanding the scope, all users will eventually be migrated to the new system. Grayscale release can significantly reduce the impact of problems in the new system on users and ensure the overall stability of the system.

[0009] Among them, grayscale release can be divided into the following three categories:

[0010] Grayscale release from the perspective of backend services: It is an improvement on full upgrade. First, upgrade one instance of the service (such as a single server, or POD or container in the Paas cloud platform). If there is no problem with the instance, then upgrade all or batches of the remaining instances. If there is a problem, roll back or isolate the instance immediately. Grayscale releases in the general sense belong to this category, such as canary release and rolling release. Specifically, canary release upgrades one instance first. If there is no problem with the instance, all the remaining instances are upgraded at once. Rolling release is an improvement and optimization of canary release. First, upgrade one instance. If there is no problem with the instance, release the remaining instances in multiple batches. Observe after each batch is released. If there is a problem, roll back or isolate the problematic instance immediately. Compared with full upgrade, grayscale release from the perspective of backend services greatly reduces security risks and shortens fault recovery time. Grayscale release from the perspective of backend services considers the problem completely from the perspective of service providers. Since the upgraded new version system does not control or cannot control the user's traffic, the scope of users affected cannot be controlled. In extreme cases, a large range of users will still be affected.

[0011] Grayscale release based on user traffic ratio: This is an improvement on full switch. First, a small amount of user traffic is switched to the new version system. If the system performs normally, the traffic ratio switched to the new version system is gradually increased in batches, and finally all user traffic is switched to the new version system. After each batch of traffic is switched, the operation of the new version system is observed. If there is a problem, all or part of the switched traffic is quickly migrated from the new version system back to the old version system according to the specific situation. Grayscale release based on user traffic ratio focuses on the user side, focusing only on the ratio of the total user traffic flowing to the new version system, but does not control the specific users, and therefore cannot control the scope of users affected. In extreme cases, a larger range of users will still be affected;

[0012] Grayscale release based on the new version of the client: The new and old versions of the system run in parallel. The old version of the client can only access the old version of the system, and the new version of the client can only access the new version of the system. By promoting the new version of the client and gradually increasing the number of users of the new version of the system and reducing the number of users of the old version of the system, when a blocking problem occurs in the new version of the system, users can use the old version of the client to access the old version of the system to complete business processing. When all users of the old version of the client switch to the new version of the client, the new version of the system completely replaces the old version of the system. Grayscale release based on the new version of the client can accurately control the scope of users affected, but the promotion process requires user cooperation, the promotion cycle is very long, the promotion cost is very high, and the service provider cannot freely control the switching progress.

[0013] Therefore, the prior art lacks a grayscale release method for civil aviation information system services with controllable release granularity and controllable user impact range. Summary of the invention

[0014] The present invention aims to provide a service grayscale release method, system, device and readable storage medium to achieve granularity-controllable system service grayscale release.

[0015] To achieve the above object, the present invention provides the following technical solutions:

[0016] A service grayscale release method, applied to a server, comprising:

[0017] Receiving a service request from a user, and obtaining a service identifier by parsing the service request, wherein the service identifier is used to identify a background service that processes the service request;

[0018] Acquire a service routing identifier from the user configuration, where the service routing identifier is a set of version identifiers pre-set based on user attributes, and the version identifier is used to indicate a service version to be called;

[0019] The routing information corresponding to the target service instance is searched according to the service identifier and the service routing identifier, and the service request is forwarded to the target service instance according to the routing information.

[0020] Furthermore, the service routing identifier is stored in the form of a binary bitmap.

[0021] Furthermore, the service routing identifier includes a plurality of identification bits for controlling background services;

[0022] The version identifier is a binary value of the identification bit, and the binary value of the identification bit corresponds to the service version to be called.

[0023] Furthermore, the service version to be called is a running version of a background service that processes the business request.

[0024] Furthermore, the method further comprises:

[0025] The service routing identifier is modified in the user configuration to switch the service version to be called.

[0026] Further, the modifying the service routing identifier in the user configuration includes:

[0027] Modify the service routing identifier as a whole;

[0028] Alternatively, the binary value of the identification bit in the service routing identifier is modified.

[0029] Further, searching for routing information corresponding to the target service instance according to the service identifier and the service routing identifier, and forwarding the service request to the target service instance according to the routing information, includes:

[0030] Searching for routing information corresponding to the target service instance from a preset routing rule set according to the service identifier and the business routing identifier, wherein the routing information is used to call the target service instance;

[0031] If routing information corresponding to the target service instance exists in the routing rule set, forwarding the service request to the target service instance according to the routing information;

[0032] If there is no routing information corresponding to the target service instance in the routing rule set, the service request is discarded.

[0033] Furthermore, the target service instance is an instance of the service version to be called in the background service that processes the business request.

[0034] Furthermore, before obtaining the service routing identifier from the user configuration, the following steps are also included:

[0035] Perform security authentication on user login information;

[0036] After the security authentication is passed, the user configuration is obtained from the configuration database.

[0037] Furthermore, before obtaining the service routing identifier from the user configuration, the following steps are also included:

[0038] Load the user configuration into cache.

[0039] A service grayscale release system, comprising:

[0040] A request parsing module, used to receive a service request from a user, and obtain a service identifier by parsing the service request, wherein the service identifier is used to identify a background service that processes the service request;

[0041] A service acquisition module, used to acquire a service routing identifier from a user configuration, wherein the service routing identifier is a set of version identifiers pre-set based on user attributes, and the version identifier is used to indicate a service version to be called;

[0042] The request forwarding module is used to search for routing information corresponding to the target service instance according to the service identifier and the business routing identifier, and forward the business request to the target service instance according to the routing information.

[0043] Based on the same inventive concept, an electronic device is also provided, including: a memory and a processor; the processor is used to read and execute a computer program stored in the memory to implement the aforementioned service grayscale release method.

[0044] Based on the same inventive concept, an embodiment of the present invention further provides a computer storage medium, wherein the computer storage medium stores computer executable instructions, and the computer executable instructions can implement the aforementioned service grayscale release method when executed.

[0045] Technical effects and advantages of the present invention:

[0046] (1) Set the service routing identifier according to the user attributes and load the service routing identifier into the user configuration, so as to route different users' requests for the same backend service to instances of different service versions for processing, and control user traffic diversion on the server side;

[0047] (2) The granularity of service grayscale release is fully controllable, and it also supports rapid switching back when problems occur in the version providing the service, and the scope of user impact is fully controllable;

[0048] (3) This method is applied on the server side, does not affect the client operation, and improves the user experience.

[0049] Other features and advantages of the present invention will be described in the following description, and partly become apparent from the description, or understood by practicing the present invention. The purpose and other advantages of the present invention can be realized and obtained by the structures pointed out in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0051] Figure 1 A flow chart of a method for grayscale publishing of services provided by an embodiment of the present invention;

[0052] Figure 2 A schematic diagram of the principle of the service grayscale release method provided by an embodiment of the present invention;

[0053] Figure 3 A schematic diagram of a workflow of a routing engine processing a user request in an embodiment of the present invention;

[0054] Figure 4 A schematic diagram of the structure of a service grayscale publishing system provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0055] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0056] like Figure 1 As shown, the present invention discloses a service grayscale publishing method, which is applied to a server side and includes the following steps:

[0057] Step S1: receiving a service request from a user, and obtaining a service identifier by parsing the service request, wherein the service identifier is used to identify a background service that processes the service request;

[0058] Step S2: Obtain a service routing identifier from the user configuration, where the service routing identifier is a set of version identifiers preset based on user attributes, and the version identifier is used to indicate a service version to be called;

[0059] Step S3: searching for routing information corresponding to the target service instance according to the service identifier and the service routing identifier, and forwarding the service request to the target service instance according to the routing information.

[0060] In an embodiment of the present invention, user configuration is a collection of user attributes, a service routing identifier is a user attribute in the user configuration, and a service routing identifier pre-set based on other user attributes includes multiple version identifiers, and the version identifier is used to indicate the service version to be called, and the service version is a running version of the background service that processes the business request. In this embodiment, requests from different users for the same background service are routed to instances of different service versions for processing according to the service routing identifier, thereby realizing batch diversion processing of user requests. This method is applied to the server side, and during the grayscale release of the service, the client does not perceive the release process and does not affect the client operation, thereby improving the user experience, and the granularity of the grayscale release of the service provided by the present invention is fully controllable.

[0061] exist Figure 2 In the schematic diagram of the service grayscale release principle shown:

[0062] User front end: The client, browser or front-end system used to access information system services.

[0063] The user initiates a business request through the user front end. Specifically, the user logs in to the business system of a specific scenario through the app or web to initiate a business request. A business request refers to a business request corresponding to a business function initiated by the user in different business scenario systems according to needs.

[0064] Access server: The boundary of the information system, used to receive business requests from the user front end, generate a transaction serial number to identify the business request, send the business request to the routing engine, and return the business response forwarded by the routing engine to the user front end. Users need to pass identity authentication before they can actually establish a connection with the access server and then access system services through the access server.

[0065] Routing engine: used to receive service requests from access servers, determine service parameters by parsing service requests, the service parameters include service identifiers, and determine the background service and service version for processing the service request according to the service identifier and the service routing identifier obtained from the user configuration according to the matching routing rules, and then forward the service request to the instance of the background service of the corresponding version.

[0066] Among them, the access server and routing engine are the entrances of all user traffic, and are the bridge and link between the user front end and various back-end services. At the traffic entrance, the routing engine is used to accurately control the flow of user traffic. The routing engine is the core component for realizing the business routing function.

[0067] User configuration: is a collection of user attributes, stored in a configuration file or configuration database. Service routing identifier is a user attribute in user configuration.

[0068] User configuration cache: used to cache user configurations and store them in shared memory to improve access speed.

[0069] Management console: used to modify the business routing identifier in the user configuration. The business routing identifier can be modified as a whole, or the version identifier can be modified. The modification of the business routing identifier is applied to the user configuration database (or configuration file) and user configuration cache at the same time.

[0070] The grayscale publishing method provided by the embodiment of the present invention comprises the following steps:

[0071] 1. Perform security authentication on user login information;

[0072] 2. After the security authentication is passed, the access server receives the service request from the user and sends the service request to the routing engine;

[0073] 3. The routing engine obtains a service identifier by parsing the service request, where the service identifier is used to identify the background service that processes the service request;

[0074] 4. The routing engine obtains the user configuration from the configuration database and loads the user configuration into the user configuration cache;

[0075] 5. The routing engine obtains the service routing identifier from the user configuration;

[0076] 6. The routing engine searches for routing information corresponding to the target service instance according to the service identifier and the business routing identifier, and forwards the business request to the target service instance according to the routing information;

[0077] 7. The routing engine receives the service response generated by the target service instance processing the service request and returns it to the user front end.

[0078] In the embodiment of the present invention, the service routing identifier is a set of version identifiers preset based on user attributes, and preferably, the service routing identifier is stored in the form of a binary bitmap. A bitmap is a data structure composed of binary bits.

[0079] The business routing identifier includes multiple identification bits for controlling background services, each identification bit controls a background service and its service version, and the binary value of the identification bit is used as the version identifier. The version identifier determines the service version to be called, and the service version to be called is a running version of the background service that processes the business request. The binary value of the identification bit corresponds to the different service versions of the background service controlled by the identification bit.

[0080] In an embodiment of the present invention, service requests of different users for the same background service are forwarded to instances of different service versions of the background service based on the service routing identifier. The service routing identifier is a user attribute in the user configuration. In actual applications, the service routing identifier of a single user can be personalized as needed, so as to select users and user traffic that need to switch to other versions of background services at different granularities, and accurately control the user range of the grayscale release of the service. For example, the service routing identifier can be set for one user, several users, users with the same service (specified by certain service parameters that meet specific conditions, such as users from airlines coded as CA) or all users.

[0081] In the embodiment of the present invention, the routing engine serves all the background services. When the background service is upgraded or the background service is migrated from the old system to the new system, there will be multiple versions running at the same time and providing services to the outside world. Generally, different versions of the background service are regarded as different background services. After the routing engine matches the routing rules according to the service identifier and the business routing identifier, it forwards the business requests of different users for the same background service to different versions of the background service according to the corresponding routing rules, thereby realizing the batch diversion of users. The routing engine can provide support for all background services with granular and controllable grayscale release requirements.

[0082] The routing engine searches for routing information corresponding to the target service instance according to the service identifier and the business routing identifier, and forwards the business request to the target service instance according to the routing information, including:

[0083] According to the service identifier and the business routing identifier, corresponding routing information is searched from a preset routing rule set, wherein the routing information is used to call a target service instance; the target service instance is an instance of a service version to be called in a background service that processes the business request;

[0084] If routing information corresponding to the target service instance exists in the routing rule set, forwarding the service request to the target service instance according to the routing information;

[0085] If the routing information corresponding to the target service instance does not exist in the routing rule set, the service request is discarded, an error prompt is returned, and an error log is output.

[0086] like Figure 3 As shown, the workflow of the routing engine processing user requests is as follows:

[0087] 1. After loading the routing rule set and user configuration, read the routing rule set and user configuration;

[0088] User configuration is a collection of user attributes, and a business routing identifier is a type of user attribute. A routing rule set contains a series of routing rules, and the routing conditions of a routing rule contain routing conditions corresponding to business parameters and may also contain routing conditions corresponding to business routing identifiers.

[0089] 2. Receive and analyze the user's business request and determine the business parameters;

[0090] The business parameter includes a service identifier, and the service identifier is used to identify a background service that processes a business request.

[0091] 3. Traverse the routing rules in the routing rule set, and determine the routing rule that matches the business request based on the business parameters and business routing identifier;

[0092] Only when all routing conditions related to business parameters and business routing identifiers are met can the corresponding routing rules be matched. The routing conditions related to business parameters determine the background service that processes the business request, and the routing conditions related to the business routing identifier determine the version of the background service. The matched routing target reflects both the background service and the service version.

[0093] 4. If the routing rule matches successfully, the business request is forwarded to the routing target determined by the routing rule, that is, forwarded to the instance of the service version of the background service that processes the business request, which is determined by the business parameters and the business routing identifier;

[0094] If the user request does not match any routing rules, the service request is regarded as an illegal request, the illegal request is discarded, an error prompt is returned, and an error log is output;

[0095] 5. Continue to process the next business request.

[0096] The routing engine forwards and processes the service request of the user according to the routing rules in the routing rule set. The routing rule set can be saved in a configuration file or in a database. In an embodiment of the present invention, the routing rule set can be updated according to business needs, including adding routing conditions or modifying routing conditions in the routing rule set, and the update of the routing rule set can be completed online without affecting the operation of the system. In addition, the corresponding routing rules are matched only when all routing conditions related to the business parameters and business routing identifiers are met. The routing engine forwards the business request message to the routing target determined by the routing rule, that is, forwards the business request to an instance of a specific version of a specific background service.

[0097] According to a specific embodiment of the present invention, the service routing identifier RULEID is a bitmap switch sequence of length N, each bitmap switch is called a RULEIDBIT, and the N bitmap switches RULEIDBIT are numbered from 0 to N-1, that is, RULEIDBIT[0] to RULEIDBIT[N-1], to form the bitmap switch sequence. The value of N is generally determined according to the actual situation. For the convenience of storage, it is usually a power of 2, such as N=64, 128, 256, 512, 1024, etc. The larger the value of N, the more background services that support granular grayscale release.

[0098] For any background service, different background service versions can be represented by the on / off status of one bitmap switch or a combination of on / off status of multiple bitmap switches. For a single bitmap switch, the on / off status is represented by binary data, for example, 0 is off and 1 is on. Moreover, a background service that occupies m bitmap switches can support running 2 m Different service versions. Usually, the number of service versions of the background service that needs to support grayscale release is 2 at the same time, and 1 bitmap switch is sufficient. In rare cases, the number of service versions of the same background service that are running at the same time reaches 3, and m=2 bitmap switches are required. In actual production environments, there are almost no cases where the number of service versions of the same background service that are running at the same time exceeds 3.

[0099] In the embodiment of the present invention, the bitmap switches used by different background services do not overlap, that is, different identification bits of the business routing identifier are used to control different background services and their service versions, so the grayscale release of different background services will not affect each other. In the user configuration, the binary value of the business routing identifier RULEID is set based on the user attributes, which specifies the service version of the background service provided for the business request initiated by the user.

[0100] Assume that a background service SRV1 originally had only one service version SRV1_1 running, and all user traffic of the background service SRV1 was forwarded to this unique version SRV1_1. After the new version SRV1_2 of the background service SRV1 is deployed to the production environment, the background service SRV1 supports two service versions running at the same time, namely version SRV1_1 and version SRV1_2. The routing engine forwards the service request to the instance of version SRV1_1 or version SRV1_2 of the background service SRV1 according to the binary value of a bitmap switch in the service routing identifier RULEID.

[0101] Specifically, assuming that the bitmap switch RULEEDBIT[1] is used as the identification bit of the background service SRV1, when RULEEDBIT[1]=0, the routing engine forwards the service request to the instance of version SRV1_1; when RULEEDBIT[1]=1, the routing engine forwards the service request to the instance of version SRV1_2.

[0102] According to a preferred embodiment, the service version to be called is switched by modifying the service routing identifier in the user configuration. Specifically, the service routing identifier may be modified as a whole; or the binary value of the identification bit in the service routing identifier may be modified.

[0103] For example, initially, the bitmap switch RULEIDBIT[1]=0 for all users, and the user traffic of the background service SRV1 is forwarded to version SRV1_1. In the service routing identifier RULEID of the user USERNAME=zhangsan, RULEIDBIT[1]=1 is set, and the service request initiated by the user is forwarded to version SRV1_2, and the service of this version is verified at the finest granularity. If a problem occurs during the verification process, the service routing identifier RULEID of the user USERNAME=zhangsan can be reset in the user configuration, and RULEIDBIT[1]=0 can be set, and the request to the background service SRV1 initiated by the user is forwarded to version SRV1_1. After the verification is passed, the service routing identifier RULEID of more users (such as trial users who have been contacted in advance, users with specified OFFICE attribute values, users with specified AIRLINE attribute values, a certain proportion of users in the user database, all users, etc.) is modified in one or more batches, and RULEIDBIT[1]=1 is set, so as to perform a more coarse-grained verification on the service of version SRV1_2. During the service verification work of each batch, if a serious problem is found in the service of version SRV1_2, the user's service routing identifier RULEID can be reset, and RULEEDBIT[1] can be modified to 0 to switch the user and user traffic back to the service of version SRV1_1.

[0104] The technical effects and advantages of the present invention are as follows:

[0105] (1) Routing different users' requests for the same backend service to instances of different service versions for processing, and controlling user traffic diversion on the server side;

[0106] (2) The granularity of service grayscale release is fully controllable, and it also supports rapid switching back when problems occur in the version providing the service, and the scope of user impact is fully controllable;

[0107] (3) Supports the simultaneous grayscale release of multiple system services in a centralized control manner, and also supports the grayscale release of multiple service versions of the same system service;

[0108] (4) This method is applied on the server side, does not affect the client operation, and improves the user experience.

[0109] Table 1 is a definition table of a service routing identifier RULEID, the length of which is N=64, namely, it contains 64 bitmap switches. "Undefined" bitmap switches will not appear in the routing rule set, namely, these bitmap switches will not be considered when matching routing rules.

[0110]

[0111]

[0112] Table 1

[0113] As shown in Table 1, the three background services SRV1, SRV2, and SRV3 each support two operating versions, which are controlled by one bitmap switch respectively; the background service SRV4 supports four operating versions, which are controlled by two bitmap switches; and the background service SRV5 supports three operating versions, which are controlled by two bitmap switches.

[0114] Table 2 is a specific configuration example table of the business routing identifier. When performing granularly controlled grayscale releases for different background services, different release granularities are used to determine how to call different versions of the service to achieve a smooth transition of grayscale upgrades.

[0115]

[0116]

[0117] Table 2

[0118] As shown in Table 2, for ease of processing, the service routing identifier RULEID can be represented by a hexadecimal number. For a user with service routing identifier RULEID=0xBE, the binary sequence of the bitmap switch RULEIDBIT[1]-RULEIDBIT[7] is 10111110, that is, the undefined bitmap switch RULEID BIT[0]=0, the bitmap switch RULEIDBIT[1] of the control background service SRV1=1, which is determined by the version SRV 1_2 provides services, the bitmap switch RULEEDBIT[2] that controls the background service SRV2 is 1, and the service is provided by version SRV2_2. The bitmap switch RULEEDBIT[3] that controls the background service SRV3 is 1, and the service is provided by version SRV3_2. The bitmap switches RULEEDBIT[4]-RULEIDBIT[5] that control the background service SRV4 are 11, and the service is provided by version SRV4_4. The bitmap switches RULEEDBIT[6]-RULEIDBIT[7] that control the background service SRV4 are 10, and the service is provided by version SRV5_2.

[0119] For the background service SRV1, the bitmap switch RULIEDBIT[1] of all users is 1, indicating that all user traffic is switched to the version SRV1_2 of SRV1.

[0120] For the background service SRV2, except for user7 (all other users), the bitmap switch RULEEDBIT[2]=1 for user1 (single user), user2 (including 10 users), user3 (including 1000 users), user4 (20% of the total number of users), user5 (users with AIRLINE attribute CA), and user6 (users with OFFICE attribute PEK001) indicates that the traffic of these users is switched to version SRV2_2.

[0121] For the background service SRV3, the user traffic of user1 (single user), user2 (including 10 users), and user3 (including 1000 users) enters version SRV3_2, while the user traffic of user4 (20% of the total number of users), user5 (users with the AIRLINE attribute of CA), user6 (users with the OFFICE attribute of PEK001), and user7 (all other users) enters version SRV3_1.

[0122] For the background service SRV4, user1 (single user), user2 (including 10 users), and user3 (including 1000 users) are provided with services by version SRV4_4, user4 (20% of the total number of users) and user5 (users with the AIRLINE attribute of CA) are provided with services by version SRV4_3, user6 (users with the OFFICE attribute of PEK001) is provided with services by version SRV4_2, and user7 (all other users) are provided with services by version SRV4_1.

[0123] For the background service SRV5, user1 (single user), user2 (including 10 users), and user3 (including 1000 users) are provided with services by version SRV5_3, user4 (20% of the total number of users) and user5 (users with the AIRLINE attribute of CA) are provided with services by version SRV5_2, and user7 (all other users) are provided with services by version SRV5_1.

[0124] Table 3 shows a fragment of a routing rule set written in a specific language. The priority of each routing rule is set according to the sequence number at the beginning of the routing rule.

[0125]

[0126]

[0127] Table 3

[0128] The following uses several scenarios to illustrate the granularity-controlled service grayscale release method. The users involved in the following scenarios can be users of any granularity in Table 2.

[0129] Scenario 1:

[0130] Set the bitmap switch RULIEDBIT[1] in the user service routing identifier RULEID attribute to 0. When the user initiates a request FUNC1, the request FUNC1 is forwarded to the instance of version SRV1_1 of the background service SRV1 for processing according to the routing rules shown in Table 3.

[0131] Set the bitmap switch RULIEDBIT[1] in the user service routing identifier RULEID attribute to 1. When the user initiates a request FUNC1, the request FUNC1 is forwarded to the instance of version SRV1_2 of the background service SRV1 for processing according to the routing rules shown in Table 3.

[0132] Set the bitmap switch RULIEDBIT[2] in the user service routing identifier RULEID attribute to 0. When the user initiates a request FUNC2, the request FUNC2 is forwarded to the instance of version SRV2_1 of the background service SRV2 for processing according to the routing rules shown in Table 3.

[0133] Set the bitmap switch RULIEDBIT[2] in the user service routing identifier RULEID attribute to 1. When the user initiates a request FUNC2, according to the routing rules shown in Table 3, the request FUNC2 is forwarded to the instance of version SRV2_2 of the background service SRV2 for processing.

[0134] In the above scenario, by setting the binary value of the 1-bit bitmap switch of the user service routing identifier RULEID, the user's service request can be forwarded to two different versions of the same service, thereby performing grayscale release of two versions of the same service within the range of user-controllable granularity; by setting the 1st bitmap switch and the 2nd bitmap switch of the user RULEID, the user's different requests can be forwarded to different services, and multiple versions of grayscale releases can be performed on different services within the range of user-controllable granularity.

[0135] Scenario 2:

[0136] Set the bitmap switch RULEIDBIT[4]=0 and RULEIDBIT[5]=0 in the user service routing identifier RULEID attribute. When the user initiates a request FUNC4, according to the routing rules shown in Table 3, the request FUNC4 is forwarded to the instance of version SRV4_1 of the background service SRV4 for processing;

[0137] Set the bitmap switch RULEIDBIT[4]=0 AND RULEIDBIT[5]=1 in the user service routing identifier RULEID attribute. When the user initiates a request FUNC4, according to the routing rules shown in Table 3, the request FUNC4 is forwarded to the instance of version SRV4_2 of the background service SRV4 for processing;

[0138] Set the bitmap switch RULEIDBIT[4]=1 AND RULEIDBIT[5]=0 in the user service routing identifier RULEID attribute. When the user initiates a request FUNC4, the request FUNC4 is diverted to the SRV4_3 version of the background service SRV4 for processing according to the routing forwarding rule.

[0139] Set the bitmap switch RULEIDBIT[4]=1ANDRULEIDBIT[5]=1 in the user service routing identifier RULEID attribute. When the user initiates a request FUNC4, according to the routing rules shown in Table 3, the request FUNC4 is forwarded to the instance of version SRV4_4 of the background service SRV4 for processing.

[0140] In the above scenario, by setting the 2-bit switch of the user's business routing identifier RULEID attribute bitmap, the user request can be distributed to four different versions of the same service, thereby performing grayscale release of four versions of the service within the range of user-controllable granularity.

[0141] Similarly, by setting the n-bit switch of the user's RULEID attribute bitmap, the user request is distributed to the 2 n For services with faster demand changes and higher version change speeds, multiple versions may coexist in the system, so that multiple versions of the same service can be released in grayscale within the range of user-controllable granularity.

[0142] Scenario 3:

[0143] Use the management console tool to modify the user's business routing identifier RULEID to achieve online switching of service versions.

[0144] Set RULEIDBIT[1]=1 in the service routing identifier RULEID of user q5901211. The language is as follows:

[0145] >SetUserRuleIDByBit-user q5901211-bit 1-ruleid 1

[0146] User[q5901211]setuserRuleIDByBit set bit[l]to[l]OK!

[0147] Scenario 4:

[0148] Use the management console tool to modify the user's service routing identifier RULEID to implement online service version switching.

[0149] Set RULEIDBIT[1]=0 in the service routing identifier RULEID of user q5901211. The language is as follows:

[0150] >SetUserRuleIDByBit-user q5901211-bit 1-ruleid 0

[0151] User[q5901211]setuserRuleIDByBit set bit[l]to[0]OK!

[0152] The embodiment of the present invention also provides a service grayscale publishing system, which is applied to the server side, such as Figure 4 As shown, the system includes:

[0153] A request parsing module, used to receive a service request from a user, and obtain a service identifier by parsing the service request, wherein the service identifier is used to identify a background service that processes the service request;

[0154] A service acquisition module, used to acquire a service routing identifier from a user configuration, wherein the service routing identifier is a set of version identifiers pre-set based on user attributes, and the version identifier is used to indicate a service version to be called;

[0155] The request forwarding module is used to search for routing information corresponding to the target service instance according to the service identifier and the business routing identifier, and forward the business request to the target service instance according to the routing information.

[0156] Regarding the system in the above embodiment, the specific manner in which each unit module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0157] Based on the same inventive concept, an embodiment of the present invention further provides an electronic device, including: a memory and a processor, wherein the processor is used to read and execute a computer program stored in the memory to implement the aforementioned service grayscale release method.

[0158] Based on the same inventive concept, an embodiment of the present invention further provides a computer storage medium, wherein the computer storage medium stores computer executable instructions, and the computer executable instructions can implement the aforementioned service grayscale release method when executed.

[0159] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the modules is only a logical function division. There may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0160] The modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. In addition, the functional modules in the various embodiments of the present invention may be integrated into a processing module, or each module may exist physically separately, or two or more modules may be integrated into one module. The above-mentioned integrated modules may be implemented in the form of hardware or in the form of software functional modules.

[0161] If the integrated module is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0162] It should be noted that, for the convenience of description, the aforementioned method embodiments are all described as a series of action combinations, but those skilled in the art should be aware that the present invention is not limited by the described action sequence, because according to the present invention, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present invention.

[0163] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0164] Finally, it should be noted that the above is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the aforementioned embodiments, it is still possible for those skilled in the art to modify the technical solutions described in the aforementioned embodiments or to make equivalent substitutions for some of the technical features therein. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A service grayscale release method, applied to a server, characterized in that: The method comprises: Receiving a service request from a user, and obtaining a service identifier by parsing the service request, wherein the service identifier is used to identify a background service that processes the service request; Acquire a service routing identifier from the user configuration, where the service routing identifier is a set of version identifiers pre-set based on user attributes, and the version identifier is used to indicate a service version to be called; The routing information corresponding to the target service instance is searched according to the service identifier and the service routing identifier, and the service request is forwarded to the target service instance according to the routing information.

2. The method according to claim 1, characterized in that The service routing identifier is stored in the form of a binary bitmap.

3. The method according to claim 2, characterized in that The service routing identifier includes a plurality of identification bits for controlling background services; The version identifier is a binary value of the identification bit, and the binary value of the identification bit corresponds to the service version to be called.

4. The method according to any one of claims 1 to 3, characterized in that: The service version to be called is a running version of the background service that processes the business request.

5. The method according to claim 3, characterized in that: The method further comprises: The service routing identifier is modified in the user configuration to switch the service version to be called.

6. The method according to claim 5, characterized in that The modifying the service routing identifier in the user configuration includes: Modify the service routing identifier as a whole; Alternatively, the binary value of the identification bit in the service routing identifier is modified.

7. The method according to claim 1, characterized in that The searching for routing information corresponding to the target service instance according to the service identifier and the service routing identifier, and forwarding the service request to the target service instance according to the routing information, includes: Searching for routing information corresponding to the target service instance from a preset routing rule set according to the service identifier and the business routing identifier, wherein the routing information is used to call the target service instance; If routing information corresponding to the target service instance exists in the routing rule set, forwarding the service request to the target service instance according to the routing information; If there is no routing information corresponding to the target service instance in the routing rule set, the service request is discarded.

8. The method according to claim 7, characterized in that The target service instance is an instance of a service version to be called in the background service that processes the business request.

9. The method according to any one of claims 1 to 7, characterized in that: Before obtaining the service routing identifier from the user configuration, it also includes: Perform security authentication on user login information; After the security authentication is passed, the user configuration is obtained from the configuration database.

10. The method according to claim 9, characterized in that Before obtaining the service routing identifier from the user configuration, it also includes: Load the user configuration into cache.

11. A service grayscale release system, characterized in that: The system comprises: A request parsing module, used to receive a service request from a user, and obtain a service identifier by parsing the service request, wherein the service identifier is used to identify a background service that processes the service request; A service acquisition module, used to acquire a service routing identifier from a user configuration, wherein the service routing identifier is a set of version identifiers pre-set based on user attributes, and the version identifier is used to indicate a service version to be called; The request forwarding module is used to search for routing information corresponding to the target service instance according to the service identifier and the business routing identifier, and forward the business request to the target service instance according to the routing information.

12. An electronic device, characterized in that: include: Memory, processor; The processor is used to read and execute the computer program stored in the memory to implement the method according to any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions, when executed, implement the method according to any one of claims 1 to 10.

Images