A Gray Release Method, Device, Equipment and Storage Medium

Abstract

The present disclosure provides a gray release method, apparatus, device, and storage medium, belonging to the technical field of automatic programming. The method includes receiving an interface call request sent by a calling party; parsing the interface call request to obtain interface identity information; determining whether gray calling exists for the interface according to the interface identity information; if gray calling does not exist for the interface, calling the interface using a first calling code corresponding to a first architecture; if gray calling exists for the interface, calling the interface using a second calling code corresponding to a second architecture, where the second architecture is an updated architecture of the first architecture. The gray release method provided by the present disclosure can take into account the matching problem of the interface call method when the system transforms from an SOA architecture to a microservices architecture, thereby being able to overcome the security problems and call failure problems caused by the mismatch of the interface call method, and improving the security and success rate of service function implementation.

Description

Technical Field

[0001] The present invention relates to the technical field of automatic programming, and in particular to a gray release method, device, equipment and storage medium. Background Art

[0002] Common system management architectures include the Service-Oriented Architecture (SOA) and the increasingly popular microservices architecture. SOA can split an application into different functional units (called services), and each service can work independently for other services. Services are connected through well-defined interfaces and protocols (dependency relationships). However, for SOA, it is a difficult problem to replace some parts of the system without causing a greater impact on the entire system. Therefore, the transition from SOA to the microservices architecture is inevitable. The microservices architecture can be essentially considered as a fine-grained SOA, and the microservices architecture can achieve low coupling between modules of the system. That is to say, the microservices architecture focuses on more lightweight services.

[0003] In the process of transitioning from the SOA architecture to the microservices architecture, existing technologies often only focus on the update and transformation of a certain application service, while ignoring the update of the interface call method of the service, resulting in production safety problems. In view of this, the present application aims to provide a gray release method, device, equipment and storage medium. Summary of the Invention

[0004] Aiming at the above problems of the prior art, the purpose of this article is to provide a gray release method to solve the production safety problems caused by ignoring the matching problem of interface call methods in the process of the system transitioning from the SOA architecture to the microservices architecture.

[0005] To solve the above technical problems, the specific technical solutions of this article are as follows:

[0006] In a first aspect, this article provides a gray release method, including:

[0007] Receiving an interface call request sent by a calling party;

[0008] Parsing the interface call request to obtain interface identity information;

[0009] Judging whether there is a gray call for the interface according to the interface identity information;

[0010] If there is no gray call for the interface, calling the interface using a first call code corresponding to a first architecture;

[0011] If there is such a gray-scale call for the interface, the second call code corresponding to the second architecture is used to call the interface, and the second architecture is the updated architecture of the first architecture.

[0012] Specifically, the determining whether there is a gray-scale call for the interface according to the interface identity information further includes:

[0013] Query whether the interface is configured with a second call code according to the interface identity information;

[0014] If the interface is not configured with the second call code, it is determined that there is no gray-scale call for the interface;

[0015] If the interface is configured with the second call code, it is determined that there is a gray-scale call for the interface.

[0016] Further, if the interface is configured with the second call code, the determination that there is a gray-scale call for the interface is further as follows:

[0017] If the interface is configured with the second call code, query whether the call mode switching switch of the interface is turned on according to the interface identity information;

[0018] If the call mode switching switch is not turned on, it is determined that there is no gray-scale call for the interface;

[0019] If the call mode switching switch is turned on, it is determined that there is a gray-scale call for the interface.

[0020] Even further, by parsing the interface call request, the caller identity information is also obtained. The determination that there is a gray-scale call for the interface when the call mode switching switch is turned on is further as follows:

[0021] If the call mode switching switch is turned on, determine whether there is a gray-scale call for the interface according to the caller identity information and the interface identity information.

[0022] Specifically, the obtaining of the caller identity information includes:

[0023] Obtain the caller identity information according to the first obtaining function or according to the second obtaining function; the first obtaining function is used for integer and long integer identity information; the second obtaining function is used for obtaining character-type identity information.

[0024] Further, the determining whether there is a gray-scale call for the interface according to the caller identity information and the interface identity information further includes:

[0025] Query the gray-scale call condition of the interface according to the interface identity information;

[0026] Based on the identity information of the caller, determine whether the caller meets the gray-scale call condition;

[0027] If the caller meets the gray-scale call condition, determine that there is a gray-scale call for the interface;

