Gray release method, device and equipment of software upgrade system and product

By constructing a user behavior data matrix and a microservice architecture, and selecting target users for personalized canary releases, the problem of poor user experience in traditional software release methods is solved, and precise push and improved stability are achieved.

CN119544495BActive Publication Date: 2025-11-04AGRICULTURAL BANK OF CHINA
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202411697079.8
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-11-25
Publication Date
2025-11-04
Estimated Expiration
2044-11-25

AI Technical Summary

Technical Problem

Traditional software release methods cannot achieve personalized canary releases, leading to system crashes, degraded user experience, or poor feedback. Existing technologies struggle to combine user profiles with canary release strategies.

Method used

By constructing a user behavior data matrix, target users are filtered based on user similarity. A microservice architecture is used for canary releases, dynamically adjusting the release schedule and scope of new features. Personalized recommendation technology is combined with user filtering and canary releases.

Benefits of technology

It enables precise push notifications to target software systems, improves the adoption rate of new features and user satisfaction, reduces system risks, and ensures system stability and user experience.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119544495B_ABST
    Figure CN119544495B_ABST
Patent Text Reader

Abstract

The embodiment of the present disclosure discloses a gray release method, device, equipment and product of a software upgrading system, comprising: constructing a first matrix and a second matrix according to user behavior data; the elements in the first matrix are used to represent the actual operation performed by each user on each function of the initial software system; determining a first target user based on the first matrix, and determining a second target user based on the second matrix and the first target user; determining a push parameter and an actual target user according to a target software system and an initial software system; the target software system is a system after the initial software system is upgraded; transmitting the access request of the actual target user to the target software system by using the micro-service architecture, so that the target software system completes the gray release. The technical scheme uses user behavior data to realize accurate push of the target software system, thereby improving the adoption rate of the target software system and providing better test effect.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] Embodiments of the present disclosure relate to the technical field of intelligent control, in particular to a gray release method, device, equipment and product of a software upgrade system. BACKGROUND

[0002] In today's rapidly developing digital era, continuous updating and iteration of software systems are crucial for maintaining competitiveness and meeting user needs. Traditional software release methods push new features to all users at once, which can cause system crashes or serious errors, making it difficult to discover and solve problems in a timely manner. Ordinary gray release methods lack consideration of user individual characteristics, and randomly selected users cannot cover the user group that is truly interested in new features, resulting in unsatisfactory push effects.

[0003] With the continuous development of Internet and big data technology, personalized recommendation technology has gradually become a popular research direction in various industries. Personalized recommendation technology analyzes user historical behavior data to build a personalized portrait of the user, thereby achieving accurate prediction of the user's personalized needs. Machine learning algorithms, as one of the core technologies for implementing personalized recommendations, have been widely used in various fields. Machine learning algorithms can learn from large amounts of data and generate models to predict or classify unknown data. In a personalized gray release system, machine learning algorithms can use user historical behavior data to build a personalized portrait of the user, predict and filter out users with high interest in new features, and provide support for gray release.

[0004] In today's digital age, continuous updating and iteration of software systems are key to maintaining competitiveness and meeting user needs. However, traditional software release methods typically push new features to all users at once or randomly select a portion of users for gray release. However, this approach has some problems, such as system crashes, decreased user experience, or poor user feedback after new feature release. Existing technologies can randomly select a certain number of users or simply filter out users for gray release based on activity levels, but they are difficult to combine user portraits with gray release strategies organically. Therefore, current technical solutions need to be improved in terms of personalized gray release. SUMMARY

[0005] Embodiments of the present disclosure provide a gray release method, device, equipment and product of a software upgrade system, which realizes accurate pushing of a target software system.

[0006] In a first aspect, a gray release method of a software upgrade system is provided, the method comprising:

[0007] constructing a first matrix and a second matrix according to user behavior data; elements in the first matrix are used to represent actual operations performed by each user for functions of each initial software system; elements in the second matrix are used to represent similarities between users;

[0008] determining a first target user based on the first matrix, and determining a second target user based on the second matrix and the first target user;

[0009] determining a push parameter and an actual target user according to a target software system and the initial software system; the actual target user belongs to the second target user; the target software system is a system after the initial software system is upgraded;

[0010] transmitting, by using a micro-service architecture, an access request of the actual target user to the target software system, so that the target software system completes gray release.

[0011] In a second aspect, a gray release device of a software upgrade system is provided, and the device comprises:

[0012] a matrix construction module configured to construct a first matrix and a second matrix according to user behavior data; elements in the first matrix are used to represent actual operations performed by each user for functions of each initial software system; elements in the second matrix are used to represent similarities between users;

[0013] a target user determination module configured to determine a first target user based on the first matrix, and determine a second target user based on the second matrix and the first target user;

[0014] an actual target user determination module configured to determine a push parameter and an actual target user according to a target software system and the initial software system; the actual target user belongs to the second target user; the target software system is a system after the initial software system is upgraded;

