Gray release method and device, storage medium and electronic equipment

Abstract

The embodiment of the invention discloses a gray level release method and device, a storage medium and electronic equipment, a network filter is arranged on a server, and the gray level release method comprises the steps that the server receives an access request for a target service from a user terminal through the network filter; according to at least one preset gray release rule, obtaining a target version to which a target service for the access request belongs; calling service data of a target service belonging to the target version through a network filter according to a data calling mode corresponding to the target version; and sending the service data to the user terminal. By adopting the embodiment of the invention, personalized setting of gray release can be realized, and the cost is relatively low.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular, to a gray release method, device, storage medium, and electronic device. Background Art

[0002] Gray release (also known as canary release) refers to a release method that can smoothly transition between black and white. A / B testing can be performed on it, that is, let some users continue to use product feature A, and some users start to use product feature B, and gradually expand the scope to migrate all users to use product feature B. Gray release can ensure the stability of the overall system, and problems can be discovered and adjusted at the initial gray level to ensure its impact.

[0003] Existing gray release methods all have some drawbacks. For example, the business layer of the server forwards the front-end requests through parameter control, distributes the front-end requests with specified parameters to the new logic, and the other part of the front-end requests still use the old logic. Therefore, gray release is completed by dynamically adjusting parameters. However, this method has a large code intrusion, which is equivalent to writing the code of the new logic and the old logic together, and the code of the old service needs to be deleted later, increasing the labor cost of code maintenance.

[0004] For another example, the production environment is isolated into two independent but identically operating environments through measures such as namespaces, and gray release is further implemented through devices such as gateways or routers. However, this method requires the deployment of middleware such as gateways or routers, and the deployment cost and maintenance cost are relatively high. Moreover, because the cost of implementing business personalization on the gateway is relatively high, the rules of gray release are relatively fixed and do not meet the needs of flexible customization. Summary of the Invention

[0005] The embodiments of this application provide a gray release method, device, storage medium, and electronic device, which can solve some or all of the above problems. The technical solutions are as follows:

[0006] In a first aspect, the embodiments of this application provide a gray release method. A network filter is set on the server. The gray release method includes:

[0007] The server receives an access request for a target service from a user terminal through the network filter;

[0008] According to at least one preset gray release rule, obtain the target version to which the target service corresponding to the access request belongs;

[0009] According to the data call method corresponding to the target version, call the service data of the target service belonging to the target version through the network filter;

[0010] Send service data to the user terminal.

[0011] In a second aspect, an embodiment of the present application provides a gray release device. A network filter is provided on the gray release device. The gray release device includes:

[0012] An access request module, configured to receive, through the network filter, an access request from a user terminal for a target service;

[0013] A version acquisition module, configured to acquire a target version to which the target service corresponding to the access request belongs according to at least one preset gray release rule;

[0014] A service invocation module, configured to invoke service data of a target service belonging to the target version through the network filter according to a data invocation method corresponding to the target version;

[0015] A data sending module, configured to send the service data to the user terminal.

[0016] In a third aspect, an embodiment of the present application provides a computer storage medium. The computer storage medium stores multiple instructions, and the instructions are adapted to be loaded and executed by a processor to perform the above method steps.

[0017] In a fourth aspect, an embodiment of the present application provides an electronic device, which may include: a processor and a memory; wherein, the memory stores a computer program, and the computer program is adapted to be loaded and executed by the processor to perform the above method steps.

[0018] The beneficial effects brought by the technical solutions provided by some embodiments of the present application at least include:

[0019] In the present application, a network filter is provided on the server. The server receives, through the network filter, an access request from a user terminal for a target service, and invokes, through the network filter, service data of a target service belonging to the target version based on a data invocation method corresponding to the target version, and sends the service data to the user terminal. Compared with setting at least one intermediate device such as a gateway between the user terminal and the server to implement the above functions, the present application effectively reduces the deployment cost and maintenance cost brought by deploying the intermediate device. And in the present application, based on the received access request, the target version to which the target service corresponding to the access request belongs is acquired according to at least one preset gray release rule. In other words, the present application can customize at least one gray release rule according to actual needs. Compared with using devices such as gateways, the cost of customizing the gray release rule through the network filter is relatively low, and the reusability of the network filter is relatively high. And in the present application, service data of different versions is invoked through different data invocation methods, and the service data of different versions can be isolated from each other. Therefore, the readability of the code data of different versions is relatively good. Description of the Drawings

[0020] To more clearly illustrate the technical solutions in the embodiments of the present application 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 the present application. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can also be obtained based on these drawings.

[0021] Figure 1 It is a schematic flowchart of a gray release method provided by an embodiment of the present application;

[0022] Figure 2 It is a schematic flowchart of another gray release method provided by an embodiment of the present application;

[0023] Figure 3 It is a schematic structural diagram of a gray release device provided by an embodiment of the present application;

[0024] Figure 4 It is a schematic flowchart of a gray release method provided by an embodiment of the present application;

[0025] Figure 5 It is a schematic flowchart of a gray release method provided by an embodiment of the present application;

[0026] Figure 6 It is a schematic structural diagram of a gray release device provided by an embodiment of the present application;

[0027] Figure 7 It is a schematic structural diagram of an electronic device provided by an embodiment of the present application. Detailed implementation manners

[0028] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only some embodiments of the present application, rather than all embodiments. Based on the embodiments of the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present application.

[0029] In the description of this application, it should be understood that the terms "first", "second", etc. are only used for descriptive purposes and cannot be construed as indicating or implying relative importance. In the description of this application, it should be noted that unless otherwise clearly specified and defined, "including" and "having", and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally also include steps or units not listed, or may optionally also include other steps or units inherent to these processes, methods, products, or devices. For those of ordinary skill in the art, the specific meanings of the above terms in this application can be understood according to specific circumstances. In addition, in the description of this application, unless otherwise stated, "a plurality" means two or more. "And / or" describes the association relationship of associated objects and indicates 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. The character " / " generally indicates that the associated objects before and after are in an "or" relationship.

