Version Release Processing Method, Device, Equipment, and Storage Medium

Abstract

The present application provides a version release processing method, apparatus, device, and storage medium. The method includes: obtaining a first traffic volume in the access data stream of a target application software, where the first traffic volume is intercepted from the access data stream by a traffic interceptor according to a pre-configured traffic interception policy; using a function test instance corresponding to the gray-scale version of the target application software deployed in a test server to perform a release risk test on the gray-scale version based on the first traffic volume to obtain a test result; outputting the test result to a research and development server, where the research and development server determines whether to perform a release process on the gray-scale version on a cloud server based on the test result. It realizes fast and accurate test verification of the gray-scale version of the target application program to avoid the risks brought by direct online release.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular, to a method, apparatus, device, and storage medium for version release processing. Background Art

[0002] Currently, the Function as a Service (FaaS) platform provides developers with a fast way to build cloud-native microservices, eliminating the complexity of managing clusters. Like conventional services, the FaaS scenario also needs to consider how to control the risks brought about by errors in newly deployed versions.

[0003] A traditional solution is to use Canary release deployment for testing to avoid the above-mentioned release risks. However, the biggest drawback of the Canary release deployment solution is that it performs random testing completely according to a ratio, which is not conducive to rapid test verification. Summary of the Invention

[0004] Embodiments of the present invention provide a method, apparatus, device, and storage medium for version release processing, which can quickly and accurately test and verify the gray version of a target application program to avoid the risks brought about by directly performing online release.

[0005] In a first aspect, an embodiment of the present invention provides a method for version release processing, the method including:

[0006] Obtain a first traffic volume in the access data stream of a target application software, where the first traffic volume is intercepted from the access data stream by a traffic interceptor according to a pre-configured traffic interception policy;

[0007] Use a function test instance corresponding to the gray version of the target application software deployed in a test server to perform a release risk test on the gray version based on the first traffic volume, and obtain a test result;

[0008] Output the test result to a research and development server, where the research and development server determines whether to perform release processing on the gray version on a cloud server based on the test result.

[0009] In a second aspect, an embodiment of the present invention provides a version release processing system, the system including:

[0010] A traffic interceptor, configured to intercept a first traffic volume from the access data stream of a target application software according to a pre-configured traffic interception policy, and send the first traffic volume to a test server;

[0011] The test server, connected to the traffic interceptor, is configured to use a function test instance corresponding to the gray version of the target application software deployed in advance to perform a release risk test on the gray version based on the first traffic volume, and obtain a test result;

[0012] A research and development server, connected to the test server, is configured to determine whether to perform a release process on the gray-scale version on the cloud server based on the test result.

[0013] In a third aspect, an embodiment of the present invention provides a version release processing apparatus, which includes:

[0014] An acquisition module, configured to acquire a first traffic volume in the access data stream of the target application software, where the first traffic volume is intercepted from the access data stream by a traffic interceptor according to a pre-configured traffic interception policy;

[0015] A test module, configured to use a function test instance corresponding to the gray-scale version of the target application software deployed in the test server to perform a release risk test on the gray-scale version based on the first traffic volume, and obtain a test result;

[0016] An output module, configured to output the test result to the research and development server, where the research and development server determines whether to perform a release process on the gray-scale version on the cloud server based on the test result.

[0017] In a fourth aspect, an embodiment of the present invention provides an electronic device, including: a memory, a processor, and a communication interface; wherein, an executable code is stored on the memory, and when the executable code is executed by the processor, the processor can at least implement the version release processing method as described in the first aspect.

[0018] In a fifth aspect, an embodiment of the present invention provides a non-transitory machine-readable storage medium, on which an executable code is stored, and when the executable code is executed by a processor of an electronic device, the processor can at least implement the version release processing method as described in the first aspect.

[0019] In the embodiment of the present invention, an FaaS test server for testing the gray-scale version of the target application software can be independently deployed outside the FaaS cloud server. Before online release, online testing is first performed through the method provided by the present invention. A traffic interceptor is used to intercept a first traffic volume from the access data stream of the target application software according to a pre-configured traffic interception policy. After obtaining the first traffic volume in the access data stream of the target application software, a function test instance corresponding to the gray-scale version of the target application software deployed in the test server is used to perform a release risk test on the gray-scale version based on the first traffic volume, and a test result is obtained. Then, the test result is output to the research and development server, so that the research and development server determines whether to perform a release process on the gray-scale version on the cloud server based on the test result.