[0028] If the caller does not meet the gray-scale call condition, determine that there is no gray-scale call for the interface.

[0029] Preferably, the gray-scale call condition includes: one or a combination of a preset identity value, a preset identity value range, a preset gray-scale ratio value, and a custom call condition.

[0030] Preferably, the method further includes updating the gray-scale call condition.

[0031] Furthermore, the updating of the gray-scale call condition includes:

[0032] Obtain the first gray-scale call condition of the interface;

[0033] Update the first gray-scale call condition to obtain a second gray-scale call condition;

[0034] Replace the first gray-scale call condition with the second gray-scale call condition.

[0035] Even further, the updating of the first gray-scale call condition to obtain a second gray-scale call condition includes:

[0036] Increase the number of the preset values, and / or increase the preset value range, and / or increase one or a combination of the preset gray-scale ratio values.

[0037] Preferably, the method further includes: storing the preset identity value, the preset numerical identity range, and the preset gray-scale ratio value in a first storage module, and storing the custom call condition in a second storage module.

[0038] In a second aspect, this article provides a gray-scale release device, including:

[0039] An interface call request receiving module, configured to receive an interface call request sent by a caller;

[0040] A parsing module, configured to parse and obtain interface identity information according to the interface call request;

[0041] A first judgment module, configured to judge whether there is a gray-scale call for the interface according to the interface identity information;

[0042] A first call execution module, configured to, when there is a gray-scale call for the interface, call the interface using a first call code corresponding to a first architecture;

[0043] A second call execution module, configured to, when there is a gray-scale call for the interface, call the interface by using a second call code corresponding to a second architecture, where the second architecture is an updated architecture of the first architecture.

[0044] In a third aspect, this document provides a computer device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the gray-scale release method provided in the above technical solution is implemented.

[0045] In a fourth aspect, this document provides a computer-readable storage medium storing a computer program, where when the computer program is executed by a processor, the gray-scale release method provided in the above technical solution is implemented.

[0046] By adopting the above technical solution, a gray-scale release method, apparatus, device, and storage medium provided in this document can take into account the matching problem of the interface call method when the system transforms from an SOA architecture to a microservices architecture, thereby overcoming the security problems and call failure problems caused by the mismatch of the interface call method, and improving the security and success rate of service function implementation.

[0047] To make the above and other purposes, features, and advantages of this document more obvious and understandable, the following specifically enumerates preferred embodiments and, in conjunction with the accompanying drawings, makes the following detailed description. Description of the Drawings

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

[0049] Figure 1 A schematic diagram of the steps of a gray-scale release method provided in an embodiment of this document is shown;

[0050] Figure 2 A first schematic diagram of the steps of a method for determining whether there is a gray-scale call for an interface in an embodiment of this document is shown;

[0051] Figure 3 A second schematic diagram of the steps of a method for determining whether there is a gray-scale call for an interface in an embodiment of this document is shown;

[0052] Figure 4 A third schematic diagram of the steps of a method for determining whether there is a gray-scale call for an interface in an embodiment of this document is shown;

[0053] Figure 5 It shows a schematic diagram of the steps for updating the grayscale call condition in the embodiments of the present disclosure;

[0054] Figure 6 It shows a schematic structural diagram of a grayscale release device provided in the embodiments of the present disclosure;

[0055] Figure 7 It shows a schematic structural diagram of an electronic device provided in the embodiments of the present disclosure.

[0056] Description of the reference numerals in the drawings:

[0057] 61, Interface call request receiving module;

[0058] 62, Parsing module;

[0059] 63, First judgment module;

[0060] 64, First call execution module;

[0061] 65, Second call execution module;

[0062] 702, Computer device;

[0063] 704, Processor;

[0064] 706, Memory;

[0065] 708, Driving mechanism;

[0066] 710, Input / output module;

[0067] 712, Input device;

[0068] 714, Output device;

[0069] 716, Presentation device;

[0070] 718, Graphical user interface;

[0071] 720, Network interface;

[0072] 722, Communication link;

[0073] 724, Communication bus. Detailed implementation manners

[0074] Next, the technical solutions in the embodiments of the present disclosure will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, rather than all the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of the present disclosure.

[0075] It should be noted that the terms "first", "second", etc. in the specification, claims and the above-mentioned drawings of this article are used to distinguish similar objects, and do not necessarily have to be used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of this article described here can be implemented in an order other than those illustrated or described here. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, device, product or equipment that includes a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or equipment.

