A product service iteration method and device, electronic equipment and storage medium

Abstract

Embodiments of the present application disclose a product service iteration method and device, electronic equipment and a storage medium. The method comprises: in response to a product service calling request, determining a product service to be called, wherein the product service can be deployed on at least two server clusters respectively; determining a service cluster from each server cluster according to the flow splitting configuration of the product service, wherein the service cluster is used to provide the product service; forwarding the product service calling request to the product service deployed on the service cluster to realize the calling process of the product service and the iteration process on the stop service cluster, wherein the stop service cluster comprises at least two server clusters except the service cluster, and the stop service cluster stops providing the product service. The technical scheme of the embodiments of the present application can realize the iteration process of the product service through the flow splitting operation in the product service dimension, thereby ensuring the implementation efficiency and success rate of the iteration process.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of computer application technology, and in particular to a product service iteration method, apparatus, electronic device and storage medium. Background Technology

[0002] With the rapid development of cloud computing technology, Software-as-a-Service (SaaS) platforms have gradually emerged. SaaS platforms are platforms that provide product services over the internet, making them highly attractive to small and medium-sized enterprises (SMEs) with limited budgets and insufficient technical capabilities.

[0003] To ensure high availability of product services, the products and services on the SaaS platform are deployed across at least two server clusters. Furthermore, to guarantee a consistent user experience, iterative processes need to be implemented for the product services on each server cluster. Currently, this iterative process is primarily achieved through platform-level traffic switching operations.

[0004] In the process of realizing this invention, the inventors discovered the following technical problems in the prior art: it is difficult to guarantee the efficiency and success rate of the product service iteration process. Summary of the Invention

[0005] This invention provides a product service iteration method, apparatus, electronic device, and storage medium, which solves the problem of difficulty in guaranteeing the implementation efficiency and success rate of the product service iteration process.

[0006] According to one aspect of the present invention, a product service iteration method is provided, which may include:

[0007] In response to a product service call request, determine the product service to be called, wherein the product service may be deployed on at least two server clusters;

[0008] Based on the flow cutting configuration of the product service, the service provision cluster is determined from each server cluster, where the service provision cluster is used to provide product services;

[0009] The product service call request is forwarded to the product service deployed on the service enhancement cluster to realize the product service call process and the iteration process on the service shutdown cluster. The service shutdown cluster is a cluster other than the service enhancement cluster among at least two server clusters. The service shutdown cluster stops providing product services.

[0010] According to another aspect of the present invention, a product service iteration apparatus is provided, which may include:

[0011] The product service determination module is used to respond to product service call requests and determine the product service to be called, wherein the product services are deployed on at least two server clusters respectively;

[0012] The service provision cluster determination module is used to determine the service provision cluster from various server clusters based on the flow switching configuration of the product service. The service provision cluster is used to provide product services.

[0013] The product service iteration module is used to forward product service call requests to the product services deployed on the service enhancement cluster, so as to realize the product service call process and the iteration process on the service suspension cluster. The service suspension cluster is a cluster other than the service enhancement cluster among at least two server clusters, and the service suspension cluster stops providing product services.

[0014] According to another aspect of the present invention, an electronic device is provided, which may include:

[0015] At least one processor; and

[0016] A memory that is communicatively connected to at least one processor; wherein,

[0017] The memory stores a computer program that can be executed by at least one processor, such that when the at least one processor executes the program, it implements the product service iteration method provided in any embodiment of the present invention.

[0018] According to another aspect of the present invention, a computer-readable storage medium is provided having computer instructions stored thereon for causing a processor to execute and implement the product service iteration method provided in any embodiment of the present invention.

[0019] The technical solution of this invention, in response to a product service call request, determines the product service to be called. To ensure the high availability of this product service, it is deployed on at least two server clusters. Based on the traffic switching configuration of the product service, a service provisioning cluster (i.e., responsible for the online traffic of the product service) is determined from each server cluster. The product service call request is forwarded to the product service deployed on the service provisioning cluster, thereby realizing the product service call process. Furthermore, since the service-inactive clusters (excluding the service provisioning cluster) in the at least two server clusters are no longer responsible for the online traffic of the product service, the iterative process of the product service on the service-inactive cluster can be realized without the user's awareness. The above technical solution, through traffic switching operations at the product service level, realizes the product service iteration process, thereby ensuring the efficiency and success rate of the product service iteration process.

[0020] It should be understood that the description in this section is not intended to identify key or important features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart of a product service iteration method provided according to an embodiment of the present invention;

[0023] Figure 2 This is a flowchart of another product service iteration method provided according to an embodiment of the present invention;

[0024] Figure 3 This is a flowchart of another product service iteration method provided according to an embodiment of the present invention;

[0025] Figure 4 This is a schematic diagram of an optional example of another product service iteration method provided according to an embodiment of the present invention;

[0026] Figure 5 This is a structural block diagram of a product service iteration device provided according to an embodiment of the present invention;

[0027] Figure 6 This is a schematic diagram of the structure of an electronic device that implements the product service iteration method of this invention. Detailed Implementation

