Gray release method and device for internet application and electronic equipment thereof

Abstract

The invention provides a gray release method and device for an internet application and electronic equipment of the gray release method and device, and relates to the technical field of computers. The method comprises the following steps: receiving an access request of a user to a front-end page, and extracting parameters carried by the access request; returning a front-end page of the target version to the user based on the carried parameters and a pre-received user gray scale rule; the front-end page comprises at least two versions of front-end pages, and the front-end page of the target version is a version corresponding front-end page carrying parameters; the front-end page comprises a version identifier; receiving an operation of a user on the front-end page to generate a first back-end service request; the first back-end service request comprises a version identifier; calling a target version instance of the first back-end service based on the version identifier to respond to the first back-end service request; wherein the first back-end service comprises at least two version instances, and the target version instance is the version instance corresponding to the version identifier, so that the reliability of gray release of the Internet application can be improved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular, to a method, apparatus, and electronic device for gray release of Internet applications. Background Art

[0002] With the rapid iterative upgrade of Internet applications, how to safely release new version functions while ensuring system stability and user experience has become an important issue in the field of software development. The traditional full-scale release method has relatively high risks, while gray release has developed into a commonly used version release strategy through technical means of gradually opening new version services. It aims to gradually push new functions or modified versions to some users to detect and fix potential problems, allowing the development team to gradually verify and optimize new functions or versions without affecting most users, thereby ensuring the stability of the overall system.

[0003] However, the current gray release implementation solutions mainly adopt independent gray strategies for front-end services and back-end services. Different version pages are allocated at the front-end page layer by means of user identification hashing or business parameter matching, and service instances are allocated at the back-end service layer according to independently configured routing rules. This results in a lack of coordination mechanism between front-end and back-end versions. When the front-end returns a new version page, it may call the old version service of the back-end that has not been synchronously gray deployed, causing problems such as incompatible function interfaces or business logic conflicts, resulting in relatively low reliability of gray release. Summary of the Invention

[0004] The present invention provides a method, apparatus, and electronic device for gray release of Internet applications to solve the defect of relatively low reliability of gray release in the prior art and achieve gray consistency between front-end services and back-end services.

[0005] The present invention provides a method for gray release of Internet applications, including: Receiving a user's access request to a front-end page and extracting the carried parameters of the access request; Returning a front-end page of a target version to the user based on the carried parameters and pre-received user gray rules; the front-end page includes at least two version front-end pages, and the front-end page of the target version is the front-end page corresponding to the carried parameters; the front-end page includes a version identifier; Receiving an operation of the user on the front-end page to generate a first back-end service request; the first back-end service request includes the version identifier; Invoking a target version instance of the first back-end service to respond to the first back-end service request based on the version identifier; wherein, the first back-end service includes at least two version instances, and the target version instance is the version instance corresponding to the version identifier.

[0006] A method for gray release of Internet applications provided by the present invention, returning a front-end page of a target version to the user based on the carried parameters and pre-received user gray rules, includes: Determining the version of the front-end page to be returned to the user based on the carried parameters and pre-received user gray rules; Adding the version identifier of the front-end page to the corresponding front-end code to generate a front-end page of the target version, and returning the front-end page of the target version to the user.

[0007] A method for gray release of Internet applications provided by the present invention, the target version instance of the first back-end service called based on the version identifier in response to the first back-end service request, includes: When it is determined that the method of calling the first back-end service is a preset calling method, sending the first back-end service request to the communication middleware of the first back-end service; Controlling the communication middleware to call the target version instance of the first back-end service to respond to the first back-end service request based on the version identifier.

[0008] A method for gray release of Internet applications provided by the present invention, after controlling the communication middleware to call the target version instance of the first back-end service to respond to the first back-end service request based on the version identifier, the method further includes: When it is determined that the first back-end service request calls the second back-end service, controlling the communication middleware to generate a second back-end service request based on the version identifier; Calling the target version instance of the second back-end service to respond to the second back-end service request based on the version identifier; wherein, the second back-end service includes at least two version instances, and the target version instance is the version instance corresponding to the version identifier.

[0009] A method for gray release of Internet applications provided by the present invention, the version identifier includes the page identifier of the front-end page and the carried label of the first back-end service request; Receiving the operation of the user on the front-end page to generate a first back-end service request, includes: Determining the initial back-end service request to be sent to the back-end according to the operation of the user on the front-end page; Converting the page identifier into a carried label, and adding the carried label to the code of the initial back-end service request to generate a first back-end service request.