[0015] a release module configured to transmit, by using a micro-service architecture, an access request of the actual target user to the target software system, so that the target software system completes gray release.

[0016] In a third aspect, an electronic device is provided, and the device comprises:

[0017] at least one processor; and

[0018] a memory connected to the at least one processor in communication; wherein

[0019] The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to perform the gray release method of the software upgrade system according to the first aspect.

[0020] In a fourth aspect, a computer-readable storage medium is provided, and the computer-readable storage medium stores a computer program. The computer program is executed by a processor to implement the gray release method of the software upgrade system according to the first aspect.

[0021] In a fifth aspect, a computer program product is provided, and the computer program product includes a computer program. The computer program is executed by a processor to implement the gray release method of the software upgrade system according to the first aspect.

[0022] Embodiments of the present disclosure disclose a gray release method, device, equipment and product of a software upgrade system, including: constructing a first matrix and a second matrix according to user behavior data; an element in the first matrix is used to represent an actual operation performed by each user for a function of each initial software system; an element in the second matrix is used to represent a similarity between users; determining a first target user based on the first matrix, and determining a second target user based on the second matrix and the first target user; determining a push parameter and an actual target user according to a target software system and the initial software system; the actual target user belongs to the second target user; the target software system is a system after the initial software system is upgraded; transmitting an access request of the actual target user to the target software system by using a micro-service architecture, so that the target software system completes gray release. The technical solution utilizes user behavior data to realize accurate push of the target software system, thereby improving the adoption rate of the target software system, providing better test effect, and improving user satisfaction.

[0023] It should be understood that the content described in this part is not intended to identify key or important features of the embodiments of the present disclosure, nor is it used to limit the scope of the embodiments of the present disclosure. Other features of the embodiments of the present disclosure will become apparent from the following description. BRIEF DESCRIPTION OF DRAWINGS

[0024] In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure, the drawings needed in the embodiments will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present disclosure, and other drawings can be obtained by those skilled in the art without creative effort on the basis of these drawings.

[0025] Figure 1 is a flowchart of a gray release method of a software upgrade system provided by the first aspect of the present disclosure;

[0026] Figure 2 is an execution process schematic diagram of a gray release method of a software upgrade system provided by an embodiment of the present disclosure;

[0027] Figure 3 is a structural schematic diagram of a gray release device of a software upgrade system provided by an embodiment of the present disclosure;

[0028] Figure 4 is a structural schematic diagram of an electronic device provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0029] In order to enable persons skilled in the art to better understand the scheme of the embodiments of the present disclosure, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only part of the embodiments of the present disclosure, rather than all the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by persons skilled in the art without creative labor should fall within the scope of protection of the present disclosure.

[0030] It should be noted that the terms "first", "second" and the like in the specification and claims of the present disclosure and the above-described drawings are used to distinguish similar objects, and do not necessarily indicate a specific order or a chronological sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the present disclosure described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units does not have to be limited to those steps or units clearly listed, but can include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0031] Embodiment one

[0032] Figure 1 A flowchart of a gray release method of a software upgrade system provided by an embodiment of the present disclosure, the embodiment can be applicable to the case of gray release of the software upgrade system, the method can be executed by a gray release device of the software upgrade system, the gray release device of the software upgrade system can be realized in the form of hardware and / or software, and the gray release device of the software upgrade system can be configured in an electronic device, which includes but is not limited to a computer, a computer, a terminal and a server, and other devices with data processing capability. As shown in the figure, the method comprises: Figure 1

[0033] ​S110, constructing a first matrix and a second matrix according to the user behavior data; elements in the first matrix are used to represent actual operations performed by each user for each function of each initial software system; elements in the second matrix are used to represent similarities between users.

[0034] In this embodiment, the user behavior data can be behavior data generated by the user history. For example, the user behavior data can include the user's click record, the user's browsing history, the user's download behavior, and the user's collection behavior.

[0035] Specifically, the first matrix and the second matrix can be constructed according to the user behavior data. The elements in the first matrix are used to represent the actual operations performed by each user for each function of each initial software system. The first matrix can be a user-function matrix, the rows can represent users, the columns can represent functions, and the elements can represent the user's behavior (such as clicking, downloading, browsing, etc.) on the corresponding function. For example, the user behavior data can be converted into feature representations such as click frequency, number of pages browsed, etc. A collaborative filtering algorithm is used to construct a user-function matrix according to the user behavior data. The collaborative filtering algorithm can be a technology used in recommendation systems, which is based on historical interaction information between users and items (such as products, articles, music, etc.) to predict the degree of user preference for items that have not been interacted with. This algorithm does not rely on the content description or attributes of the items, but mainly calculates based on the user's behavior patterns and other users' behavior patterns. The similarity between users is a key factor in the collaborative filtering algorithm, as it directly affects the performance of the recommendation system. By finding users with high similarity, the system can more accurately predict new functions that the target user may like.