[0030] The following will describe this application in detail with specific embodiments.

[0031] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data for analysis, stored data, displayed data, etc.), and signals involved in the embodiments of this application are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of relevant data need to comply with the relevant laws, regulations, and standards of relevant countries and regions. For example, the access requests, service data, etc. involved in this application are all obtained under full authorization.

[0032] With the rapid development of the Internet, in order to continuously improve the user experience and enhance the competitiveness of their own products, various Internet companies are constantly updating and replacing various software and operating systems. And gray-box testing is an essential stage before the launch of new versions of various software. Operating systems include but are not limited to Android, HarmonyOS, Windows, iOS, macOS, etc., and software includes but is not limited to application software on operating systems such as Android, HarmonyOS, Windows, iOS, macOS, etc.

[0033] The so-called gray-box testing means that before the official launch of a new version, the new version is first pushed to a part of the target population for use, and some deficiencies of the new version to be launched are modified based on their usage results and feedback, so as to identify and fill in the gaps, improve the new version, and lay a foundation for the full launch of the new version later.

[0034] Existing gray release methods all have some drawbacks. For example, the business layer of the server forwards front-end requests through parameters, distributes front-end requests with specified parameters to the new logic, and another part of the front-end requests still uses the old logic. Therefore, gray release is completed by dynamically adjusting parameters. However, this method has a large code intrusion. It is equivalent to writing the code of the new logic and the old logic together, and the code of the old service needs to be deleted later, increasing the labor cost of code maintenance.

[0035] Another example is to isolate the production environment into two independent but identically operating environments through measures such as namespaces, and further implement gray release through devices such as gateways or routers. However, this method requires the deployment of middleware such as gateways or routers, with relatively high deployment and maintenance costs. Moreover, because the cost of implementing business personalization on the gateway is relatively high, the gray release rules are relatively fixed and do not meet the requirements of flexible customization.

[0036] Therefore, in view of the above problems, the present application proposes a gray release method to solve some or all of the above problems. In one embodiment, as Figure 1 shown, it is a schematic architecture diagram of a gray release method proposed in an embodiment of the present application. The schematic architecture diagram includes: a plurality of user terminals, server 102, and server 103. The above-mentioned plurality of user terminals at least include user terminal 1011, user terminal 1012, and user terminal 1013. It can be understood that Figure 1 the number of the servers and the plurality of user terminals shown is only for illustration, and the embodiments of the present application do not impose any restrictions on this.

[0037] Server 102 can be understood as a server or a cluster composed of multiple servers. Server 102 receives requests or information through a plurality of set interfaces, and provides corresponding data or services based on the request content of the request. In the embodiment of the present application, server 102 is used to receive access requests from a plurality of user terminals respectively for a target service. The target service can be a service provided by a certain application. For example, the splash screen animation service of a certain application. Further, server 102 sends service data of the target service belonging to the target version version to each user terminal based on the access request and at least one gray release rule. For example, it sends the data of the splash screen animation belonging to version 1.0 to user terminal 1011, and sends the data of the splash screen animation belonging to version 2.0 to user terminal 1012, so that the splash screen animation of version 1.0 is displayed on the display device of user terminal 1011, and the splash screen animation of version 2.0 is displayed on the display device of user terminal 1012.

[0038] Servers 102 and 103 store service data of different versions of the target service, and the domain names of servers 102 and 103 are different. For example, the target service includes a first version and a second version. Server 102 stores the service data of the first version of the target service, and server 103 stores the service data of the second version of the target service. It can be understood that the server types of servers 103 and 102 may be the same or different. For example, both servers 103 and 102 are clusters composed of multiple servers.

[0039] It can be understood that servers 102 and 103 also have other service capabilities and functions to complete the tasks in the following embodiments. For example, server 102 also provides portal services, resource management services, and CI / CD services, etc. The above data does not limit the quantity, format, or content of the data. For example, the data may include any form and any content such as pictures, texts, voices, etc.

[0040] The above-mentioned server 102 or server 103 may be multiple physical servers, and the multiple physical servers are independent in terms of hardware; or multiple virtual servers, and the multiple virtual servers are deployed in the same hardware resource pool. The deployment methods of virtual servers include, but are not limited to: VMware, Virtual Box, and Virtual PC.

[0041] Servers 102 and 103, and between server 102 and multiple user terminals can communicate through a communication link established based on a communication protocol. For example: the gRPC protocol. gRPC is a high-performance, general-purpose open-source remote procedure call (RPC) framework, which is mainly designed for mobile application development and is based on the HTTP / 2 protocol standard. It is developed based on the Protocol Buffers (PB) serialization protocol and supports many development languages. In addition, the communication link can also be a wireless communication link or a wired communication link. For example: the wired communication link includes optical fiber, twisted pair, or coaxial cable, and the wireless communication link includes a Bluetooth communication link, a wireless fidelity (Wi-Fi) communication link, or a microwave communication link, etc.

[0042] The user communicates with server 102 through a user terminal, that is, sends an access request for a target service to server 102 through user terminal 1011 or user terminal 1012 or user terminal 1013 or other user terminals. For example, the user sends an access request for a target service to server 102 through terminal 1011, the user sends an access request to server 102 through user terminal 1012, or the user sends an access request to server 102 through user terminal 1013. The content of the access request can be any content in any format set by the user through the user terminal, and is used to obtain data related to the target service.

[0043] The types of user terminals include, but are not limited to, physical or virtual servers, mobile stations (MS), mobile terminal devices, mobile telephones, handsets, portable equipment, Bluetooth headsets, smart watches, etc. The electronic device can communicate with one or more core networks via a radio access network (RAN). It can be understood that the types of the above terminals are not limited in the embodiments of the present application.