[0010] A method for gray release of Internet applications provided by the present invention, the version identifier includes a gray identifier and a version value; The target version instance of the first backend service called based on the version identifier responds to the first backend service request, including: When it is determined that the gray scale identifier in the version identifier takes the gray scale version value and the version value is the current gray scale version value of the first backend service, the first backend service request is sent to the gray scale version instance of the first backend service for processing.

[0011] According to a method for gray release of an Internet application provided by the present invention, before returning the front-end page of the target version to the user based on the carried parameters and the pre-received user gray scale rule, the method further includes: Setting a specified number of groups, and determining the gray scale group and the baseline group in the groups based on the gray release ratio; Obtaining the user identifier from the carried parameters and randomly assigning the user identifier to the groups; Returning the front-end page of the target version to the user based on the carried parameters and the pre-received user gray scale rule, including: When it is determined that the carried parameters are non-mandatory test parameters, obtaining the user identifier in the access request; Based on the group where the user identifier is located, returning the front-end page of the target version to the user.

[0012] The present invention also provides a device for gray release of an Internet application, including: A parameter extraction module, configured to receive an access request of a user to a front-end page and extract the carried parameters of the access request; A page return module, configured to return the front-end page of the target version to the user based on the carried parameters and the pre-received user gray scale rule; the front-end page includes at least two version front-end pages, and the front-end page of the target version is the front-end page corresponding to the carried parameters; the front-end page includes a version identifier; A request generation module, configured to receive an operation of the user on the front-end page and generate a first backend service request; the first backend service request includes the version identifier; A request response module, configured to call the target version instance of the first backend service based on the version identifier to respond to the first backend service request; wherein, the first backend service includes at least two version instances, and the target version instance is the version instance corresponding to the version identifier.

[0013] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein when the processor executes the computer program, the method for gray release of an Internet application as described in any one of the above is implemented.

[0014] The present invention also provides a non-transitory computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the method for gray release of an Internet application as described in any one of the above is implemented.

[0015] The method, device and electronic device for gray release of an Internet application provided by the embodiments of the present invention receive an access request from a user for a front-end page, and extract the carried parameters of the access request; based on the carried parameters and the pre-received user gray rule, return a target version of the front-end page to the user; receive an operation of the user on the front-end page to generate a first back-end service request; the first back-end service request includes the version identifier; based on the version identifier, call a target version instance of the first back-end service to respond to the first back-end service request. By adding a version identifier to the front-end page and adding the version identifier to the first back-end service request generated by the user's operation on the front-end page, the gray consistency between the front-end service and the back-end service is achieved through the version identifier, so as to improve the reliability of gray release. Description of the Drawings

[0016] In order to more clearly illustrate the technical solutions in the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. 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.

[0017] Figure 1 is one of the flow diagrams of the method for gray release of an Internet application provided by the present invention.

[0018] Figure 2 is the second flow diagram of the method for gray release of an Internet application provided by the present invention.

[0019] Figure 3 is the framework diagram of the method for gray release of an Internet application provided by the present invention.

[0020] Figure 4 is the structural diagram of the device for gray release of an Internet application provided by the present invention.

[0021] Figure 5 is the structural diagram of the electronic device provided by the present invention. Detailed Embodiments

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

[0023] The following will describe Figures 1-5 the method, device, and its electronic device for the gray release of Internet applications of the present invention.

[0024] Figure 1 is one of the schematic flowcharts of the method for the gray release of Internet applications provided by the present invention. As Figure 1 shown, the method includes the following steps: Step 101: Receive the access request of the user for the front-end page and extract the carried parameters of the access request.

[0025] An access request refers to a request initiated by a user through a traditional browser or the platform browser of other traffic platforms for obtaining and loading the front-end page. The access request can be an HTTP request or a Web Transport request, etc.

[0026] The carried parameters refer to the parameters embedded in the request for transmitting additional information or control logic. The carried parameters here at least include the parameters corresponding to the user gray rule.

[0027] The front-end page refers to the page that the user directly views and interacts with through a traditional browser or the platform browser of other traffic platforms.

[0028] Exemplarily, in the case of the gray release of a certain e-commerce platform for the "promotion activity page", the user can send an access request for the "promotion activity page" to the front-end gateway by clicking on the social media advertisement link, and the front-end gateway can extract the carried parameters from the access request.

[0029] Step 102: Return the front-end page of the target version to the user based on the carried parameters and the pre-received user gray rule; the front-end page includes at least two versions of the front-end page, and the front-end page of the target version is the front-end page corresponding to the carried parameters; the front-end page includes a version identifier.

[0030] The user gray rule refers to a set of predefined condition sets used to dynamically determine whether to return the front-end page of the gray version or the front-end page of the baseline version to the user according to the carried parameters during the gray release process. Among them, the front-end page of the gray version can also be called the front-end page of the new version, and the front-end page of the baseline version can also be called the front-end page of the old version.

