System update methods, devices, electronic equipment, storage media, and program products

Abstract

This invention discloses a system update method, apparatus, electronic device, storage medium, and program product. It establishes a baseline swimlane and a grayscale swimlane in a production environment, deploys the initial system on the baseline swimlane, and deploys the target system on the grayscale swimlane. Based on preset grayscale allocation rules, it determines the target swimlane corresponding to the business request traffic of the target user and allocates the business request traffic to the target swimlane. Based on monitored events indicating changes in the binding relationship between the target user and associated entities, it updates the grayscale allocation rules. It then reallocates the business request traffic according to the updated grayscale allocation rules and verifies the target system in the grayscale swimlane. After successful verification, the service components belonging to the target system deployed in the grayscale swimlane are merged and deployed to the baseline swimlane. This solves the problem of incomplete traffic distribution during system architecture upgrades in related technologies, leading to user and associated entity synchronization issues, operational failures, and resource consumption.

Description

Technical Field

[0001] This invention relates to the field of system architecture upgrade technology, specifically to system update methods, devices, electronic devices, storage media, and program products. Background Technology

[0002] During system architecture updates, to ensure a stable launch of the new system, traditional solutions typically deploy the new system in a separate, gray-scale testing environment and conduct tests using virtual users to simulate requests. Only after passing these tests is the new system deployed to the actual production environment. However, this testing environment often fails to fully simulate the real production environment, resulting in inaccurate reflection of real user interactions and system load during testing, leading to low test accuracy. After launch, issues such as system lag, service congestion, or partial functional abnormalities are likely to occur, ultimately impacting user experience.

[0003] To improve the realism of the test, the proposed improvement involves running the original and upgraded systems in parallel in a production environment, while simultaneously importing a portion of real user traffic into the new system for verification according to rules. However, this approach suffers from incomplete traffic diversion. For example, when a target user and their associated vehicle are diverted to the new system, the user's authorized mobile terminal may still remain in the original system, causing the terminal to be unable to accurately operate the vehicle or receive a response. Furthermore, during system operation, if a user authorizes another mobile device, that device may be in a different system swimlane than the target vehicle, resulting in control failure. Similarly, after a user unbinds their device, the traffic information in the grayscale swimlane and the baseline swimlane is not updated in a timely manner, causing residual devices to still occupy system resources. Summary of the Invention

[0004] This invention provides a system update method, apparatus, electronic device, storage medium, and program product to solve the problem of incomplete traffic distribution during system architecture upgrades in related technologies, which leads to the failure of users, vehicles, and mobile terminals to synchronize across different systems, resulting in operational failures and resource consumption.

[0005] In a first aspect, the present invention provides a system update method, the method comprising: Establish a baseline swimlane and a grayscale swimlane in the production operation environment. Based on the current upgrade scenario, deploy the initial system on the baseline swimlane and the target system on the grayscale swimlane. According to the preset grayscale allocation rules, the target swimlane corresponding to the business request traffic of the target user is determined, and the business request traffic of the target user is allocated to the target swimlane; wherein, the target user is the user group associated with each target vehicle; When testing based on the allocated business request traffic, listen for binding relationship change events between the target user and the associated entity, and update the canary allocation rules based on the listened binding relationship change events; The service request traffic is reallocated according to the updated grayscale allocation rules, and the target system is verified in the grayscale swimlane; After successful verification, the service components belonging to the target system deployed in the grayscale swimlane are merged and deployed to the baseline swimlane to complete the update of the initial system.

[0006] This embodiment establishes a baseline swimlane and a grayscale swimlane in the production environment. The initial system is deployed on the baseline swimlane, and the target system is deployed on the grayscale swimlane. Based on preset grayscale allocation rules, the target swimlane corresponding to the business request traffic of the target user is determined, and the business request traffic of the target user is allocated to the target swimlane. The target user is the user group associated with each target vehicle. Events indicating changes in the binding relationship between the target user and its associated entities are monitored, and the grayscale allocation rules are updated based on these events. Business request traffic is redistributed according to the updated grayscale allocation rules, and the target system is verified in the grayscale swimlane. After successful verification, the service components belonging to the target system deployed in the grayscale swimlane are merged and deployed to the baseline swimlane. This solves the problem of incomplete traffic distribution during system architecture upgrades in related technologies, which leads to a lack of synchronization between users and associated entities, causing operational failures and resource consumption.

[0007] In one optional implementation, determining the target swimlane corresponding to the target user's service request traffic according to a preset grayscale allocation rule, and allocating the target user's service request traffic to the target swimlane, includes: For each target vehicle, identify all target users associated with the target vehicle and all associated entities corresponding to the target users, the associated entities including associated vehicles and associated devices; The swimlane to which the target vehicle is assigned is determined as the target swimlane, and the service request traffic of all target users and all associated entities corresponding to the target users is allocated to the target swimlane.

[0008] In this embodiment, when a target vehicle is marked into a grayscale swimlane according to a preset grayscale allocation rule, not only will the requests of the target user bound to it be automatically routed to the grayscale environment, but other vehicles associated with the target user and their related users will also be colored synchronously, thereby ensuring the consistency of business data and status in multi-vehicle and multi-user scenarios and avoiding logical errors or inconsistent experiences caused by some links in the same business chain being in different environments.

[0009] In one optional implementation, the upgrade scenario includes a first upgrade scenario, a second upgrade scenario, and a third upgrade scenario; wherein, in the first upgrade scenario, the target system is characterized as a new system completely different from the initial system or a new service set composed of one or more newly added microservices; in the second upgrade scenario, the target system is characterized as an upgraded service set composed of one or more upgraded microservices; and in the third upgrade scenario, the target system is characterized as a hybrid service set composed of one or more upgraded microservices and one or more newly added microservices.

[0010] In an optional implementation, in the first upgrade scenario, deploying the initial system on the baseline lane and the target system on the grayscale lane further includes: The first microservice of the initial system, the first service adaptation module, and the second microservice of the target system are deployed in the baseline swimlane, wherein the second microservice is a microservice different from the first microservice. No services are deployed in the grayscale swimlane; the interactive data in the initial system is stored in the first database, and the interactive data in the target system is stored in the first database or the second database; When the second database exists, some or all of the data stored in the first database are synchronously stored in the second database in real time.

[0011] In this embodiment, by directly deploying the microservices of the new system in the baseline swimlane, the target system can run directly after completing gray-scale testing in the baseline swimlane, reducing system deployment work and achieving a smooth transition between the old and new systems. Simultaneously, no adaptation layer changes are required, and the original adaptation module can be reused to directly connect the old and new services, significantly simplifying the deployment structure. This allows the core microservices of the new system to be ready and accept traffic in the baseline environment in advance. Real-time synchronization of baseline data through a second database ensures data consistency during the coexistence of the old and new systems. During the merging phase, if the new system replaces the initial system, only the first microservice needs to be taken offline; if a new microservice is added on top of the initial system, all user business request traffic is switched to the new system, completing the full switch to the new system. This significantly reduces system risks and business interruption time during the full replacement process, achieving a safe, controllable, and efficient overall system replacement.

[0012] In an optional implementation, in the second upgrade scenario, deploying the initial system on the baseline lane and the target system on the grayscale lane includes: The first microservice and the first service adaptation module of the initial system are deployed in the baseline swimlane; A second service adaptation module and a third microservice of the upgraded service set are deployed in the grayscale swimlane; wherein, the third microservice is characterized as the upgraded microservice in the first microservice, and the second service adaptation module is used to communicate with the third microservice; The interactive data in the initial system is stored in the first database, and the interactive data in the target system is stored in the first database or the second database. When the second database exists, some or all of the data stored in the first database will be synchronized to the second database in real time in a one-way manner. The step of merging and deploying service components belonging to the target system deployed in the grayscale swimlane to the baseline swimlane further includes: The upgraded service set is migrated to the baseline swimlane to replace the initial microservice being upgraded in the first microservice, and the second service adaptation module is taken offline.

[0013] In this embodiment, when gray-scale testing is required, the gray-scale swimlane independently deploys a second service adaptation module and the upgraded microservice. The second service adaptation module distributes gray-scale traffic to the upgraded microservice. Furthermore, according to system update needs, a second database can be set up to synchronize baseline data in real time. Upgrading the database ensures that the gray-scale environment can verify data without sacrificing consistency. During the merge deployment phase, the upgraded microservice is deployed to the baseline swimlane, and the second service adaptation module is taken offline, achieving a standardized process from gray-scale verification to full deployment. The gray-scale release mechanism in this embodiment not only ensures the reliability of system upgrades but also provides elastic adaptation capabilities to cope with different architectural change scenarios, significantly improving the efficiency and controllability of microservice system iteration.