[0044] In the embodiments of the present application, a display device may also be installed on the terminal. The display device can be various devices capable of implementing a display function. For example, the display device can be a cathode ray tube display (CR), a light-emitting diode display (LED), an electronic ink screen, a liquid crystal display (LCD), a plasma display panel (PDP), etc. The user can use the display settings on the user terminal to view the service data sent from server 102. And the user can send an instruction to the user terminal through the display settings, for example, send an instruction to the user terminal by performing a long press, click, or double click operation on the display settings of the user terminal. The instruction includes selecting a certain application, or selecting a target service of a certain application, or sending an access request for a target service to server 102, etc.

[0045] In one embodiment, as Figure 2 shown, it is a schematic flowchart of a gray release method proposed in the embodiments of the present application. The method can be implemented depending on a computer program and can run on a gray release device based on the von Neumann architecture. The computer program can be integrated in an application or run as an independent tool class application.

[0046] Specifically, the gray release method includes:

[0047] S101. The server receives an access request for a target service from a user terminal through a network filter.

[0048] The network filter (Web filter) is set on the server that receives the access request. For example, in the architecture diagram shown, the network filter (Web filter) is set on server 102, and the server receives an access request for a target service from a user terminal through the network filter. In other words, the access request is intercepted through the network filter. Figure 1 The target service can be one of multiple services provided by an application software developed based on any operating system on the user terminal. For example, the target service is the splash screen animation service when a certain communication software starts to display the splash screen after receiving a start instruction, which is used to play an animation for several seconds when the communication software displays the splash screen. The access request for the target service is used to instruct the server that receives the access request to obtain service data related to the target service and send it to the user terminal, so that the user terminal provides the target service to the user based on the service data.

[0049] S102. According to at least one preset gray release rule, obtain the target version to which the target service targeted by the access request belongs.

[0050] There are multiple versions of the target service, such as version = versionN, where N is a positive integer. In other words, the service data of the target service between different versions is different. For example, if the target service is the splash screen animation service of a certain communication software, the content of the splash screen animation corresponding to the target service in different versions is different, or the playing speed of the splash screen animation corresponding to the target service in different versions is different.

[0051] The preset gray release rules are used to indicate which version of the target service the access request for the target service is forwarded to. In this application, the number of gray release rules can be one or more. The at least one preset gray release rule is set in the server that receives the access request. As shown, it is set in the storage unit of server 102.

[0052] Figure 1 shown in the storage unit of server 102.

[0053] For example, the target service is the splash screen animation service of a certain communication software. After the release of the new version of the splash screen animation, the gray release rule is set to provide the new version of the splash screen animation to users with monthly activity higher than 95% of others. Therefore, after receiving an access request for the target service, the monthly activity of the user corresponding to the user terminal sending the access request is detected. When the monthly activity of the user meets the requirements of the above gray release rule, it is determined that the target version corresponding to the access request is the new version. When the monthly activity of the user does not meet the requirements of the above gray release rule, it is determined that the target version corresponding to the access request is the old version.

[0054] It can be understood that the above new version and old version are relative concepts based on time. The actual number of versions included in the new version can be one or more, and the actual number of versions included in the old version can also be one or more. For example, the target service includes 3 versions, that is, the target service includes the first version version1, the second version version2, and the third version version3. According to multiple preset gray release rules, it is determined that the target version to which the target service corresponding to the access request that meets the first gray release rule belongs is the first version version1, it is determined that the target version to which the target service corresponding to the access request that meets the second gray release rule belongs is the second version version2, and it is determined that the target version to which the target service corresponding to the access request that meets the third gray release rule belongs is the third version version3.

[0055] S103. According to the data call method corresponding to the target version, call the service data of the target service belonging to the target version through the network filter.

[0056] The target versions to which the target service belongs are different, and the acquisition methods of the service data of each version, that is, the data call methods, are also different. The service data corresponding to each version, that is, the control logic for implementing the target service, is different. For example, the control logic of the target service corresponding to different versions is versionN_control_logic, such as versionN_control_logic = lua / code. And the URL addresses corresponding to each version are different, that is, versionN_url is different. In other words, the domain names of the servers corresponding to each version, that is, the paths for calling the service data of the target service, are different. For example, it can be an absolute path such as the internal forwarding address http: / / a.local / item / vN of the server receiving the access request, or it can be the address of another server http: / / a.com / item / vN.

[0057] Therefore, different versions of the target service correspond to different data calling methods versionN_dispatch. The network filter calls the service data of the target service belonging to the target version through the corresponding data calling method. For example, if it is determined that the target version corresponding to the access request is version1, the service data corresponding to version1 is called through the data calling method corresponding to version1. Among them, the data calling methods corresponding to each version among the multiple versions to which the target service belongs can be set as needed by relevant personnel.

[0058] S104. Send the service data to the user terminal.

[0059] After obtaining the service data belonging to the target service, the service data is sent to the user terminal through the communication connection with the user terminal that sent the access request. For example, as Figure 1 shown, the target service is the splash screen animation service of a certain communication software. The user sends an access request for the target service to the server 102 through the user terminal 1011. After the server 1011 matches the access request with at least one preset gray release rule, it is determined that the target version to which the target service targeted by the access request belongs is version1. After obtaining the service data through the data calling method corresponding to version1, the service data is sent to the user terminal 1011, so that the user terminal plays the splash screen animation corresponding to the service data on the display device based on the service data, that is, provides the user with the target service of version1.

[0060] In this application, a network filter is set on the server. The server receives the access request for the target service from the user terminal through the network filter, and calls the service data of the target service belonging to the target version through the network filter based on the data calling method corresponding to the target version, and sends the service data to the user terminal. Compared with setting at least one intermediate device such as a gateway between the user terminal and the server to implement the above functions, this application effectively reduces the deployment cost and maintenance cost brought by deploying the intermediate device. And in this application, based on the received access request, the target version to which the target service targeted by the access request belongs is obtained according to at least one preset gray release rule. In other words, this application can customize at least one gray release rule according to actual needs. Compared with using devices such as gateways, the cost of customizing the gray release rule through the network filter is relatively low, and the reusability of the network filter is relatively high. And in this application, the service data of different versions is called through different data calling methods, and the service data of different versions can be isolated from each other. Therefore, the readability of the code data of different versions is better.