[0028] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0029] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. The same applies to "target," "original," etc., and will not be repeated here. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0030] To better understand how the product service iteration method described in this embodiment of the invention ensures the efficiency of the product service iteration process, the iteration process implemented through platform-level flow switching operations, as described in the background section, will be explained exemplarily below. For example, taking a SaaS platform, to ensure that all service products on the SaaS platform provide users with a unified user experience, a unified gateway architecture design is adopted to standardize the platform's technical architecture and design style. Specifically, assuming that product service A, product service B, product service C, and a gateway service are connected to the SaaS platform, and to ensure high availability, a primary cluster (i.e., a primary server cluster) and a backup cluster (i.e., a backup server cluster) are set up, then these four services are deployed under both clusters. The SaaS platform provides a unified platform domain name (hereinafter referred to as the domain name) (e.g., www.xxx.com) as an entry point for users, allowing users to access the domain name through a browser to call product services on the SaaS platform. For example, the domain name service on the SaaS platform resolves the domain name to the gateway service of a certain cluster, and then forwards the product service call request sent by the user through the browser to the corresponding product service under that cluster through the gateway service, thereby realizing the product service call process.

[0031] It's important to note that since the cluster to which a domain name is resolved is controllable, a smooth rollout of service products can be achieved by switching the domain name's resolution across different clusters. For example, taking product service A as an example, the currently deployed (i.e., on the primary and backup clusters) version is 1.0. To deploy version 2.0 of product service A, the following steps can be taken:

[0032] 1. First, resolve the domain name to the primary cluster gateway instance. At this time, the backup cluster has no production traffic. Then, publish and verify the A product service under the backup cluster.

[0033] 2. After the A product service under the standby cluster has been published and verified, the domain name is resolved to the standby cluster gateway instance. At this time, there is no production traffic in the primary cluster, so the A product service under the primary cluster is published and verified.

[0034] 3. After the A product service under the primary cluster is published and verified, the domain name will be resolved to the primary and backup cluster gateway instances simultaneously to support the online traffic of the A product service.

[0035] As can be seen from the above, this is a product-level traffic switching operation (i.e., traffic switching is achieved by resolving the domain name to different cluster gateway instances). In other words, during the iteration of product services under the main cluster, the backup cluster has no production traffic, and vice versa. Thus, the iteration process of product services can be achieved without the user's awareness. That is, the iteration process of a product service can be achieved while allowing users to use a certain product service normally.

[0036] It should be noted that the above-described solution for implementing product service iteration through product-level traffic switching is feasible when the number of product services integrated into the SaaS platform is limited and the iteration frequency of each product service is low. However, when the SaaS platform integrates a large number of product services and / or the iteration frequency of each product service is high, the above solution can easily lead to a consistently high deployment pace on the SaaS platform, resulting in the following problems:

[0037] On the one hand, there are a large number of product services that need to be iterated within the same time period. Since they all need to switch traffic through domain name resolution, this means that each product service that needs to be deployed must be verified before the primary and backup clusters can switch traffic. If there are problems in the release verification process of one or more product services and they cannot be resolved for a long time, other product services that need to be deployed will have to wait, resulting in a continuous increase in deployment time and a decrease in efficiency, making it difficult to guarantee the efficiency of the iteration process.

[0038] On the other hand, the deployment of each product service depends on domain name resolution switching. Before the resolution switching, it is necessary to confirm with each product service whether it is verified to be correct in the cluster where it is currently deployed. Obviously, this not only makes domain name resolution switching a bottleneck, but also may cause a product service to have online problems after the resolution switching due to the failure to execute the complex confirmation process properly, thus causing a major online incident. In other words, it is difficult to guarantee the success rate of the product service iteration process.

[0039] To address the two issues mentioned above, the inventors, based on a thorough study of the prior art, proposed the product service iteration method described in the following embodiments.

[0040] Figure 1This is a flowchart of a product service iteration method provided in an embodiment of the present invention. This embodiment is applicable to product service iteration, especially to situations where product service iteration is achieved through flow switching operations at the product service dimension. This method can be executed by the product service iteration device provided in this embodiment of the present invention. This device can be implemented in software and / or hardware, and can be integrated into an electronic device, which can be a server (such as a gateway server) or a user terminal.

[0041] See Figure 1 The method of this invention specifically includes the following steps:

[0042] S110. In response to the product service call request, determine the product service to be called, wherein the product service is deployed on at least two server clusters.

[0043] The product service invocation request can be a request initiated by a user terminal to invoke a product service deployed on a server cluster. This product service is the one to be invoked, such as a query service, save service, or modify service. It should be noted that, to ensure the high availability of this product service, it can be pre-deployed on at least two server clusters. The above product service invocation request only requests to invoke the product service and does not specify which server cluster the product service is deployed on.

[0044] In practical applications, optionally, the aforementioned product service call request can be responded to by a gateway service. This gateway service can be a service deployed on servers (or server clusters) outside of at least two server clusters, or it can be a service deployed separately on at least two server clusters; no specific limitation is made here. When the gateway service is deployed separately on at least two server clusters, which server cluster ultimately responds to the product service call request, or in other words, which server cluster receives the product service call request, can be determined by a pre-configured load balancing algorithm.

