Gray release method and device, electronic equipment and storage medium

Abstract

The invention discloses a gray release method and device, electronic equipment and a storage medium, which are applied to a callback gateway, and comprise the following steps: determining a target service module corresponding to a callback request sent by a target object; obtaining a gray condition corresponding to the target service module; obtaining condition parameters in the callback request; determining the target object as a test server and the callback request as a first callback request under the condition that the condition parameter meets the gray condition, and distributing the first callback request to a gray instance; and under the condition of determining that the condition parameter does not meet the gray condition, determining that the target object is a third-party server and the callback request is a second callback request, and distributing the second callback request to a normal instance. By setting the callback gateway, the callback gateway distributes the callback request based on gray condition matching, gray identification of the callback request is achieved, and the problem that in the prior art, only gray identification can be carried out on a message initiated by a user side, and the accuracy of the callback request is improved is solved. And for a callback request sent by a third-party server, whether the callback request should be distributed to a gray instance or a normal instance cannot be identified.

Description

Technical Field

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

[0002] The business of many enterprises is in the process of rapid iteration, with many and frequent functional iterations. If the service is unavailable during the production release process or there is a problem with the functional verification after the release, it will inevitably affect the normal business. In serious cases, it may lead to business interruption and cause various online failures, directly exposing the problem to all users.

[0003] Therefore, the mainstream approach is to adopt grayscale release, exposing only the backend and frontend functions to some users first, and continuously monitoring the actual online status of the version before full release, ensuring that the version is fault-free before pushing it to all users, minimizing the impact of the fault. However, the mainstream approach can only perform grayscale identification on messages initiated by the user end to determine whether the source of the message belongs to grayscale release, but cannot perform grayscale identification on messages sent by other message senders other than the user end. Summary of the invention

[0004] In order to solve at least one of the technical problems mentioned above, the present disclosure proposes a grayscale release method, device, electronic device and storage medium.

[0005] According to some embodiments of the present disclosure, a grayscale publishing method is provided, which is applied to a callback gateway, and the method includes:

[0006] Determine the target business module corresponding to the callback request sent by the target object;

[0007] Obtaining the grayscale condition corresponding to the target business module;

[0008] Obtaining conditional parameters in the callback request;

[0009] In the case where it is determined that the condition parameter satisfies the grayscale condition, determining that the target object is a test server, the callback request is a first callback request, and distributing the first callback request to a grayscale instance;

[0010] When it is determined that the condition parameter does not satisfy the grayscale condition, the target object is determined to be a third-party server, the callback request is a second callback request, and the second callback request is distributed to a normal instance.

[0011] Based on the above solution, by setting up a callback gateway, the callback gateway distributes the callback requests based on grayscale condition matching, thereby realizing grayscale recognition of callback requests. This solves the problem that in traditional technology, only grayscale recognition can be performed on messages initiated by the user end, but the callback requests sent by the third-party server cannot be identified whether they should be distributed to the grayscale instance or the normal instance.

[0012] In some possible implementations, the method includes:

[0013] Determining the access success rate of the grayscale instance;

[0014] When the access success rate is greater than the first threshold, a diversion ratio is set, where the diversion ratio is the proportion of the second callback requests that allow access to the grayscale instance in all second callback requests;

[0015] Based on the diversion ratio, a second callback request allowing access to the grayscale instance is distributed to the grayscale instance.

[0016] Based on the above solution, more access traffic is sent to the grayscale instance, which allows continuous testing and iteration of new versions or new functions without having to rely entirely on normal instances. After a certain test of the stability of the grayscale instance, the second callback request is distributed to the grayscale instance. By processing part of the traffic through the grayscale instance, more monitoring data and user feedback can be collected for further optimization and improvement of the system.

[0017] In some possible implementations, determining the access success rate of the grayscale instance includes:

[0018] Determining a service execution process of the target service module and a distribution path of the first callback request;

[0019] When the distribution path of the first callback request is consistent with the business execution process of the target business module, determining that the access to the grayscale instance is successful;

[0020] Counting the number of successful accesses to the grayscale instance and the total number of accesses to the grayscale instance;

[0021] Based on the total number of times and the number of successes, the access success rate of the grayscale instance is determined.

[0022] Based on the above scheme, by counting the number and total number of successful accesses to the grayscale instance, the performance of the grayscale instance can be accurately evaluated, which helps to determine whether the grayscale instance can meet the needs of the business environment and realize the performance evaluation of the grayscale instance.

[0023] In some possible implementations, obtaining the conditional parameter in the callback request includes:

[0024] Obtain a target parsing expression corresponding to the target business module and a separator in the target parsing expression;

[0025] The callback request is parsed based on the delimiter and the target parsing expression to obtain the conditional parameters in the callback request.

[0026] Based on the above solution, the conditional parameters in the callback request can be extracted through the pre-configured parsing expression and the separator of the parsing expression, so as to subsequently match the conditional parameters with the grayscale conditions to further determine the distribution of the callback request.

[0027] In some possible implementations, parsing the callback request based on the delimiter and the target parsing expression to obtain the conditional parameter in the callback request includes:

[0028] Extracting each parsing field in the target parsing expression according to the delimiter to obtain a parsing field sequence;

[0029] Determine the level to which each parsed field in the parsed field sequence belongs in the callback request;

[0030] Extracting conditional parameters from the callback request according to the level to which each parsed field in the parsed field sequence belongs in the callback request.