[0076] Common system management architectures include the Service-Oriented Architecture (SOA) and the increasingly popular microservices architecture. SOA is a coarse-grained, loosely coupled service architecture that can split different functional units (called services) of an application, and the services are connected through interfaces and protocols. When replacing certain parts of the system under the SOA architecture, it is difficult not to have a greater impact on the entire system. The microservices architecture can be regarded as a fine-grained SOA. The microservices architecture can achieve low coupling between the modules of the system, that is to say, the microservices architecture focuses on being more lightweight. Therefore, the microservices architecture can overcome the above-mentioned defects of the SOA architecture, making it inevitable to transition from SOA to the microservices architecture.

[0077] However, during the process of transitioning from the SOA architecture to the microservices architecture, existing technologies often only focus on the update and transformation of a certain application service, while ignoring the update of the interface call method of the service, resulting in production safety problems.

[0078] To solve the production safety problems caused by the untimely update of the interface call method, the embodiments of this article provide a gray release method. Figure 1 It is a schematic diagram of the steps of a gray release method provided by the embodiments of this article. This specification provides the method operation steps as described in the embodiments or flowcharts, but based on routine or non-creative labor, it may include more or fewer operation steps. The step order listed in the embodiments is only one way among the execution orders of numerous steps and does not represent the only execution order. When the actual system or device product executes, it can be executed in the order of the method shown in the embodiments or the drawings or executed in parallel. Specifically, as Figure 1 shown, the method may include:

[0079] S101: Receive an interface call request sent by a calling party;

[0080] In the embodiments of this specification, the calling party is the service. The service initiates a call request to an interface to complete the implementation of its function. The interfaces required to be called by different services can be the same or different according to their actual functional requirements. In the embodiments of this specification, the interface refers to a remote call interface.

[0081] S102: Parse the interface call request to obtain interface identity information;

[0082] That is, according to the interface call request, clarify the interface that the service needs to call. The interface identity information may include: the name of the interface (ID information). For example, if the name of the interface is "getUserById", it can represent that the interface can be used to implement the function of obtaining a user according to the user's ID. It should be noted that the names (ID information) of different interfaces are different, that is, a specific interface can be uniquely determined according to the name (ID information).

[0083] S103: Determine whether there is a gray-scale call for the interface according to the interface identity information;

[0084] S104: If there is no gray-scale call for the interface, call the interface using the first call code corresponding to the first architecture;

[0085] S105: If there is a gray-scale call for the interface, call the interface using the second call code corresponding to the second architecture, where the second architecture is the updated architecture of the first architecture.

[0086] In the embodiments of this specification, the first architecture is the SOA architecture, and the second architecture corresponds to the microservices architecture. The microservices architecture can be understood as being updated / upgraded based on the SOA architecture. When there is no gray-scale call for the called interface, the calling party still calls the interface using the call code (the first call code) corresponding to the SOA architecture; otherwise, it calls the interface using the call code (the second call code) corresponding to the microservices architecture. Thus, regardless of whether the interface is configured with a gray-scale call, it can meet the calling party's need to call it, enabling the calling party's service to complete its own function implementation and meeting the transition from the SOA architecture to the microservices architecture of the system.

[0087] In summary, the gray-scale release method provided by the embodiments of this specification can consider the matching problem of the interface call method when the system transitions from the SOA architecture to the microservices architecture, thereby overcoming the security problems and call failure problems caused by the mismatch of the interface call method, and improving the security and success rate of service function implementation.

[0088] In some feasible embodiments, as Figure 2 shown, step S103: Determine whether there is a gray-scale call for the interface according to the interface identity information, further includes:

[0089] S201: Query whether a second call code is configured for the interface according to the interface identity information;

[0090] S202: If the second call code is not configured for the interface, determine that there is no gray-scale call for the interface;

[0091] S203: If the second call code is configured for the interface, determine that there is a gray-scale call for the interface.

[0092] In the embodiments of the present specification, on the premise of meeting the call requirements of the service for the interface, a part of the interfaces still use the first call code to meet the call requirements corresponding to the SOA architecture; another part of the interfaces are configured with the second call code to meet the call requirements of the microservice architecture. And in the embodiments of the present specification, there is no need to add or replace the interface, but according to the system transition and transformation requirements, new call codes are written for the involved interfaces, which is beneficial to reducing the development cost.