[0045] S120. Based on the product service flow switching configuration, determine the service provision cluster from each server cluster, whereby the service provision cluster is used to provide product services.

[0046] The traffic switching configuration can be a pre-set configuration for this product service to determine which one or more server clusters from at least two server clusters are responsible for online traffic (i.e., providing the product service). This online traffic can also be referred to as production traffic. Therefore, the service-providing cluster, i.e., the server cluster used to provide the product service, can be determined from each server cluster based on this traffic switching configuration.

[0047] S130. Forward the product service call request to the product service deployed on the service-enhancing cluster to realize the product service call process and the iteration process on the service-stopping cluster. The service-stopping cluster is a cluster other than the service-enhancing cluster among at least two server clusters. The service-stopping cluster stops providing product services.

[0048] In this configuration, the service provisioning cluster is the server cluster responsible for the online traffic of this product service. Therefore, received product service call requests can be forwarded to the product service deployed on this cluster, thus enabling the product service call process. For example, since each product service provides a unique external interface, the product service call request can be forwarded to the product service deployed on the service provisioning cluster through the corresponding interface. It should be noted that under this traffic switching configuration, every product service call request will be forwarded to the service provisioning cluster. This means that at least two server clusters, excluding the service provisioning cluster, no longer need to handle the online traffic of this product service. In other words, the service provisioning cluster can be understood as the server cluster that has stopped providing this product service, allowing the product service iteration process to be implemented on this service provisioning cluster.

[0049] Therefore, the above technical solution achieves the product service iteration process through traffic switching operations at the product service level. Specifically, when iterating on a particular product service, all online traffic for that product service is switched to its dedicated server cluster. The server cluster to which the online traffic of other product services is switched depends on their respective traffic switching configurations; all online traffic for all product services will not be uniformly switched to the same dedicated server cluster. This ensures that even if multiple product services have iteration needs within the same timeframe, the iteration process will not suffer from low efficiency due to waiting for all product services to be released and verified on one server cluster before switching to another, nor will it fail due to incomplete complex confirmation processes. This guarantees the efficiency and success rate of the iteration process for any product service.

[0050] To more vividly illustrate the product service iteration process achieved through traffic switching operations at the product service level, the following example demonstrates how traffic switching configurations can be configured. When R&D testers need to iterate (i.e., update) a deployed product service, they can easily configure the traffic switching for that service on the established product service traffic switching platform. This configuration can be represented by a mapping relationship like appType:prd, where appType represents the service identifier (i.e., the product service is represented by the service identifier), and prd represents the cluster identifier of the corresponding service provisioning cluster (i.e., the service provisioning cluster is represented by the cluster identifier). It's important to note that multiple product services may have iteration requirements within the same timeframe, and these services may correspond to the same or different service provisioning clusters. This is a clear demonstration of traffic switching operations based on the product service level. For example, suppose any product service is deployed on two server clusters prd1 and prd2 respectively. For three product services appType1, appType2 and appType3 that have iteration requirements within the same time period, the traffic switching configuration set by the R&D testers for them is appType1:prd1, appType2:prd1 and appType3:prd2 respectively. This means that prd1 is responsible for the online traffic of appType1 and appType2, and prd2 is responsible for the online traffic of appType3. Then the R&D testers can implement the deployment of new versions of appType1 and appType2 on prd2, which is not responsible for the online traffic of appType1 and appType2, and implement the deployment of new versions of appType3 on prd1, which is not responsible for the online traffic of appType3. Taking appType2 as an example, once the new version of appType2 has passed release verification on prd2, the development testers can change appType2:prd1 to appType2:prd2, so that prd2 will be responsible for the online traffic of appType2, thus enabling the deployment of the new version of appType2 on prd1. The traffic switching process for appType1 and appType3 is similar and will not be described in detail here.

[0051] As can be seen from the above, compared with the product service iteration process achieved through platform-level traffic switching operations, the above technical solution does not rely on domain name resolution, thereby reducing the domain name traffic switching resolution cost; it isolates the impact of traffic switching between various product services, and can switch traffic online at any time according to iteration needs, thereby reducing the risk of misoperation caused by unified traffic switching and improving the implementation efficiency of the iteration process; by sinking the traffic switching operation from the domain name service to the gateway service, the gateway service no longer needs to switch traffic back and forth according to the product service launch rhythm.

[0052] The technical solution of this invention, in response to a product service call request, determines the product service to be called. To ensure the high availability of this product service, it is deployed on at least two server clusters. Based on the traffic switching configuration of the product service, a service provisioning cluster (i.e., responsible for the online traffic of the product service) is determined from each server cluster. The product service call request is forwarded to the product service deployed on the service provisioning cluster, thereby realizing the product service call process. Furthermore, since the service-inactive clusters (excluding the service provisioning cluster) in the at least two server clusters are no longer responsible for the online traffic of the product service, the iterative process of the product service on the service-inactive cluster can be realized without the user's awareness. The above technical solution achieves the product service iteration process through traffic switching operations at the product service level, thereby ensuring the efficiency and success rate of the iteration process.