[0031] Based on the above solution, the structure of parsing the field sequence in the callback request is used as navigation, and the value of each field is extracted as the conditional parameter. The callback request is parsed through a pre-configured parsing expression to obtain the conditional parameters of the callback request, which improves the efficiency of determining the conditional parameters. The parsing expression can be configured according to different types, which is applicable to a variety of business types and has high flexibility.

[0032] In some possible implementations, after distributing the second callback request for allowing access to the grayscale instance to the grayscale instance based on the diversion ratio, the method further includes:

[0033] Counting the number of second callback requests for accessing the grayscale instance;

[0034] When the number of second callback requests for accessing the grayscale instance reaches a second threshold, the grayscale instance is updated to a normal instance.

[0035] Based on the above scheme, by counting the number of second callback requests sent by third-party servers that access the grayscale instance in actual operation, the stability and reliability of the grayscale instance can be more accurately evaluated. When the number of second callback requests to access the grayscale instance reaches the preset second threshold, it indicates that the grayscale instance can bear more business traffic. At this time, the grayscale instance is updated to a normal instance and the grayscale release is completed. By dynamically evaluating the use of grayscale instances in actual application processes, rapid iteration and continuous improvement can be achieved to improve system quality and user experience.

[0036] In some possible implementations, the method includes:

[0037] Send a request to the business server;

[0038] In the case of receiving the instance configuration information returned by the business server, determining to store the instance configuration information, wherein the instance configuration information is the instance configuration information of all business modules;

[0039] The obtaining of the grayscale condition corresponding to the target business module includes:

[0040] The grayscale condition corresponding to the target business module is determined from the stored instance configuration information.

[0041] Based on the above solution, long polling allows the business server to immediately respond to the callback gateway when there is a configuration update, thereby realizing real-time update of configuration information; at the same time, it reduces frequent invalid requests, reduces network load, reduces the amount of data transmission between the server and the client, and reduces the server's processing pressure and the number of concurrent connections.

[0042] According to some other embodiments of the present disclosure, a grayscale publishing device is provided, which is applied to a callback gateway and includes:

[0043] A first determination module, used to determine a target business module corresponding to the callback request sent by the target object;

[0044] A first acquisition module, used to acquire the grayscale condition corresponding to the target business module;

[0045] A second acquisition module is used to obtain the conditional parameters in the callback request;

[0046] A first distribution module is used for, when it is determined that the condition parameter satisfies the grayscale condition, determining that the target object is a test server, the callback request is a first callback request, and distributing the first callback request to a grayscale instance;

[0047] The second distribution module is used to determine that the target object is a third-party server and the callback request is a second callback request when it is determined that the condition parameter does not meet the grayscale condition, and distribute the second callback request to a normal instance.

[0048] According to some other embodiments of the present disclosure, an electronic device is provided, which includes a processing device and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded and executed by the processing device to implement the grayscale release method described in any one of the above embodiments.

[0049] According to some other embodiments of the present disclosure, a computer-readable storage medium is provided, in which at least one instruction or at least one program is stored, and the at least one instruction or the at least one program is loaded by a processing device and executes the grayscale publishing method described in any one of the above embodiments.

[0050] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

[0051] Further features and aspects of the present disclosure will become apparent from the following detailed description of exemplary embodiments with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] In order to more clearly illustrate the technical solutions and advantages in the embodiments of this specification or the prior art, the drawings required for use in the embodiments or the prior art descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0053] Figure 1 A schematic diagram showing a process of a grayscale publishing method according to an embodiment of the present disclosure is shown;

[0054] Figure 2 A schematic diagram showing a flow chart of a method for distributing a second callback request according to an embodiment of the present disclosure;

[0055] Figure 3 A schematic diagram showing a flow chart of a method for determining a grayscale instance access success rate according to an embodiment of the present disclosure;

[0056] Figure 4 A schematic diagram showing a flow chart of a conditional parameter extraction method according to an embodiment of the present disclosure;

[0057] Figure 5a A target analytical expression according to an embodiment of the present disclosure is shown;

[0058] Figure 5b An example of a callback request according to an embodiment of the present disclosure is shown;

[0059] Figure 6 A schematic diagram showing a flow chart of another conditional parameter extraction method according to an embodiment of the present disclosure;

[0060] Figure 7 A block diagram of a grayscale publishing device according to an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

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

[0062] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products, or devices.

[0063] Various exemplary embodiments, features and aspects of the present disclosure will be described in detail below with reference to the accompanying drawings. The same reference numerals in the accompanying drawings represent elements with the same or similar functions. Although various aspects of the embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless otherwise specified.

[0064] The word “exemplary” is used exclusively herein to mean “serving as an example, example, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0065] The term "and / or" herein is only a description of the association relationship of the associated objects, indicating that there may be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the term "at least one" herein represents any combination of at least two of any one or more of a plurality of. For example, including at least one of A, B, and C can represent including any one or more elements selected from the set consisting of A, B, and C.

[0066] In addition, in order to better illustrate the present disclosure, numerous specific details are given in the following specific embodiments. It should be understood by those skilled in the art that the present disclosure can also be implemented without certain specific details. In some examples, methods, means, components and circuits well known to those skilled in the art are not described in detail in order to highlight the subject matter of the present disclosure.

[0067] The payment system is an important part of the financial technology field. A sound payment system is usually very complex, including multiple business modules such as basic services, payment gateways, business products, account entry and exit, merchant systems, channel systems, accounting systems, clearing and settlement systems, reconciliation systems, and billing systems. Each business module corresponds to multiple sub-modules. In the current popular microservice architecture, such as SpringCloud or Dubbo framework, the number of payment system business modules is quite large, and the interactions between various business modules are intricate.