[0061] In one embodiment, as Figure 3As shown in the figure, it is a schematic flowchart of a gray release method proposed in an embodiment of the present application. This method can be implemented depending on a computer program and can run on a gray release device based on the von Neumann architecture. This computer program can be integrated into an application or run as an independent tool application.

[0062] Specifically, this gray release method includes:

[0063] S201. The server receives an access request for a target service from a user terminal through a network filter.

[0064] Refer to the above S101, which will not be elaborated here.

[0065] S202. According to at least one preset gray release rule, obtain the target version to which the target service corresponding to the access request belongs.

[0066] In this embodiment, the target version includes at least a first version or a second version. The release time of the first version is earlier than that of the second version. The data calling method corresponding to the first version is local calling, and the data calling method corresponding to the second version is remote calling. In this embodiment, the release time of the first version or the second version is used to distinguish the first version and the second version. In other embodiments, the research and development time, the online time, or the time when it is prepared to be promoted to all users can also be used to distinguish the first version and the second version. For example, the release time of the first version is September 1, 2022, and the release time of the second version is October 1, 2022. In other words, the first version is equivalent to the old version, and the second version is equivalent to the new version.

[0067] For the specific steps of obtaining the target version to which the target service corresponding to the access request belongs according to at least one preset gray release rule, refer to the above S202, which will not be elaborated here.

[0068] S203A. When the target version is the second version, forward the access request to the server corresponding to the second version.

[0069] When the target version corresponding to the target service belongs to the second version, the data calling method corresponding to the second version is remote calling. Since the second version is equivalent to the new version, the service data of the target service belonging to the second version is stored in a server other than the server that receives the access request. According to the server domain name corresponding to the second version preset, further forward the access request to the server corresponding to the second version, so as to obtain the service data of the target service belonging to the second version stored in the server corresponding to the second version.

[0070] Specifically, an encapsulated request is obtained by encapsulating an access request through a network applet ServletRequest, and the encapsulated request is forwarded to the server corresponding to the second version; service data sent by the server in response to the access request is received through a network filter, and further, an encapsulated response sent by the server in response to the encapsulated request is received. The encapsulated response is obtained by the server encapsulating the service data through a network applet set on the server, and the service data is obtained based on the encapsulated response.

[0071] As Figure 4 shown, it is a schematic flowchart of a gray release method provided by an embodiment of the present application. The server 202 corresponding to the first version includes a network filter Webfilter2021, a gray release rule Forward Rule2022, service data 2023 corresponding to the first version, and a network applet ServletRequest2024. The network applet Servlet is a small Java program running in the server 202, and receives and responds to access requests from a user terminal through http (HyperText Transfer Protocol). It can be understood that the number of gray release rules 2022 is at least one, Figure 4 only for illustration.

[0072] Specifically, in Figure 4 the illustrated embodiment, when the server 202 corresponding to the first version receives an access request sent by the user terminal 201, and determines through a preset gray release rule 2022 that the target version of the target service targeted by the access request is the second version, the access request implemented based on the http protocol is encapsulated through the network applet 2024, that is, the request parameters in the access request are encapsulated to obtain an encapsulated request corresponding to the access request, and further, the encapsulated request is sent to the server 203 corresponding to the second version according to the domain name of the server 203 corresponding to the second version.

[0073] S204A. Receive service data sent by the server in response to the access request through a network filter.

[0074] After receiving the access request, the server corresponding to the second version sends service data of the target service belonging to the second version to the server corresponding to the first version in response to the access request, so that the server corresponding to the first version receives the service data of the target service of the second version.

[0075] In one embodiment, service data sent by the server in response to the access request is received through a network filter, and further, an encapsulated response sent by the server in response to the encapsulated request is received. The encapsulated response is obtained by the server encapsulating the service data through a network applet set on the server, and the service data is obtained based on the encapsulated response.

[0076] In this embodiment, after the server corresponding to the second version receives the encapsulated request corresponding to the access request encapsulated by the network applet ServletRequest, it determines the service data corresponding to the access request, and further re-encapsulates the service data through the network applet ServletResponse to obtain an encapsulated response, so that the server corresponding to the first version receives the encapsulated response and then unpacks the encapsulated response to obtain the service data.

[0077] S203B: When the target version is the first version, the locally stored service data is called through the network filter.

[0078] When the target version corresponding to the target service belongs to the first version, the data call method corresponding to the first version is a local call. Since the first version is equivalent to the old version, the service data of the target service belonging to the first version is stored in the server that receives the access request. According to the preset storage path corresponding to the second version, the service data of the target service belonging to the first version is further stored in the local server.

[0079] S205: Send the service data to the user terminal.

[0080] See the above S104, which will not be described again here.

[0081] In one embodiment, after detecting that the grayscale release for the target service belonging to the second version is completed, the target service belonging to the first version is taken offline. The method for judging whether the grayscale release of the target service belonging to the second version is completed is that the access request for the target service is no longer forwarded to the target service of the first version. For example, after the target service of the second version is launched or released, the grayscale release is preset to be completed within one month, that is, the grayscale release ratio in the grayscale release rules is getting higher and higher. When the preset time is reached or the grayscale release ratio is 100%, in other words, it can be understood that the grayscale release of the target service belonging to the second version is completed when the access request is no longer forwarded to the target service of the first version or the service data of the target service of the first version is no longer sent to the user terminal.

[0082] After detecting that the grayscale release of the target service belonging to the second version is completed, the target service belonging to the first version will be taken offline, thereby reducing the storage space of the server corresponding to the first version occupied by the service data or logical resources of the first version of the target service, and reducing the thread resources of the server corresponding to the first version occupied by determining whether the service data of the target service corresponding to the first version needs to be sent to the user terminal.