[0014] In one optional implementation, in the third upgrade scenario, deploying the initial system on the baseline lane and the target system on the grayscale lane includes: The first microservice, the first service adaptation module, and the second microservice of the hybrid service set contained in the initial system are deployed in the baseline swimlane; wherein, the second microservice is a microservice different from the first microservice; A second service adaptation module and a third microservice of the hybrid service set are deployed in the grayscale swimlane; wherein, the third microservice is characterized as an upgraded microservice in the first microservice, and the second service adaptation module is used to communicate between the second microservice and the third microservice; The interactive data in the initial system is stored in the first database, and the interactive data in the target system is stored in the first database or the second database. When the second database exists, some or all of the data stored in the first database will be synchronized to the second database in real time in a one-way manner. The step of merging and deploying service components belonging to the target system deployed in the grayscale swimlane to the baseline swimlane further includes: The third microservice is migrated to the baseline swimlane, and the second service adaptation module is taken offline.

[0015] For complex scenarios involving partial replacement and upgrades of old and new systems, this embodiment ensures the continued stability of the system's basic functions by deploying existing services and new microservices in parallel in the baseline swimlane. Simultaneously, upgraded microservices and adaptation modules are deployed selectively in the grayscale swimlane, achieving isolated verification of upgraded components. This allows the system to maintain overall service continuity while safely performing grayscale iterations on specific modules. An independent second service adaptation module can complete interface adaptation and grayscale traffic routing in the grayscale swimlane. Real-time data synchronization can also be achieved by setting up a second database, ensuring the consistency and reliability of the grayscale verification environment while upgrading the database. By merging verified upgrade components in the grayscale swimlane into the baseline swimlane, a smooth transition from a hybrid architecture to the target architecture can be completed, significantly reducing integration risks and release delays in complex upgrade scenarios.

[0016] In one optional implementation, the binding relationship change event includes an authorization binding event or unbinding event between the target user and the associated entity, and the monitoring of binding relationship change events between the target user and the associated entity includes: Obtain the binding relationship change event by subscribing to the message queue or data change log that processes the binding relationship of the associated entities.

[0017] This embodiment listens for binding relationship events by subscribing to message queues or database change logs, which can capture changes and trigger traffic rerouting within milliseconds. In addition, message queues and database logs are core components inherent in the system architecture, with high availability and persistence guarantees, which fundamentally avoids event loss.

[0018] In an optional implementation, the step of monitoring for changes in the binding relationship between the target user and the associated entity further includes: When the binding relationship change event is detected, the target user and the associated entity are identified using a preset grayscale identifier in the grayscale allocation rule.

[0019] This embodiment fundamentally ensures that no matter how the authorization relationship changes dynamically, all participants within the business unit can be identified and directed to the same swimlane, realizing traffic coordination and thorough diversion, and solving the problem of incomplete diversion caused by dynamic authorization in the prior art.

[0020] In a second aspect, the present invention provides a system update apparatus for applying the system update method of the first aspect or any corresponding embodiment thereof, the apparatus comprising: The baseline swimlane is deployed in the production environment to run the initial system or the initial system and the second microservice. The grayscale swimlane, deployed in parallel with the baseline swimlane in the production environment, is used to run the target system or the third microservice; wherein, the initial system includes the first microservice, the second microservice is a microservice different from the first microservice, and the third microservice is represented as an upgraded microservice in the first microservice; The interactive data in the initial system is stored in the first database, and the interactive data in the target system is stored in the first database or the second database. When the second database exists, the device further includes a data synchronization module, used to synchronize some or all of the data stored in the first database to the second database in real time in a one-way manner; The caching module is used to store and maintain preset grayscale allocation rules; The monitoring module is used to monitor in real time the binding relationship change events between the target user and the associated entity, and notify the caching module to update the canary allocation rules according to the monitored binding relationship change events; The gateway module is communicatively connected to the baseline swimlane, the grayscale swimlane, and the cache module, respectively. It is used to determine the target swimlane corresponding to the service request traffic of the target user according to the grayscale allocation rule, allocate the service request traffic of the target user to the target swimlane, and reallocate the service request traffic in response to the update of the grayscale allocation rule.

[0021] In one alternative embodiment, the device further includes: The traffic splitting control platform communicates with the gateway module and is used to configure and send preset grayscale identifiers to the gateway module. Attached Figure Description

[0022] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0023] Figure 1 This is a schematic diagram of the architecture of a system update device according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating a system update method according to an embodiment of the present invention; Figure 3 This is another schematic diagram of the system update apparatus according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

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

[0025] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0026] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0027] Figure 1 This is a schematic diagram of the architecture of a system update device according to an embodiment of the present invention. This embodiment provides a system update device, which includes a baseline swimlane, a grayscale swimlane, a cache module, a monitoring module, a gateway module, and a traffic splitting control platform.

[0028] First, the grayscale swimlane and baseline swimlane are deployed in the production environment. The baseline swimlane contains all microservices of both the initial and target systems. The initial system includes a first service adaptation module and a first microservice. The first microservice is a specific service component designed using the facade pattern in a microservice architecture; it encapsulates and aggregates the complex calls and data of one or more internal microservices, providing a unified, streamlined, and stable interface to the outside world. The interactive data of the initial system is stored in the first database. The first service adaptation module serves as an interaction bridge between the front-end user and the back-end service. The interactive data of the target system is stored in either the first or second database. The second database is configured according to system update needs. When the second database exists, the data in the first database is configured to be fully or partially synchronized unidirectionally to the second database in real time. The first and second databases are not configured in the baseline and grayscale swimlanes, but rather in other areas of the production environment. The configuration of the second service adaptation module depends on whether microservices are deployed in the grayscale swimlane. If microservices are deployed in the grayscale swimlane, the second service adaptation module needs to be configured in the grayscale swimlane. If no service is deployed in the grayscale swimlane, there is no need to set up the second service adaptation module. Business traffic can be directly transmitted to the old and new microservices according to the grayscale identifier based on the first service adaptation module, which greatly reduces deployment complexity and resource overhead.

[0029] The gateway module communicates with the initial system in the baseline swimlane, the second service adaptation module in the grayscale swimlane, the traffic distribution control platform, and the caching module. The gateway module is used to label and route service request traffic flowing to the initial and target systems according to the grayscale allocation rules issued by the traffic distribution control platform. The gateway module is also used to dynamically update the grayscale allocation rules based on notifications from the caching module.

[0030] The second service adaptation module is deployed in the grayscale swimlane and serves as a communication bridge between front-end requests and the microservices of the target system deployed in the grayscale swimlane.

[0031] The listening module is used to monitor data updates generated by the data microservices responsible for handling vehicle binding and unbinding in both the initial and target systems. These updates include at least events indicating changes in the binding relationship between users and associated entities, such as changes in the binding relationship between users and associated vehicles. In this embodiment, the data microservice refers to a microservice based on a Kafka message queue responsible for listening to and transmitting vehicle binding change events. Associated entities include associated vehicles and other associated devices different from the associated vehicles. The listening module communicates with the caching module and sends binding change events to it.

[0032] The caching module stores and maintains dynamic canary allocation rules. Specifically, the caching module receives binding relationship change events from the listening module, updates the canary allocation rules according to the binding relationship change events, and after the canary allocation rules are updated, notifies the gateway module to reconfigure the canary identification and routing of business request traffic according to the updated canary allocation rules. A canary identification is an identifier attached to a business request or service instance, used to mark the traffic environment category to which the business request or service instance belongs (such as the baseline swimlane and canary swimlane in this embodiment).

[0033] During system architecture updates, to ensure a stable launch of the new system, traditional solutions typically deploy the new system in a separate, gray-scale testing environment and conduct tests using virtual users to simulate requests. Only after passing these tests is the new system deployed to the actual production environment. However, this testing environment often fails to fully simulate the real production environment, resulting in inaccurate reflection of real user interactions and system load during testing, leading to low test accuracy. After launch, issues such as system lag, service congestion, or partial functional abnormalities are likely to occur, ultimately impacting user experience.

[0034] To improve the realism of the test, the proposed improvement involves running the original and upgraded systems in parallel in a production environment, while simultaneously importing a portion of real user traffic into the new system for verification according to rules. However, this approach suffers from incomplete traffic diversion. For example, when a target user and their associated vehicle are diverted to the new system, the user's authorized mobile terminal may still remain in the original system, causing the terminal to be unable to accurately operate the vehicle or receive a response. Furthermore, during system operation, if a user authorizes another mobile device, that device may be in a different system swimlane than the target vehicle, resulting in control failure. Similarly, after a user unbinds their device, the traffic information in the grayscale swimlane and the baseline swimlane is not updated in a timely manner, causing residual devices to still occupy system resources.