[0093] As Figure 3 shown, further, step S203: If the second call code is configured for the interface, determining that there is a gray-scale call for the interface is further as follows:

[0094] S301: If the second call code is configured for the interface, query whether the call mode switching switch of the interface is turned on according to the interface identity information;

[0095] S302: If the call mode switching switch is not turned on, determine that there is no gray-scale call for the interface;

[0096] S303: If the call mode switching switch is turned on, determine that there is a gray-scale call for the interface.

[0097] In the embodiments of the present specification, the caller does not directly delete the first call code corresponding to the original SOA architecture, but adds the second call code corresponding to the microservice architecture and sets the call mode switching switch to control the switch to call the interface with one of the first call code and the second call code. Specifically, when the call mode switching switch is turned on, the call mode of the interface can be switched from the mode corresponding to the first call code to the mode corresponding to the second call code; when the call mode switching switch is not turned on, although the interface is configured with the second call code, the interface still can only use the call mode corresponding to the first call code.

[0098] Therefore, the gray release method provided in the embodiments of this specification can selectively turn on the call method switching switch for the interface call method, rather than making all interfaces configured with the second call code be called with the second call code in a "one-size-fits-all" manner. By opening or closing the call method switching switch, some interfaces can still be called with the first call code corresponding to the SOA architecture; another part of the interfaces are called with the second call code corresponding to the microservices and used for call testing, so that the interface call method is adapted to the transition from the SOA architecture to the microservices architecture, realizing the gray release of the interface, and at the same time, realizing the test of the gray release quality, and improving the success rate and efficiency of the transformation of the interface call method.

[0099] Whether there is a gray call for the interface and the switching of the interface call method can be implemented based on the following code:

[0100] boolean callNewApi = true;

[0101] if (!callNewApi) { / / If callNewApi is not true, that is, when the call method switching switch of the interface is not turned on;

[0102] / / Call the SOA interface and call the interface with the first call code corresponding to the SOA architecture;

[0103] } else { / / Otherwise

[0104] / / Call the Micro Service interface and call the interface with the second call code corresponding to the microservices architecture;

[0105] }

[0106] In some feasible embodiments, when parsing the interface call request in step S102, in addition to obtaining the interface identity information, the caller identity information can also be obtained. For example, the name of the caller (caller ID information). Therefore, step S303: If the call method switching switch has been turned on, determining that there is a gray call for the interface is further:

[0107] If the call method switching switch has been turned on, then judge whether there is a gray call for the interface according to the caller identity information and the interface identity information.

[0108] In the embodiments of this specification, the caller identity information can be the ID information of the interface (for example, if it is a digital number, it corresponds to an integer type or a long integer type) or the name of the interface (corresponding to a string). Then the caller identity information can be obtained through the following method, and the method includes:

[0109] The caller identity information is obtained according to the first acquisition function or the second acquisition function; the first acquisition function is used for integer and long integer identity information; the second acquisition function is used for character identity information. The grayscale publishing method provided in the embodiment of this specification can meet the needs of various types of callers to make grayscale calls to the interface, and has wide applicability.

[0110] Obtaining the caller's identity information can be achieved based on the following code:

[0111] public interface IDarkFeature{

[0112] boolean enabled(); / / Used to determine whether the calling mode switch is turned on;

[0113] boolean dark(long darkTarget); / / The first acquisition function is used to obtain the caller identity information of integer or long integer type;

[0114] boolean dark(String darkTarget); / / The second acquisition function is used to obtain the caller identity information in character type;

[0115] }

[0116] Different callers may have different types of identity information. In the embodiment of this specification, the two acquisition functions in the above code are used to obtain the identity information of the caller, and then used to determine whether the caller meets the grayscale call conditions of the interface. For example, for the "getUserById" interface, the identity information of the caller who initiates the call request to the interface is the user ID, which is an integer type parameter.

[0117] The grayscale publishing method provided in the embodiments of this specification can comprehensively determine whether a grayscale call exists by combining interface identity information and caller identity information, which is conducive to realizing flexible configuration of interface grayscale publishing.

[0118] Specifically, Figure 4 As shown, judging whether there is a grayscale call on the interface according to the caller identity information and the interface identity information further includes:

[0119] S401: querying the grayscale calling condition of the interface according to the interface identity information;

[0120] S402: judging whether the caller meets the grayscale calling condition according to the caller identity information;

[0121] S403: If the caller meets the gray call condition, determine that gray call exists for the interface.