[0083] In this application, a network filter is set on the server. The server receives an access request for a target service from a user terminal through the network filter, and based on the data call method corresponding to the target version, calls the service data of the target service belonging to the target version through the network filter, and sends the service data to the user terminal. Compared with setting at least one intermediate device such as a gateway between the user terminal and the server to implement the above functions, this application effectively reduces the deployment cost and maintenance cost brought by deploying intermediate devices. And in this application, based on the received access request, the target version to which the target service targeted by the access request belongs is obtained according to at least one preset gray release rule. In other words, this application can customize at least one gray release rule according to actual needs. Compared with using devices such as gateways, the cost of customizing gray release rules through network filters is lower, and the reusability of network filters is higher. And in this application, service data of different versions is called through different data call methods, and the service data of different versions can be isolated from each other. Therefore, the readability of the code data of different versions is better.

[0084] In one embodiment, as Figure 5 shown, it is a schematic flowchart of a gray release method proposed by an embodiment of this application. This method can be implemented depending on a computer program and can run on a gray release device based on the von Neumann architecture. This computer program can be integrated in an application or run as an independent tool class application.

[0085] Specifically, this gray release method includes:

[0086] S301. Receive a setting instruction.

[0087] The setting instruction can be sent by the user to the server through the user terminal in a wired connection or wireless connection manner, or other possible sending methods, so that the server executing the gray release method receives the setting instruction.

[0088] S302. In response to the setting instruction, set at least one gray release rule.

[0089] Each gray-scale release rule includes at least one rule parameter, and at least one rule parameter includes at least one of the following parameters: user characteristics, the sending time of the access request, and the sending location of the access request. User characteristics can be the identity characteristics or activity characteristics of the user. For example, the identity information of the user can be understood as the user identity, that is, the identification data representing the user's identity. For example, the identity characteristics of the user are the user's ID number, name, mobile phone number, email address, etc., and can also be the device data of the electronic device used by the user, and can also be the characteristics generated according to physiological characteristics. The user's identity characteristics can also be a combination of multiple pieces of the above data, which will not be listed here. The activity characteristics of the user can be the daily active duration, daily active time period, daily startup times, monthly active duration, monthly active time period, monthly startup times, etc., and can also be a combination of multiple pieces of the above data, which will not be listed here. At least one rule parameter can also be other parameters other than the above rule parameters, which are set by relevant personnel as needed.

[0090] According to the setting instruction, each gray-scale release rule includes at least one parameter and the parameter value corresponding to the parameter. For example, a gray-scale release rule is that the access requests of users with more than 2 daily startup times and more than 1 hour of daily active duration target the target service belonging to the second version. In this gray-scale release rule, the rule parameters include the daily startup times and the daily active duration, and corresponding parameter values are set for each rule parameter.

[0091] In one embodiment, in response to the setting instruction, at least one gray-scale release rule is set, and the release ratio of each gray-scale release rule is gradually configured. Gradual configuration can be understood as increasing the release ratio of each gray-scale release rule over time, or increasing the release ratio of each gray-scale release rule according to the R & D progress of the target service of the new version. For example, a gray-scale release rule is that the access requests of users with more than 2 daily startup times and more than 1 hour of daily active duration target the target service belonging to the second version, and the initial release ratio of this gray-scale release rule is 20%, which is gradually increased to 100%. When 10,000 access requests that meet this gray-scale release rule are received, the service data of the second version is sent to the user terminals corresponding to 20% of the access requests, and the service data of the first version is sent to the user terminals corresponding to 80% of the access requests.

[0092] In this embodiment, it is supported to configure the release ratio for each gray-scale release rule, enrich the gray-scale release process, and greatly improve the personalization degree of the gray-scale release of the target service.

[0093] S303. Abstract at least one gray-scale release rule into a rule interface.

[0094] Abstract at least one gray release rule into an interface, so that the server executing the gray release method can directly call or inherit this interface to determine the target version to which the target service targeted by the access request belongs. Since the at least one gray release rule is set in the server including the service data of the target service belonging to the first version, at least one gray release rule can be set according to the business logic of the service data and at least one gray release rule can be abstracted into a rule interface, thereby realizing the highly customized gray release rules.

[0095] S304. The server receives, through the network filter, an access request from the user terminal for the target service.

[0096] Refer to the above S101, which will not be elaborated here.

[0097] S305. According to at least one preset gray release rule, obtain the target version to which the target service targeted by the access request belongs.

[0098] Specifically, according to at least one rule parameter corresponding to each gray release rule, obtain the parameter value of each rule parameter in at least one rule parameter corresponding to the access request; according to the matching situation between the parameter values of each rule parameter in at least one rule parameter corresponding to the access request and at least one gray release rule, obtain the target version to which the target service targeted by the access request belongs.

[0099] For example, a gray release rule is that the access request of a user whose daily startup times are greater than 2 times and whose daily active duration is greater than 1 hour for the target service belongs to the second version. Therefore, for the parameters of the daily startup times and the daily active duration included in the above gray release rule, obtain the parameter values of the above two parameters corresponding to the access request, that is, obtain the daily startup times and the daily active duration of the user corresponding to the user terminal sending the access request for the target service. When the daily startup times and the daily active duration of the user for the target service match the gray release rule, that is, satisfy the gray release rule, the target version to which the target service targeted by the access request belongs is the second version. If the daily startup times and the daily active duration of the user for the target service do not match the gray release rule, that is, do not satisfy the gray release rule, the target version to which the target service targeted by the access request belongs is the first version.

[0100] In this embodiment, by obtaining the parameter values of each rule parameter in at least one rule parameter corresponding to the access request and the matching situation with at least one gray release rule to obtain the target version to which the target service targeted by the access request belongs, the accuracy of obtaining the target version to which the target service targeted by the access request belongs can be improved.

[0101] S306. According to the data call method corresponding to the target version, call the service data of the target service belonging to the target version through the network filter.

[0102] Refer to the above S103, which will not be elaborated here.

[0103] S307: Send the service data to the user terminal.