[0035] Based on this, the present invention provides a system update method embodiment. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0036] This embodiment provides a system update method. Figure 2 This is a flowchart of a system update method according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps: Step S201: Establish a baseline swimlane and a grayscale swimlane in the production operation environment. Based on the current upgrade scenario, deploy the initial system on the baseline swimlane and the target system on the grayscale swimlane.

[0037] Step S202: According to the preset grayscale allocation rules, determine the target swimlane corresponding to the service request traffic of the target user, and allocate the service request traffic of the target user to the target swimlane; wherein, the target user is the user group associated with each target vehicle.

[0038] Step S203: When testing based on the allocated business request traffic, listen for binding relationship change events between the target user and the associated entity, and update the canary allocation rules based on the listened binding relationship change events.

[0039] Step S204: Redistribute business request traffic according to the updated grayscale allocation rules, and verify the target system in the grayscale swimlane.

[0040] Step S205: After verification, the service components belonging to the target system deployed in the grayscale swimlane are merged and deployed to the baseline swimlane to complete the update of the initial system.

[0041] The system update method provided in this embodiment deploys baseline swimlanes and gray-scale swimlanes in parallel in the production environment. According to preset gray-scale allocation rules, real business request traffic related to the target user is distributed to the same swimlane, ensuring the target system under test operates under completely realistic production load and data conditions, fundamentally guaranteeing the accuracy and reliability of the test results. Secondly, by monitoring changes in the binding relationship between users and associated entities in real time and dynamically updating the gray-scale allocation rules and rerouting business request traffic accordingly, it ensures that all requests related to the same business entity are collaboratively guided to the same swimlane for processing. This solves the problem of operational failures and inconsistent states caused by traffic being dispersed across different swimlanes due to changes in binding relationships, achieving precise and thorough traffic distribution in complex scenarios. Finally, after successful verification, only the core components of the gray-scale swimlane are merged into the baseline swimlane, reducing the workload and risks of traditional full migration and achieving a smooth, efficient, and secure transition for system upgrades.

[0042] The steps described above will be explained in detail below.

[0043] In step S201, a baseline swimlane and a grayscale swimlane are established in the production operation environment. Based on the current upgrade scenario, the initial system is deployed on the baseline swimlane, and the target system is deployed on the grayscale swimlane.

[0044] In one embodiment, the upgrade scenarios include a first upgrade scenario, a second upgrade scenario, and a third upgrade scenario; wherein, in the first upgrade scenario, the target system is characterized as a new system completely different from the initial system or a new service set composed of one or more newly added microservices; in the second upgrade scenario, the target system is characterized as an upgraded service set composed of one or more upgraded microservices; and in the third upgrade scenario, the target system is characterized as a hybrid service set composed of one or more upgraded microservices and one or more newly added microservices.

[0045] Specifically, two logically isolated and resource-independent runtime environment units are constructed in parallel within the production environment, defined as the baseline swimlane and the grayscale swimlane, respectively. The baseline and grayscale swimlanes share underlying resources, such as the computing cluster and network plane, but are completely isolated at the application service layer, forming a parallel verification architecture for system upgrades. Based on the specific upgrade scenario to be executed, the initial system, currently providing stable services and awaiting updates, is deployed and run in the baseline swimlane; the target system, planned for deployment and awaiting verification, is deployed and run in the grayscale swimlane. The upgrade scenarios are further divided into a first upgrade scenario, a second upgrade scenario, and a third upgrade scenario based on the scope and nature of the system changes, to accommodate different needs ranging from local functional optimization to global architecture replacement.

[0046] In one embodiment, in a first upgrade scenario, deploying the initial system on the baseline lane and the target system on the grayscale lane further includes: The first microservice of the initial system, the first service adaptation module, and the second microservice of the target system are deployed in the baseline swimlane. The second microservice is a microservice that is different from the first microservice. In the grayscale swimlane, no service is deployed. The interactive data in the initial system is stored in the first database, and the interactive data in the target system exists in either the first database or the second database. When the second database exists, some or all of the data stored in the first database is synchronously and one-way synchronized to the second database in real time.

[0047] In the first upgrade scenario, the second microservice refers to a software functional unit that completely replaces the first microservice in the initial system, or one or more software functional units added based on the first microservice in the initial system. Therefore, the target system is represented as a completely new system distinct from the initial system, or a new service set composed of one or more added microservices. This scenario is suitable for comprehensive technology upgrades or adding one or more software functional units based on the initial system. In this scenario, the initial system is deployed in the baseline swimlane. Specifically, the baseline swimlane deploys the first microservice and the first service adaptation module of the initial system. The first microservice (Facade-1) is a specific service component designed using the facade pattern in the microservice architecture. It encapsulates and aggregates the complex calls and data of one or more internal microservices, providing a unified, concise, and stable interface to the outside world. The first service adaptation module (BFF-1, Backend for Frontend) is a middleware component typically deployed between the system's frontend and backend microservice clusters, responsible for protocol adaptation, request aggregation, and route distribution.

[0048] The first database is used to persistently store all interaction data of the initial system, such as a relational database like RDS. If the first database is not upgraded, it also stores the interaction data of the target system. If the first database is upgraded to the second database in the first upgrade scenario, the interaction data of the target system is stored in the second database, and some or all of the data stored in the first database are synchronously and unidirectionally synchronized to the second database in real time. Specifically, the second database can use a different technology than the first database, such as PostgreSQL.

[0049] In the first upgrade scenario, a second microservice of the target system is also deployed in the baseline swimlane. This second microservice (Facade-2) is also a specific service component designed using the facade pattern in a microservice architecture. It encapsulates and aggregates the complex calls and data of one or more internal microservices, providing a unified, streamlined, and stable interface to the outside world. However, the second microservice differs from the first microservice in its technical implementation, business logic, or architectural design. It represents the core business capabilities of the target system, placing the first microservice of the initial system and the second microservice component of the target system side-by-side in the same baseline swimlane, providing a foundation for direct or indirect communication between them. In the first upgrade scenario, the second microservice refers to a software functional unit that completely replaces the first microservice in the initial system, or one or more software functional units added based on the first microservice in the initial system. Therefore, the target system is represented as a new system completely different from the initial system, or a new service set consisting of one or more newly added microservices.

[0050] After deployment, baseline traffic (such as normal user requests) continues to be routed to the original microservice (i.e., the first microservice in this embodiment) to ensure online business stability; gray-scale traffic (such as specific test users or internal requests) is directed to the new microservice (i.e., the second microservice in this embodiment) to verify the functionality of the new version. In this embodiment, the old and new microservices exist in the same swimlane, avoiding verification deviations caused by environmental differences; traffic allocation control is achieved through gray-scale indicators on business request traffic, and the gray-scale ratio can be adjusted at any time; finally, only the traffic routing configuration needs to be modified to achieve a seamless switch from the original microservice to the new microservice, significantly reducing the system risk and business interruption time of a full replacement.

[0051] The service adaptation module acts as an interaction bridge between front-end users and back-end services. Whether or not a service adaptation module is configured in the grayscale swimlane depends on whether microservices are deployed in the grayscale swimlane. If no microservices are deployed in the grayscale swimlane, no service adaptation module is needed; if microservices are deployed, then the service adaptation module needs to be configured. In the first upgrade scenario, when no service adaptation module is deployed in the grayscale swimlane, the first service adaptation module (BFF-1, Backend for Frontend) deployed in the baseline swimlane can be directly used to distribute business request traffic according to the grayscale distribution rules configured in the gateway module, such as... Figure 3 This shows another architecture diagram of the system's update device when no service adaptation module is deployed in the grayscale swimlane.

[0052] At this point, the first microservice and the second microservice are directly connected via the first service adaptation module, thereby routing business request traffic to the corresponding business logic units for processing, significantly reducing deployment complexity and resource overhead. Specifically, the second microservice deployed in the baseline swimlane establishes a communication connection with the first service adaptation module, enabling gray-scale business request traffic accessed via the first service adaptation module to be correctly routed to the target system's business logic units for processing. If the first database is not upgraded, it is used to store the interaction data generated by the target system when processing business request traffic, such as various business records, status changes, and log information generated by the target system in response to real user requests. If the first database is upgraded to the second database in the first upgrade scenario, the interaction data generated by the target system when processing business request traffic is stored in the second database. Furthermore, by establishing a real-time one-way data synchronization link from the first database to the second database, some or all of the interaction data stored in the first database is continuously transmitted to the second database for storage, ensuring that the target system can obtain the necessary and consistent historical context information when processing requests, enabling gray-scale testing of the target system to be conducted based on real business data.