[0068] At present, in such a complex system, if a certain part of the business function needs to be iterated, due to the uncertainty of the performance of the new function and user experience, grayscale release is usually used to avoid the use risk brought by the uncertainty of the performance of the software product as much as possible. However, the current grayscale release can only perform grayscale identification on messages initiated by the user end to determine whether the source of the message belongs to grayscale release, but cannot perform grayscale identification on other non-user end messages, such as callback messages sent by external servers.

[0069] In order to solve the above technical problems, an embodiment of the present disclosure provides a grayscale publishing method, which is applied to a callback gateway, and the method includes: determining a target business module corresponding to a callback request sent by a target object; obtaining a grayscale condition corresponding to the target business module; obtaining a condition parameter in the callback request; when it is determined that the condition parameter satisfies the grayscale condition, determining that the target object is a test server, the callback request is a first callback request, and distributing the first callback request to a grayscale instance; when it is determined that the condition parameter does not satisfy the grayscale condition, determining that the target object is a third-party server, the callback request is a second callback request, and distributing the second callback request to a normal instance.

[0070] The grayscale publishing method of the disclosed embodiment, by setting up a callback gateway, distributes the callback request based on grayscale condition matching, thereby realizing grayscale recognition of the callback request, and solving the problem in traditional technology that only grayscale recognition can be performed on messages initiated by the user end, but it is impossible to identify whether the callback request sent by the third-party server should be distributed to the grayscale instance or the normal instance; at the same time, the grayscale instance is first tested by the test server, and only the callback request sent by the test server is distributed to the grayscale instance, while other users still access the normal instance, which does not affect the normal use of other users and improves the user experience.

[0071] Please refer to Figure 1 , Figure 1 A schematic diagram of a process of a grayscale publishing method according to an embodiment of the present disclosure is shown; the grayscale publishing method comprises:

[0072] It should be noted that, because the business server cannot send instance configuration information to the third-party server, the callback request sent by the third-party server cannot distinguish whether the grayscale instance or the normal instance in the target business module should be accessed. Therefore, in the embodiment of the present disclosure, a callback gateway is set in the business system, and the callback gateway obtains the instance configuration information of each business module from the business server, receives the callback requests sent by the third-party server and the test server, and distributes the callback requests through the callback gateway, thereby solving the problem that the callback message sent by the external server cannot be grayscale recognized.

[0073] S101: Determine the target business module corresponding to the callback request sent by the target object;

[0074] Specifically, the target objects include: a test server and a third-party server; the test server is a third-party server simulated by a tester, such as a development test server or a quality assurance test server, etc.; the third-party server is other servers that the business server depends on.

[0075] Optionally, the third-party server may be an Alipay server or a WeChat payment server that the payment system relies on; optionally, the third-party server may be a SF Express logistics server or a ZTO Logistics server that logistics relies on.

[0076] Specifically, the callback request is used to notify that a certain event has occurred or that certain operations need to be performed.

[0077] For example: in a payment system, the callback request may be a notification of updated order status returned by a third-party payment application; in another example, in a logistics system, the callback request may be a notification of updated logistics status returned by a third-party logistics company; in another example, in a software subscription system, the callback request may be a notification sent by a third-party service provider to remind users to renew their subscriptions.

[0078] Specifically, a business module is a service or component in the system that is responsible for processing specific business logic and operations. Each business module corresponds to one or more business functions. For example, in a payment system, it includes: an order processing module, a payment processing module, a user authentication module, a billing module, etc. The target business module is the business module requested to be accessed by the callback request.

[0079] In a specific embodiment, the callback request is an HTTP message, and the callback request at least includes: a service identifier;

[0080] Specifically, the service identifier may be a specific part in an HTTP message; optionally, the service identifier may be a URL path, a query parameter, request header information, or request body information, etc.

[0081] It should be noted that, in this embodiment, multiple business modules can be pre-set for each third-party server, and each business module pre-sets a corresponding business identifier to uniquely identify each business module. The business identifiers of each business module in different business scenarios are different. For example, for a payment scenario, the corresponding business identifier may be an order number; for another example, for a logistics scenario, the corresponding business identifier may be a logistics order number. Multiple business scenarios can be set in each third-party server, and multiple business modules and corresponding business identifiers can be set for each business scenario.

[0082] Specifically, the callback gateway pre-stores a correspondence table of various business modules and business identifiers corresponding to each business module; after receiving the callback request, based on the business identifier in the callback request, the business module corresponding to the callback request is determined from the correspondence table as the target business module.

[0083] S102: Obtaining the grayscale condition corresponding to the target business module;

[0084] The grayscale conditions are grayscale rules defined in the grayscale publishing process, and the grayscale conditions determine requests that are allowed to be distributed to grayscale instances for processing and requests that are allowed to be distributed to normal instances for processing.

[0085] Specifically, the grayscale condition at least includes: grayscale parameter name, grayscale parameter value and matching rule. Exemplarily, the grayscale parameter can be: merchant number, site number, transaction amount, transaction currency, transaction order number, bank card information, customer information, version information, etc. Exemplarily, the matching rule can be regular expression, dynamic script, consistent, inconsistent, including, not including, greater than, less than, interval, etc.

[0086] Specifically, after determining the target service module corresponding to the callback request, the callback gateway determines the grayscale condition corresponding to the target service module from pre-stored instance configuration information of each service module.

[0087] Exemplarily, the grayscale condition of the target business module may be "transaction amount equals 1000.1"; Exemplarily, the grayscale condition of the target business module may be "transaction currency is US dollars" etc. Exemplarily, the grayscale condition of the target business module may also be "transaction amount equals 1000.1 & transaction currency is US dollars".