[0122] S404: If the caller does not meet the gray call condition, determine that gray call does not exist for the interface.

[0123] In the embodiments of this specification, gray call conditions can be set for an interface so that only callers meeting the gray call conditions can call the interface using the second call code corresponding to the microservice architecture. For an interface configured with the second call code, when its call mode switch is in the open state, it is not a "one-size-fits-all" situation where all callers can call the interface using the call mode corresponding to the second call code; rather, callers meeting the gray call conditions of the interface can call the interface using the second call code, while another part of the callers not meeting the gray call conditions still call the interface using the first call code. Thus, on the premise of implementing gray release of the interface, callers are screened according to their identity information.

[0124] When a part of the callers meeting the gray call conditions of the interface can call the interface using the second call code, they can also be used as interface call test samples to verify the performance such as the success rate and efficiency of the call of the microservice architecture of the interface, improving the ability of the interface to adapt to microservice calls. After testing and optimization, gradually expand the applicable range of the gray call conditions of the interface, so that more and more callers can call the interface using the second call code, realizing the gray release of the interface. Therefore, in some preferred embodiments, the gray release method further includes: S405: Update the gray call conditions.

[0125] It should be noted that in this article, step S405: Update the gray call conditions is not strictly executed after step S404, but can be executed in any link after configuring the second call code for the interface.

[0126] In some preferred embodiments, the gray call conditions of the interface include one or more of a preset call identity value, a preset identity value range, a preset gray ratio value, and a custom call condition, where the custom call condition can be programmatically implemented by the business side using Spring.

[0127] In the embodiments of this specification, the gray call conditions can support configurations in different formats (such as JSON, YAML, XML, etc.) and different data sources (such as local file configuration or centralized configuration in a configuration center); and are extensible, supporting complex gray rules, such as rules related to business logic.

[0128] In the embodiments of this specification, according to the established grammar rules, the gray-scale call conditions applicable to the second call code for the identity of the caller are configured. In addition to providing the three rules of specific values, value ranges, and percentage values, it also supports business extension to define complex gray-scale call conditions, taking into account the convenience and flexibility of gray-scale calls for the caller.

[0129] The configuration of the gray-scale call conditions for the interface can be implemented based on the following code:

[0130]

[0131] For the interface "getUserById", its gray-scale call conditions are "893, 342, 1020 - 1120, 30%". Among them, "893" and "342" are specific caller identity values, and "1020 - 1120" is the identity data range. That is, when the identity information of the caller (caller ID information) is "893" or "342", or when the identity information of the caller is within the range of [1020, 1120], the caller can call the interface "getUserById" with the second call code; the "30%" in the gray-scale call conditions is the preset gray-scale percentage value, that is, among all the callers who want to call the interface "getUserById", the callers who can call this interface with the second call code account for 30% of the total number of callers. For the interface "loan", its gray-scale call conditions are only set with a range value, which will not be elaborated here.

[0132] As can be seen from the above example, in the gray-scale call conditions, when there are preset identity values, the number of values can be one or more; and in addition, when there are preset identity ranges, the number of ranges can be one or more.

[0133] As Figure 5 shown, in some preferred embodiments, step S405: The update of the gray-scale call conditions includes:

[0134] S501: Obtain the first gray-scale call condition of the interface; the first gray-scale call condition is the gray-scale call condition currently configured for the interface.

[0135] S502: Update the first gray-scale call condition to obtain the second gray-scale call condition;

[0136] S503: Replace the first gray-scale call condition with the second gray-scale call condition.

[0137] That is, in the embodiments of this specification, when updating the gray-scale call condition of the interface, instead of directly updating the current first gray-scale call condition of the interface, the first gray-scale call condition is first saved and updated according to a preset update rule to obtain a second gray-scale call condition, and then the updated second gray-scale call condition is used to replace the original first gray-scale call condition, which can avoid conflicts between the update of the gray-scale call condition and the process of determining whether the calling party meets the gray-scale call condition.

[0138] It should be noted that in the embodiments of this specification, preferably, the gray-scale call condition is updated in a hot update manner, so that when the gray-scale call condition is modified, the system can automatically load and update the gray-scale call condition without restarting, which can improve the availability of the system.