[0053] In this embodiment, the existing adaptation module is reused to directly connect the old and new services, greatly simplifying the deployment structure. This allows the core microservices of the new system to be ready and accept traffic in the baseline environment in advance, without the need for additional configuration of the grayscale swimlane. Real-time synchronization of interactive data through a second database ensures data consistency during the coexistence of the old and new systems. During the merging phase, only the first microservice needs to be taken offline according to the upgrade scenario, or all user traffic needs to be switched to the new system to complete the complete switchover of the new system. This significantly reduces the system risk and business interruption time during the full replacement process, achieving a safe, controllable, and efficient overall system replacement.

[0054] In one embodiment, in a second upgrade scenario, deploying the initial system on the baseline lane and the target system on the grayscale lane includes: Deploy the first microservice and the first service adaptation module of the initial system in the baseline swimlane; A second service adaptation module and a third microservice of an upgraded service set are deployed in a grayscale swimlane; wherein, the third microservice is represented as the upgraded microservice in the first microservice, and the second service adaptation module is used for communication connection of the third microservice; Interactive data in the initial system is stored in the first database, and interactive data in the target system is stored in either the first database or the second database. When a second database exists, some or all of the data stored in the first database will be synchronized to the second database in real time in a one-way manner.

[0055] In the second upgrade scenario, the target system is represented as a set of upgraded services consisting of one or more upgraded microservices. This embodiment aims to iteratively upgrade a portion of the initial system's functionality, rather than replacing the entire system. In this scenario, the target system is specifically represented as a set of upgraded services consisting of one or more modified or optimized microservices. The set of upgraded services does not include all components of the initial system, but only the business functional units that need to be upgraded.

[0056] In specific deployment, the initial system is fully deployed on the baseline swimlane. Specifically, this includes deploying the first microservice and the first service adaptation module of the initial system. The first microservice (Facade-1) refers to the software functional unit that implements the core business logic of the initial system and can be deployed and expanded independently; the first service adaptation module (BFF-1, Backend for Frontend) refers to an intermediate layer component that is usually deployed between the frontend and backend microservice clusters of the system and is responsible for protocol adaptation, request aggregation, and route distribution.

[0057] The first database is used to persistently store all interaction data of the initial system, such as a relational database like RDS. If the first database is not upgraded, it also stores the interaction data of the target system. If, in the second upgrade scenario, the first database is upgraded to the second database, the interaction data of the target system is stored in the second database, and all or part of the data stored in the first database is synchronously stored in the second database in real time. Specifically, the second database can use a different technology than the first database, such as PostgreSQL.

[0058] The service adaptation module serves as an interaction bridge between front-end users and back-end services. Whether or not a service adaptation module is configured in the grayscale swimlane depends on whether microservices are deployed in the grayscale swimlane. If no microservices are deployed in the grayscale swimlane, no service adaptation module needs to be configured. If microservices are deployed in the grayscale swimlane, a service adaptation module needs to be configured. Since this embodiment deploys a third microservice for upgrading the service set in the grayscale swimlane, a corresponding second service adaptation module needs to be further deployed in the grayscale swimlane. The second service adaptation module distributes grayscale business request traffic according to the grayscale allocation rules configured in the gateway module.

[0059] Therefore, in the second upgrade scenario, the set of upgrade services involved in this upgrade and its supporting components are centrally deployed on the grayscale swimlane, specifically including: the third microservice and the second service adaptation module in the set of upgrade services.

[0060] The third microservice (Facade-3) is also a specific service component designed using the facade pattern in a microservice architecture. It encapsulates and aggregates the complex calls and data of one or more internal microservices, providing a unified, streamlined, and stable interface to the outside world. In terms of business domain, the third microservice corresponds to one or more microservices in the initial system, but it has been upgraded in terms of implementation logic, performance, or functionality; it is an improved version of one or more microservices. For example, it can be an optimized version of the "remote vehicle control microservice" in the initial system, adding new instructions or improving processing efficiency in a second-stage upgrade scenario.

[0061] The second service adaptation module (BFF-2, Backend for Frontend) is configured to establish a communication connection with the third microservice, and is responsible for receiving business request traffic and accurately forwarding it to the third microservice.

[0062] Similarly, in this scenario, a new second database can be set up as needed. Specifically, the second database (PostgreSQL) serves the upgrade service set and is used to receive full, partial, or incremental business data synchronized from the first database via a real-time one-way synchronization link. This ensures that the third microservice can access the latest basic data consistent with the baseline swimlane when processing requests. The second database is also used to store new interaction data generated during the operation of the grayscale swimlane itself, such as all new business records, state changes, and system log information generated during the processing of the third microservice and related components, triggered by real user requests routed to the grayscale swimlane.

[0063] After deployment, the gateway module's tag routing strategy continuously directs some user requests (i.e., baseline traffic in this embodiment) to the first microservice in the baseline swimlane, ensuring online business continuity. Meanwhile, another portion of user requests (i.e., canary traffic in this embodiment) are directed to the third microservice in the canary swimlane, achieving closed-loop verification of the upgraded version. Once verification is complete, simply taking the second service adaptation module offline, merging the third microservice from the canary swimlane back into the baseline swimlane to replace the initial upgraded microservice in the first microservice, and switching all traffic allows for a zero-downtime upgrade, significantly improving the reliability and release efficiency of microservice iteration.

[0064] In this embodiment, when gray-scale testing is required, the upgraded second service adaptation module and the upgraded microservice are independently deployed in the gray-scale swimlane, realizing gray-scale verification of the backend service layer and ensuring a smooth transition of service upgrade changes. Furthermore, by setting a second database to synchronize baseline data in real time, the gray-scale environment can both isolate verification and maintain data consistency. During the merge deployment phase, the second service adaptation module is taken offline, and the third microservice is merged and deployed to the baseline swimlane to replace the initial microservice being upgraded in the first microservice. Then, full traffic is switched, achieving a zero-downtime upgrade and realizing a standardized process from gray-scale verification to full deployment. The gray-scale release mechanism in this embodiment not only ensures the reliability of system upgrades but also provides elastic adaptability to different architectural change scenarios, significantly improving the efficiency and controllability of microservice system iteration.

[0065] In one embodiment, in a third upgrade scenario, deploying the initial system on the baseline lane and the target system on the grayscale lane includes: The first microservice, the first service adaptation module, and the second microservice of the hybrid service set contained in the initial system are deployed in the baseline swimlane; wherein, the second microservice is a microservice different from the first microservice.

[0066] A second service adaptation module and a third microservice of a hybrid service set are deployed in a grayscale swimlane; wherein, the third microservice is represented as an upgraded microservice in the first microservice, and the second service adaptation module is used to communicate between the second microservice and the third microservice.

[0067] The interactive data in the initial system is stored in the first database, and the interactive data in the target system is stored in either the first database or the second database. Furthermore, a second database can be set up as needed. When a second database exists, some or all of the data stored in the first database is synchronized to the second database in real time. That is, the second database is used to store the interactive data in the grayscale swimlane and the data synchronized from the first database to the second database in real time.

[0068] In the third upgrade scenario, the second microservice refers to one or more software functional units added based on the first microservice in the initial system. The third microservice corresponds to one or more microservices in the initial system in terms of business domain, but has been upgraded in terms of implementation logic, performance, or functionality; it is an improved version of one or more microservices. Therefore, in the third upgrade scenario, the target system is represented as a hybrid service set composed of one or more upgraded microservices, one or more microservices added based on the first microservice in the initial system, and the second service adaptation module. Specifically, this embodiment, in addition to involving the upgrade of some microservices, also includes entirely new microservices added in parallel with the original functions.

[0069] Specifically, the complete initial system is deployed in the baseline swimlane, including the deployment of the original first microservice and first service adaptation module of the initial system. The first microservice refers to the software functional unit that implements the core business logic of the initial system and can be deployed and expanded independently; the first service adaptation module (BFF-1, Backend for Frontend) is a middleware component that is usually deployed between the frontend and backend microservice clusters of the system and is responsible for protocol adaptation, request aggregation and routing distribution; the interactive data in the initial system is stored in the first database.

[0070] The first database refers to the database that persistently stores all business data of the initial system, such as a relational database like RDS. If the first database is not upgraded, it is also used to store the interaction data of the target system. If, in the third upgrade scenario, the first database is upgraded to the second database, the interaction data of the target system is stored in the second database, and some or all of the data stored in the first database are synchronously and unidirectionally synchronized to the second database in real time. Specifically, the second database can use a different technology than the first database, such as PostgreSQL.