[0088] S103: Obtaining conditional parameters in the callback request;

[0089] S104: When it is determined that the condition parameter satisfies the grayscale condition, determining that the target object is a test server, the callback request is a first callback request, and distributing the first callback request to a grayscale instance;

[0090] Specifically, when it is determined that the extracted conditional parameters meet the grayscale condition, the callback request is determined to be a test callback request for testing the grayscale instance sent by the test server, and the callback request for testing the grayscale instance is determined as the first callback request.

[0091] After receiving the callback request, the grayscale conditions are used to distinguish the callback requests used for testing, ensuring that only callback requests that meet specific characteristics are routed or distributed to the grayscale instance, so as to test specific user groups, specific business scenarios or specific functions; by setting test callback requests with the same characteristics during the application process, the test results can better reflect the performance in the real environment and improve the accuracy of the test results.

[0092] At the same time, grayscale testing is implemented by allowing only callback requests for testing to access the grayscale. If problems are found during the grayscale testing process, the grayscale instance can be quickly rolled back to a stable normal instance version without affecting the stability of the environment for actual interaction between the various business modules of the system.

[0093] S105: When it is determined that the condition parameter does not satisfy the grayscale condition, the target object is determined to be a third-party server, the callback request is a second callback request, and the second callback request is distributed to a normal instance.

[0094] Specifically, when it is determined that the extracted condition parameter does not satisfy the grayscale condition, it is determined that the callback request is a normal callback request sent by the third-party server, and the normal callback request is determined as the second callback request.

[0095] After receiving the callback request, the grayscale condition is also used to distinguish the normal callback request, ensuring that the third-party callback request is routed or distributed to the normal instance when the grayscale test is not completed. In this way, the release of the grayscale instance is prevented from affecting the normal interaction between business modules, ensuring the continuity and integrity of the business process and not being affected by the grayscale test.

[0096] In this embodiment, a callback gateway is set up, and the callback gateway distributes the callback request based on grayscale condition matching, thereby realizing grayscale recognition of the callback request, and solving the problem that in traditional technology, only grayscale recognition can be performed on messages initiated by the user end, but it is impossible to identify whether the callback request sent by the third-party server should be distributed to the grayscale instance or the normal instance; at the same time, the grayscale instance is first tested by the test server, and only the callback request sent by the test server is distributed to the grayscale instance. Other users still access the normal instance, which does not affect the normal use of other users and improves the user experience.

[0097] Figure 2 A flow chart of a method for distributing a second callback request according to an embodiment of the present disclosure is shown as follows: Figure 2 As shown;

[0098] S201: Determine the access success rate of the grayscale instance;

[0099] Specifically, the access success rate is the proportion of callback requests received and successfully processed by the grayscale instance.

[0100] S202: When the access success rate is greater than a first threshold, setting a diversion ratio, where the diversion ratio is a proportion of second callback requests that are allowed to access the grayscale instance in all second callback requests;

[0101] Specifically, the first threshold is a preset value used to determine whether the grayscale instance can accept more traffic. Optionally, the preset value can be a value set by an administrator when configuring the grayscale instance; optionally, the preset value can also be a value dynamically adjusted by the administrator based on test results.

[0102] It should be noted that the diversion ratio can be adjusted dynamically based on the performance changes of the grayscale instance to adapt to different testing requirements.

[0103] For example, the default initial diversion ratio is 0, and when the access success rate is greater than the first threshold, the diversion ratio is gradually increased.

[0104] In a specific embodiment, if the access success rate is greater than a preset first threshold, it means that the grayscale instance performs well and can accept more traffic. In this way, the diversion ratio is set to divert part of the second callback request to the grayscale instance.

[0105] In an optional embodiment, if the access success rate is less than a preset first threshold, it means that the grayscale instance may have undiscovered errors or configuration errors, resulting in the failure of callback request processing, or the grayscale instance may encounter performance problems when processing a large number of requests, such as insufficient resources, memory leaks, database connection problems, etc.

[0106] In this case, troubleshooting is required to fix the problem. If the problem cannot be solved immediately, a rollback operation is performed to roll back the grayscale instance to the normal instance version before the grayscale release to confirm the operation of the business environment.

[0107] Specifically, you can analyze logs and monitoring data to troubleshoot, locate the problem, and perform corresponding repair work.

[0108] S203: Based on the diversion ratio, distribute a second callback request allowing access to the grayscale instance to the grayscale instance.

[0109] Specifically, in this process, the received multiple second callback requests are no longer distributed according to the grayscale condition, but part of the received multiple second callback requests are sent to the grayscale instance based on the diversion ratio.

[0110] In this way, more access traffic is sent to the grayscale instance, and new versions or new functions can be continuously tested and iterated without having to rely entirely on normal instances. After a certain test of the performance and stability of the grayscale instance, the second callback request is distributed to the grayscale instance. By processing part of the traffic through the grayscale instance, more monitoring data and user feedback can be collected for further optimization and improvement of the system.

[0111] Furthermore, after distributing the second callback request allowing access to the grayscale instance to the grayscale instance based on the diversion ratio, the method also includes: counting the number of second callback requests accessing the grayscale instance; when the number of second callback requests accessing the grayscale instance reaches a second threshold, updating the grayscale instance to a normal instance.

[0112] Specifically, the second threshold is a preset value, which is used to determine the critical point at which the grayscale instance is upgraded from the test environment to the application environment. Optionally, the preset value can be a value set when configuring the grayscale instance; optionally, the preset value can also be a value dynamically adjusted by the tester based on the test results.