[0020] By adding an independent online testing phase before online release and using an independently deployed online FaaS testing server to conduct online testing on the gray version of the target application software. Since a traffic interceptor is added at the entrance of the access data stream, it supports developers to intercept the specified first traffic to the online FaaS testing server according to the pre-configured traffic interception policy. Since this FaaS testing server is independent of the FaaS cloud server and the function test instances corresponding to the gray version of the target application software are deployed on this FaaS testing server, the function test instances corresponding to the gray version are used to conduct release risk testing on the gray version based on the first traffic, obtain the test results, and then output the test results to the R & D server, so that the R & D server can determine whether to perform release processing on the gray version on the cloud server based on the test results. That is, an independent control strategy is adopted to achieve better isolation and higher test verification efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0022] Figure 1 It is a flowchart of a version release processing method provided by an embodiment of the present invention;

[0023] Figure 2 It is a schematic structural diagram of a version release processing system provided by an embodiment of the present invention;

[0024] Figure 3 It is a schematic diagram of an optional version release processing flow provided by an embodiment of the present invention;

[0025] Figure 4 It is a schematic structural diagram of a version release processing device provided by an embodiment of the present invention;

[0026] Figure 5 It is a schematic structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0027] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art without creative efforts based on the embodiments of the present invention belong to the scope of protection of the present invention.

[0028] The following will describe in detail some embodiments of the present invention. Without conflict between the embodiments, the following embodiments and the features in the embodiments can be combined with each other. In addition, the step timings in the following method embodiments are only examples and are not strictly limited.

[0029] First, the terms or concepts involved in the embodiments of the present invention will be explained:

[0030] Function as a Service (FaaS): It is a cloud computing service that allows developers to build, calculate, run, and manage these application packages in the form of functions without maintaining their own infrastructure.

[0031] Canary release strategy: It is a gray release strategy, which means gradually updating the version of the backend application in stages in the production environment (requiring traffic control capabilities). After small-scale verification meets expectations, it is then promoted to the entire production environment.

[0032] API traffic: That is, data interaction without direct human participation, which has reached several times that of traditional HTTP traffic.

[0033] HTTP traffic: The traffic required for a file to be downloaded from the server to the user device.

[0034] Domain Name System (DNS) can resolve domain names into IP addresses to provide users with Internet access. Ultimately, being able to access the Internet means finding the IP address.

[0035] Active Mobility Domain Controller (AMDC): The domain controller DC provides services through Active Directory (AD). For example, it is responsible for maintaining the Active Directory database, auditing whether the user's account and password are correct, and replicating the Active Directory database to other domain controllers.

[0036] Virtual IP (VIP): An IP that is not assigned to a real host. That is to say, the host providing the database server externally has not only a real IP but also a virtual IP. Either of these two IPs can be used to connect to this host. The virtual IP is configured for the database connection item in all projects. When the server fails and cannot provide services externally, this virtual IP is dynamically switched to the standby host.

[0037] In the relevant technical field, Function as a Service (FaaS) refers to an event-driven execution model that runs in stateless containers and can leverage the services of a FaaS provider to manage server-side logic and state. FaaS platforms provide developers with a quick way to build cloud-native microservices, eliminating the complexity of cluster management. Developers will have a programming environment where they can write small, simple microservices like functions in a variety of languages, including Java, C#, JavaScript, and Python. Developers can package and deploy a function as a ZIP or JAR file, or as a custom image.

[0038] For example, FaaS providers will automatically scale services up and down based on service needs. Like regular services, FaaS scenarios also require consideration of how to prevent errors in newly deployed versions from causing significant impact.

[0039] To mitigate the significant impact of errors in newly deployed versions, one solution is to use canary releases. Canary releases are a software release strategy that deploys a new version for testing while maintaining the base version as the production version for normal operations. However, the biggest drawback of canary releases is that they are completely randomized, which doesn't facilitate rapid testing and verification.