[0071] In addition, a second microservice (Facade-2) of a hybrid service set is deployed in the baseline swimlane. This second microservice, also a specific service component designed using the facade pattern in the microservice architecture, encapsulates and aggregates the complex calls and data of one or more internal microservices, providing a unified, streamlined, and stable interface to the outside world. However, it is completely independent of the initial system's first microservice in terms of business functionality; it is a completely new microservice that adds new business capabilities to the system. By deploying the second microservice directly in the baseline swimlane, it is made readily available in the production environment.

[0072] The service adaptation module serves as an interaction bridge between front-end users and back-end services. Whether or not a service adaptation module is configured in the grayscale swimlane depends on whether microservices are deployed in the grayscale swimlane. If no microservices are deployed in the grayscale swimlane, no service adaptation module is needed; if microservices are deployed, then a service adaptation module is required. In the third upgrade scenario, since a third microservice is deployed in the grayscale swimlane, a second service adaptation module needs to be deployed in the grayscale swimlane in the above implementation. This allows the second service adaptation module to directly distribute business request traffic according to the grayscale allocation rules configured in the gateway module.

[0073] In the third upgrade scenario, the third microservice and the second service adaptation module from the hybrid service set are deployed in the grayscale swimlane. The third microservice (Facade-3) is also a specific service component designed using the facade pattern in the microservice architecture. It encapsulates and aggregates the complex calls and data of one or more internal microservices, providing a unified, concise, and stable interface to the outside world. In terms of business domain, the third microservice corresponds to one or more microservices in the initial system, but it has been upgraded in terms of implementation logic, performance, or functionality, and is an improved version of one or more microservices.

[0074] The second service adaptation module (BFF-2, Backend for Frontend) communicates with the new second microservice deployed in the baseline swimlane and the upgraded third microservice deployed in the gray swimlane. It is responsible for receiving business request traffic and accurately forwarding it to the third microservice and the second microservice.

[0075] Furthermore, a second database can be set up as needed. The second database (PostgreSQL) serves the business processing within the grayscale swimlane. It is used to receive the full baseline data synchronized from the first database through a stable real-time one-way synchronization link; and during the operation of the grayscale swimlane, it receives newly generated interactive data from the business request traffic flowing through the second service adaptation module, such as all new business records, status changes and process logs generated by the target system when processing real user requests.

[0076] After the above deployment is completed, multiple redirects are performed using the label routing policy of the gateway module. Specifically, a portion of the business requests from normal users (i.e., the baseline traffic in this embodiment) are continuously allocated to the first microservice in the baseline swimlane to ensure absolute business stability. The gray-scale traffic is split into two verification branches: one part is directed to the second microservice in the baseline swimlane to verify its functional completeness and performance; the other part is directed to the third microservice in the gray-scale swimlane to verify the correctness of its iterative modifications. The two gray-scale branches can be configured independently in terms of traffic ratio and do not interfere with each other. After verification is completed, the third microservice is merged back into the baseline swimlane to complete the full switchover.

[0077] For complex scenarios involving partial replacement and upgrades of old and new systems, this embodiment ensures the continued stability of the system's basic functions by deploying existing services and new microservices in parallel in the baseline swimlane. Simultaneously, it selectively deploys upgraded microservices and service adaptation modules in the grayscale swimlane, achieving isolated verification of upgraded components. This allows the system to maintain overall service continuity while safely performing grayscale iterations on specific modules. Furthermore, if the system requires a second database, real-time data synchronization with the second database ensures data consistency and reliability in the grayscale verification environment. By merging verified upgrade components from the grayscale swimlane to the baseline swimlane, a smooth transition from a hybrid architecture to the target architecture can be achieved, significantly reducing integration risks and release delays in complex upgrade scenarios.

[0078] In step S202, the target swimlane corresponding to the service request traffic of the target user is determined according to the preset grayscale allocation rule, and the service request traffic of the target user is allocated to the target swimlane; wherein, the target user is the user group associated with each target vehicle.

[0079] In one embodiment, according to a preset grayscale allocation rule, the target swimlane corresponding to the service request traffic of the target user is determined, and the service request traffic of the target user is allocated to the target swimlane, including: For each target vehicle, identify all target users associated with the target vehicle and all associated entities corresponding to the target users. The associated entities include associated vehicles and associated devices. The swimlane to which the target vehicle is assigned is determined as the target swimlane, and the business request traffic of all target users and all associated entities corresponding to the target users is allocated to the target swimlane.

[0080] Specifically, business request traffic refers to the collection of all network requests sent from the user or associated entities to the system, aimed at triggering specific business operations or obtaining business data. Associated entities include associated vehicles and devices that are logically strongly bound to or subordinate to the target user. In this embodiment, associated vehicles at least include vehicles authorized and bound by the target user. Furthermore, depending on the business model, associated devices refer to other smart devices owned by the target user that are different from associated vehicles, such as smartwatch keys or specific vehicle-to-everything (V2X) service packages subscribed to by the user.

[0081] In this embodiment, based on preset grayscale allocation rules, such as static or dynamic rules based on vehicle model, region, user group, etc., the target swimlane to which the target vehicle needs to be assigned is determined. Subsequently, using the target vehicle as the initial coloring point, based on the user and vehicle binding relationship data configured from the user profile database or permission management database, all target users directly bound to the target vehicle (including the vehicle owner and all authorized users, i.e., the target users in this embodiment) are identified. Using the target user as the query node, all other vehicles (i.e., associated vehicles in this embodiment) under its name or authorized by it are retrieved and associated devices are obtained. With the newly discovered associated vehicles and associated devices as the new diffusion starting point, the user identification and vehicle and device search process is recursively executed until all users, vehicles, and devices with direct or indirect binding relationships have been traversed.

[0082] During the traffic routing phase, all identified target users, associated vehicles, and associated devices are uniformly labeled with the same swimlane tag as the target vehicle. When a target user initiates a service request, the gateway module will route the service request to the corresponding target swimlane for processing based on its coloring identifier. For example, if the target vehicle is assigned to a gray-scale swimlane according to the rules, other associated vehicles and devices associated with the target vehicle, such as the vehicle owner and authorized users, as well as the users associated with these vehicles and devices, will all be synchronously assigned to the gray-scale swimlane environment, ensuring that the complete request chain of business scenarios involving multi-vehicle and multi-user collaboration is always executed within the same swimlane environment.

[0083] For example, the preset grayscale allocation rule can be a static strategy based on vehicle attributes, such as marking vehicles with VINs ending in specific numbers, specific vehicle models, or specific sales regions as candidate vehicles to enter the grayscale swimlane environment. Assume that according to the preset grayscale allocation rule, vehicle V1 is identified as the target vehicle and is planned to be allocated to the grayscale swimlane. Then, based on pre-stored binding relationship data between users, vehicles, and devices, with the target vehicle V1 as the initial node, a traversal of associated entities is performed. Specifically, this includes querying all users directly bound to vehicle V1, including the vehicle owner U1 and all authorized family member users U2 and U3; querying other vehicles owned by these users (i.e., associated vehicles in this embodiment), for example, U2 also owns vehicle V2; querying all users bound to vehicle V2, such as U4 and U5; querying all smart devices bound to associated users, such as U1's mobile device D1, U2's vehicle terminal D2, and U4's smart key D3; and repeating the above association queries until all users, vehicles, and devices with direct or indirect binding relationships have been traversed. Ultimately, all identified target users and associated vehicles, including users U1~U5, vehicles V1~V2, and devices D1~D3, will be uniformly marked with the same swimlane identifier as target vehicle V1, i.e., grayscale swimlane.

[0084] During the traffic routing phase, based on the gray-scale allocation rules pre-configured in the gateway module, such as: if the gray-scale label value carried in the request is "gray", the request is routed to the service instance of the gray-scale swimlane; otherwise, it is routed to the baseline swimlane. When the aforementioned tagged users initiate business requests (such as remote vehicle control, vehicle status query, authorization management, etc.) through their associated devices, the gateway matches the corresponding swimlane label according to the user identity or device identifier carried in the request, and routes all related requests to the gray-scale swimlane for processing. For example, if vehicle V1 is assigned to the gray-scale swimlane, then the vehicle control request initiated by vehicle owner U1 through mobile phone D1, the vehicle status query initiated by authorized user U2 through vehicle terminal D2, and the vehicle unlocking request initiated by U4 through smart key D3 will all be routed to the gray-scale environment. At the same time, another vehicle V2 under U2's name and its related operations are also kept in the gray-scale environment, ensuring data consistency and functional integrity in complex business scenarios such as vehicle sharing and multi-device collaboration.