[0113] Optionally, the number of the second callback requests for accessing the grayscale instance may be obtained based on information such as a request ID, a request time, and a request status in a log file of the grayscale instance.

[0114] Optionally, a monitoring platform is set to collect the number of second callback requests for accessing the grayscale instance.

[0115] Specifically, when the number of second callback requests for accessing the grayscale instance reaches or exceeds the second threshold, the grayscale instance state is determined to be stable, the grayscale instance update process is triggered, and the grayscale instance is updated to a normal instance.

[0116] In this embodiment, by counting the number of second callback requests sent by third-party servers that access the grayscale instance in actual operation, the stability and reliability of the grayscale instance can be more accurately evaluated. When the number of second callback requests accessing the grayscale instance reaches the preset second threshold, it indicates that the grayscale instance can bear more business traffic. At this time, the grayscale instance is updated to a normal instance and the grayscale release is completed. By dynamically evaluating the use of the grayscale instance in the actual application process, rapid iteration and continuous improvement can be achieved to improve system quality and user experience.

[0117] Figure 3 A flow chart of a method for determining the access success rate of a grayscale instance according to an embodiment of the present disclosure is shown, as shown in FIG. Figure 3 As shown,

[0118] S301: Determine the service execution process of the target service module and the distribution path of the first callback request;

[0119] Specifically, the business execution process refers to the sequence of steps and activities that a business operation goes through from start to finish, the logical order and operation sequence of the business operation.

[0120] Specifically, the distribution path is the path for the grayscale instance to transmit and process the callback request in the business system. The distribution path determines how the first callback request is distributed to different processing units or services after reaching the target business module; exemplarily, the distribution path includes at least: a transmission path, a processing order, and a final destination.

[0121] Specifically, the business execution process corresponding to the target business module in the business system is obtained, and the business execution process may be pre-stored in the callback gateway. After the grayscale instance receives and processes the first callback request, the grayscale instance determines a distribution path for the processed information.

[0122] S302: When the distribution path of the first callback request is consistent with the business execution process of the target business module, determining that the access to the grayscale instance is successful;

[0123] Specifically, whether the distribution path of the first callback request is consistent with the service execution process of the target service module can be determined through process mapping or path comparison.

[0124] Optionally, the business execution process of the grayscale instance is mapped with the business execution process of the target business module to determine whether the steps and sequence between the two are consistent.

[0125] Optionally, the business execution process of the grayscale instance is compared with the business execution process of the target business module to determine whether the steps and sequence between the two are consistent.

[0126] Specifically, verify whether the distribution path of the first callback request is completely consistent with the business execution process of the target business module. If consistent, it can be considered that the first callback request is correctly processed on the grayscale instance, and it is determined that the grayscale instance is successfully accessed; if inconsistent, it is considered that although the first callback request is distributed to the grayscale instance, the grayscale instance fails to process the first callback message or there is an error.

[0127] In this way, by verifying the consistency between the information distribution path of the grayscale instance after processing the callback request and the business execution process of the target business module, it is possible to verify whether the performance of the grayscale instance meets the expected standards and achieve effective verification of the grayscale instance performance.

[0128] In an optional embodiment, it is also possible to determine whether the first callback request to access the grayscale instance is successful through the instance log of the grayscale instance.

[0129] S303: Counting the number of successful accesses to the grayscale instance and the total number of accesses to the grayscale instance;

[0130] S304: Determine the access success rate of the grayscale instance based on the total number of times and the number of successes.

[0131] Specifically, the total number includes: the number of successful accesses to the grayscale instance and the number of failed accesses to the grayscale instance. The access success rate is equal to: the number of successful accesses divided by the total number.

[0132] In this embodiment, by counting the number and total number of successful accesses to the grayscale instance, the performance of the grayscale instance can be accurately evaluated, which helps to determine whether the grayscale instance can meet the needs of the business environment and realize the performance evaluation of the grayscale instance.

[0133] Figure 4 A flow chart of a conditional parameter extraction method according to an embodiment of the present disclosure is shown as follows: Figure 4 As shown,

[0134] S401: Obtain a target parsing expression corresponding to the target business module and a separator in the target parsing expression;

[0135] When configuring each instance in each business module, set the respective parsing expression corresponding to the business type handled by each business module and store it in the instance configuration information. The instance configuration information corresponding to each business module is sent to the callback gateway for storage by the business server based on the acquisition request of the callback gateway.

[0136] Specifically, the target parsing expression is a preset grayscale condition parsing rule formula corresponding to the target business module; the target parsing expression is used to parse specific business parameters in the callback request.

[0137] Specifically, the callback gateway stores instance configuration information corresponding to each business module, determines instance configuration information corresponding to the target business module from the stored instance configuration information, and determines the target parsing expression based on the instance configuration information.

[0138] Specifically, the separator may be a dot, an underscore, a colon, or the like.

[0139] S402: Parse the callback request based on the delimiter and the target parsing expression to obtain conditional parameters in the callback request.

[0140] In a specific embodiment, the target parsing expression is segmented according to separators in the target parsing expression, such as periods, to obtain various fields, and then the parameters corresponding to the various fields are extracted from the callback request using json and xml tools.

[0141] Exemplarily, the above target parsing expression may be merchant_id, card_info.card_no, and Request.Body.WaybillRoute.orderid, etc. For example, when the target parsing expression is merchant_id, when parsing the callback request message, "content" and "merchant_id" may be found in the callback request to obtain the corresponding value after "merchant_id" and obtain the merchant number.