[0031] Exemplarily, the user gray scale rule can be sent down through the publishing platform to facilitate real-time rule updates without restarting the Internet application.

[0032] The version identifier refers to the feature marker used to uniquely distinguish the gray scale version from the baseline version during the gray scale release process. That is, through the version identifier in the front-end page, it is possible to determine whether the front-end page is a front-end page of the gray scale version or a front-end page of the baseline version.

[0033] Exemplarily, the front-end gateway can determine whether the carried parameter extracted from the access request sent by the user conforms to the gray scale condition based on the user gray scale rule. If it conforms, it returns the front-end page of the gray scale version; otherwise, it returns the front-end page of the baseline version.

[0034] Step 103: Receive the operation of the user on the front-end page to generate a first back-end service request; the first back-end service request includes the version identifier.

[0035] The back-end service request can also be called a business service request, which refers to the request for executing specific business logic to implement the operation of the user on the front-end page and is used to trigger the back-end service processing. It can be understood that the first and the second, third, etc. that appear below are used to distinguish different back-end service requests or different back-end services, rather than to limit the sequence.

[0036] It can be understood that by adding the version identifier to the first back-end service request, it is convenient for the back-end service to associate the back-end gray scale policy with the user gray scale rule of the front-end. It can be understood that the back-end gray scale policy refers to how to determine which version instance of the first back-end service to call according to the version identifier.

[0037] Step 104: Call the target version instance of the first back-end service to respond to the first back-end service request based on the version identifier; where the first back-end service includes at least two version instances, and the target version instance is the version instance corresponding to the version identifier.

[0038] Exemplarily, the user operates on the front-end page to generate a first back-end service request and sends the first back-end service request to the global traffic gateway. The global traffic gateway can forward the first back-end service request to the back-end service gateway. The back-end service gateway extracts the version identifier from the first back-end service request, determines that the version identifier meets the gray scale condition of the preset back-end gray scale policy, and calls the gray scale version instance of the first back-end service to respond to the first back-end service request. It can be understood that the at least two version instances include a gray scale version instance and a baseline version instance.

[0039] The gray release method of Internet applications provided by the embodiments of the present invention receives an access request from a user to a front-end page, extracts the carried parameters of the access request; returns a front-end page of the target version to the user based on the carried parameters and the pre-received user gray rules; receives an operation of the user on the front-end page to generate a first back-end service request; the first back-end service request includes the version identifier; based on the version identifier, calls the target version instance of the first back-end service to respond to the first back-end service request, adds a version identifier to the front-end page, adds the version identifier to the first back-end service request generated by the user's operation on the front-end page, and realizes the gray consistency between the front-end service and the back-end service through the version identifier, so as to improve the reliability of gray release.

[0040] Based on the above embodiment, the returning a front-end page of the target version to the user based on the carried parameters and the pre-received user gray rules includes: Determine the version of the front-end page to be returned to the user based on the carried parameters and the pre-received user gray rules; Add the version identifier of the front-end page to the corresponding front-end code to generate a front-end page of the target version, and return the front-end page of the target version to the user.

[0041] It can be understood that the front-end page of the gray version and the front-end page of the baseline version can be pre-generated and stored independently. According to the carried parameters and the user gray rules, it is determined whether to point to the front-end page of the gray version or the front-end page of the baseline version, so as to return the front-end page of the target version to the user.

[0042] Compared with adding the version identifier of the front-end page by relying on runtime environments such as Cookies and Local Storage, in this embodiment, by directly embedding the version identifier into the front-end code, the risk of version identifier loss caused by traditional browser settings or platform browser restrictions of third-party traffic platforms can be avoided, thereby enhancing the compatibility of the gray release of the front-end page with traditional browsers and platform browsers of third-party traffic platforms.

[0043] It can be understood that the front-end page and the back-end service can be released together through the release platform. When releasing, the corresponding version identifier can be injected into the front-end pages of different versions through an automated script. After release, each back-end service in the back-end service link can have a gray version instance (new version instance) and a baseline version instance (old version instance).

[0044] Based on any of the above embodiments, the carried parameters include a forced test parameter and a user identifier; the returning a front-end page of the target version to the user based on the carried parameters and the pre-received user gray rules includes: When it is determined that the carried parameter is a mandatory test parameter, return a grayscale version of the front-end page to the user.

[0045] Exemplarily, if the carried parameter extracted from the access request includes channel=_canary_, return a grayscale version of the front-end page to the user.