[0036] Based on the above description, after the first matrix is determined, the similarity between each user (each pair of users) can be calculated based on each user in the first matrix, and a second matrix can be obtained, the elements in the second matrix are used to represent the similarity between users. The similarity between users can be calculated by cosine similarity, Pearson correlation coefficient, and / or Euclidean distance, etc.

[0037] S120, determining a first target user based on the first matrix, and determining a second target user based on the second matrix and the first target user.

[0038] Specifically, after the first matrix is determined, the first target user can be determined based on the first matrix. The first target user can be a user who intends to use the target software system. For example, the target software system upgrades the download function, and the user who uses the download function multiple times can be determined as the first target user based on the elements in the first matrix.

[0039] According to the above description, after the first target user is determined, the second target user can be determined based on the second matrix and the first target user. The second target user can be a user in the second matrix whose similarity with the first target user is higher than a preset threshold. The preset threshold can be a pre-set similarity threshold.

[0040] In S130, the push parameters and the actual target users are determined according to the target software system and the initial software system. The actual target users belong to the second target users. The target software system is a system upgraded from the initial software system.

[0041] In this embodiment, after the second target user is determined, the push parameters and the actual target users can be determined according to the business requirements of the target software system and the actual situation of the initial software system. The target software system is a system upgraded from the initial software system. The business requirements can include target requirements and rules that must be followed. For example, the business requirements can include product targets, user requirements, market trends, competitive analysis, income targets, user experience, regulatory compliance, brand strategy, key performance indicators, product iteration speed, etc.

[0042] According to the above description, the actual situation can be technical conditions and result feedback when the initial software system is executed. For example, the actual situation can include technical capabilities, resource limitations, infrastructure, system stability, security, maintenance costs, historical data, user feedback, test results, risk assessment, urgency, team collaboration, project management, etc.

[0043] According to the foregoing description, the push parameter can be a parameter when the access request of the user is pushed to the target software system. For example, the push parameter can include a time node for pushing a new function according to business needs and a proportion of pushing. The actual target user can be an actual user to whom the access request is pushed. The actual target user can be adjusted according to business needs and actual conditions.

[0044] In S140, the access request of the actual target user is transmitted to the target software system by using the microservice architecture, so that the target software system completes the gray release.

[0045] Specifically, after the actual target user is determined, the access request of the actual target user is transmitted to the target software system by using the microservice architecture, so that the target software system completes the gray release. The gray release can also be referred to as canary release, which refers to a release mode for smooth transition between black and white. A part of users continue to use product feature A, and a part of users start to use product feature B. If the user experience of B is good, the use range of B is gradually expanded until all users migrate to B.

[0046] According to the foregoing description, the microservice architecture (Microservices Architecture) can be a software development architecture that builds an application as a collection of small services, each running in its own process and usually built around specific business capabilities.

[0047] The embodiment provides a gray release method of a software upgrade system, including: constructing a first matrix and a second matrix according to user behavior data; elements in the first matrix are used to represent actual operations performed by each user on each function of an initial software system; elements in the second matrix are used to represent similarities between users; determining a first target user based on the first matrix, and determining a second target user based on the second matrix and the first target user; determining a push parameter and an actual target user according to a target software system and the initial software system; the actual target user belongs to the second target user; the target software system is a system after the initial software system is upgraded; transmitting an access request of the actual target user to the target software system by using a microservice architecture, so that the target software system completes the gray release. According to the actual target user screening result, the release progress and range of the new function are dynamically adjusted, the system risk is reduced, the system stability is ensured, and the user experience and satisfaction are improved.

[0048] As an optional implementation manner of the embodiment, the gray release method of the software upgrade system provided by the embodiment further includes, before the first matrix and the second matrix are constructed according to the user behavior data:

[0049] 1) obtaining initial user behavior data; the initial user behavior data includes actual operations performed by the user on different functions of the software system;

[0050] Specifically, the initial user behavior data, which includes actual operations performed by the user on different functions of the software system, can be obtained using front-end burying point technology and log recording. For example, the initial user behavior data includes actual operations performed by the user on the attachment function of the mailbox of the software system, such as downloading attachments or online previewing attachments.

[0051] For example, a suitable burying point tool or technology can be selected according to the requirements and application scenarios, and the code can be embedded in the application program to track the user behavior and send the initial user behavior data to the back-end server. The burying point scheme is designed to determine the events, pages and attributes that need to be buried. Finally, the burying point code is inserted into the key pages, functions or events of the application program to record the initial user behavior data.

[0052] 2) data cleaning and / or data conversion are performed on the initial user behavior data to determine the user behavior data.

[0053] Specifically, after obtaining the initial user behavior data, data cleaning and / or data conversion can be performed on the initial user behavior data to determine the user behavior data. Data cleaning can refer to the process of identifying, correcting or deleting errors and inconsistencies in the data, which can improve the quality of the data and ensure the accuracy and reliability of the data. For example, data cleaning can include removing duplicate records, handling missing values, handling abnormal values, etc.