[0053] An optional technical solution for determining the product service to be invoked may include: obtaining the service identifier of the product service to be invoked from the product service invocation request, and determining the product service based on the service identifier; the above product service iteration method may further include: obtaining a pre-configured set of traffic-switching configurations, and obtaining traffic-switching configurations from the set of traffic-switching configurations, wherein the traffic-switching configurations represent the mapping relationship between the service identifier and the cluster identifier of the service cluster. Here, the service identifier can be understood as a unique identifier for the product service, thus the product service can be uniquely identified based on the service identifier. The set of traffic-switching configurations may be a pre-set set containing multiple candidate configurations. Since each candidate configuration can represent the mapping relationship between a service identifier and the cluster identifier of a server cluster, the traffic-switching configuration related to the mapping relationship of the service identifier can be obtained from the set of traffic-switching configurations, thereby achieving the effect of rapid determination of traffic-switching configurations.

[0054] Another optional technical solution is to apply the above-mentioned product service iteration method to gateway services, which are deployed on each server cluster. Furthermore, the product service iteration method can further include: if a traffic switching configuration is not obtained, the server cluster where the gateway service receiving the product service call request resides is designated as the service provisioning cluster. In practical applications, relevant personnel can only set the corresponding traffic switching configuration for product services with iteration needs. This is because product service call requests for product services that do not require iteration can be processed by any server cluster. This is similar to a non-splitting state, where the product service call request falls into a server cluster and can be directly processed by that server cluster. In other words, when a gateway service deployed on a server cluster receives a product service call request, if it has not obtained the traffic switching configuration for the requested product service, it can directly use its own server cluster as the service provisioning cluster, thereby ensuring an effective response to product service call requests for product services with or without iteration needs.

[0055] Another optional technical solution, the aforementioned product service iteration method, may further include: periodically obtaining the traffic switching configuration and updating the traffic switching configuration stored in the cache based on the periodically obtained traffic switching configuration; correspondingly, after determining the product service to be called, the aforementioned product service iteration method may further include: obtaining the traffic switching configuration from the cache. In the process of product service iteration, in order not to affect the normal application of product services with iteration requirements by users, relevant personnel usually first deploy the product service on one server cluster, and then switch to another server cluster for deployment. This means that the traffic switching configuration of the product service is not fixed. Therefore, the traffic switching configuration can be obtained periodically, and the traffic switching configuration stored in the cache can be updated based on the periodically obtained traffic switching configuration, that is, the historically obtained traffic switching configuration can be updated. This ensures that the traffic switching configuration obtained from the cache later is the latest traffic switching configuration, thereby preventing the forwarding of product service call requests to the server cluster where the product service is being deployed. This achieves the iteration process of the product service on each server cluster without the user's awareness. Based on this, optionally, the above-mentioned timed acquisition process can be understood as acquiring the configuration once every preset time interval (e.g., 20 seconds), or it can be understood as acquiring it once at each preset time point, etc., without specific limitations. Further optionally, the above technical solution can also be used to implement timed synchronization of the flow switching configuration for any product service, not limited to the timed synchronization of product services with iteration and / or calling requirements, thereby ensuring that when iterating any product service, its latest flow switching configuration can be obtained from the cache.

[0056] Before introducing the embodiments of the present invention, the application scenarios of the embodiments of the present invention will be illustrated by way of example. Product services often involve some static resources that rarely change, such as JS files or CSS files. These static resources can be stored directly in the product service; or they can be stored in a Content Delivery Network (CDN) node. In this way, when calling the product service, the address of the CDN node where the static resources of the product service are located can be directly returned to the user terminal without returning the static resources, thereby speeding up the user terminal's acquisition of these static resources. In the second case, the address of the CDN node where the static resources of each product service are located can be stored in the gateway service. However, this method of maintaining the address through the gateway service increases the coupling between the product service and the gateway service, causing the independent product service to lose its complete closed-loop capability. In addition, although static resources rarely change, there is always the possibility of change. This means that the address stored in the gateway service needs to be modified and published at that time. When this operation is too frequent, it can easily reduce the overall stability of the platform. To solve the above problems, the product service iteration method in the following embodiments is proposed.

[0057] Figure 2 This is a flowchart of another product service iteration method provided in this embodiment of the invention. This embodiment is based on the above-described technical solutions and optimized. In this embodiment, optionally, the production resources of the product service are stored on a first content delivery network node, and the first address of the first content delivery network node is configured within the product service; after determining the service delivery cluster from each server cluster, the above-described product service iteration method may further include: obtaining the first address from the product service deployed on the service delivery cluster; returning the first address to the initiator of the product service call request, so that the initiator obtains the production resources from the first content delivery network node corresponding to the received first address, and loads and renders the production resources. The explanations of terms that are the same as or corresponding to those in the above embodiments are not repeated here.

[0058] See Figure 2 The method in this embodiment may specifically include the following steps:

[0059] S210. In response to the product service call request, determine the product service to be called, wherein the product service is deployed on at least two server clusters.

[0060] S220. Based on the product service flow switching configuration, determine the service provision cluster from each server cluster, whereby the service provision cluster is used to provide product services.

[0061] S230, The production resources of the product service are stored on the first content distribution network node, and the first address of the first content distribution network node is configured in the product service, and the first address is obtained from the product service deployed on the service cluster.