[0046] Based on any of the above embodiments, before returning a front-end page of a target version to the user based on the carried parameter and the pre-received user grayscale rule, the method further includes: Set a specified number of groups, and determine the grayscale group and the baseline group in the groups based on the grayscale release ratio; Obtain the user identifier from the carried parameter and randomly assign the user identifier to the groups; Returning a front-end page of a target version to the user based on the carried parameter and the pre-received user grayscale rule includes: When it is determined that the carried parameter is a non-mandatory test parameter, obtain the user identifier in the access request; Based on the group where the user identifier is located, return a front-end page of a target version to the user.

[0047] Exemplarily, 100 traffic groups can be set, and the user identifier is randomly and fixedly assigned to a traffic group. When the grayscale release ratio is 1%, for the access request corresponding to the user identifier assigned to the traffic group with the serial number 0, return a grayscale version of the front-end page, and for the access request corresponding to the user identifier assigned to the traffic groups with the serial numbers 1 to 99, return a baseline version of the front-end page.

[0048] It can be understood that when it is necessary to increase the grayscale release ratio, for example, when the grayscale release ratio is increased to 10%, it is only necessary to set that for the access request corresponding to the user identifier assigned to the traffic groups with the serial numbers 0 to 9, return a grayscale version of the front-end page, and for the access request corresponding to the user identifier assigned to the traffic groups with the serial numbers 10 to 99, return a baseline version of the front-end page, which can facilitate the adjustment of the grayscale release volume.

[0049] The operation on the front-end page generates a first back-end service request, which is generally a first back-end service request sent from the front-end to the global traffic gateway. The version identifier can be added to the request Header of the first back-end service request. The service call methods between some technology stacks support the transmission of the request Header, while the service call methods between some technology stacks do not support the transmission of the request Header.

[0050] In order to enable the version identifier to be transparently transmitted in the backend service call link, based on any of the above embodiments, the target version instance of the first backend service called based on the version identifier to respond to the first backend service request includes: When it is determined that the method of calling the first backend service is a preset calling method, the first backend service request is sent to the communication middleware of the first backend service; Based on the version identifier, control the communication middleware to call the target version instance of the first backend service to respond to the first backend service request.

[0051] The preset calling method refers to a calling method that does not support passing the request Header, such as Dubbo RPC calling and K8sSVC calling, etc.

[0052] The communication middleware can be a component that identifies the version identifier of the service - to - service call request in the service - to - service call link and processes the service - to - service call request. Both the first backend service request and the second backend service request belong to the service - to - service call request. The communication middleware can be a proxy Java Agent or a service mesh Istio Sidecar.

[0053] When the communication middleware is the service mesh Istio Sidecar, the service mesh Istio Sidecar can intercept the first backend service request and read the predefined configuration rules, such as VirtualService. When the version identifier in the first backend service request meets the gray - scale condition in the configuration rules, call the gray - scale version instance of the first backend service to respond to the first backend service request. When the version identifier in the first backend service request does not meet the gray - scale condition in the configuration rules, call the baseline version instance of the first backend service to respond to the first backend service request.

[0054] When the communication middleware is a proxy Java Agent, the proxy Java Agent can intercept the first backend service request, extract the version identifier from the current call context such as the HTTP header or the implicit parameters of Dubbo, and read the predefined configuration rules. When the version identifier in the first backend service request meets the gray - scale condition in the configuration rules, call the gray - scale version instance of the first backend service to respond to the first backend service request. When the version identifier in the first backend service request does not meet the gray - scale condition in the configuration rules, call the baseline version instance of the first backend service to respond to the first backend service request.

[0055] In this embodiment, the predefined configuration rules are centralized configuration rules that can be read by each backend service or communication middleware.

[0056] In this embodiment, when the method of invoking the first backend service is the preset invocation method, the first backend service request is sent to the communication middleware. The communication middleware identifies the version identifier in the first backend service request, which can avoid the loss of the version identifier caused by cross-protocol and cross-technology stack invocations, reduce the failure of backend service invocations, or the risk that the version instance of the backend service invocation is inconsistent with the version of the front-end page.

[0057] Based on any of the above embodiments, after the communication middleware is controlled to invoke the target version instance of the first backend service to respond to the first backend service request based on the version identifier, the method further includes: When it is determined that the first backend service request invokes the second backend service, controlling the communication middleware to generate a second backend service request based on the version identifier; Invoking the target version instance of the second backend service based on the version identifier to respond to the second backend service request; wherein, the second backend service includes at least two version instances, and the target version instance is the version instance corresponding to the version identifier.

[0058] The communication middleware can also identify the version identifier of the service invocation request in the service invocation link between services and pass the version identifier to the subsequent invoked backend service.