[0054] As described above, after data cleaning, the cleaned data can be converted. Data conversion can refer to the process of converting raw data into a more suitable form for analysis, which can make the data more suitable for subsequent analysis and modeling. For example, data conversion can include converting timestamps to date format, encoding text data, etc. Finally, data from different data sources is integrated for subsequent analysis and mining.

[0055] As an optional implementation of the present embodiment, the software upgrade system provided by the present embodiment further comprises:

[0056] 1) monitoring the actual target user corresponding to the to-be-transmitted access request to obtain monitoring information.

[0057] It can be known that the actual target user corresponding to the to-be-accessed request can also be monitored to obtain monitoring information, wherein the monitoring information can be the use of the target software system by the actual target user.

[0058] 2) determining whether the target software system is stable based on the monitoring information and preset stable conditions.

[0059] In this embodiment, the preset stable conditions can be used to determine conditions under which the target software system is stably used by the target users, for example, the preset stable conditions can be that the actual target users use the target software system without problems such as system lag and crash. Specifically, whether the target software system is stable can be determined based on the monitoring information and the preset stable conditions.

[0060] 3) if the target software system is unstable, the routing and forwarding rules and the gray marking information are modified, so that the actual target users access the initial software system according to the modified routing and forwarding rules and gray marking information.

[0061] According to the above description, if the target software system is unstable, the routing and forwarding rules and the gray marking information are modified, so that the actual target users access the initial software system according to the modified routing and forwarding rules and gray marking information. For example,

[0062] For example, the use of the target software system by the actual target users is monitored in real time, and once serious problems occur in the use of the actual target users, the gray release strategy is stopped or the gray release marking is revoked to immediately stop the continuous release of the new version, ensure that user requests are no longer forwarded to the new version, and the routing and forwarding rules are switched in the gateway layer or the load balancer to re-route the traffic to the original initial software system.

[0063] As an optional implementation of this embodiment, the gray release method of the software upgrade system provided by this embodiment further includes:

[0064] If the configuration of the target software system is different from the configuration of the initial software system, the configuration of the target software system is updated to the initial configuration.

[0065] Specifically, if the configuration of the target software system is modified in the configuration center, it needs to be restored to the original configuration in time to ensure that the system uses the configuration information of the original initial software system;

[0066] As an optional implementation of this embodiment, the gray release method of the software upgrade system provided by this embodiment further includes:

[0067] If the database of the target software system is different from the database of the initial software system, the database of the target software system is data-rolled back; the database is a database that interacts with the target software system.

[0068] Specifically, if the target software system has modified the database, the changes need to be rolled back in time to restore the database to the same state as the database of the initial software system.

[0069] It should be noted that, in order to prevent the error state of the target software system from affecting the normal operation of the overall system, the state information that the target software system may cause, such as cache data and temporary files, should be cleaned up; during the rollback process, the state and performance indicators of the overall system need to be monitored in time, and if abnormal conditions occur, relevant personnel need to be notified in time and measures need to be taken to handle them; after confirming that the problem has been solved and the system has returned to a normal state, the release can be performed again, at which time the target software system can be further tested and verified to ensure that the target software system can operate stably after being released again.

[0070] The technical solution adds a personalized recommendation technology based on the traditional gray release, screens users who flexibly adjust the test new functions according to the personalized characteristics of the users, and pushes the new software functions or new software to the part of the users in the form of gray release, improves the adoption rate and usage rate of the new functions or new software of the target software system by the users, and takes emergency plans when problems occur, rolls back the release version, solves the problems of the new functions, and releases again after the problems are solved, which can not only improve the work efficiency of the new function test, but also maximize the user experience.

[0071] As an optional implementation manner of the embodiment, the transmitting the access request of the actual target user to the target software system by using the micro-service architecture comprises:

[0072] 1) determining a to-be-transmitted access request based on the business rules of the target software system by using a global filter of the gateway layer; the to-be-transmitted access request is a request that needs to be transmitted to the target software system in the access request of the actual target user.

[0073] It can be known that the microservice architecture can include a service registry, a gateway layer and downstream microservices. In the microservice architecture, the service registry is used for service discovery. Each microservice registers its own information (such as service address, port, etc.) with the registry when it starts, and unregisters when it stops; the gateway layer is used to handle request routing, load balancing, authentication, authorization, throttling, monitoring, logging, etc., to simplify the interaction between the client and the backend service, provide unified Application Programming Interface (API) management, and protect the backend service from being directly exposed to the client; in the microservice architecture, downstream microservices refer to those services that are called by other services. They are small, independent business units that make up the entire application. Downstream microservices can discover each other through the service registry and communicate through defined APIs.