[0062] In this context, production resources can be understood as static resources for the online formal application of a product service, also known as formal resources. These production resources are stored on the first CDN node, and the first address of this first CDN node is configured within the product service. In other words, the first address corresponding to each product service is maintained by the product service itself. Based on this, for a product service to be invoked, the corresponding first address can be obtained from the product service deployed on the service provider cluster. In practical applications, optionally, this first address can be obtained through a resource loading interface.

[0063] S240. Return the first address to the initiator of the product service call request, so that the initiator can obtain the production resources from the first content delivery network node corresponding to the received first address, and load and render the production resources.

[0064] The initiator can be the object that initiates the product service call request, such as the user terminal illustrated above. The first address is returned to the initiator so that the initiator can dynamically pull the production resource from the first CDN node corresponding to the received first address, thereby enabling the loading and rendering of the production resource.

[0065] It should be noted that when static resources change, the iteration process of those resources can also be implemented based on the product service iteration methods described in the above technical solutions. Specifically, in addition to configuring the traffic switching of the product service to obtain the service cluster, relevant personnel can also modify the first address configured within the product service deployed on the off-site cluster to a second address. The second CDN node corresponding to this second address stores the gray-scale resources (i.e., the updated production resources). Thus, similar product service release verification can be performed on the gray-scale resources, thereby realizing the iteration process of the static resources.

[0066] S250. Forward the product service call request to the product service deployed on the service-enhancing cluster to realize the product service call process and the iteration process on the service-stopping cluster. The service-stopping cluster is a cluster other than the service-enhancing cluster among at least two server clusters. The service-stopping cluster stops providing product services.

[0067] It should be noted that S230 and S250 can be executed sequentially (e.g., S250 is executed after S230 has finished executing, or S230 is executed after S250 has finished executing) or in parallel (i.e., the execution processes of S230 and S250 do not interfere with each other), without any specific limitations here.

[0068] The technical solution of this invention uses a dynamic loading mechanism for production resources to split the production resources into product services for maintenance. That is, the address configuration is moved from the gateway service to the product service, thereby eliminating the product service's dependence on the gateway service and realizing the independent closed-loop development and deployment of the product service. Furthermore, the gateway service no longer needs to be configured and released in accordance with the product service's launch schedule, thereby reducing the daily manpower investment for gateway service launches and improving the overall stability of the platform.

[0069] Based on this, an optional technical solution is that the grayscale resources of the product service are stored on a second content distribution network node, and the second address of the second content distribution network node is configured within the product service. The grayscale resources are updated production resources. Obtaining the first address from the product service deployed on the service provisioning cluster may include: if the grayscale resource request parameters are not obtained from the product service call request, then obtaining the first address from the product service deployed on the service provisioning cluster. After determining the service provisioning cluster from each server cluster, the above product service iteration method may further include: if the grayscale resource request parameters are obtained, then obtaining the second address from the product service deployed on the service provisioning cluster; returning the second address to the initiator so that the initiator can obtain the grayscale resources from the second content distribution network node corresponding to the received second address, and load and render the grayscale resources.

[0070] In this context, gray-scale resources can be understood as updated production resources, i.e., static resources awaiting release and verification. Similar to production resources, these gray-scale resources are stored on a second CDN node, and the second address of this second CDN node is configured within the product service. In other words, if a product service corresponds to a second address, then that second address is maintained by the product service itself. It should be noted that, typically, the first address and the second address are different addresses, meaning the first CDN node and the second CDN node are different CDN nodes. This is because if they were the same, meaning the gray-scale resource overwrites the production resource, users would directly apply the unverified gray-scale resource, potentially leading to online incidents.

[0071] In addition to the static resource iteration process implemented through product service-level traffic switching operations as described above, another optional solution for implementing static resource iteration is presented here. Specifically, to distinguish between product service call requests initiated by users and those initiated by relevant personnel (such as R&D and testing personnel), the relevant personnel can add a grayscale resource request parameter (grayTag) to the product service call request, indicating that this request is for grayscale resources. In this way, upon receiving a product service call request, it can be first determined whether it contains the grayscale resource request parameter. If it is not included, it indicates that the request was initiated by a user, and the first address can be obtained from the product service deployed on the service delivery cluster. If it is included, it indicates that the request was initiated by a relevant personnel, and the second address can be obtained from the product service deployed on the service delivery cluster. This second address is then returned to the initiator (such as the user terminal operated by the relevant personnel), enabling the initiator to obtain the grayscale resource from the second CDN node corresponding to the received second address, thereby realizing the loading and rendering of the grayscale resource. The above technical solution determines whether to return the first address or the second address to the initiator by judging whether the gray-scale resource request parameters are obtained from the received product service call request. This ensures both the normal application of the product service by the user and the release and verification of gray-scale resources by relevant personnel. This is an iterative process of static resources that can be achieved without traffic switching operations, and it is more convenient to use.

[0072] Optionally, the above product service iteration method may further include: responding to an address overwrite instruction, overwriting the first address with the second address, and deleting the second address. That is, after the gray-scale resource release verification is passed, the first address configured within the product service is overwritten with the second address configured within the product service, thereby ensuring that users are using the updated online resources (i.e., gray-scale resources) when calling the product service; and, the second address configured within the product service is deleted.