[0059] It can be understood that generating a second backend service request based on the version identifier may mean that the communication middleware obtains the version identifier from the first backend service request and passes the version identifier to the communication middleware of the second backend service through the second backend service request, so that the communication middleware of the second backend service can compare the version identifier with the metadata of each version instance of the second backend service to determine which version instance to route to.

[0060] Exemplarily, in RPC invocations such as Dubbo, the first backend service request can be sent to the proxy Java Agent, and the Java Agent automatically embeds the version identifier into the context of all subsequent service invocations to avoid the loss of the version identifier caused by cross-protocol invocations.

[0061] The working principle of the service mesh Istio Sidecar passing the version identifier is basically the same as that of the proxy Java Agent passing the version identifier, and will not be elaborated here.

[0062] In this embodiment, when the first backend service is called in a preset call mode, the communication middleware passes the version identifier to the subsequent called backend service, which can facilitate the differential processing of different backend service link call modes, avoid the loss of the version identifier caused by cross-protocol and cross-technology stack calls, reduce the failure of backend service calls, or the risk that the version instance of the backend service call is inconsistent with the version of the front-end page.

[0063] Based on any of the above embodiments, the version identifier includes the page identifier of the front-end page and the carried flag of the first backend service request.

[0064] The page identifier refers to the front-end variable used to identify the page version in the browser environment, and the carried flag is the standardized version identifier transmitted across protocols. The carried flag can be an HTTP request header or a Dubbo implicit parameter, etc.

[0065] In one embodiment, the generating of the first backend service request by receiving the user's operation on the front-end page includes: Determining the initial backend service request to be sent to the backend according to the user's operation on the front-end page; Converting the page identifier into a carried flag, adding the carried flag to the code of the initial backend service request, and generating the first backend service request.

[0066] In this embodiment, by converting the page identifier of the front-end page into a carried flag and adding the carried flag to the code of the initial backend service request, in the case of different call modes such as HTTP, Dubbo, or K8s between services in the backend service link, cooperating with the corresponding backend service request processing method, it can ensure that the carried flag can be transparently transmitted in the backend call link, facilitating the realization that the version of the user accessing the front-end page is consistent with the instance version of the backend service.

[0067] In one embodiment, the version identifier includes a gray-scale identifier and a version value.

[0068] Exemplarily, the page identifier of the front-end page can be the global variables window.__canary_flag and window.__canary_version. The value of window.__canary_flag can be false for the baseline version and true for the gray-scale version. The value of window.__canary_version can be the timestamp of the last release of the baseline version, which increases monotonically; or the timestamp of the local release of the gray-scale version.

[0069] The carried flags for the backend service requests can be the request Headers x-canary-flag and x-canary-version. The value of x-canary-flag is basically the same as the value of window.__canary_flag, and the uqvi of x-canary-version is basically the same as that of window.__canary_version, which will not be elaborated here.

[0070] In one embodiment, when publishing on the release platform, global variables can be injected into the front-end code corresponding to the front-end pages of the gray version through an automated script: window.__canary_flag__=true; window.__canary_version__="20241201103000"; and global variables can be injected into the front-end code corresponding to the front-end pages of the baseline version: window.__canary_flag__=false; window.__canary_version__="20241101103000".

[0071] Exemplarily, in the case where the version identifier is the carried flag, after obtaining the carried flag from the first backend service request by the communication middleware of the first backend service, the carried flag can be passed through to the communication middleware of the second backend service via the second backend service request, so that the communication middleware of the second backend service can compare the carried flag with the metadata of each version instance of the second backend service to determine which version instance to route to.

[0072] Based on any of the above embodiments, the calling of the target version instance of the first backend service in response to the first backend service request includes: When it is determined that the gray scale identifier in the version identifier takes the value of the gray version and the version value is the current gray version value of the first backend service, the first backend service request is sent to the gray version instance of the first backend service for processing.

[0073] It can be understood that the current gray version value of the first backend service refers to the version value in the metadata of the gray version instance of the first backend service.

[0074] In this embodiment, by verifying the consistency between the version value in the carried flag and the current gray version value, it is ensured that the gray traffic is routed to the gray version instance only in the scenario where the versions are exactly matched, and in other cases, it is routed to the baseline version instance, reducing the risk of data errors caused by compatibility issues in the gray function.

[0075] In one embodiment, when it is determined that the grayscale identifier in the version identifier has a grayscale version value and the version value is not the current grayscale version value of the first backend service, the first backend service request is sent to the baseline version instance of the first backend service for processing, that is, it is routed to the baseline version instance when the version identifier expires.

[0076] As mentioned above, in the backend service request, the version identifier can be a carry flag. Therefore, determining the grayscale identifier in the version identifier can also be said to be determining the grayscale identifier in the carry flag, and determining the version value in the version identifier can also be said to be determining the version value in the carry flag.