[0040] For example, after releasing a new version, developers want to direct all their traffic to the Canary version for immediate testing. Canary traffic is typically kept at a small percentage and randomly selected, resulting in only a small amount of developer traffic being directed to the Canary version. Therefore, developers rely more on real-time testing to identify issues. However, since Canary traffic is typically kept at a small percentage, real-time testing metrics may not provide clear feedback, thus delaying risk detection and hindering release risk control.

[0041] In view of this, an embodiment of the present invention provides a version release processing solution. The version release processing method provided in the embodiment of the present invention can be executed by an electronic device. In actual applications, the electronic device can be a server or a user terminal such as a PC. The server can be a physical server or a virtual server (virtual machine) in the cloud.

[0042] Figure 1 A flowchart of a version release processing method provided by an embodiment of the present invention is as follows Figure 1 As shown, the method includes the following steps:

[0043] 101. Obtain first traffic in an access data stream of a target application software, wherein the first traffic is intercepted from the access data stream by a traffic interceptor according to a pre-configured traffic interception policy.

[0044] 102. Use a function test instance corresponding to the grayscale version of the target application software deployed in the test server to perform a release risk test on the grayscale version based on the first traffic flow to obtain a test result.

[0045] 103. Output the test results to the R&D server, where the R&D server determines whether to execute the release process for the grayscale version on the cloud server based on the test results.

[0046] Optionally, in an embodiment of the present invention, a corresponding traffic interception strategy is determined based on the characteristics of the access data flow, such as the traffic source, and then different parsing and forwarding are performed on the first traffic and the second traffic in the access data flow, respectively.

[0047] Optionally, in the embodiment of the present invention, the first flow and the second flow may be directly intercepted from the access data flow according to a developer's customized interception strategy.

[0048] Optionally, the grayscale version can be a newly deployed version of the target application, i.e., an updated version. The target application can be any application that is allowed to run in a cloud-native microservice built on a FaaS platform. The specific type and category are not limited.

[0049] Optionally, based on the traffic source of the target application software's access data flow, the access data flow can be classified as HTTP traffic or wireless traffic. Specifically, the aforementioned pre-configured traffic interception strategy can be selected based on the traffic source of the access data flow. For example, for HTTP traffic, the domain name system (DNS) can be used for traffic interception, while for wireless traffic, the AMDC can be used for traffic interception to obtain the first traffic in the access data flow.

[0050] The aforementioned cloud server, also known as a cloud computing server, can be, for example, a FaaS cloud server. This FaaS cloud server is deployed with a function compute instance corresponding to the production version of the target application software, and is used to handle other online traffic in addition to the first traffic. In an embodiment of the present invention, a FaaS test server for testing a grayscale version of the target application software is independently deployed in addition to the FaaS cloud server. This server allows for online testing using the method provided by the present invention before online release.

[0051] Optionally, a traffic interceptor is used to intercept the first traffic from the access data stream of the target application software according to a pre-configured traffic interception policy. After obtaining the first traffic in the access data stream of the target application software, a function test instance corresponding to the gray version of the target application software deployed in the test server is used to perform a release risk test on the gray version based on the first traffic, and a test result is obtained. Then, the test result is output to the R & D server so that the R & D server can determine whether to perform a release process on the gray version on the cloud server based on the test result.

[0052] In the embodiment of the present invention, outside the FaaS cloud server, an FaaS test server for testing the gray version of the target application software is independently deployed in advance. That is, it can be understood that an independent online test phase is added before the online release to implement online testing of the gray version of the target application software using the independently deployed online FaaS test server. An independent control strategy is adopted to achieve better isolation and higher test verification efficiency.

[0053] Optionally, Figure 2 The structure diagram of a version release processing system provided by an embodiment of the present invention is shown as Figure 2 As shown, by adding a traffic interceptor at the entrance of the access data stream, it supports developers to intercept the specified first traffic to the online FaaS test server according to a pre-configured traffic interception policy. Since the FaaS test server is independent of the FaaS cloud server, the FaaS test server uses a function test instance corresponding to the gray version to perform a release risk test on the gray version based on the first traffic, and a test result is obtained. For example, test results such as no release risk, there is a risk and it is not conducive to release, and there is a low risk and it can be tried to release. Then, the test result is output to the R & D server so that the R & D server can determine whether to perform a release process on the gray version on the FaaS cloud server based on the test result. For example, if the test result is: no release risk, there is a low risk and it can be tried to release, the R & D server can instruct the FaaS cloud server to release the gray version of the target application program.