[0139] In the embodiments of this specification, by updating the gray-scale call condition, a part of the calling parties can call the interface by using the call code corresponding to the microservice architecture. After the call test passes, the number of calling parties that can call the interface by using the call code corresponding to the microservice architecture is gradually increased, so that its proportion becomes higher and higher and the range becomes larger and larger, realizing the gray-scale release of the interface; it is beneficial to reduce the repeated development of interface calls and shorten the development cycle.

[0140] In some feasible embodiments, in step S502: when updating the first gray-scale call condition to obtain a second gray-scale call condition, the update rule for updating the first gray-scale call condition may include:

[0141] Increasing the number of the preset values, and / or increasing the preset value range, and / or increasing one or a combination of several of the preset gray-scale ratio values.

[0142] Preferably, in order to avoid the custom call condition being overwritten by one or more of the preset identity values, preset identity ranges, and preset gray-scale ratio values when the gray-scale call condition is hot-updated, in the embodiments of this specification, the preset identity values, preset identity ranges, and preset gray-scale ratio values are stored in the first storage module, and the custom call condition is stored in the second storage module.

[0143] In some feasible embodiments, step S502: judging whether the calling party meets the gray-scale call condition according to the calling party identity information further includes:

[0144] Judging whether the calling party identity information is an integer type or a long integer type;

[0145] If the calling party identity information is an integer type or a long integer type, the calling party identity information is compared with the gray-scale call condition;

[0146] If the caller identity information is not an integer or a long integer, compare the caller identity information with a preset gray scale ratio value in the gray scale call condition and / or a custom call condition.

[0147] As Figure 6 shown, in an embodiment of this specification, a gray scale release device is further provided, including:

[0148] An interface call request receiving module 61, configured to receive an interface call request sent by a caller;

[0149] An analysis module 62, configured to analyze and obtain interface identity information according to the interface call request;

[0150] A first judgment module 63, configured to judge whether there is a gray scale call for the interface according to the interface identity information;

[0151] A first call execution module 64, configured to, when there is a gray scale call for the interface, call the interface by using a first call code corresponding to a first architecture;

[0152] A second call execution module 65, configured to, when there is a gray scale call for the interface, call the interface by using a second call code corresponding to a second architecture, where the second architecture is an updated architecture of the first architecture.

[0153] The device further includes:

[0154] A query module, configured to query whether the interface is configured with a second call code according to the interface identity information;

[0155] A second judgment module, configured to judge that there is no gray scale call for the interface when the interface is not configured with the second call code;

[0156] A third judgment module, configured to judge that there is a gray scale call for the interface when the interface is configured with the second call code.

[0157] In summary, a gray scale release method and device provided by an embodiment of this specification can meet the change in the interface call method during the transformation of the system from the SOA architecture to the microservices architecture, implement interface gray scale, and meet the call requirements of services for interfaces; and the gray scale call conditions of the interfaces can be flexibly extended and support complex gray scale release rules, taking into account both usability and flexibility, which can shorten the business application development cycle and reduce the maintenance cost.

[0158] An embodiment of this specification further provides a gray scale release system, including a rule configuration unit, an interface determination unit, a rule loading unit, and a rule extension unit. The responsibilities and functions of each unit are as follows:

[0159] A rule configuration unit is used to define the gray-scale call conditions of each interface in a unified syntax format. The gray-scale call conditions of an interface include a preset identity value, a preset identity value range, and a preset gray-scale ratio value.

[0160] When the gray-scale release system is started, the configuration made by the rule configuration unit will be parsed and loaded into a memory object, so that the gray-scale call conditions can be directly used to determine whether a certain caller meets the conditions for calling the interface with the second call code.

[0161] An interface determination unit is used to expose a gray-scale determination interface to the business caller, support flexible expansion of the caller, and is defined using an abstract interface.

[0162] It includes the logic for returning the call mode switching switch, which is used to determine whether the call mode switching switch is enabled, that is, whether to use the first call code corresponding to the SOA architecture or the second call code corresponding to the microservice; in addition, it also includes the acquisition of the caller's identity information, through two dark() acquisition functions, to meet the acquisition of the identity information of different types of callers.

[0163] A rule loading unit. Since the gray-scale release system needs to be integrated into the business application for use, it is necessary to achieve low intrusion and loose coupling as much as possible. In the gray-scale release system provided by the embodiments of this specification, the writing of the gray-scale call rules continues the configuration method of Spring and supports several configuration file formats such as XML, YAML, and Properties. At the same time, drawing on the design principle of convention over configuration of Spring, users only need to name the configuration file according to the convention and place it in the agreed path, and the configuration file can be automatically searched and loaded according to the convention. In addition to local file configuration, it also supports flexible data source configuration, such as Zookeeper or an enterprise-level configuration center.