[0085] In this embodiment, when a target vehicle is marked into a grayscale swimlane according to a preset grayscale allocation rule, not only will the requests of the target user bound to it be automatically routed to the grayscale environment, but other vehicles associated with the target user and their related users will also be colored synchronously, thereby ensuring the consistency of business data and status in multi-vehicle and multi-user scenarios and avoiding logical errors or inconsistent experiences caused by some links in the same business chain being in different environments.

[0086] In summary, this embodiment determines the coloring starting point through grayscale allocation rules and performs full-link diffusion based on pre-stored association relationships. It achieves unified coloring of all business entities, with vehicles as the core and covering users and devices, solving the problem of business logic confusion caused by traffic fragmentation in traditional grayscale releases and significantly improving the reliability of grayscale testing.

[0087] In step S203, when testing based on the allocated business request traffic, the binding relationship change event between the target user and the associated entity is monitored, and the gray-scale allocation rule is updated based on the monitored binding relationship change event.

[0088] In one embodiment, the binding relationship change event includes an authorization binding event or unbinding event between the target user and the associated entity. Monitoring binding relationship change events between the target user and the associated entity includes: Obtain binding relationship change events by subscribing to message queues or data change logs that handle the binding relationships of related entities.

[0089] Specifically, the associated entity binding relationship refers to the binding relationship between users, vehicles, and devices; a binding relationship change event refers to a key business operation that marks the establishment, transfer, or termination of the ownership or usage relationship between the target user and the associated entity (such as the associated vehicle or associated device in this embodiment), mainly including authorization binding events and unbinding events. For example, an authorization binding event could be that user A authorizes user B to use vehicle V under their name through the application App; an unbinding event could be that user A revokes the authorization for user B to use vehicle V, or user A revokes their own binding with the vehicle after selling vehicle V.

[0090] This embodiment obtains binding relationship change events by subscribing to a message queue or data change log that processes the binding relationships of related entities. The message queue for processing binding relationships refers to an asynchronous message middleware channel, such as a Kafka topic, specifically used in the system architecture to transmit "binding relationship change" events. When the data microservice responsible for user and vehicle management completes a binding or unbinding operation, it sends a structured message to this predefined message queue while updating the database. The message contains key information such as the event type (e.g., binding / unbinding), user identifier, vehicle identifier, and timestamp. The listening module in this embodiment can capture binding relationship change events in real time by continuously subscribing to this message queue.

[0091] In addition, the data change log refers to the log file that the database itself records all data addition, deletion, and modification operations, such as MySQL's binlog. The listening module in this embodiment can indirectly obtain binding relationship change events by parsing the data change log and filtering out insertion and deletion operation records in the user and vehicle binding relationship table.

[0092] This embodiment listens for binding relationship events by subscribing to message queues or database change logs, captures relationship changes, and triggers traffic rerouting. In addition, message queues and database logs are core components inherent in the system architecture, with high availability and persistence guarantees, which fundamentally avoids event loss.

[0093] In one embodiment, monitoring a binding relationship change event between a target user and an associated entity further includes: when a binding relationship change event is detected, using a preset grayscale identifier to identify the target user and the associated entity in the grayscale allocation rule.

[0094] In another embodiment, when the monitoring module successfully captures a binding relationship change event, it uses a preset grayscale identifier to identify the target user and associated entity involved in the binding relationship change event. The grayscale identifier is an identifier used to distinguish whether business request traffic should be directed to the baseline swimlane or the grayscale swimlane. For example, it adds a specific key-value pair `x-gray-release:canary` to the HTTP request header. For instance, when the event "User A authorizes vehicle V to User B" is detected, while ensuring that the label status of User A and vehicle V is consistent (e.g., already marked as grayscale), the identifier of User B in the grayscale allocation rule will also be immediately updated to the same grayscale identifier status as User A. Therefore, all subsequent business requests related to vehicle V initiated by User B will be identified as business request traffic with a grayscale identifier and correctly routed to the grayscale swimlane. This embodiment fundamentally ensures that regardless of how the authorization relationship dynamically changes, all participants within the business unit can be identified and directed to the same swimlane, achieving traffic coordination and thorough diversion, and solving the problem of incomplete diversion caused by dynamic authorization in the prior art.

[0095] In step S204, service request traffic is reallocated according to the updated grayscale allocation rules, and the target system is verified in the grayscale swimlane.

[0096] Specifically, when the monitoring module captures a binding relationship change event and updates the canary allocation rules, the gateway module is configured to continuously monitor or periodically retrieve the latest state of the canary allocation rules. Once a change in the canary allocation rules is detected—for example, recognizing that user B has been given a new canary identifier due to authorization by user A—the gateway module will perform real-time identification and routing decisions based on the updated rules for all newly arriving and subsequent ongoing business request traffic. For example, any subsequent request from user B to vehicle A will be identified in the gateway module as the first business request traffic with a valid canary identifier, and thus rerouted to the canary swimlane, instead of being directed to the baseline swimlane according to the old canary allocation rules, ensuring strict synchronization between traffic scheduling and business relationship status.

[0097] While implementing traffic redirection according to the new grayscale allocation rules, the target system is measured and analyzed across multiple dimensions based on the actual business load that has been accurately redistributed to the grayscale swimlanes. Specifically, this may include checking whether the target system can output the correct results that meet business expectations for redirected complex business requests arising from changes in dynamic binding relationships.

[0098] Next, monitor the target system's runtime metrics in the grayscale swimlane, such as request response time, throughput, error rate, service dependency call success rate, and resource (such as CPU and memory) utilization, to assess whether its performance and stability meet the deployment criteria.

[0099] Next, it is confirmed whether the consistency of business logic and results of the data (i.e., interactive data) written to the second database after the target system processes business request traffic in the grayscale swimlane is logically equivalent to or meets the upgrade design expectations, and whether it meets the expected results of the same business processed by the initial system in the baseline swimlane.

[0100] This embodiment achieves dynamic adaptability in traffic distribution while verifying the target system based on traffic that is fully synchronized with the production environment and reflects the real business relationship graph in real time. This improves the credibility and effectiveness of the verification results and enables the early detection and resolution of problems that would only occur in highly dynamic and complex real-world scenarios.

[0101] In step S205, after verification, the service components belonging to the target system deployed in the grayscale swimlane are merged and deployed to the baseline swimlane to complete the update of the initial system.

[0102] In one embodiment, in the first upgrade scenario, merging and deploying service components belonging to the target system deployed in the grayscale swimlane to the baseline swimlane further includes: When replacing the microservices in the initial system with new microservices, the system upgrade is completed by taking the first microservice offline and switching all user traffic to the baseline swimlane. When adding a new microservice to the initial system, the system upgrade is completed by switching all user traffic to the baseline swimlane.

[0103] Merged deployment refers to the secure and efficient integration of the service deployment of the target system, which has been fully validated in the grayscale swimlane, into the production environment of the baseline swimlane, and ultimately replace or cover the corresponding part of the initial system.

[0104] Specifically, in the first upgrade scenario, the second microservice of the target system has been pre-deployed in the baseline swimlane along with the initial system during the gray-scale testing phase. At this time, there is no service deployment in the gray-scale swimlane. Therefore, the upgrade is completed by switching traffic and taking the system offline according to the actual update situation of the system.

[0105] Meanwhile, if a second database is set up in this embodiment, it contains partial or complete historical data synchronized from the initial system, as well as all valid interactive data generated during the gray-scale test.

[0106] When the second database contains complete historical data synchronized from the initial system, it is designated as the new production master database. Application connections for the baseline swimlane are switched from the original first database to this second database, ensuring that the new system has complete and continuous business data upon deployment. Subsequently, the first database can be safely and gradually decommissioned to release resources. When the second database contains only partial historical data synchronized from the initial system, both the first and second databases run concurrently. Upgraded system data is stored in the corresponding first and second databases according to its data type.

[0107] In the first upgrade scenario, whether the first microservice included in the initial system is taken offline depends on the composition of the target system. When the target system is a completely new system that is different from the initial system, the first microservice is taken offline after completing the gray-scale verification. When the target system is a new service set consisting of one or more newly added microservices, the first microservice runs together with the new service set and does not need to be taken offline.

[0108] Specifically, in the first upgrade scenario, when the target system is a completely new system distinct from the initial system, after the second database stably takes over all business request traffic, the original initial system components—the first microservice and the first database—in the baseline swimlane can be safely and gradually taken offline to release resources. If no second database is configured in this embodiment, there is no need to take the first database offline.