[0054] After passing through the online test phase and then entering the online release phase, and in the online test phase, the first traffic is intercepted from the access data stream according to a pre-configured traffic interception policy, which can achieve fast and accurate test verification of the gray version of the target application program to avoid the risks brought by direct online release.

[0055] There is also an optional embodiment. The above method further includes:

[0056] Obtain the second traffic in the access data stream of the target application software; use the function computing instance corresponding to the production version of the target application software deployed in the above cloud server to undertake the above second traffic, where the second traffic is other traffic in the access data stream except the first traffic.

[0057] Optionally, a function computing instance corresponding to the production version of the target application software deployed in the FaaS cloud server. The second traffic is other traffic in the access data stream except the first traffic.

[0058] Still as Figure 2 As shown, by adding a traffic interceptor at the entrance of the access data stream, it supports developers to intercept the specified first traffic to the online FaaS test server according to the pre-configured traffic interception policy. Then, the second traffic in the access data stream of the target application software is given to the FaaS cloud server, and the function computing instance corresponding to the production version of the target application software deployed in the FaaS cloud server undertakes the second traffic.

[0059] Since the FaaS cloud server and the FaaS test server are two separate and independent clusters respectively, therefore, the basic version of the target application software can be deployed in the FaaS cloud server as the production version, and the application programming interface gateway deployed in the FaaS cloud server is used to request the scheduler to create a function computing instance corresponding to the production version after receiving the second traffic, and forward the second traffic to the function computing instance after successful creation. There is no need to conduct online release testing on the FaaS cloud server, making the release testing process safer and faster.

[0060] Still as Figure 2 As shown, after intercepting the first traffic, use a load balancer to perform load balancing processing on the first traffic and the second traffic. For example, the load balancer includes a load soft load balancing controller and a four-layer reverse proxy server, which are respectively responsible for service discovery, routing, and load balancing, and can achieve the effect of affinity routing.

[0061] An optional embodiment, as Figure 3 As shown in the schematic diagram of an optional version release processing flow, according to the traffic source of the access data stream of the target application software, the access data stream is divided into HTTP traffic or wireless traffic. For HTTP traffic, the traffic interceptor can use the Domain Name System (DNS) for traffic interception, and for wireless traffic, it can use the Active Mobility Domain Controller (AMDC) for traffic interception to obtain the first traffic in the access data stream. By setting the traffic interceptor to automatically intercept the specified first traffic, the efficiency and experience of developers are improved.

[0062] After obtaining the first traffic in the access data stream of the target application software, the above method can also send the first traffic to the first virtual IP provided in the load balancer, perform load balancing processing on the first traffic, and then forward the processed first traffic to the test server;

[0063] When implementing the sending of the second traffic in the access data stream to the FaaS cloud server, still as Figure 3 shown, the second traffic can be sent to the second virtual IP provided in the load balancer, perform load balancing processing on the second traffic, and then forward the processed second traffic to the FaaS cloud server.

[0064] Optionally, the load balancer provides a dedicated first virtual IP for the FaaS test server and a dedicated second virtual IP for the FaaS cloud server respectively.

[0065] As described above, after obtaining the first traffic in the access data stream of the target application software, the first traffic can be sent to the first virtual IP provided by the load balancer for the FaaS test server, perform load balancing processing on the first traffic, and then forward the processed first traffic to the test server; similarly, after obtaining the second traffic in the access data stream of the target application software, the second traffic can be sent to the second virtual IP provided by the load balancer for the FaaS cloud server, perform load balancing processing on the second traffic, and then forward the processed second traffic to the FaaS cloud server.

[0066] For example, under the microservice architecture built by the FaaS test server, an application program may be split into multiple functions. If more than one function changes, integration testing between the Canary versions of these functions needs to be done online, and the Canary release and deployment solution cannot meet the requirements.

[0067] Therefore, in the embodiments of the present invention, if it is determined that at least one of the multiple functions obtained by splitting the target application software changes, when multiple functions call each other (for example, remote procedure call), the load balancer is used to provide an affinity routing function for the remote procedure call between the multiple functions to integrate and test the first traffic corresponding to the multiple functions. That is, through the affinity routing function provided by the load balancing policy controller, the problem of being unable to perform online integration testing on multiple functions currently existing is solved.