[0073] Figure 3 This is a flowchart of another product service iteration method provided in this embodiment of the invention. This embodiment is based on and optimized from the above-described technical solutions. Optionally, in this embodiment, the product service iteration method is applied to a gateway service, which can be deployed on each server cluster. Furthermore, the production resources of the product service are stored on a first CDN node, and the gray-scale resources of the product service are stored on a second CDN node. The gray-scale resources are updated production resources, and the first address of the first CDN node and the second address of the second CDN node are both configured within the product service. Explanations of terms that are the same as or corresponding to those in the above embodiments will not be repeated here.

[0074] See Figure 3The method in this embodiment may specifically include the following steps:

[0075] S3010. In response to a product service call request, obtain the service identifier of the product service to be called from the product service call request, and determine the product service based on the service identifier, wherein the product service is deployed on at least two server clusters respectively.

[0076] Each server cluster deploys both product services and gateway services. When a gateway service deployed on any server cluster receives a product service invocation request, it responds to the request by obtaining the service identifier of the product service to be invoked, and then identifies the product service.

[0077] S3020: Periodically obtain the flow switching configuration set and update the flow switching configuration set stored in the cache according to the periodically obtained flow switching configuration set.

[0078] It should be noted that this step is a timed execution step, meaning that its execution order with the other steps depends on the actual situation, and no restrictions are imposed here.

[0079] S3030: Retrieve the flow switching configuration set from the cache.

[0080] S3040. If the flow cutting configuration of the product service is obtained from the flow cutting configuration set, the service provisioning cluster is determined from each server cluster according to the flow cutting configuration. The flow cutting configuration represents the mapping relationship between the service identifier and the cluster identifier of the service provisioning cluster.

[0081] S3050. If a flow-cutting configuration is not obtained from the flow-cutting configuration set, the server cluster where the gateway service that receives the product service call request is located will be used as the service provision cluster, where the service provision cluster is used to provide product services.

[0082] S3060. If the grayscale resource request parameters are not obtained from the product service call request, the first address is obtained from the product service deployed on the service cluster.

[0083] S3070. Return the first address to the initiator of the product service call request so that the initiator can obtain the production resources from the first CDN node corresponding to the received first address and load and render the production resources.

[0084] S3080. If the gray-scale resource request parameters are obtained, the second address is obtained from the product service deployed on the service cluster.

[0085] S3090. Return the second address to the initiator so that the initiator can obtain the grayscale resource from the second CDN node corresponding to the received second address and load and render the grayscale resource.

[0086] S3100: In response to the address overwrite instruction, the first address is overwritten based on the second address, and the second address is deleted to realize the iterative process of production resources.

[0087] S3110. Forward the product service call request to the product service deployed on the service-providing cluster to realize the product service call process and the iteration process on the service-stopping cluster. The service-stopping cluster is a cluster other than the service-providing cluster among at least two server clusters. The service-stopping cluster stops providing product services.

[0088] It should be noted that, taking the S3060-S3070 branch as an example (the situation for S3080-S3090 is similar), the execution order of this branch and S3110 can be either first or last, or they can be executed in parallel, without any specific restrictions here.

[0089] The technical solution of this invention realizes the flow switching operation at the product service level by sinking the flow switching operation from the domain name service to the gateway service, thereby ensuring the efficiency and success rate of the product service iteration process. In addition, by sinking the address configuration from the gateway service to the product service, the independent closed-loop development and deployment of the product service is realized, and the overall stability of the platform is improved.

[0090] To better understand the above technical solution, a specific example is provided below for illustration. For an example, see [link to example]. Figure 4 Here, we'll still use the SaaS platform from the example above to demonstrate the traffic switching operation at the product service level. Specifically,

[0091] 1. Introduce a product service switching platform to support R&D and testing personnel in setting switching configurations for product services with iteration needs on the product service switching platform, and obtain a set of switching configurations. This set of switching configurations can be stored in the database by the product service switching service.

[0092] 2. The gateway services deployed in each cluster periodically pull the flow switching configuration set and store the pulled flow switching configuration set in the local cache of the gateway service, thereby realizing the synchronization of the flow switching configuration set;

[0093] 3. After a user accesses www.xxx.com through a browser, the platform uses a load balancing algorithm to forward the corresponding product service call request to the gateway service deployed in a cluster (such as a primary cluster or a backup cluster). The gateway service then performs the following steps: If it obtains the flow-cutting configuration from the flow-cutting configuration set stored in the local cache based on the appType in the received product service call request, it can determine whether to use the primary cluster or the backup cluster as the service provisioning cluster based on the flow-cutting configuration; otherwise, it means that the product service corresponding to the appType (taking product service A as an example here) does not have an iteration requirement, and the cluster where the gateway service is located can be used as the service provisioning cluster.

[0094] 4. The gateway service forwards product service call requests to the product service deployed on the service cluster through the interface provided by product service A. This enables the call process of product service A and the iteration process on the service cluster, thereby realizing the dynamic flow switching of product service A.

[0095] Based on this, if some static resources of product A's service are stored on CDN nodes, the flow switching process for these static resources can be implemented through the following steps. Specifically,