[0142] In this embodiment, the conditional parameters in the callback request can be extracted through the pre-configured parsing expression and the separator of the parsing expression, so that the conditional parameters and the grayscale conditions can be matched later to further determine the distribution of the callback request.

[0143] In a specific embodiment, referring to Figure 5a , Figure 5b and Figure 6 , Figure 5a is a target analytical expression in the embodiment of the present disclosure; Figure 5b is an example of a callback request in an embodiment of the present disclosure; Figure 6 A schematic diagram showing a flow chart of another conditional parameter extraction method according to an embodiment of the present disclosure is shown. Figure 6 Based on Figure 5a Given the target analytical expression and Figure 5b The callback request example given is a method for conditional parameter extraction.

[0144] The step of parsing the callback request based on the delimiter and the target parsing expression to obtain the conditional parameters in the callback request includes:

[0145] S4021: extracting each parsing field in the target parsing expression according to the delimiter to obtain a parsing field sequence;

[0146] Specifically, in this embodiment, Figure 5a As shown, the separator is ".", and the extraction process is as follows:

[0147] For "merchant_id": "body.merchant_id", the extracted fields are "body", "merchant_id";

[0148] For "order_id": "body.order_id", the extracted fields are "body", "order_id";

[0149] For "amount": "body.amount", the extracted fields are "body", "amount";

[0150] For "currency": "body.currency", the extracted fields are "body", "currency";

[0151] For "card_no": "body.card_info.card_no", the extracted fields are "body", "card_info", "card_no";

[0152] For "customer_email":"body.customer.email", the extracted fields are "body", "customer", "email";

[0153] The resulting field sequence is: [

[0154] ["body","merchant_id"],

[0155] ["body","order_id"],

[0156] ["body","amount"],

[0157] ["body","currency"],

[0158] ["body","card_info","card_no"],

[0159] ["body","customer","email"]

[0160] ].

[0161] S4022: Determine the level to which each parsed field in the parsed field sequence belongs in the callback request;

[0162] Specifically, the obtained field sequence is matched with the structure of the callback request, each field in the field sequence is traversed and parsed, and its level in the request is determined.

[0163] For example, for ["body", "merchant_id"], "body" is the root level, that is, the first level, and "merchant_id" is the direct child level under "body", that is, the second level.

[0164] For example, for ["body", "customer", "email"], "body" is the root level, i.e., the first level, "customer" is the first child level under "body", i.e., the second level, and "email" is the direct child level under "customer", i.e., the third level.

[0165] S4023: Extracting conditional parameters from the callback request according to the level to which each parsed field in the parsed field sequence belongs in the callback request.

[0166] Specifically, according to the level to which each parsed field in the parsed field sequence belongs in the callback request, directly from Figure 5b The conditional parameters are extracted from the corresponding level in the callback request shown.

[0167] In this embodiment, the extracted conditional parameters are as follows:

[0168] "body":{

[0169] "merchant_id":"123456789",

[0170] "order_id":"1234567890",

[0171] "amount":"100.00",

[0172] "currency":"CNY",

[0173] "card_info.card_no":"123456789012345678",

[0174] "customer.email":"customer@example.com"

[0175] }

[0176] In this embodiment, the structure of parsing the field sequence in the callback request is used as navigation, and the value of each field is extracted as a condition parameter. The callback request is parsed through a pre-configured parsing expression to obtain the condition parameter of the callback request, which improves the efficiency of determining the condition parameter, and the parsing expression can be configured according to different types, which is applicable to various business types and has high flexibility.

[0177] Furthermore, the method further comprises: sending an acquisition request to a business server; upon receiving instance configuration information returned by the business server, determining to store the instance configuration information, wherein the instance configuration information is instance configuration information of all business modules;

[0178] The callback gateway sends a request to the business server through long polling; when there is a grayscale instance for grayscale release, the business server updates the instance configuration information corresponding to each business module and returns it to the callback gateway in response to the request. If there is no grayscale instance for grayscale release, the business server suspends the request until the instance configuration information corresponding to the business module is updated, and then responds to the request again and returns the instance configuration information to the callback gateway.

[0179] In this way, long polling allows the business server to respond to the callback gateway immediately when there is a configuration update, thereby realizing real-time update of configuration information; at the same time, it reduces frequent invalid requests, reduces network load, reduces the amount of data transmission between the server and the client, and reduces the server's processing pressure and the number of concurrent connections.

[0180] In this embodiment, a callback gateway is set up, and the callback gateway distributes the callback request based on grayscale condition matching, thereby realizing grayscale recognition of the callback request, and solving the problem that in traditional technology, only grayscale recognition can be performed on messages initiated by the user end, but it is impossible to identify whether the callback request sent by the third-party server should be distributed to the grayscale instance or the normal instance; at the same time, the grayscale instance is first tested by the test server, and only the callback request sent by the test server is distributed to the grayscale instance. Other users still access the normal instance, which does not affect the normal use of other users and improves the user experience.

[0181] The grayscale publishing method described in the embodiment of the present invention is described below with a specific embodiment:

[0182] Step 1: The administrator configures the grayscale instance;

[0183] Step 1.1: Open the grayscale button corresponding to the grayscale instance;

[0184] Specifically, a business module will correspond to multiple instances, and the payment system is no exception. When a business module needs to update an instance, it turns on the grayscale button of the instance to be updated on the control panel. When the grayscale button is turned on, the business server receives a signal that the grayscale button is turned on, which includes at least: business identifier, instance identifier, instance address, and open mark. At this time, a notification is sent to all business module instances to notify that a grayscale instance exists in the target business instance. At this time, all received callback requests do not access the grayscale instance.