[0074] Specifically, in actual production, new functions are not directly updated to online services, but a part of online traffic is cut out for function testing, and after testing, it can be fully put online. The global filter of the gateway layer can be used to determine the to-be-transmitted access request based on the business rules of the target software system; wherein the to-be-transmitted access request is the request in the actual target user's access request that needs to be transmitted to the target software system.

[0075] It should be noted that the business rules of the target software system can be a series of standards or conditions formulated according to specific business logic and requirements, used to guide decision-making and operations. In the scenario of gray release, the business rules can include but are not limited to: user grouping: grouping users into different groups according to their behavior, geographic location, device type, etc.; function switch: setting a switch for new functions to control which users can see or use new functions; traffic allocation: determining the allocation ratio of traffic between new and old version services; performance indicators: dynamically adjusting traffic allocation based on performance monitoring data (such as response time, error rate); user feedback: adjusting the scope and speed of gray release according to user feedback; version compatibility: ensuring compatibility between new and old versions to avoid data inconsistency or function conflicts; security and compliance: ensuring that the new version meets security and compliance requirements; business goals: rules related to business goals and KPIs (Key Performance Indicators), such as improving conversion rates or reducing user churn; fault recovery: rules for automatically rolling back to the old version when problems are detected.

[0076] 2) determining the gray marking information of the to-be-transmitted access request using the gateway layer, and adding the gray marking information to the request header; the gray marking information is used to indicate whether the to-be-transmitted access request belongs to the gray release range of the to-be-pushed software system;

[0077] Specifically, after the to-be-transmitted access request is determined, the gateway layer can be used to determine the gray marking information of the to-be-transmitted access request. The gray marking information can be used to indicate whether the to-be-transmitted access request belongs to the gray release range of the to-be-pushed software system. The gray marking information can include the version number of the software system (which can be specified according to the user's needs), the user identification (ID), and the user Internet Protocol (IP) address. It should be noted that the version number in the gray marking information of the to-be-transmitted access request can be the version number of the target software system, and the version number in the gray marking information of the non-to-be-transmitted access request can be the version number of the initial software system.

[0078] It can be known that after the gray marking information is determined, the gray marking information can be added to the request header,

[0079] 3) The downstream microservice acquires the request header and adjusts the load balancing rule according to the request header. The load balancing rule includes each to-be-transmitted access request and the server of the target software system corresponding thereto.

[0080] Specifically, the request header of the gateway layer can be passed to the downstream microservice through an HTTP request. The downstream microservice can acquire the request header and adjust the load balancing rule according to the request header. The load balancing rule includes each to-be-transmitted access request and the server of the target software system corresponding thereto. In the microservice architecture, load balancing refers to the process of distributing requests to multiple service instances to avoid overloading a single instance, thereby improving the availability and performance of the system. For example, the load balancing rule can be a Ribbon load balancing strategy. In the Ribbon load balancing strategy, modification is needed to support the acquisition of gray services from the registration center according to the traffic marking. This can be achieved by customizing the load balancing rule or using an interceptor. The modified load balancing strategy needs to be able to select the server of the corresponding version from the service registration center for load balancing according to the gray marking information in the request header.

[0081] 4) Based on the load balancing rule, the server of the target software system corresponding to the to-be-transmitted access request is selected from the service registration center;

[0082] It can be known that after the load balancing rule is determined, the server of the target software system corresponding to the to-be-transmitted access request can be selected from the service registration center based on the load balancing rule.

[0083] 5) Each to-be-transmitted access request is transmitted to the server of the target software system corresponding thereto by using the routing and forwarding rule of the gateway layer.

[0084] Specifically, after the server of the target software system corresponding to the to-be-transmitted access request is determined, the to-be-transmitted access request can be transmitted to the server of the target software system corresponding to the to-be-transmitted access request by using the routing forwarding rule of the gateway layer.

[0085] Figure 2 An execution process schematic diagram of a gray release method of a software upgrading system provided by the embodiment is shown in Figure 2 The technical solution as a whole can be divided into four steps of user data collection, user data processing, target user screening, and individualized gray release. The user behavior data can be collected by inserting the front segment into the buried point code, and the collected user behavior data can be subjected to data cleaning and data conversion. The user-function matrix (first matrix) is constructed by means of data integration, and then the user similarity matrix (second matrix) is calculated, and the target user (first target user) is constructed based on the user-function matrix, and the neighbor user (second target user) is screened out by means of the second matrix. First, the scheme of gray release should be determined. For the push user group, the above-mentioned screened user group can be adjusted according to the business demand and the actual situation, such as the time node of pushing the new function required by the business, and the proportion of pushing. The technical solution adopts a full-link gray release implementation method: the service registration center and the service registration discovery component ensure the automatic registration and discovery of the micro service, so that the micro services can discover and establish communication with each other; in the global filter of the gateway layer, the to-be-transmitted access request can be judged according to the business rule and the above-mentioned screened user, to decide whether the gray release is needed. If the gray release is needed, the gray mark can be added to the request header, and the gray mark can be a version number (specified according to the demand, for user differentiation), user ID, IP address, etc. information, for identifying whether the request belongs to the gray release range; the gray mark added by the gateway is put into the request header, and is delivered to the downstream micro service through the HTTP request. The HTTP request is a way for the client (such as a browser) to request data from the server. In this way, the downstream service can obtain the gray mark information of the request; in the Ribbon load balancing strategy, the modification is needed to support the gray service from the registration center according to the traffic mark. The modified load balancing strategy needs to be able to select the corresponding version of the micro service instance from the service registration center according to the gray mark information in the request header for load balancing; the routing rule is configured in the gateway, and the received request is forwarded to the corresponding gray service instance according to the gray mark information. In the routing forwarding process, the gateway selects the instance of the target micro service to forward the request according to the gray mark information in the request header, so as to realize the access to the gray service.