[0104] Refer to the above S104, which will not be elaborated here.

[0105] In this application, a network filter is set on the server. The server receives an access request for a target service from the user terminal through the network filter, and based on the data call method corresponding to the target version, calls the service data of the target service belonging to the target version through the network filter, and sends the service data to the user terminal. Compared with setting at least one intermediate device such as a gateway between the user terminal and the server to implement the above functions, this application effectively reduces the deployment cost and maintenance cost brought by deploying intermediate devices. And in this application, based on the received access request, the target version to which the target service corresponding to the access request belongs is obtained according to at least one preset gray release rule. In other words, this application can customize at least one gray release rule according to actual needs. Compared with using devices such as gateways, the cost of customizing the gray release rule through the network filter is lower, and the reusability of the network filter is higher. And in this application, the service data of different versions is called through different data call methods, and the service data of different versions can be isolated from each other. Therefore, the readability of the code data of different versions is better.

[0106] The following is an apparatus embodiment of this application, which can be used to execute the method embodiment of this application. For details not disclosed in the apparatus embodiment of this application, please refer to the method embodiment of this application.

[0107] Please refer to Figure 6 , which shows a schematic structural diagram of a gray release apparatus provided by an exemplary embodiment of this application. The gray release apparatus can be implemented as all or part of the apparatus through software, hardware, or a combination of both. A network filter is set on the gray release apparatus. The gray release apparatus includes an access request module 601, a version acquisition module 602, a service call module 603, and a data sending module 604.

[0108] The access request module 601 is configured to receive an access request for a target service from the user terminal through the network filter;

[0109] The version acquisition module 602 is configured to obtain the target version to which the target service corresponding to the access request belongs according to at least one preset gray release rule;

[0110] The service call module 603 is configured to call the service data of the target service belonging to the target version through the network filter according to the data call method corresponding to the target version;

[0111] A data sending module 604, configured to send service data to a user terminal.

[0112] In one embodiment, the target version includes at least a first version or a second version, and the release time of the first version is earlier than that of the second version;

[0113] The data calling method corresponding to the first version is local calling, and the data calling method corresponding to the second version is remote calling.

[0114] In one embodiment, the service calling module 603 includes:

[0115] A request forwarding unit, configured to forward an access request to a server corresponding to the second version;

[0116] A data receiving unit, configured to receive, through a network filter, service data sent by the server in response to the access request, where the service data is service data corresponding to a target service belonging to the target version.

[0117] In one embodiment, the request forwarding unit includes:

[0118] An encapsulation subunit, configured to encapsulate an access request through a network applet to obtain an encapsulated request, and forward the encapsulated request to a server corresponding to the second version;

[0119] The data receiving unit includes:

[0120] A first receiving subunit, configured to receive, through a network filter, an encapsulated response sent by the server in response to the encapsulated request, where the encapsulated response is obtained by the server encapsulating service data through a network applet set on the server;

[0121] A second receiving subunit, configured to obtain service data according to the encapsulated response.

[0122] In one embodiment, the service calling module 603 includes:

[0123] A local calling unit, configured to call, through a network filter, service data of a target service belonging to the target version stored locally.

[0124] In one embodiment, the gray release device further includes:

[0125] An instruction receiving module, configured to receive a setting instruction;

[0126] A rule setting module, configured to, in response to the setting instruction, set at least one gray release rule, where each gray release rule includes at least one rule parameter, and the at least one rule parameter includes at least one of the following parameters: user characteristics, sending time of the access request, and sending location of the access request.

[0127] In one embodiment, the rule setting module includes:

[0128] A ratio setting unit, configured to set at least one gray release rule in response to a setting instruction, and gradually configure the release ratio of each gray release rule.

[0129] In one embodiment, the gray release device further includes:

[0130] An abstract interface module, configured to abstract at least one gray release rule into a rule interface;

[0131] The version acquisition module 602 includes:

[0132] A version acquisition unit, configured to acquire the target version to which the target service targeted by the access request belongs according to the rule interface.

[0133] In one embodiment, the version acquisition module 602 includes:

[0134] A parameter acquisition unit, configured to acquire the parameter values of the respective rule parameters in at least one rule parameter corresponding to the access request according to at least one rule parameter corresponding to each gray release rule.

[0135] A parameter matching unit, configured to obtain the target version to which the target service targeted by the access request belongs according to the matching condition between the parameter values of the respective rule parameters in at least one rule parameter corresponding to the access request and at least one gray release rule.

[0136] In one embodiment, the gray release device further includes:

[0137] A service off-line module, configured to take the target service belonging to the first version off-line after detecting that the gray release of the target service belonging to the second version is completed.

[0138] In this application, a network filter is set on the server. The server receives an access request for a target service from a user terminal through the network filter, and based on the data call method corresponding to the target version, calls the service data of the target service belonging to the target version through the network filter, and sends the service data to the user terminal. Compared with setting at least one intermediate device such as a gateway between the user terminal and the server to implement the above functions, this application effectively reduces the deployment cost and maintenance cost brought by deploying intermediate devices. And in this application, based on the received access request, the target version to which the target service corresponding to the access request belongs is obtained according to at least one preset gray release rule. In other words, this application can customize at least one gray release rule according to actual needs. Compared with using devices such as gateways, the cost of customizing the gray release rule through the network filter is lower, and the reusability of the network filter is higher. And in this application, different versions of service data are called through different data call methods, and different versions of service data can be isolated from each other. Therefore, the readability of the code data of different versions is better.

[0139] It should be noted that when the gray release device provided in the above embodiment executes the gray release method, only the above-mentioned division of each functional module is used for illustration. In actual application, the above functions can be allocated to different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the gray release device provided in the above embodiment and the gray release method embodiment belong to the same concept, and the implementation process is shown in detail in the method embodiment, which will not be repeated here.