[0185] Step 1.2: Configure the grayscale instance;

[0186] The administrator configures the grayscale instance, including the configuration of grayscale conditions. Here, the grayscale condition setting parameters include: business name, instance ID, instance IP address, condition parameter type, condition parameter name, condition parameter value, matching mode or dynamic script, etc.

[0187] Here, the conditional parameter types include HttpHeader, HttpParameter, HttpBody, TrackAttribute tracking attributes or instance inherent attributes, etc.

[0188] The condition parameter types include:

[0189] HttpHeader is for the request parameters in the Http request header. The configurable parameters include request IP, transaction merchant number, etc.

[0190] HttpParameter is for request parameters on the Http path, applicable to the GET request interface, and configurable parameters include merchant number, transaction number, etc.

[0191] HttpBody is for the request parameters in the request body, which is generally in JSON format and needs to be parsed. Most business parameters can be configured, such as merchant number, site number, transaction amount, transaction currency, transaction order number, bank card information, customer information, etc.

[0192] TrackAttribute tracking attribute is implemented in HttpHeader and is generally used by internal applications other than gateway applications. The gateway is generally configured to extract various types of parameters and send them in the form of HttpHeader;

[0193] SystemAttribute is the inherent attributes that can be extracted from the instance, such as the example IP, application version, etc.

[0194] The matching modes include: consistent, inconsistent, included, not included, greater than, less than, interval, regular expression, etc., and even simple script operations. The parameter value corresponding to the condition parameter can be single or multiple.

[0195] By way of example, some possible matching methods in the matching mode are explained:

[0196] Consistent / Inconsistent: Parameter values ​​must be either identical or different.

[0197] Contains / Does not contain: Whether the parameter value contains a specific substring.

[0198] Greater than / Less than: Whether the parameter value is greater than or less than a specific value.

[0199] Range: Whether the parameter value is within the specified range.

[0200] Starts with / Ends with: Whether the parameter value starts or ends with a specific string.

[0201] Regular Expression: Whether the parameter value matches a specific regular expression pattern.

[0202] Script operation: Execute more complex matching logic through simple scripts.

[0203] Condition parameter value: Single value: directly specify a value, such as "100". Multiple values: specify a range or list, such as "1-100" or "['A','B','C']".

[0204] The grayscale condition may be formed by combining any one or more of the above condition parameters and any one or more matching modes.

[0205] By configuring these parameters, you can precisely control which requests should be routed to the grayscale instance. For example, you can set the grayscale condition to "route to the grayscale instance when the merchant number is a specific value and the transaction amount is greater than 1,000." Such configuration provides great flexibility and control, allowing the team to adjust the grayscale strategy according to specific business needs and testing goals.

[0206] After the configuration is completed, the configuration information of the grayscale instance is sent from the client to the business server.

[0207] Step 2: Call back the gateway to update instance configuration information;

[0208] Specifically, after receiving the updated instance configuration information, the service server updates it to the callback gateway in real time, and the callback gateway saves each service module and the instance configuration information corresponding to each service module.

[0209] It should be noted that the callback network here obtains instance configuration information from the business server through a long polling mechanism between business servers.

[0210] Step 3: Test the grayscale instance;

[0211] Step 3.1: The target object sends a callback request to the callback gateway;

[0212] The target object here can be a test server or a third-party server.

[0213] Step 3.2: The callback gateway determines the target business module corresponding to the business identifier based on the business identifier and condition parameters in the callback request, and obtains the grayscale condition in the target business module.

[0214] Step 3.3: when it is determined that the condition parameter satisfies the grayscale condition, determining that the target object is a test server, the callback request is a first callback request, distributing the first callback request to the grayscale instance, and executing step 4;

[0215] Step 3.4: When it is determined that the condition parameter does not satisfy the grayscale condition, the target object is determined to be a third-party server, the callback request is a second callback request, and the second callback request is distributed to a normal instance.

[0216] Step 4: Determine the access success rate of the grayscale instance.

[0217] Step 4.1: Determine the service execution process of the target service module and the distribution path of the first callback request;

[0218] Step 4.2: When the distribution path of the first callback request is consistent with the business execution process of the target business module, determine that the access to the grayscale instance is successful;

[0219] Step 4.3: Count the number of successful accesses to the grayscale instance and the total number of accesses to the grayscale instance;

[0220] Step 4.4: Based on the total number of times and the number of successes, determine the access success rate of the grayscale instance; if the access success rate is greater than a first threshold, execute step 5; otherwise, execute step 8.

[0221] Step 5: Set up permission for the second callback request to access the grayscale instance.

[0222] Step 5.1: Set the diversion ratio, which is the proportion of the second callback request that allows access to the grayscale instance in all second callback requests, and execute step 5.2.

[0223] Step 5.2: Based on the diversion ratio, distribute the second callback request allowing access to the grayscale instance to the grayscale instance, and execute step 6.

[0224] Specifically, in this process, the received multiple second callback requests are no longer distributed according to the grayscale condition, but part of the received multiple second callback requests are sent to the grayscale instance based on the diversion ratio.

[0225] The diversion ratio here can be dynamically adjusted by the administrator as the performance of the grayscale instance changes to meet different testing requirements.

[0226] Step 5.2: Change the grayscale condition and expand the grayscale condition range to distribute part of the second callback requests among the multiple second callback requests to the grayscale server, and execute step 6.