[0077] Thus, this embodiment can achieve that when x-canary-flag=true and the x-canary-version value matches the current grayscale version value of the backend service, the request is processed by the grayscale version instance of the backend service; when x-canary-flag=true and the x-canary-version value does not match the current grayscale version value of the backend service, it is determined that the front-end page has expired, and the request is processed by the baseline version instance of the backend service; when x-canary-flag=false, the request is processed by the baseline version instance of the backend service.

[0078] As Figure 2 shown, in order to specifically illustrate the function of the grayscale release method for Internet applications provided by this embodiment, a specific example is provided below.

[0079] The user sends an access request to obtain the front-end page. Refer to Figure 3 , the user can send an access request through the Web-side page, and the access request can be sent to the front-end service gateway through the global traffic gateway; The front-end service gateway obtains the user's grayscale rule and determines whether the access request is forced test traffic; if so, it returns the new version page (the front-end page of the grayscale version), if not, it determines whether the access request accesses the new version page. Refer to Figure 3 It can be determined whether the access request accesses the new version page based on the grayscale release ratio and the user identifier in the access request; When it is determined that the access request accesses the new version page, the new version page is returned; the user operates on the new version page to generate a backend service request with a new version flag (the new version flag means that the version identifier indicates the grayscale version service instance of the backend service request) to access the backend service link; determine whether the version value has expired (the version value is not the current grayscale version value of the first backend service); if not, determine whether the backend service has released a new version. In the case where the backend service has released a new version, the backend service request is processed by each backend service new version instance (grayscale version service instance); When it is determined that the access request does not access the new version page, return the old version page (the front-end page of the baseline version); when the user operates on the old version page to generate a back-end service request with an old version label (the old version label refers to the version identifier indicating the baseline version service instance of the back-end service request), access the back-end service link; the old version instances of each back-end service (baseline version service instances) process the back-end service request.

[0080] It can be understood that in the case where the version value has expired or the back-end service has not released a new version, the old version instances of each back-end service also process the back-end service request.

[0081] Such as Figure 3 As shown, when accessing the back-end service link, the first back-end service request can be sent to the global traffic gateway. Exemplarily, the global traffic gateway supports the transfer of request Headers. The global traffic gateway can obtain the centralized configuration rules and based on this, send the first back-end service request to the back-end service gateway. The back-end service gateway supports the transfer of request Headers. It can obtain the centralized configuration rules by the back-end service gateway and based on this, HTTP (gateway) calls the old version (Agent) of back-end service A. The old version (Agent) of back-end service A obtains the centralized configuration rules and based on this, Dubbo calls the old version (Agent + Sidercar) of back-end service B. The old version (Agent + Sidercar) of back-end service B obtains the centralized configuration rules and based on this, HTTP (SVC) calls the old version (Sidercar) of back-end service C.

[0082] It can be understood that the global traffic gateway can also obtain the centralized configuration rules and based on this, HTTP (intranet domain name) calls the old version (Sidercar) of back-end service C. The old version (Sidercar) of back-end service C obtains the centralized configuration rules and based on this, HTTP (SVC) calls the old version (Agent + Sidercar) of back-end service B. The old version (Agent + Sidercar) of back-end service B obtains the centralized configuration rules and based on this, Dubbo calls the old version (Agent) of back-end service A.

[0083] It can be understood that Figure 3 In the figure, the solid line represents the actually called version, and the dashed line represents the existing but not called version.

[0084] The gray-scale release device of the Internet application provided by the present invention will be described below. The gray-scale release device of the Internet application described below can be mutually corresponded and referred to with the gray-scale release method of the Internet application described above.

[0085] Figure 4 It is a schematic structural diagram of the gray-scale release device of the Internet application provided by the present invention. Such asFigure 4 As shown, the device includes: A parameter extraction module 401, configured to receive an access request from a user to a front-end page and extract the carried parameters of the access request; A page return module 402, configured to return a front-end page of a target version to the user based on the carried parameters and a pre-received user gray-scale rule; the front-end page includes at least two versions of the front-end page, and the front-end page of the target version is the front-end page of the version corresponding to the carried parameters; the front-end page includes a version identifier; A request generation module 403, configured to receive an operation of the user on the front-end page to generate a first back-end service request; the first back-end service request includes the version identifier; A request response module 404, configured to call a target version instance of a first back-end service to respond to the first back-end service request based on the version identifier; wherein, the first back-end service includes at least two version instances, and the target version instance is the version instance corresponding to the version identifier.

[0086] Based on any of the above embodiments, the page return module 402 is specifically configured to: Determine the version of the front-end page to be returned to the user based on the carried parameters and a pre-received user gray-scale rule; Add the version identifier of the front-end page to the corresponding front-end code to generate a front-end page of the target version, and return the front-end page of the target version to the user.