[0096] 1. Configure the first address of the first CDN node where the production resource corresponding to the static resource is located and the second address of the second CDN node where the grayscale resource is located in product service A.

[0097] 2. The gateway service determines whether the received product service call request contains a grayTag. If it does, it obtains the first address from product service A based on the resource loading interface and returns the first address to the browser, so that the browser can obtain the production resource from the first CDN node corresponding to the received first address, load and render the production resource, and the user can browse the production resource. Otherwise, it obtains the second address from product service A based on the resource loading interface and returns the second address to the browser, so that the browser can obtain the grayscale resource from the second CDN node corresponding to the received second address, load and render the grayscale resource, and the R&D testers can verify the grayscale resource.

[0098] 3. After verification, the first address can be overwritten by the second address configured within the A product service, thereby completing the formal release of static resources.

[0099] Figure 5This is a structural block diagram of a product service iteration apparatus provided in an embodiment of the present invention. This apparatus is used to execute the product service iteration method provided in any of the above embodiments. This apparatus and the product service iteration methods of the above embodiments belong to the same inventive concept. Details not described in detail in the embodiments of the product service iteration apparatus can be found in the embodiments of the above product service iteration methods. See also... Figure 5 The device may specifically include: a product service determination module 410, a service cluster determination module 420, and a product service iteration module 430. Among them,

[0100] Product service determination module 410 is used to determine the product service to be called in response to a product service call request, wherein the product services are deployed on at least two server clusters respectively;

[0101] The service cluster determination module 420 is used to determine the service cluster from each server cluster based on the flow switching configuration of the product service, wherein the service cluster is used to provide product services.

[0102] Product service iteration module 430 is used to forward product service call requests to product services deployed on the service enhancement cluster, so as to realize the product service call process and the iteration process on the service shutdown cluster. The service shutdown cluster is a cluster other than the service enhancement cluster among at least two server clusters, and the service shutdown cluster stops providing product services.

[0103] Optionally, the product service determination module 410 may include:

[0104] The product service determination unit is used to obtain the service identifier of the product service to be called from the product service call request, and determine the product service based on the service identifier.

[0105] The aforementioned product service iteration device may further include:

[0106] The flow-cutting configuration acquisition module is used to obtain a pre-configured set of flow-cutting configurations and obtain the flow-cutting configuration from the set of flow-cutting configurations. The flow-cutting configuration represents the mapping relationship between the service identifier and the cluster identifier of the service cluster.

[0107] Optionally, the above-mentioned product service iteration device is configured in the gateway service, and the gateway service is deployed on each server cluster respectively;

[0108] The aforementioned product service iteration device may further include:

[0109] The service cluster acquisition module is used to select the server cluster where the gateway service that receives the product service call request is located as the service cluster if the traffic switching configuration is not obtained.

[0110] Optionally, the aforementioned product service iteration device may further include:

[0111] The flow switching configuration update module is used to periodically obtain the flow switching configuration and update the flow switching configuration stored in the cache based on the periodically obtained flow switching configuration;

[0112] The traffic switching configuration acquisition module is used to retrieve the traffic switching configuration from the cache after determining the product service to be called.

[0113] Optionally, the production resources of the product service are stored on the first content distribution network node, and the first address of the first content distribution network node is configured within the product service.

[0114] The aforementioned product service iteration device may further include:

[0115] The first address acquisition module is used to obtain the first address from the product service deployed on the service cluster after determining the service cluster from each server cluster.

[0116] The production resource rendering module is used to return the first address to the initiator of the product service call request, so that the initiator can obtain the production resource from the first content distribution network node corresponding to the received first address, and load and render the production resource.

[0117] Optionally, the gray resources of the product service can be stored on the second content distribution network node, and the second address of the second content distribution network node can be configured within the product service. The gray resources are the updated production resources.

[0118] The first address acquisition module may include:

[0119] The first address acquisition unit is used to obtain the first address from the product service deployed on the service cluster if the gray-scale resource request parameters are not obtained from the product service call request.

[0120] The aforementioned product service iteration device may further include:

[0121] The second address acquisition module is used to obtain the second address from the product service deployed on the service cluster after determining the service cluster from each server cluster and obtaining the gray-scale resource request parameters.

[0122] The grayscale resource rendering module is used to return the second address to the initiator, so that the initiator can obtain the grayscale resource from the second content distribution network node corresponding to the received second address, and load and render the grayscale resource.

[0123] Optionally, the aforementioned product service iteration device may further include:

[0124] The second address deletion module is used to respond to the address overwrite instruction, overwrite the first address based on the second address, and delete the second address.

[0125] The product service iteration apparatus provided in this embodiment of the invention, through a product service determination module, responds to a product service call request and determines the product service to be called. To ensure the high availability of the product service, it can be deployed on at least two server clusters. The service provision cluster determination module, based on the traffic switching configuration of the product service, determines the service provision cluster (i.e., responsible for the online traffic of the product service) from each server cluster. The product service iteration module forwards the product service call request to the product service deployed on the service provision cluster, thereby realizing the product service call process. Furthermore, since the offline clusters (excluding the service provision cluster) in at least two server clusters are no longer responsible for the online traffic of the product service, the iteration process of the product service on the offline cluster can be realized without the user's awareness. The above apparatus implements the product service iteration process through traffic switching operations at the product service level, thereby ensuring the efficiency and success rate of the iteration process.