[0086] Through the above method, the release progress and range of the new function are dynamically adjusted according to the actual target user screening result, full-link gray release is realized, the range of gray release can be effectively controlled, the new function or version is effectively pushed to the user who has more willingness to test the new function in the production environment, not only the new function can be more efficiently tested, but also the influence on the system is reduced, the system stability is ensured, and the user experience and satisfaction are improved.

[0087] Embodiment Two

[0088] Figure 3 is a structural schematic diagram of a gray release device of a software upgrade system provided by Embodiment Two of the present disclosure; as shown in the figure, the device comprises a matrix construction module 210, a target user determination module 220, an actual target user determination module 230, and a release module 240. Figure 3

[0089] The matrix construction module 210 is configured to construct a first matrix and a second matrix according to user behavior data; the elements in the first matrix are used to represent the actual operations performed by each user on each function of the initial software system; and the elements in the second matrix are used to represent the similarity between users.

[0090] The target user determination module 220 is configured to determine a first target user based on the first matrix, and determine a second target user based on the second matrix and the first target user.

[0091] The actual target user determination module 230 is configured to determine a push parameter and an actual target user according to a target software system and the initial software system; the actual target user belongs to the second target user; and the target software system is a system after the initial software system is upgraded.

[0092] The release module 240 is configured to transmit an access request of the actual target user to the target software system by using a micro-service architecture, so that the target software system completes gray release.

[0093] Embodiment Two of the present disclosure provides a gray release device of a software upgrade system, which realizes dynamic adjustment of the release progress and range of a new function according to an actual target user screening result, reduces system risk, ensures system stability, and improves user experience and satisfaction.

[0094] Further, the device further comprises:

[0095] A data acquisition module is configured to acquire initial user behavior data; the initial user behavior data comprises actual operations performed by a user on different functions of the software system.

[0096] ​a data conversion module, configured to perform data cleaning and / or data conversion on the initial user behavior data to determine the user behavior data.

[0097] Further, the micro-service architecture comprises a service registry, a gateway layer and downstream micro-services.

[0098] The publishing module 240 is further configured to:

[0099] determine, by using a global filter of the gateway layer, a to-be-transmitted access request based on a business rule of the target software system; the to-be-transmitted access request is a request in the actual target user's access request that needs to be transmitted to the target software system;

[0100] determine, by using the gateway layer, gray label information of the to-be-transmitted access request, and add the gray label information to a request header; the gray label information is used to indicate whether the to-be-transmitted access request belongs to a gray publishing range of the to-be-pushed software system;

[0101] obtain, by using the downstream micro-services, the request header, and adjust a load balancing rule according to the request header; the load balancing rule comprises each to-be-transmitted access request and a server of the target software system corresponding to the to-be-transmitted access request;

[0102] select, based on the load balancing rule, a server of the target software system corresponding to the to-be-transmitted access request from the service registry;

[0103] transmit, by using a routing forwarding rule of the gateway layer, each to-be-transmitted access request to the server of the target software system corresponding to the to-be-transmitted access request.

[0104] Further, the apparatus further comprises:

[0105] a monitoring module, configured to monitor the actual target user corresponding to the to-be-transmitted access request to obtain monitoring information;

[0106] a determination module, configured to determine, based on the monitoring information and a preset stable condition, whether the target software system is stable;

[0107] a modification module, configured to, if the target software system is not stable, modify the routing forwarding rule and the gray label information, so that the actual target user accesses the initial software system according to the modified routing forwarding rule and gray label information.

[0108] Further, the apparatus further comprises:

[0109] The configuration updating module is configured to update the configuration of the target software system to the initial configuration if the configuration of the target software system is different from the configuration of the initial software system.

[0110] Further, the apparatus further comprises:

[0111] The rollback module is configured to perform data rollback on the database of the target software system if the database of the target software system is different from the database of the initial software system; the database is a database that interacts with the target software system.

[0112] The software upgrade system gray release apparatus provided by the embodiments of the present disclosure can perform the software upgrade system gray release method provided by any of the embodiments of the present disclosure, and has the corresponding function modules and beneficial effects of the execution method.