[0087] Based on any of the above embodiments, the request generation module 403 is specifically configured to: When it is determined that the method of calling the first back-end service is a preset calling method, send the first back-end service request to the communication middleware of the first back-end service; Control the communication middleware to call a target version instance of the first back-end service to respond to the first back-end service request based on the version identifier.

[0088] Based on any of the above embodiments, the gray-scale release device of the Internet application further includes a version identifier pass-through module, configured to: When it is determined that the first back-end service request calls a second back-end service, control the communication middleware to generate a second back-end service request based on the version identifier; Call a target version instance of the second back-end service to respond to the second back-end service request based on the version identifier; wherein, the second back-end service includes at least two version instances, and the target version instance is the version instance corresponding to the version identifier.

[0089] Based on any of the above embodiments, the version identifier includes the page identifier of the front-end page and the carry flag of the first back-end service request; The request generation module 403 is specifically configured to: Determine an initial back-end service request to be sent to the back-end according to the user's operation on the front-end page; Convert the page identifier into a carry flag, add the carry flag to the code of the initial back-end service request, and generate a first back-end service request.

[0090] Based on any of the above embodiments, the version identifier includes a gray-scale identifier and a version value; The request response module 404 is specifically configured to: When it is determined that the gray-scale identifier in the version identifier takes a gray-scale version value and the version value is the current gray-scale version value of the first back-end service, send the first back-end service request to the gray-scale version instance of the first back-end service for processing.

[0091] Based on any of the above embodiments, the gray-scale release device of the Internet application further includes a user grouping module for: Set a specified number of groups, and determine the gray-scale group and the baseline group in the groups based on the gray-scale release ratio; Obtain the user identifier from the carry parameters and randomly assign the user identifier to the groups; The page return module 402 is specifically configured to: When it is determined that the carry parameter is a non-mandatory test parameter, obtain the user identifier in the access request; Based on the group where the user identifier is located, return the front-end page of the target version to the user.

[0092] Figure 5 Illustrates a schematic structural diagram of an electronic device, such as Figure 5As shown in the figure, the electronic device may include: a processor 510, a communications interface 520, a memory 530, and a communication bus 540. Among them, the processor 510, the communications interface 520, and the memory 530 complete communication with each other through the communication bus 540. The processor 510 may call the logical instructions in the memory 530 to execute the method for the gray release of Internet applications. The method includes: receiving an access request from a user for a front-end page, and extracting the carried parameters of the access request; returning a front-end page of a target version to the user based on the carried parameters and the pre-received user gray rules; the front-end page includes at least two versions of the front-end page, and the front-end page of the target version is the front-end page corresponding to the carried parameters; the front-end page includes a version identifier; receiving an operation of the user on the front-end page to generate a first back-end service request; the first back-end service request includes the version identifier; calling a target version instance of the first back-end service to respond to the first back-end service request based on the version identifier; where the first back-end service includes at least two version instances, and the target version instance is the version instance corresponding to the version identifier.

[0093] In addition, when the logical instructions in the above-mentioned memory 530 can be implemented in the form of software functional units and sold or used as an independent product, they can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of the present invention. The foregoing storage medium includes: various media such as a USB flash drive, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk, or an optical disc that can store program codes.

[0094] On the other hand, the present invention also provides a computer program product, which includes a computer program. The computer program can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the gray release method of the Internet application provided by the above-mentioned various methods. The method includes: receiving an access request from a user to a front-end page, and extracting the carried parameters of the access request; based on the carried parameters and the pre-received user gray rules, returning a front-end page of a target version to the user; the front-end page includes at least two version front-end pages, and the front-end page of the target version is the front-end page corresponding to the carried parameters; the front-end page includes a version identifier; receiving an operation of the user on the front-end page to generate a first back-end service request; the first back-end service request includes the version identifier; based on the version identifier, calling a target version instance of the first back-end service to respond to the first back-end service request; wherein, the first back-end service includes at least two version instances, and the target version instance is the version instance corresponding to the version identifier.

[0095] In another aspect, the present invention also provides a non-transitory computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it is configured to execute the gray release method of the Internet application provided by the above-mentioned various methods. The method includes: receiving an access request from a user to a front-end page, and extracting the carried parameters of the access request; based on the carried parameters and the pre-received user gray rules, returning a front-end page of a target version to the user; the front-end page includes at least two version front-end pages, and the front-end page of the target version is the front-end page corresponding to the carried parameters; the front-end page includes a version identifier; receiving an operation of the user on the front-end page to generate a first back-end service request; the first back-end service request includes the version identifier; based on the version identifier, calling a target version instance of the first back-end service to respond to the first back-end service request; wherein, the first back-end service includes at least two version instances, and the target version instance is the version instance corresponding to the version identifier.