[0068] Through the affinity routing function provided by the load balancing policy controller, a request from a function A in the FaaS test server to another function B will be routed to the function computing instance of function B in the same environment, thereby realizing the function of online integration testing of multiple functions under the microservice architecture.

[0069] Still as Figure 3As shown, the application programming interface gateway deployed in the FaaS test server is used to request the scheduler to create a function test instance corresponding to the gray version after receiving the first traffic, and forward the first traffic to the function test instance after successful creation.

[0070] Moreover, the application programming interface gateway deployed in the FaaS cloud server is used to request the scheduler to create a function computing instance corresponding to the production version after receiving the second traffic, and forward the second traffic to the function test instance after successful creation.

[0071] Optionally, in the embodiments of the present invention, the method may further include the following method steps:

[0072] Detect whether the traffic value of the first traffic is greater than a preset threshold; if the traffic value of the first traffic is greater than the preset threshold, in addition to using the function test instance corresponding to the gray version of the target application software deployed in the test server to perform a release risk test on the gray version based on the first traffic, a gray release deployment policy is also executed on the target application software.

[0073] That is, if the intercepted traffic value of the first traffic is relatively large and has exceeded the preset threshold, the function test instance corresponding to the gray version of the target application software deployed in the test server can be used to perform a release risk test on the gray version based on the first traffic. In addition, a gray release deployment policy is also executed on the target application software, that is, the two release deployment policies are used in combination. In this way, the disadvantages of the Canary gray release deployment policy can be avoided, while retaining the advantages of the Canary release deployment solution.

[0074] Through the above solution of using the release deployment policies in combination, the problems of low test efficiency of the Canary gray release deployment policy solution and the inability to perform online integration tests on multiple Canary version functions can be solved. However, the Canary gray release deployment policy can be retained to test the updated version in the real environment. When there are problems with the updated version, at most only some users are affected, and a safe and fast rollback policy is supported. For example, the traffic routed to the new version can be switched to other old version machines.

[0075] To help discover problems and reduce risks after release, optionally, in the embodiments of the present invention, the method further includes: after performing release processing on the gray version, executing a gray release deployment policy on the target application software.

[0076] As mentioned above, a function test instance corresponding to the gray version and a function computing instance corresponding to the production version are deployed in the FaaS cloud server.

[0077] In an alternative embodiment, a canary release deployment strategy is executed for the target application software. Specifically, the access data stream can be randomly split into a first traffic and a second traffic according to a predetermined ratio; then, the first traffic and the second traffic are sent to the FaaS cloud server, so that the FaaS cloud server can perform a release risk test on the canary version based on the first traffic.

[0078] Optionally, during the canary release deployment process, all API traffic is randomly split into the production version and the canary version according to a pre-configured ratio. By keeping the canary traffic at a small ratio and randomly selecting it, the release risk can be controlled. After the test metrics meet the requirements, the canary version can be promoted to the production version, so that the new functions developed for the target application software are available in the production stage.

[0079] The solution of the present invention provides a version release processing solution in the FaaS scenario, which solves the problems of low developer testing efficiency and inability to integrate and test multiple canary version functions online in the canary release deployment solution, while retaining the advantages of the canary release deployment solution.

[0080] An embodiment of the present invention further provides a version release processing system, as Figure 2 shown. The system includes:

[0081] A traffic interceptor, configured to intercept a first traffic from the access data stream of the target application software according to a pre-configured traffic interception strategy, and send the first traffic to the test server;

[0082] A test server, connected to the traffic interceptor, configured to perform a release risk test on the canary version based on the first traffic by using a function test instance corresponding to the canary version of the target application software deployed in advance, and obtain a test result;

[0083] A R & D server, connected to the test server, configured to determine whether to perform a release process on the canary version on the cloud server based on the test result.

[0084] By adding a traffic interceptor at the entrance of the access data stream, developers are supported to intercept the specified first traffic to the online FaaS test server according to the pre-configured traffic interception policy. Since the FaaS test server is independent of the FaaS cloud server, the FaaS test server uses the function test instance corresponding to the gray version to perform a release risk test on the gray version based on the first traffic, and obtain test results. For example, there is no release risk, there is a risk and it is not conducive to release, there is a low risk and it can be tried to release, etc. Then, the test results are output to the R & D server so that the R & D server can determine whether to perform a release process on the gray version on the cloud server based on the test results. For example, if the test results are: there is no release risk, there is a low risk and it can be tried to release, the R & D server can instruct the cloud server to release the gray version of the target application.