[0113] Embodiment three

[0114] Figure 4 A structural schematic diagram of an electronic device 10 that can be used to implement the embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptops, desktops, tablets, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The components shown here, their connections and relationships, and their functions, are meant to be examples only, and are not intended to limit implementations of the embodiments of the present disclosure described and / or claimed in this document.

[0115] As shown in Figure 4 The electronic device 10 includes at least one processor 11, and a memory, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., which is communicatively connected to the at least one processor 11, wherein the memory stores a computer program that can be executed by the at least one processor, and the processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 into the random access memory (RAM) 13. In the RAM 13, various programs and data required for the operation of the electronic device 10 can also be stored. The processor 11, the ROM 12, and the RAM 13 are connected to each other through a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

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

[0117] The processor 11 can be various general and / or special purpose processing components with processing and computing capabilities. Some examples of the 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 appropriate processor, controller, microprocessor, etc. The processor 11 performs various methods and processes described above, such as the gray release method of the software upgrade system.

[0118] In some embodiments, the gray release method of the software upgrade system can be implemented as a computer program tangibly embodied in a computer readable storage medium, such as the storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed onto the electronic device 10 via the ROM 12 and / or the communication unit 19. When the computer program is loaded onto the RAM 13 and executed by the processor 11, one or more steps of the gray release method of the software upgrade system described above can be performed. Alternatively, in other embodiments, the processor 11 can be configured to perform the gray release method of the software upgrade system by any other appropriate means, such as by means of firmware.

[0119] Various implementations of the systems and techniques described above can be realized in digital electronic circuitry, integrated circuitry, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on a chip (SOC), a programmable logic device (CPLD), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and / or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

[0120] Computer programs for implementing the methods of embodiments of the disclosure 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, special purpose computer, or other programmable data processing apparatus, such that the computer programs, when executed by the processor, cause the functions / acts specified in the flow diagrams and / or block diagrams to be implemented. The computer programs can be implemented in a global computer system, a distributed computer system, or across multiple computer systems. Computer programs can be implemented in a machine language, which includes instructions that implement the functions / acts specified in the flow diagrams and / or block diagrams, and in via high level languages that are compiled, interpreted, or moni- tored for machine code, a base, a macro-assembler or a markup language in a completely analogous fashion. The software programs can be stored on one or more computer usable storage media, such as with a memory device.

[0121] In the context of the present embodiments, a computer-readable storage medium can be a tangible medium that can contain or store computer programs for use by or in connection with an instruction execution system, apparatus, or device. The computer-readable storage medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. Alternatively, the computer-readable storage medium can be a machine-readable signal medium. More specific examples of the computer-readable storage medium will include one or more lines of a program of instructions in a transitory signal, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0122] To provide for interaction with a user, the systems and techniques described here 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 a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the electronic device. Other kinds of devices can be used to provide for interaction with a user as well; 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 acoustic, speech, or tactile input.

[0123] The systems and techniques described herein can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a user computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described herein), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), blockchain network, and the Internet.

[0124] The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. A server can be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system, to solve the defects of large management difficulty and weak business scalability in traditional physical host and VPS service.

[0125] It should be understood that the various forms of flow shown above can be reordered, added to, or deleted from without departing from the scope of the present disclosure. For example, the steps described in the embodiments of the present disclosure can be executed in parallel, in sequence, or in a different order, as long as the desired results of the technical solutions of the embodiments of the present disclosure can be achieved, and the present disclosure is not limited herein.

[0126] The specific embodiments described above do not constitute an limitation on the protection scope of the embodiments of the present disclosure. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent replacements, and improvements made within the spirit and principles of the embodiments of the present disclosure shall be included in the protection scope of the embodiments of the present disclosure.

[0127] The embodiments of the present disclosure also provide a computer program product, including a computer program and / or instructions, which, when executed by a processor, implement the gray release method of the software upgrade system as provided by any of the embodiments of the present disclosure.

[0128] The computer program product can be implemented in one or more computer programs executing on one or more programmable computers containing computer usable program code. A computer program, in the form of computer readable program code, can be written in any form of programming language, including compiled or interpreted languages, and executed in a single or distributed computer system. The computer readable program code can be stored in any type of computer readable medium, or media, suitable for the use in computing. Many of the components of the computer system can be used in more than one of the computer programs.

[0129] It should be noted that the above only describes preferred embodiments of the present disclosure and the applied technical principles. Those skilled in the art can understand that the present disclosure is not limited to the specific embodiments herein, and various obvious changes, readjustments and substitutions can be made without departing from the protection scope of the present disclosure. Therefore, although the present disclosure has been described in detail through the above embodiments, the present disclosure is not limited to the above embodiments, and can include more other equivalent embodiments without departing from the concept of the present disclosure, and the scope of the present disclosure is determined by the scope of the appended claims.

Claims