[0126] The product service iteration apparatus provided in the embodiments of the present invention can execute the product service iteration method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0127] It is worth noting that in the embodiments of the above-mentioned product service iteration device, the various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy differentiation and are not used to limit the scope of protection of the present invention.

[0128] Figure 6 A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0129] like Figure 6As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded into the RAM 13 from storage unit 18. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0130] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0131] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as product service iteration methods.

[0132] In some embodiments, the product service iteration method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or mounted on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the product service iteration method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the product service iteration method by any other suitable means (e.g., by means of firmware).

[0133] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0134] Computer programs used to implement the methods of the present invention can be written in any combination of one or more programming languages. These computer programs can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer programs can be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0135] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0136] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0137] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0138] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0139] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0140] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A product service iteration method, characterized in that, Applied to gateway services, the method includes: In response to a product service invocation request, the product service to be invoked is determined, wherein the product service is deployed on at least two server clusters respectively; Based on the flow cutting configuration of the product service, a service provisioning cluster is determined from each of the server clusters, wherein the service provisioning cluster is used to provide the product service; The product service call request is forwarded to the product service deployed on the service enhancement cluster to realize the product service call process and the iteration process on the service shutdown cluster. The service shutdown cluster is a cluster other than the service enhancement cluster among the at least two server clusters, and the service shutdown cluster stops providing the product service. If the grayscale resource request parameters are not obtained from the product service call request, the first address is obtained from the product service deployed on the service cluster, and the first address is returned to the initiator of the product service call request, so that the initiator can obtain the production resource from the first content distribution network node corresponding to the received first address, load and render the production resource, and browse the production resource. The grayscale resource request parameters are used to request grayscale resources, and the grayscale resources are the updated production resources. If the grayscale resource request parameters are obtained, a second address is obtained from the product service deployed on the service cluster, and the second address is returned to the initiator, so that the initiator can obtain the grayscale resource from the second content distribution network node corresponding to the received second address, and load and render the grayscale resource to verify the grayscale resource. The first address and the second address are both maintained by the product service, and the first address and the second address are different addresses before the grayscale resource verification is passed.

2. The method according to claim 1, characterized in that, The determination of the product service to be invoked includes: Obtain the service identifier of the product service to be invoked from the product service invocation request, and determine the product service based on the service identifier; The method further includes: Obtain a pre-configured set of traffic switching configurations, and obtain the traffic switching configuration from the set of traffic switching configurations, wherein the traffic switching configuration represents the mapping relationship between the service identifier and the cluster identifier of the service cluster.

3. The method according to claim 1, characterized in that, This is applied to a gateway service, which is deployed in each of the server clusters. The method further includes: If the flow switching configuration is not obtained, the server cluster where the gateway service that received the product service call request is located will be used as the service cluster.

4. The method according to claim 1, characterized in that, Also includes: The flow-switching configuration is periodically retrieved, and the flow-switching configuration stored in the cache is updated according to the periodically retrieved flow-switching configuration; After determining the product service to be invoked, the method further includes: Retrieve the flow switching configuration from the cache.

5. The method according to claim 1, characterized in that, Also includes: In response to the address overwrite instruction, the first address is overwritten based on the second address, and the second address is deleted, thereby realizing the iterative process of the production resource.

6. A product service iteration device, characterized in that, Configured for gateway services, the device includes: The product service determination module is used to respond to product service call requests and determine the product service to be called, wherein the product services are deployed on at least two server clusters respectively; The service provision cluster determination module is used to determine the service provision cluster from each of the server clusters according to the flow cutting configuration of the product service, wherein the service provision cluster is used to provide the product service; The product service iteration module is used to forward the product service call request to the product service deployed on the service enhancement cluster, so as to realize the product service call process and the iteration process on the service shutdown cluster. The service shutdown cluster is a cluster other than the service enhancement cluster among the at least two server clusters, and the service shutdown cluster stops providing the product service. The first address acquisition module is used to obtain the first address from the product service deployed on the service cluster if the gray-scale resource request parameter is not obtained from the product service call request. The gray-scale resource request parameter is used to request gray-scale resources, and the gray-scale resources are updated production resources. The production resource rendering module is used to return the first address to the initiator of the product service call request, so that the initiator can obtain the production resource from the first content delivery network node corresponding to the received first address, and load and render the production resource to browse the production resource. The second address acquisition module is used to obtain a second address from the product service deployed on the service cluster if the grayscale resource request parameters are obtained. The grayscale resource rendering module is used to return the second address to the initiator, so that the initiator can obtain the grayscale resource from the second content distribution network node corresponding to the received second address, and load and render the grayscale resource to verify the grayscale resource. The first address and the second address are both maintained by the product service, and the first address and the second address are different addresses before the grayscale resource verification is passed.

7. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor to cause the at least one processor to perform the product service iteration method as described in any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute and implement the product service iteration method as described in any one of claims 1-5.

Images