[0096] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated. The components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. 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 labor.

[0097] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on such an understanding, the essence of the above technical solution, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0098] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than 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 make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A grayscale release method for an Internet application, characterized in that: include: Receive a user's access request to a front-end page, and extract parameters carried in the access request; Returning the front-end page of the target version to the user based on the carried parameters and the pre-received user grayscale rules; the front-end page includes at least two version front-end pages, and the front-end page of the target version is the front-end page of the version corresponding to the carried parameters; the front-end page includes a version identifier; Receive a first backend service request generated by a user's operation on the frontend page; the first backend service request includes the version identifier; Based on the version identifier, a target version instance of the first backend service is called to respond to the first backend service request; wherein the first backend service includes at least two version instances, and the target version instance is the version instance corresponding to the version identifier.

2. The grayscale release method of Internet applications according to claim 1, characterized in that: The returning the target version of the front-end page to the user based on the carried parameters and the pre-received user grayscale rule includes: Determine the version of the front-end page to be returned to the user based on the carried parameters and the pre-received user grayscale rule; The version identifier of the front-end page is added to the corresponding front-end code to generate a target version of the front-end page, and the target version of the front-end page is returned to the user.

3. The grayscale release method of an Internet application according to claim 1 or 2, characterized in that: The calling of the target version instance of the first backend service based on the version identifier to respond to the first backend service request includes: When determining that the method of calling the first backend service is a preset calling method, sending the first backend service request to the communication middleware of the first backend service; The communication middleware is controlled based on the version identifier to call a target version instance of a first backend service to respond to the first backend service request.

4. The grayscale release method of Internet applications according to claim 3, characterized in that: After controlling the communication middleware to call the target version instance of the first backend service in response to the first backend service request based on the version identifier, the method further includes: When determining that the first backend service request calls a second backend service, controlling the communication middleware to generate a second backend service request based on the version identifier; Based on the version identifier, the target version instance of the second backend service is called to respond to the second backend service request; wherein the second backend service includes at least two version instances, and the target version instance is the version instance corresponding to the version identifier.

5. The grayscale release method of Internet applications according to claim 1, characterized in that: The version identifier includes the page identifier of the front-end page and the carrying identifier of the first back-end service request; The receiving of a first backend service request generated by an operation of a user on the frontend page includes: Determine an initial backend service request to be sent to the backend according to the user's operation on the frontend page; The page identifier is converted into a carrying tag, and the carrying tag is added to the code of the initial backend service request to generate a first backend service request.

6. The grayscale release method of Internet applications according to claim 1, characterized in that: The version identifier includes a grayscale identifier and a version value; The calling of the target version instance of the first backend service based on the version identifier to respond to the first backend service request includes: When it is determined that the grayscale identifier in the version identifier is a grayscale version value and the version value is the current grayscale version value of the first backend service, the first backend service request is sent to the grayscale version instance of the first backend service for processing.

7. The grayscale release method of Internet applications according to claim 1, characterized in that: Before returning the front-end page of the target version to the user based on the carried parameters and the pre-received user grayscale rule, the method further includes: Setting a specified number of groups, and determining a grayscale group and a baseline group in the group based on a grayscale release ratio; Obtaining a user identifier from the carried parameter, and randomly assigning the user identifier to the group; Returning a front-end page of a target version to the user based on the carried parameters and the pre-received user grayscale rule includes: When it is determined that the carried parameter is a non-mandatory test parameter, obtaining the user identifier in the access request; Based on the group to which the user ID belongs, a front-end page of a target version is returned to the user.

8. A grayscale release device for an Internet application, characterized in that: include: A parameter extraction module is used to receive a user's access request to a front-end page and extract the parameters carried in the access request; A page return module, used to return the front-end page of the target version to the user based on the carried parameters and the pre-received user grayscale rules; the front-end page includes at least two version front-end pages, and the front-end page of the target version is the front-end page of the version corresponding to the carried parameters; the front-end page includes a version identifier; A request generation module, configured to receive an operation performed by a user on the front-end page to generate a first back-end service request; the first back-end service request includes the version identifier; A request response module is used to call a target version instance of a first backend service based on the version identifier to respond to the first backend service request; wherein the first backend service includes at least two version instances, and the target version instance is the version instance corresponding to the version identifier.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that: When the processor executes the computer program, the method for grayscale release of an Internet application as described in any one of claims 1 to 7 is implemented.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method for grayscale release of an Internet application as described in any one of claims 1 to 7 is implemented.

Images