1. A method for gray release of a software upgrade system, characterized in that, The method comprises: constructing a first matrix and a second matrix according to user behavior data; elements in the first matrix are used to represent actual operations performed by each user for each function of an initial software system; elements in the second matrix are used to represent similarities between users; determining a first target user based on the first matrix, and determining a second target user based on the second matrix and the first target user; determining a push parameter and an actual target user according to a target software system and the initial software system; the actual target user belongs to the second target user; the target software system is a system upgraded from the initial software system; transmitting, by using a micro-service architecture, an access request of the actual target user to the target software system, so that the target software system completes gray release; the micro-service architecture comprises a service registry center, a gateway layer and a downstream micro-service; the transmitting, by using the micro-service architecture, the access request of the actual target user to the target software system comprises: determining, by using a global filter of the gateway layer, a to-be-transmitted access request based on a business rule of the target software system; the to-be-transmitted access request is a request in the access request of the actual target user that needs to be transmitted to the target software system; determining, by using the gateway layer, gray marking information of the to-be-transmitted access request, and adding the gray marking information to a request header; the gray marking information is used to indicate whether the to-be-transmitted access request belongs to a gray release range of a to-be-pushed software system; acquiring, by using the downstream micro-service, the request header, and adjusting a load balancing rule according to the request header; the load balancing rule comprises each to-be-transmitted access request and a server of the target software system corresponding to the to-be-transmitted access request; selecting, based on the load balancing rule, a server of the target software system corresponding to the to-be-transmitted access request from the service registry center; transmitting, by using a routing forwarding rule of the gateway layer, each to-be-transmitted access request to the server of the target software system corresponding to the to-be-transmitted access request.

2. The method of claim 1, wherein, Before the constructing a first matrix and a second matrix according to user behavior data, the method further comprises: acquiring initial user behavior data; the initial user behavior data comprises actual operations performed by a user for different functions of the software system; performing data cleaning and / or data conversion on the initial user behavior data to determine the user behavior data.

3. The method of claim 1, wherein, The method further comprises: monitoring the actual target user corresponding to the to-be-transmitted access request to acquire monitoring information; determining whether the target software system is stable based on the monitoring information and a preset stable condition; if the target software system is unstable, modifying the routing forwarding rule and the gray marking information, so that the actual target user accesses the initial software system according to the modified routing forwarding rule and gray marking information.

4. The method of claim 3, wherein, The method further comprises: if a configuration of the target software system is different from a configuration of the initial software system, updating the configuration of the target software system to the configuration of the initial software system.

5. The method of claim 3, wherein, The method further comprises: If a database of the target software system is different from a database of the initial software system, data of the database of the target software system is rolled back; the database is a database interacting with the target software system. 6.A gray release device of a software upgrade system, characterized in that, The method comprises the steps of: a matrix construction module is configured to construct a first matrix and a second matrix according to user behavior data; elements in the first matrix are used to represent actual operations performed by each user for each function of the initial software system; elements in the second matrix are used to represent similarities between users; a target user determination module is configured to determine a first target user based on the first matrix and a second target user based on the second matrix and the first target user; an actual target user determination module is configured to determine a push parameter and an actual target user according to the target software system and the initial software system; the actual target user belongs to the second target user; the target software system is an upgraded system of the initial software system; a publishing module is configured to transmit an access request of the actual target user to the target software system by using a micro-service architecture, so that the target software system completes a gray release; the micro-service architecture comprises a service registry center, a gateway layer, and a downstream micro-service; the publishing module is further configured to: determine a to-be-transmitted access request based on business rules of the target software system by using a global filter of the gateway layer; the to-be-transmitted access request is a request in the access request of the actual target user that needs to be transmitted to the target software system; determine gray marking information of the to-be-transmitted access request by using the gateway layer, and add the gray marking information to a request header; the gray marking information is used to indicate whether the to-be-transmitted access request belongs to a gray release range of a to-be-pushed software system; obtain the request header by using the downstream micro-service, and adjust a load balancing rule according to the request header; the load balancing rule comprises each to-be-transmitted access request and a server of the target software system corresponding to the to-be-transmitted access request; select a server of the target software system corresponding to the to-be-transmitted access request from the service registry center based on the load balancing rule; transmit each to-be-transmitted access request to the server of the target software system corresponding to the to-be-transmitted access request by using a routing forwarding rule of the gateway layer.

7. An electronic device, comprising: The method comprises the steps of: at least one processor; and a memory connected in communication with the at least one processor; wherein the memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute the gray release method of the software upgrade system according to any one of claims 1-5.

8. A computer readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the gray release method of the software upgrade system according to any one of claims 1-5.

9. A computer program product, characterised in that, The computer program product comprises a computer program that, when executed by a processor, implements the gray release method of the software upgrade system according to any one of claims 1-5.

Citation Information

Patent Citations

  • Software service gray release method and device, equipment and medium

    CN116775107A

  • Gray scale test processing method

    CN118227501A