[0164] In addition, during the process of interface gray-scale release, the gray-scale call conditions of the interface will be frequently modified to gradually increase the number and scope of callers who meet the conditions for calling the interface with the second call code. From the perspective of operation and maintenance, if the system needs to be restarted every time the gray-scale call conditions are modified, it will greatly affect the availability of the system. Therefore, the gray-scale rules need to support hot update. Specifically, when the gray-scale rules are modified, the system will automatically load and update the gray-scale rules without restarting.

[0165] Rule extension unit. The gray release system provided in the embodiments of this specification. In addition to the three basic gray conditions of providing a preset identity value, a preset identity value range, and a preset gray scale value, the gray call conditions also support the business party to expand and define complex business rules by itself. In the scenario of interface gray release, the three basic gray conditions can already meet most cases. For extremely individual complex gray conditions, the programming configuration of Spring can be referred to and implemented by the business party programming, taking into account both usability and flexibility.

[0166] As Figure 7 shown, a computer device provided by an embodiment of this article. The computer device 702 may include one or more processors 704, such as one or more central processing units (CPUs), and each processing unit may implement one or more hardware threads. The computer device 702 may also include any memory 706 for storing any kind of information such as code, settings, data, etc. Non-limiting, for example, the memory 706 may include any one or more combinations of the following: any type of RAM, any type of ROM, flash memory devices, hard disks, optical discs, etc. More generally, any memory may use any technology to store information. Further, any memory may provide volatile or non-volatile retention of information. Further, any memory may represent a fixed or removable component of the computer device 702. In one case, when the processor 704 executes the associated instructions stored in any memory or combination of memories, the computer device 702 may perform any operation of the associated instructions. The computer device 702 also includes one or more drive mechanisms 708 for interacting with any memory, such as a hard disk drive mechanism, an optical disc drive mechanism, etc.

[0167] The computer device 702 may also include an input / output module 710 (I / O) for receiving various inputs (via the input device 712) and for providing various outputs (via the output device 714)). A specific output mechanism may include a presentation device 716 and an associated graphical user interface 718 (GUI). In other embodiments, the input / output module 710 (I / O), the input device 712, and the output device 714 may not be included and it may only be a computer device in the network. The computer device 702 may also include one or more network interfaces 720 for exchanging data with other devices via one or more communication links 722. One or more communication buses 724 couple the components described above together.

[0168] The communication link 722 can be implemented in any way, for example, through a local area network, a wide area network (e.g., the Internet), a point-to-point connection, etc., or any combination thereof. The communication link 722 can include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc. governed by any protocol or combination of protocols.

[0169] Corresponding to Figures 1-5 In the method of, embodiments of the present invention also provide a computer-readable storage medium, on which a computer program is stored, and when the computer program is run by a processor, the steps of the above method are executed.

[0170] Embodiments of the present invention also provide a computer-readable instruction, wherein when the processor executes the instruction, the program therein causes the processor to execute as Figures 1 to 5 the method shown.

[0171] It should be understood that in various embodiments of the present invention, the magnitude of the sequence numbers of the above processes does not mean the order of execution, and the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present invention.

[0172] It should also be understood that in the embodiments of the present invention, the term "and / or" is merely a description of the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in this article generally represents an "or" relationship between the associated objects before and after.

[0173] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described according to their functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this article.

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

[0175] In several embodiments provided in this document, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Additionally, the displayed or discussed coupling, direct coupling, or communication connection to each other can be an indirect coupling or communication connection through some interfaces, devices, or units, and can also be in the form of electrical, mechanical, or other connections.

[0176] The units described as separate components may or may not be physically separated. The components displayed as units may or may not be physical units, that is, they can be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the objectives of the embodiments of this document.

[0177] In addition, in each embodiment of this document, the functional units can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0178] If the above-mentioned integrated units are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the essence of the technical solution in this document, or the part that contributes to the prior art, or all or part of this technical solution can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in each embodiment of this document. The aforementioned storage medium includes: USB flash drives, mobile hard disks, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), magnetic disks, or optical discs and other various media that can store program codes.