[0140] At the same time, those skilled in the art can clearly understand that the technical solution of this application can be realized by means of software and / or hardware. The "unit" and "module" in this application refer to software and / or hardware that can independently complete or cooperate with other components to complete specific functions. Among them, the hardware can be, for example, a Field-Programmable Gate Array (FPGA), an Integrated Circuit (IC), etc.

[0141] The serial numbers of the above embodiments of this application are only for description and do not represent the advantages and disadvantages of the embodiments.

[0142] The embodiment of this application also provides a computer storage medium, which can store multiple instructions, and the instructions are suitable for being loaded and executed by a processor to perform the gray release method as shown in the above Figure 1 - Figure 5 shown embodiment. The specific execution process can refer to the specific description of the Figure 1 - Figure 5 shown embodiment, which will not be repeated here.

[0143] The present application also provides a computer program product. The computer program product stores at least one instruction, and the at least one instruction is loaded and executed by a processor to perform the gray release method of the embodiment as described above Figure 1 - Figure 5 The specific execution process can refer to Figure 1 - Figure 5 the specific description of the embodiment shown, which will not be elaborated here.

[0144] Please refer to Figure 7 , which is a schematic structural diagram of an electronic device provided by an embodiment of the present application. As Figure 7 shown, the electronic device 700 may include: at least one processor 701, at least one network interface 704, a user interface 703, a memory 705, and at least one communication bus 702.

[0145] Among them, the communication bus 702 is used to realize the connection and communication between these components.

[0146] Among them, the user interface 703 may include a display screen (Display) and a camera (Camera). Optionally, the user interface 703 may further include a standard wired interface and a wireless interface.

[0147] Among them, the network interface 704 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface).

[0148] Among them, the processor 701 may include one or more processing cores. The processor 701 connects various parts within the entire server 700 through various interfaces and lines, and executes various functions of the server 700 and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 705, and by calling the data stored in the memory 705. Optionally, the processor 701 may be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), or programmable logic array (PLA). The processor 701 may integrate one or a combination of several of a central processing unit (CPU), a graphics processing unit (GPU), and a modem, etc. Among them, the CPU mainly processes the operating system, user interface, application programs, etc.; the GPU is responsible for rendering and drawing the content to be displayed on the display screen; the modem is used to process wireless communication. It can be understood that the above-mentioned modem may not be integrated into the processor 701 and may be implemented separately by a single chip.

[0149] Among them, the memory 705 may include random access memory (RAM) and may also include read-only memory. Optionally, the memory 705 includes a non-transitory computer-readable storage medium. The memory 705 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 705 may include a program storage area and a data storage area. Among them, the program storage area may store instructions for implementing the operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area may store the data involved in the above-mentioned various method embodiments. Optionally, the memory 705 may also be at least one storage device located far from the aforementioned processor 701. As Figure 7 shown, the memory 705, as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a gray-scale release application program.

[0150] In Figure 7In the electronic device 700 shown, the user interface 703 is mainly used to provide an interface for the user to input and obtain the data input by the user; and the processor 701 can be used to call the grayscale release application program stored in the memory 705 and specifically perform the following operations:

[0151] Receive an access request from the user terminal for a target service through the network filter;

[0152] According to at least one preset grayscale release rule, obtain the target version to which the target service targeted by the access request belongs;

[0153] According to the data calling method corresponding to the target version, call the service data of the target service belonging to the target version through the network filter;

[0154] Send the service data to the user terminal.

[0155] In one embodiment, the target version includes at least a first version or a second version, and the release time of the first version is earlier than that of the second version;

[0156] The data calling method corresponding to the first version is local calling, and the data calling method corresponding to the second version is remote calling.

[0157] In one embodiment, when the target version is the second version, the processor 701 executes to call the service data of the target service belonging to the target version through the network filter according to the data calling method corresponding to the target version, and specifically executes:

[0158] Forward the access request to the server corresponding to the second version;

[0159] Receive the service data sent by the server in response to the access request through the network filter, and the service data is the service data corresponding to the target service belonging to the target version.

[0160] In one embodiment, when the processor 701 executes to forward the access request to the server corresponding to the second version, it specifically executes:

[0161] Encapsulate the access request through a network applet to obtain an encapsulated request, and forward the encapsulated request to the server corresponding to the second version;

[0162] When the processor 701 executes to receive the service data sent by the server in response to the access request through the network filter, it specifically executes:

[0163] Receive the encapsulated response sent by the server in response to the encapsulated request through the network filter, and the encapsulated response is obtained by the server encapsulating the service data through the network applet set on the server;

[0164] Obtain the service data according to the encapsulated response.

[0165] In one embodiment, when the target version is the second version, the processor 701 invokes the service data of the target service belonging to the target version through the network filter according to the data invocation method corresponding to the target version, and specifically executes:

[0166] Invoke the service data of the target service belonging to the target version stored locally through the network filter.

[0167] In one embodiment, before the processor 701 executes to obtain the target version to which the target service targeted by the access request belongs according to at least one preset gray release rule, the processor 701 also executes:

[0168] Receive a setting instruction;

[0169] In response to the setting instruction, set at least one gray release rule, and each gray release rule includes at least one rule parameter, and the at least one rule parameter includes at least one of the following parameters: user characteristics, the sending time of the access request, and the sending location of the access request.

[0170] In one embodiment, when the processor 701 executes to set at least one gray release rule in response to the setting instruction, the specific execution is as follows:

[0171] In response to the setting instruction, set at least one gray release rule and gradually configure the release ratio of each gray release rule.

[0172] In one embodiment, after the processor 701 executes to set at least one gray release rule in response to the setting instruction and before obtaining the target version to which the target service targeted by the access request belongs according to at least one preset gray release rule, the processor 701 also executes:

[0173] Abstract at least one gray release rule into a rule interface;

[0174] When the processor 701 executes to obtain the target version to which the target service targeted by the access request belongs according to at least one preset gray release rule, the specific execution is as follows:

[0175] Obtain the target version to which the target service targeted by the access request belongs according to the rule interface.