[0085] Optionally, according to the traffic source of the access data stream of the target application software, the access data stream can be divided into HTTP traffic or wireless traffic. Specifically, the above-mentioned pre-configured traffic interception policy can be selected according to the traffic source of the access data stream. For example, for HTTP traffic, the Domain Name System (DNS) can be used for traffic interception, and for wireless traffic, AMDC can be used for traffic interception to obtain the first traffic in the access data stream.

[0086] Optionally, the above cloud server can also be called a cloud computing server. For example, it can be a FaaS cloud server, in which a function computing instance corresponding to the production version of the target application software is deployed to undertake other online traffic except the first traffic. In the embodiment of the present invention, a FaaS test server for testing the gray version of the target application software is independently deployed outside the FaaS cloud server in advance to perform an online test through the method provided by the present invention before an online release.

[0087] Optionally, a traffic interceptor is used to intercept the first traffic from the access data stream of the target application software according to the pre-configured traffic interception policy. After obtaining the first traffic in the access data stream of the target application software, the function test instance corresponding to the gray version of the target application software deployed in the test server is used to perform a release risk test on the gray version based on the first traffic, obtain the test results, and then output the test results to the R & D server so that the R & D server can determine whether to perform a release process on the gray version on the cloud server based on the test results.

[0088] In an embodiment of the present invention, outside the FaaS cloud server, an FaaS test server for testing the gray-scale version of the target application software is independently deployed in advance. That is, it can be understood that an independent online test phase is added before the online release to implement online testing of the gray-scale version of the target application software using the independently deployed online FaaS test server. An independent control strategy is adopted to achieve better isolation and higher test verification efficiency.

[0089] Optionally, still as Figure 2 shown, the FaaS cloud server is connected to the traffic interceptor, and is used to receive the second traffic sent by the traffic interceptor, and use the function computing instance corresponding to the production version of the pre-deployed target application software to undertake the second traffic.

[0090] Optionally, the second traffic is other traffic in the access data stream except the first traffic.

[0091] In an embodiment of the present invention, by giving the second traffic in the access data stream of the target application software to the FaaS cloud server, the function computing instance corresponding to the production version of the target application software deployed in the FaaS cloud server undertakes the second traffic.

[0092] Since the FaaS cloud server and the FaaS test server are two independent separate clusters respectively, therefore, the basic version of the target application software can be deployed in the FaaS cloud server as the production version, and the application programming interface gateway deployed in the FaaS cloud server is used to request the scheduler to create a function computing instance corresponding to the production version after receiving the second traffic, and forward the second traffic to the function computing instance after the creation is successful. There is no need to perform online release testing on the FaaS cloud server, making the release testing process safer and faster.

[0093] The version release processing device of one or more embodiments of the present invention will be described in detail below. Those skilled in the art can understand that these devices can be configured by using commercially available hardware components according to the steps taught by this solution.

[0094] Figure 4 The structural schematic diagram of a version release processing device provided for an embodiment of the present invention, as Figure 4 shown, the device includes: an acquisition module 11, a test module 12, and an output module 13.

[0095] The acquisition module 11 is used to acquire the first traffic in the access data stream of the target application software, where the first traffic is intercepted by the traffic interceptor from the access data stream according to a pre-configured traffic interception policy;

[0096] A test module 12 is configured to perform a release risk test on a gray-scale version based on a first traffic volume by using a function test instance corresponding to the gray-scale version of a target application software deployed in a test server, and obtain a test result.

[0097] An output module 13 is configured to output the test result to a R & D server. The R & D server determines whether to perform a release process on the gray-scale version on a cloud server based on the test result.

[0098] Optionally, the apparatus further includes: an operation module configured to obtain a second traffic volume in an access data stream of the target application software; and use a function calculation instance corresponding to a production version of the target application software deployed in the cloud server to receive the second traffic volume, where the second traffic volume is other traffic volumes in the access data stream except the first traffic volume.

[0099] Optionally, the apparatus further includes:

[0100] A load balancing processing module is configured to send the first traffic volume to a first virtual IP provided in a load balancer, perform load balancing processing on the first traffic volume, and then forward the processed first traffic volume to the test server; and send the second traffic volume to a second virtual IP provided in the load balancer, perform load balancing processing on the second traffic volume, and then forward the processed second traffic volume to the cloud server.

[0101] Optionally, the apparatus further includes:

[0102] A detection module is configured to detect whether a traffic value of the first traffic volume is greater than a preset threshold.

[0103] A gray-scale release deployment module is configured to, if the traffic value of the first traffic volume is greater than the preset threshold, in addition to performing a release risk test on the gray-scale version based on the first traffic volume by using a function test instance corresponding to the gray-scale version of the target application software deployed in the test server, also execute a gray-scale release deployment policy on the target application software.

[0104] Optionally, the gray-scale release deployment module is further configured to execute a gray-scale release deployment policy on the target application software after performing a release process on the gray-scale version.

[0105] Optionally, the gray-scale release deployment module is specifically configured to: randomly split the access data stream into a first traffic volume and a second traffic volume according to a predetermined ratio; and send the first traffic volume and the second traffic volume to the cloud server to perform a release risk test on the gray-scale version by using the cloud server based on the first traffic volume; where a function test instance corresponding to the gray-scale version and a function calculation instance corresponding to the production version are deployed in the cloud server.

[0106] Optionally, the device is further configured to, if at least one of the multiple functions obtained by splitting the target application software changes, when making mutual calls between the multiple functions, use a load balancer to provide an affinity routing function for remote procedure calls between the multiple functions, so as to integrally test the first traffic corresponding to the multiple functions.

[0107] Optionally, the application programming interface gateway deployed in the test server is configured to, after receiving the first traffic, request the scheduler to create a function test instance corresponding to the gray version, and forward the first traffic to the function test instance after successful creation.

[0108] In a possible design, the structure of the above Figure 4 version release processing device can be implemented as an electronic device. As Figure 5 shown, the electronic device may include: a processor 21, a memory 22, and a communication interface 23. Among them, executable code is stored on the memory 22. When the executable code is executed by the processor 21, the processor 21 can at least implement the version release processing method provided in the foregoing embodiments.

[0109] In addition, an embodiment of the present invention provides a non-transitory machine-readable storage medium, on which executable code is stored. When the executable code is executed by a processor of an electronic device, the processor can at least implement the version release processing method provided in the foregoing embodiments.

[0110] The device embodiments described above are merely illustrative. The network elements described as separate components may or may not be physically separated. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art can understand and implement it without creative efforts.

[0111] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of adding a necessary general hardware platform, and of course, can also be implemented by a combination of hardware and software. Based on such an understanding, the above technical solution essentially or the part that contributes to the prior art can be embodied in the form of a computer product. The present invention can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memories, CD-ROMs, optical memories, etc.) containing computer-usable program codes.

[0112] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A version release processing method, applied to the FaaS platform, characterized in that Including: Obtain a first traffic volume in the access data stream of the target application software, where the first traffic volume is intercepted by a traffic interceptor from the access data stream according to a pre-configured traffic interception policy, and the target application software is FaaS; access data streams with different traffic sources correspond to different traffic interception policies; The application programming interface gateway deployed in the test server is used to, after receiving the first traffic volume, request the scheduler to create a function test instance corresponding to the gray-scale version, and after successful creation, forward the first traffic volume to the function test instance, and use the function test instance corresponding to the gray-scale version of the target application software deployed in the test server to perform a release risk test on the gray-scale version based on the first traffic volume to obtain a test result, where a test server for testing the gray-scale version of the target application software is independently deployed outside the cloud server; Output the test result to the R & D server, where the R & D server determines whether to perform a release process on the gray-scale version on the cloud server based on the test result; Obtain a second traffic volume in the access data stream of the target application software; Use the function computing instance corresponding to the production version of the target application software deployed in the cloud server to receive the second traffic volume, where the second traffic volume is other traffic in the access data stream except the first traffic volume.

2. The method according to claim 1, wherein After obtaining the first traffic volume in the access data stream of the target application software, the method further includes: sending the first traffic volume to a first virtual IP provided in the load balancer, and after performing load balancing processing on the first traffic volume, forwarding the processed first traffic volume to the test server; The step of sending the second traffic volume in the access data stream to the cloud server includes: sending the second traffic volume to a second virtual IP provided in the load balancer, and after performing load balancing processing on the second traffic volume, forwarding the processed second traffic volume to the cloud server.