[0109] In the first upgrade scenario, when the target system is a new service set consisting of one or more newly added microservices, the second microservice of the target system has already been pre-deployed in the baseline swimlane along with the initial system during the gray-scale testing phase. No services are deployed in the gray-scale swimlane. The upgrade of the initial system is completed once all traffic has been switched to the new system. When the second database contains complete historical data synchronized from the initial system, and the second database stably takes over all business request traffic, the original first database in the baseline swimlane can be safely and gradually taken offline to release resources. If no second database is configured in this embodiment, there is no need to take the first database offline.

[0110] In this embodiment, after the target system completes testing and verification in the grayscale swimlane, a smooth transition between the old and new systems is achieved by directly deploying the microservices of the new system in the baseline swimlane. No services are deployed in the grayscale swimlane; existing adaptation modules are reused to directly connect the old and new services, significantly simplifying the deployment structure. This allows the core microservices of the new system to be ready and accept traffic in the baseline environment beforehand, while the grayscale swimlane focuses on upgrading services or iterative verification of new services. If a second database is deployed in this embodiment, the baseline data is synchronized in real time, ensuring data consistency during the coexistence of the old and new systems. During the merging phase, only the verified service adaptation modules in the grayscale swimlane need to be migrated to complete the complete switchover of the new system, significantly reducing system risks and business interruption time during the full replacement process, and achieving a safe, controllable, and efficient overall system replacement.

[0111] In one embodiment, in the second upgrade scenario, merging and deploying service components belonging to the target system deployed in the grayscale swimlane to the baseline swimlane further includes: The upgraded service set is migrated to the baseline swimlane to replace the initial microservice being upgraded in the first microservice, and the second service adaptation module is taken offline.

[0112] An upgraded service set refers to one or more third-party microservices that have been fully validated in the grayscale swimlane. These third-party microservices correspond to one or more microservices in the initial system of the baseline swimlane in terms of business functionality, but are new versions that have undergone code updates, logic optimizations, or bug fixes.

[0113] The second service adaptation module refers to the traffic access layer component deployed in the grayscale swimlane in conjunction with the upgrade service set, and which has been adapted to the new version service interfaces. The second service adaptation module receives grayscale traffic and routes it to the corresponding third microservice. In the second upgrade scenario, the second service adaptation module functionally corresponds to the first service adaptation module in the baseline swimlane, but includes interface routing logic for the microservices in the grayscale swimlane.

[0114] In the second upgrade scenario, after testing, the set of upgraded services that are running stably in the grayscale swimlane will be smoothly deployed to the baseline swimlane using automated deployment tools, and the second service adaptation module will be taken offline from the grayscale swimlane. At this time, the baseline swimlane will briefly show a coexistence of the old and new sets of corresponding components. Then, the business request traffic involving the upgraded business functions that flows to the baseline swimlane will be gradually switched from the original first microservice to the newly deployed set of upgraded services, i.e., the third microservice.

[0115] Once it is confirmed that the new set of upgraded services runs stably and as expected under business request traffic, the corresponding first microservice in the baseline swimlane is taken offline and its running instance is stopped, thus completing the code-level replacement. Simultaneously, it is necessary to clean up or migrate ancillary resources such as configurations and caches related to the old service.

[0116] Meanwhile, if a second database is configured in this embodiment, the second database contains partial or complete historical data synchronized from the initial system, as well as all valid interaction data generated during the gray-scale testing. If the second database contains complete historical data synchronized from the initial system, then the second database is used as the new production master database, and the application connections of the baseline swimlane are switched from the original first database to the second database, ensuring that the new system has complete and continuous business data after going live. Then, the microservices corresponding to the third microservice in the first microservice and the first database can be safely and gradually taken offline to release resources. If the second database contains partial historical data synchronized from the initial system, then the first and second databases run simultaneously, and the upgraded system data is stored in the corresponding first and second databases according to data type. In addition, if no second database is configured in this embodiment, there is no need to take the first database offline.

[0117] In this embodiment, a second service adaptation module and the upgraded microservice are independently deployed in the grayscale swimlane, enabling synchronous grayscale verification between the front-end interface layer and the back-end service layer. This ensures that grayscale business traffic accurately flows into the upgraded microservice in the grayscale swimlane. Furthermore, a second database can be set up, and baseline data can be synchronized in real time through the second database. This allows the grayscale environment to both isolate verification and maintain data consistency. During the merge deployment phase, the third microservice is migrated to the baseline swimlane, one or more microservices corresponding to the third microservice in the baseline swimlane are deregistered, and auxiliary resources such as configurations and caches related to the old service are cleaned up or migrated. This achieves a standardized process from grayscale verification to full deployment. The layered and hierarchical grayscale release mechanism in this embodiment not only ensures the reliability of system upgrades but also provides elastic adaptability to different architectural change scenarios, significantly improving the efficiency and controllability of microservice system iteration.

[0118] In one embodiment, in the third upgrade scenario, merging and deploying service components belonging to the target system deployed in the grayscale swimlane to the baseline swimlane further includes: Migrate the third microservice to the baseline swimlane and take the second service adaptation module offline.

[0119] The third microservice refers to a new version that has been validated in the grayscale swimlane and has undergone functional upgrades or performance optimizations of one or more microservices in the initial system. It is the part that needs to replace one or more microservices in the third upgrade scenario.

[0120] The second service adaptation module refers to the traffic scheduling and aggregation layer component deployed in the grayscale swimlane that has been adapted and uniformly connected to the second and third microservices.

[0121] The second database refers to a database instance set up according to system upgrade requirements. It stores baseline business data synchronized in real time from the first database, as well as all valid interactive data generated by the actual gray-scale traffic flowing through the second service adaptation module during the gray-scale testing phase, such as new business records, status changes, and process logs that have been confirmed as correct by the business and generated by the system in processing user requests.

[0122] In the third upgrade scenario, after testing, only the third microservice needs to be migrated to the baseline swimlane. Specifically, the verified third microservice in the gray-scale swimlane is migrated to the baseline swimlane using an automated deployment tool, and the second service adaptation module is taken offline from the gray-scale swimlane. At this time, the baseline swimlane includes the first service adaptation module, the pre-deployed second microservice, and the migrated third microservice. If a second database is set up in this embodiment, and if the second database contains complete historical data synchronized from the initial system and all valid interaction data generated during the gray-scale testing, then the second database is used as the new production master database, and the application connection of the baseline swimlane is switched from the original first database to the second database, ensuring that the new system has complete and continuous business data after going online. Then, the upgraded microservices corresponding to the third microservice in the first microservice and the first database can be safely and gradually taken offline to release resources. If the second database contains some historical data synchronized from the initial system, then the first database and the second database run simultaneously, and the upgraded system data is stored in the corresponding first database and the second database according to the data type. In addition, if no second database is configured in this embodiment, there is no need to take the first database offline.

[0123] Furthermore, traffic for business requests involving new features will be routed to the second microservice, and traffic for business requests involving upgrade features will be routed to the third microservice. Once the new service architecture is running stably and confirmed to be error-free, the old version of the first microservice (i.e., the part of the microservice replaced by the third microservice) and the first database that have been replaced in the baseline swimlane will be gradually taken offline. Additionally, if a second database is not configured separately in this embodiment, there is no need to take the first database offline.

[0124] For complex scenarios involving partial replacement and upgrades of old and new systems, this embodiment ensures the continued stability of the system's basic functions by deploying existing services and new microservices in parallel in the baseline swimlane. Simultaneously, it isolates and verifies upgraded components by deploying upgraded microservices and service adaptation modules selectively in the grayscale swimlane. This allows the system to maintain overall service continuity while safely performing grayscale iterations on specific modules. A separate second service adaptation module can complete interface adaptation and routing of grayscale business traffic within the grayscale swimlane. If a second database is set up, real-time data synchronization ensures data consistency and reliability in the grayscale verification environment. By merging verified upgrade components from the grayscale swimlane to the baseline swimlane, a smooth transition from a hybrid architecture to the target architecture can be achieved, significantly reducing integration risks and release delays in complex upgrade scenarios.

[0125] like Figure 1 As shown, this embodiment also provides a system update device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. The device includes: The baseline swimlane is deployed in the production environment to run the initial system or the initial system and the second microservice. Grayscale swimlanes are deployed in parallel with baseline swimlanes in the production environment to run the target system or third-party microservices. The initial system includes a first microservice, a second microservice is a microservice different from the first microservice, and a third microservice is an upgraded microservice in the first microservice. The interactive data in the initial system is stored in the first database, and the interactive data in the target system is stored in the first database or the second database. When a second database exists, the device further includes a data synchronization module, used to synchronize some or all of the data stored in the first database to the second database in the grayscale swimlane in real time in a one-way manner. The caching module is used to store and maintain preset grayscale allocation rules; The monitoring module is used to monitor changes in the binding relationship between the target user and the associated entity in real time, and to notify the caching module to update the canary distribution rules based on the monitored changes in the binding relationship. The gateway module communicates with the baseline swimlane, grayscale swimlane, and cache module respectively. It is used to determine the target swimlane corresponding to the business request traffic of the target user according to the grayscale allocation rules, allocate the business request traffic of the target user to the target swimlane, and reallocate the business request traffic in response to the update of the grayscale allocation rules.