[0176] In one embodiment, when the processor 701 executes to obtain the target version to which the target service targeted by the access request belongs according to at least one preset gray release rule, the specific execution is as follows:

[0177] Obtain the parameter values of the respective rule parameters in the at least one rule parameter corresponding to the access request according to the at least one rule parameter corresponding to each gray release rule;

[0178] Based on the matching situation between the parameter values of each rule parameter in at least one rule parameter corresponding to the access request and at least one gray release rule, obtain the target version to which the target service targeted by the access request belongs.

[0179] In one embodiment, after the processor 701 executes sending service data to the user terminal, it also executes:

[0180] After detecting that the gray release of the target service belonging to the second version is completed, take the target service belonging to the first version offline.

[0181] In this application, a network filter is set on the server. The server receives, through the network filter, an access request from the user terminal for the target service, and based on the data call method corresponding to the target version through the network filter, calls the service data of the target service belonging to the target version and sends the service data to the user terminal. Compared with setting at least one intermediate device such as a gateway between the user terminal and the server to implement the above functions, this application effectively reduces the deployment cost and maintenance cost brought by deploying the intermediate device. And in this application, based on the received access request, obtain the target version to which the target service targeted by the access request belongs according to at least one preset gray release rule. In other words, this application can customize at least one gray release rule according to actual needs. Compared with using devices such as gateways, the cost of customizing the gray release rule through the network filter is lower, and the reusability of the network filter is higher. And in this application, different versions of service data are called through different data call methods, and different versions of service data can be isolated from each other. Therefore, the readability of the code data of different versions is better.

[0182] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. Among them, the storage medium can be a magnetic disk, an optical disc, a read-only memory or a random access memory, etc.

[0183] The above-disclosed are only the preferred embodiments of this application. Of course, the scope of rights of this application cannot be limited thereby. Therefore, equivalent changes made according to the claims of this application still fall within the scope covered by this application.

Claims

1. A gray release method, characterized in that, a network filter is set on the server, and the method includes: the server receives an access request for a target service from a user terminal through the network filter; according to at least one preset gray release rule, obtain the target version to which the target service targeted by the access request belongs; according to the data call method corresponding to the target version, call the service data of the target service belonging to the target version through the network filter; send the service data to the user terminal.

2. The gray release method according to claim 1, characterized in that, the target version includes at least a first version or a second version, and the release time of the first version is earlier than the release time of the second version; the data call method corresponding to the first version is local call, and the data call method corresponding to the second version is remote call.

3. The gray release method according to claim 2, characterized in that, when the target version is the second version, the step of calling the service data of the target service belonging to the target version through the network filter according to the data call method corresponding to the target version includes: forward the access request to the server corresponding to the second version; receive, through the network filter, the service data sent by the server in response to the access request, and the service data is the service data corresponding to the target service belonging to the target version.

4. The gray release method according to claim 3, characterized in that, the step of forwarding the access request to the server corresponding to the second version includes: encapsulate the access request through a network applet to obtain an encapsulated request, and forward the encapsulated request to the server corresponding to the second version; the step of receiving, through the network filter, the service data sent by the server in response to the access request includes: receive, through the network filter, an encapsulated response sent by the server in response to the encapsulated request, and the encapsulated response is obtained by the server encapsulating the service data through a network applet set on the server; obtain the service data according to the encapsulated response.

5. The gray release method according to claim 2, characterized in that, when the target version is the second version, the step of calling the service data of the target service belonging to the target version through the network filter according to the data call method corresponding to the target version includes: call, through the network filter, the service data of the target service belonging to the target version stored locally.

6. The gray release method according to claim 1, characterized in that, before obtaining the target version to which the target service targeted by the access request belongs according to at least one preset gray release rule, it further includes: receive a setting instruction; in response to the setting instruction, set the at least one gray release rule, and each gray release rule includes at least one rule parameter, and the at least one rule parameter includes at least one of the following parameters: user characteristics, the sending time of the access request, the sending location of the access request.

7. The gray release method according to claim 6, wherein, responding to the setting instruction to set at least one of the gray release rules includes: responding to the setting instruction to set at least one of the gray release rules and gradually configuring the release ratio of each of the gray release rules.

8. The gray release method according to claim 6, wherein, after responding to the setting instruction to set at least one of the gray release rules and before obtaining the target version of the target service targeted by the access request according to at least one preset gray release rule, further includes: abstracting the at least one gray release rule into a rule interface; the obtaining the target version of the target service targeted by the access request according to at least one preset gray release rule includes: obtaining the target version of the target service targeted by the access request according to the rule interface.

9. The gray release method according to claim 6, wherein, the obtaining the target version of the target service targeted by the access request according to at least one preset gray release rule includes: obtaining the parameter values of each rule parameter in at least one rule parameter corresponding to the access request according to at least one rule parameter corresponding to each of the gray release rules; obtaining the target version of the target service targeted by the access request according to the matching condition between the parameter values of each rule parameter in at least one rule parameter corresponding to the access request and the at least one gray release rule.

10. The gray release method according to claim 2, wherein, after sending the service data to the user terminal, further includes: after detecting that the gray release of the target service belonging to the second version is completed, taking the target service belonging to the first version offline.

11. A gray release device, wherein, a network filter is provided on the gray release device, and the device includes: an access request module, configured to receive, through the network filter, an access request from a user terminal for a target service; a version obtaining module, configured to obtain the target version of the target service targeted by the access request according to at least one preset gray release rule; a service calling module, configured to call, through the network filter, service data of the target service belonging to the target version according to the data calling method corresponding to the target version; a data sending module, configured to send the service data to the user terminal.

12. A computer storage medium, wherein, the computer storage medium stores multiple instructions, and the instructions are suitable for being loaded and executed by a processor to perform the method steps of any one of claims 1 to 10.

13. An electronic device, wherein, including: a processor and a memory; wherein, the memory stores a computer program, and the computer program is suitable for being loaded and executed by the processor to perform the method steps of any one of claims 1 to 10.

Images