[0227] Step 6: Count the number of second callback requests for accessing the grayscale instance; when the number of second callback requests for accessing the grayscale instance reaches a second threshold, execute step 7; otherwise, execute step 5.1 or 5.2;

[0228] Step 7: Update the grayscale instance to a normal instance.

[0229] Step 8: Roll back the current grayscale instance to a normal instance or perform troubleshooting to fix the problem.

[0230] Please refer to Figure 7 , which shows a block diagram of a grayscale publishing device provided in an embodiment of the present application. The grayscale publishing device is applied to a callback gateway, and the device includes:

[0231] A first determination module 701 is used to determine a target business module corresponding to a callback request sent by a target object;

[0232] A first acquisition module 702, used to acquire the grayscale condition corresponding to the target business module;

[0233] The second acquisition module 703 is used to obtain the condition parameter in the callback request;

[0234] A first distribution module 704 is used to determine that the target object is a test server and the callback request is a first callback request when it is determined that the condition parameter satisfies the grayscale condition, and distribute the first callback request to the grayscale instance;

[0235] The second distribution module 705 is used to determine that the target object is a third-party server and the callback request is a second callback request when it is determined that the condition parameter does not meet the grayscale condition, and distribute the second callback request to a normal instance.

[0236] In some embodiments, the computer device (not shown) may include a processor, a memory, and a network interface connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, a grayscale publishing method is implemented.

[0237] It should be noted that the above-mentioned sequence of the embodiments of the present application is for description only and does not represent the advantages and disadvantages of the embodiments. The above-mentioned specific embodiments of this specification are described. Other embodiments are within the scope of the attached claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0238] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device and server embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.

[0239] A person skilled in the art will appreciate that all or part of the steps to implement the above embodiments may be accomplished by hardware, or by a program to instruct the relevant hardware, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a disk or an optical disk, etc.

[0240] The embodiments of the present disclosure have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or technical improvements in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A grayscale release method, characterized in that: Applied to a callback gateway, the method includes: Determine the target business module corresponding to the callback request sent by the target object; Obtaining the grayscale condition corresponding to the target business module; Obtaining conditional parameters in the callback request; In the case where it is determined that the condition parameter satisfies the grayscale condition, determining that the target object is a test server, the callback request is a first callback request, and distributing the first callback request to a grayscale instance; When it is determined that the condition parameter does not satisfy the grayscale condition, the target object is determined to be a third-party server, the callback request is a second callback request, and the second callback request is distributed to a normal instance.

2. The method according to claim 1, characterized in that The method comprises: Determining the access success rate of the grayscale instance; When the access success rate is greater than the first threshold, a diversion ratio is set, where the diversion ratio is the proportion of the second callback requests that allow access to the grayscale instance in all second callback requests; Based on the diversion ratio, a second callback request allowing access to the grayscale instance is distributed to the grayscale instance.

3. The method according to claim 2, characterized in that The determining the access success rate of the grayscale instance includes: Determining a service execution process of the target service module and a distribution path of the first callback request; When the distribution path of the first callback request is consistent with the business execution process of the target business module, determining that the access to the grayscale instance is successful; Counting the number of successful accesses to the grayscale instance and the total number of accesses to the grayscale instance; Based on the total number of times and the number of successes, the access success rate of the grayscale instance is determined.

4. The method according to claim 1, characterized in that The obtaining of the conditional parameters in the callback request includes: Obtain a target parsing expression corresponding to the target business module and a separator in the target parsing expression; The callback request is parsed based on the delimiter and the target parsing expression to obtain the conditional parameters in the callback request.

5. The method according to claim 4, characterized in that The step of parsing the callback request based on the delimiter and the target parsing expression to obtain the conditional parameters in the callback request includes: Extracting each parsing field in the target parsing expression according to the delimiter to obtain a parsing field sequence; Determine the level to which each parsed field in the parsed field sequence belongs in the callback request; Extracting conditional parameters from the callback request according to the level to which each parsed field in the parsed field sequence belongs in the callback request.

6. The method according to claim 2, characterized in that After distributing the second callback request allowing access to the grayscale instance to the grayscale instance based on the diversion ratio, the method further includes: Counting the number of second callback requests for accessing the grayscale instance; When the number of second callback requests for accessing the grayscale instance reaches a second threshold, the grayscale instance is updated to a normal instance.

7. The method according to claim 1, characterized in that The method comprises: Send a request to the business server; In the case of receiving the instance configuration information returned by the business server, determining to store the instance configuration information, wherein the instance configuration information is the instance configuration information of all business modules; The obtaining of the grayscale condition corresponding to the target business module includes: The grayscale condition corresponding to the target business module is determined from the stored instance configuration information.

8. A grayscale publishing device, characterized in that: Applied to a callback gateway, the device comprises: A first determination module, used to determine a target business module corresponding to the callback request sent by the target object; A first acquisition module, used to acquire the grayscale condition corresponding to the target business module; A second acquisition module, used to acquire the conditional parameters in the callback request; A first distribution module is used for, when it is determined that the condition parameter satisfies the grayscale condition, determining that the target object is a test server, the callback request is a first callback request, and distributing the first callback request to a grayscale instance; The second distribution module is used to determine that the target object is a third-party server and the callback request is a second callback request when it is determined that the condition parameter does not meet the grayscale condition, and distribute the second callback request to a normal instance.

9. An electronic device, comprising a processing device and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded and executed by the processing device to implement the grayscale release method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The storage medium stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded by a processing device and executes the grayscale release method as described in any one of claims 1 to 7.

Images