[0126] In one embodiment, the apparatus further includes: The traffic splitting control platform communicates with the gateway module to configure and send preset grayscale identifiers to the gateway module.

[0127] In one embodiment, the apparatus further includes: The first microservice refers to a software functional unit that constitutes the initial system's business capabilities and can be independently deployed and expanded.

[0128] A second microservice refers to a software functional unit that completely replaces the first microservice in the initial system, or one or more software functional units added based on the first microservice in the initial system.

[0129] The third microservice refers to an upgraded version of a software functional unit that optimizes one or more first microservices.

[0130] The first service adaptation module refers to the middleware software component deployed in the baseline swimlane, which is built between the user front-end and the first microservice cluster.

[0131] The second service adaptation module refers to the middleware software component deployed in the grayscale swimlane to adapt to the second and / or third microservices. The second service adaptation module receives business request traffic and routes it to the corresponding second or third microservice.

[0132] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0133] The following is a detailed reference. Figure 4 This diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present invention. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 401, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 402 or a program loaded from memory 408 into random access memory (RAM) 403. The RAM 403 also stores various programs and data required for the operation of the electronic device. The processor 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0134] Typically, the following devices can be connected to I / O interface 405: input devices 406 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 407 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 408 including, for example, magnetic tapes, hard disks, etc.; and communication devices 409. Communication device 409 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0135] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 409, or installed from a memory 408, or installed from a ROM 402. When the computer program is executed by the processor 401, it performs the functions defined in the system update method of the embodiments of the present invention.

[0136] Figure 4 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0137] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium after being downloaded via a network. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium may also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the system update method shown in the above embodiments is implemented.

[0138] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0139] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A method of updating a system, characterized by, The method includes: Establish a baseline swimlane and a grayscale swimlane in the production operation environment. Based on the current upgrade scenario, deploy the initial system on the baseline swimlane and the target system on the grayscale swimlane. According to the preset grayscale allocation rules, the target swimlane corresponding to the business request traffic of the target user is determined, and the business request traffic of the target user is allocated to the target swimlane; wherein, the target user is the user group associated with each target vehicle; When testing based on the allocated business request traffic, listen for binding relationship change events between the target user and the associated entity, and update the canary allocation rules based on the listened binding relationship change events; The service request traffic is reallocated according to the updated grayscale allocation rules, and the target system is verified in the grayscale swimlane; After successful verification, the service components belonging to the target system deployed in the grayscale swimlane are merged and deployed to the baseline swimlane to complete the update of the initial system; The step of determining the target swimlane corresponding to the service request traffic of the target user according to the preset grayscale allocation rule, and allocating the service request traffic of the target user to the target swimlane, includes: For each target vehicle, identify all target users associated with the target vehicle and all associated entities corresponding to the target users, the associated entities including associated vehicles and associated devices; determine the swimlane to which the target vehicle is assigned as the target swimlane, and allocate the service request traffic of all target users and all associated entities corresponding to the user to the target swimlane; The step of determining all target users associated with the target vehicle and all associated entities corresponding to the target users includes: using the target vehicle as the initial node, identifying all target users directly bound to the target vehicle; using the target users as query nodes, traversing to obtain all associated entities of the target users; and using the associated entities as diffusion nodes, repeatedly executing the above identification and traversal steps until all target users associated with the target vehicle and all associated entities corresponding to the target users are obtained.

2. The method of claim 1, wherein, The upgrade scenarios include a first upgrade scenario, a second upgrade scenario, and a third upgrade scenario; wherein, in the first upgrade scenario, the target system is characterized as a new system completely different from the initial system or a new service set composed of one or more newly added microservices; in the second upgrade scenario, the target system is characterized as an upgraded service set composed of one or more upgraded microservices; and in the third upgrade scenario, the target system is characterized as a hybrid service set composed of one or more upgraded microservices and one or more newly added microservices.

3. The method of claim 2, wherein, In the first upgrade scenario, deploying the initial system on the baseline lane and the target system on the grayscale lane further includes: The first microservice of the initial system, the first service adaptation module, and the second microservice of the target system are deployed in the baseline swimlane, wherein the second microservice is a microservice different from the first microservice. No services are deployed in the grayscale swimlane; the interactive data in the initial system is stored in the first database, and the interactive data in the target system is stored in the first database or the second database; When the second database exists, some or all of the data stored in the first database are synchronously stored in the second database in real time.

4. The method of claim 2, wherein, In the second upgrade scenario, deploying the initial system on the baseline lane and the target system on the grayscale lane includes: The first microservice and the first service adaptation module of the initial system are deployed in the baseline swimlane; A second service adaptation module and a third microservice of the upgraded service set are deployed in the grayscale swimlane; wherein, the third microservice is characterized as the upgraded microservice in the first microservice, and the second service adaptation module is used to communicate with the third microservice; The interactive data in the initial system is stored in the first database, and the interactive data in the target system is stored in the first database or the second database. When the second database exists, some or all of the data stored in the first database will be synchronized to the second database in real time in a one-way manner. The step of merging and deploying service components belonging to the target system deployed in the grayscale swimlane to the baseline swimlane further includes: The upgraded service set is migrated to the baseline swimlane to replace the initial microservice being upgraded in the first microservice, and the second service adaptation module is taken offline.

5. The method of claim 2, wherein, In the third upgrade scenario, deploying the initial system on the baseline lane and the target system on the grayscale lane includes: The first microservice, the first service adaptation module, and the second microservice of the hybrid service set contained in the initial system are deployed in the baseline swimlane; wherein, the second microservice is a microservice different from the first microservice; A second service adaptation module and a third microservice of the hybrid service set are deployed in the grayscale swimlane; wherein, the third microservice is characterized as an upgraded microservice in the first microservice, and the second service adaptation module is used to communicate between the second microservice and the third microservice; The interactive data in the initial system is stored in the first database, and the interactive data in the target system is stored in the first database or the second database. When the second database exists, some or all of the data stored in the first database will be synchronized to the second database in real time in a one-way manner. The step of merging and deploying service components belonging to the target system deployed in the grayscale swimlane to the baseline swimlane further includes: The third microservice is migrated to the baseline swimlane, and the second service adaptation module is taken offline.

6. The method of claim 1, wherein, The binding relationship change event includes an authorization binding event or unbinding event between the target user and the associated entity. Monitoring the binding relationship change event between the target user and the associated entity includes: Obtain the binding relationship change event by subscribing to the message queue or data change log that processes the binding relationship of the associated entities.

7. The method according to claim 1, characterized in that, The monitoring of binding relationship change events between the target user and the associated entity also includes: When the binding relationship change event is detected, the target user and the associated entity are identified using a preset grayscale identifier in the grayscale allocation rule.

8. A system update device, characterized in that, The apparatus for using the method of any one of claims 1 to 7 comprises: The baseline swimlane is deployed in the production environment to run the initial system or the initial system and the second microservice. The grayscale swimlane, deployed in parallel with the baseline swimlane in the production environment, is used to run the target system or the third microservice; wherein, the initial system includes the first microservice, the second microservice is a microservice different from the first microservice, and the third microservice is represented as an upgraded microservice in the first microservice; The interactive data in the initial system is stored in the first database, and the interactive data in the target system is stored in the first database or the second database. When the second database exists, the device further includes a data synchronization module, used to synchronize some or all of the data stored in the first database to the second database in real time in a one-way manner; The caching module is used to store and maintain preset grayscale allocation rules; The monitoring module is used to monitor in real time the binding relationship change events between the target user and the associated entity, and notify the caching module to update the canary allocation rules according to the monitored binding relationship change events; The gateway module is communicatively connected to the baseline swimlane, the grayscale swimlane, and the cache module, respectively. It is used to determine the target swimlane corresponding to the service request traffic of the target user according to the grayscale allocation rule, allocate the service request traffic of the target user to the target swimlane, and reallocate the service request traffic in response to the update of the grayscale allocation rule.

9. The apparatus of claim 8, wherein, The device further includes: The traffic splitting control platform communicates with the gateway module and is used to configure and send preset grayscale identifiers to the gateway module.

Images