3. The method according to claim 1, wherein The method further includes: detecting whether the traffic value of the first traffic volume is greater than a preset threshold; if the traffic value of the first traffic volume is greater than the preset threshold, then in addition to using the function test instance corresponding to the gray-scale version of the target application software deployed in the test server to perform a release risk test on the gray-scale version based on the first traffic volume, also execute a gray-scale release deployment policy on the target application software; The method further includes: after performing a release process on the gray-scale version, execute a gray-scale release deployment policy on the target application software.

4. The method according to claim 3, wherein Executing a gray-scale release deployment policy on the target application software includes: Randomly splitting the access data stream into a first traffic volume and a second traffic volume according to a predetermined ratio; Sending the first traffic volume and the second traffic volume to the cloud server to use the cloud server to perform a release risk test on the gray-scale version based on the first traffic volume; where a function test instance corresponding to the gray-scale version and a function computing instance corresponding to the production version are deployed in the cloud server.

5. The method according to claim 1, characterized in that, The method further includes: If at least one of the multiple functions obtained by splitting the target application software changes, when the multiple functions call each other, a load balancer is used to provide an affinity routing function for remote procedure calls between the multiple functions, so as to integrally test the first traffic corresponding to the multiple functions.

6. A version release processing system, characterized in that, Applied to the FaaS platform, it includes: A traffic interceptor, configured to intercept the first traffic from the access data stream of the target application software according to a pre-configured traffic interception policy, and send the first traffic to a test server. The target application software is FaaS; different access data streams with different traffic sources correspond to different traffic interception policies; The test server, connected to the traffic interceptor, is configured to receive the first traffic through the application programming interface gateway deployed in the test server, request the scheduler to create a function test instance corresponding to the gray version, and after successful creation, forward the first traffic to the function test instance. Use the function test instance corresponding to the gray version of the pre-deployed target application software to perform a release risk test on the gray version based on the first traffic, and obtain a test result. Among them, a test server for testing the gray version of the target application software is independently deployed outside the cloud server in advance; A R & D server, connected to the test server, is configured to determine whether to perform a release process on the gray version on the cloud server based on the test result; The cloud server, connected to the traffic interceptor, is configured to receive the second traffic sent by the traffic interceptor, and use the function computing instance corresponding to the production version of the pre-deployed target application software to receive the second traffic. Among them, the second traffic is other traffic in the access data stream except the first traffic.

7. A version release processing device, characterized in that, Applied to the FaaS platform, it includes: An acquisition module, configured to acquire the first traffic in the access data stream of the target application software. The first traffic is intercepted from the access data stream by the traffic interceptor according to a pre-configured traffic interception policy. The target application software is FaaS; different access data streams with different traffic sources correspond to different traffic interception policies; the traffic interceptor sends the first traffic to the test server; A test module, configured to receive the first traffic through the application programming interface gateway deployed in the test server, request the scheduler to create a function test instance corresponding to the gray version, and after successful creation, forward the first traffic to the function test instance. Use the function test instance corresponding to the gray version of the target application software deployed in the test server to perform a release risk test on the gray version based on the first traffic, and obtain a test result. Among them, a test server for testing the gray version of the target application software is independently deployed outside the cloud server in advance; An output module, configured to output the test result to the R & D server. The R & D server determines whether to perform a release process on the gray version on the cloud server based on the test result; An operation module, configured to obtain a second traffic volume in an access data stream of a target application software; and use a function computing instance corresponding to a production version of the target application software deployed in the cloud server to undertake the second traffic volume, where the second traffic volume is other traffic volumes in the access data stream except the first traffic volume.

8. An electronic device, characterized in that, It includes: A memory, a processor, and a communication interface; wherein, executable code is stored on the memory, and when the executable code is executed by the processor, the processor is caused to execute the version release processing method according to any one of claims 1 to 5.

9. A non-transitory machine-readable storage medium, characterized in that, Executable code is stored on the non-transitory machine-readable storage medium, and when the executable code is executed by a processor of an electronic device, the processor is caused to execute the version release processing method according to any one of claims 1 to 5.

Images