[0179] Specific embodiments are used in this document to elaborate on the principles and implementation methods of this document. The descriptions of the above embodiments are only used to help understand the methods and their core ideas in this document; at the same time, for those of ordinary skill in the art, according to the ideas in this document, there will be changes in the specific implementation methods and application scopes. In summary, the content of this specification should not be construed as a limitation to this document.

Claims

1. A gray release method, characterized in that, Including: Receiving an interface call request sent by a calling party; Parsing the interface call request to obtain interface identity information; Judging whether there is a gray-scale call for the interface according to the interface identity information, including: Querying whether the interface is configured with a second call code according to the interface identity information; If the interface is not configured with the second call code, it is determined that there is no gray-scale call for the interface; If the interface is configured with the second call code, query whether the call mode switching switch of the interface is turned on according to the interface identity information; If the call mode switching switch is not turned on, it is determined that there is no gray-scale call for the interface; If the call mode switching switch is turned on, it is determined that there is a gray-scale call for the interface; If there is no gray-scale call for the interface, call the interface using the first call code corresponding to the first architecture; If there is the gray-scale call for the interface, call the interface using the second call code corresponding to the second architecture, where the second architecture is the updated architecture of the first architecture, the first architecture is the SOA architecture, and the second architecture is the microservices architecture.

2. The gray release method according to claim 1, wherein Parsing the interface call request also obtains the calling party identity information, and the step of if the call mode switching switch is turned on, it is determined that there is a gray-scale call for the interface is further: If the call mode switching switch is turned on, judge whether there is a gray-scale call for the interface according to the calling party identity information and the interface identity information.

3. The gray release method according to claim 2, characterized in that, The obtaining the calling party identity information includes: Obtaining the calling party identity information according to the first obtaining function or according to the second obtaining function; the first obtaining function is used for integer and long integer identity information; the second obtaining function is used for obtaining character type identity information.

4. The gray release method according to claim 2, characterized in that The judging whether there is a gray-scale call for the interface according to the calling party identity information and the interface identity information further includes: Querying the gray-scale call condition of the interface according to the interface identity information; Judging whether the calling party meets the gray-scale call condition according to the calling party identity information; If the calling party meets the gray-scale call condition, judge that there is a gray-scale call for the interface; If the calling party does not meet the gray-scale call condition, judge that there is no gray-scale call for the interface.

5. The gray-scale release method according to claim 4, characterized in that, The gray-scale call condition includes one or more of a preset identity value, a preset identity value range, a preset gray-scale ratio value, and a custom call condition.

6. The gray-scale release method according to claim 5, characterized in that It also includes: Updating the gray-scale call condition.

7. The gray release method according to claim 6, characterized in that, The updating the gray-scale call condition further includes: Obtaining the first gray-scale call condition of the interface; Updating the first gray-scale call condition to obtain a second gray-scale call condition; Replacing the first gray-scale call condition with the second gray-scale call condition.

8. The gray release method according to claim 7, characterized in that The obtaining the second gray-scale call condition by updating the first gray-scale call condition includes: Increasing the number of preset values, and / or increasing the preset value range, and / or increasing the preset gray-scale ratio value, or a combination of several of them.

9. The gray release method according to claim 5, wherein The method also includes: Store the preset identity value, the preset numerical identity range, and the preset gray-scale ratio value in the first storage module, and store the custom call condition in the second storage module.

10. A gray release device, characterized in that, It includes: An interface call request receiving module, configured to receive an interface call request sent by a caller; A parsing module, configured to parse and obtain interface identity information according to the interface call request; A first judgment module, configured to judge whether there is a gray-scale call for the interface according to the interface identity information; A query module, configured to query whether a second call code is configured for the interface according to the interface identity information; A second judgment module, configured to judge that there is no gray-scale call for the interface when the second call code is not configured for the interface; A third judgment module, configured to query whether the call mode switching switch of the interface is turned on according to the interface identity information when the second call code is configured for the interface; If the call mode switching switch is not turned on, it is determined that there is no gray-scale call for the interface; If the call mode switching switch is turned on, it is determined that there is a gray-scale call for the interface; A first call execution module, configured to call the interface by using a first call code corresponding to a first architecture when there is a gray-scale call for the interface; A second call execution module, configured to call the interface by using a second call code corresponding to a second architecture when there is a gray-scale call for the interface, and the second architecture is an updated architecture of the first architecture.

11. A computer device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the computer program, the method steps described in any one of claims 1 to 9 are implemented.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method steps described in any one of claims 1 to 9 are implemented.

Images