Continuous integration-based e-commerce platform service automatic deployment method and system

Abstract

This application proposes an automated deployment method and system for e-commerce platform services based on continuous integration. The method includes: responding to code changes in the target service by acquiring historical call pattern data of the target service being called by upstream callers within a historical time period; performing simulation stress testing on the target service after code changes based on the historical call pattern data to obtain dynamic call characteristic information of the target service under the historical call pattern data; matching and analyzing the dynamic call characteristic information with the pre-configured call tolerance information of each upstream caller to predict the risk impact on each upstream caller after the target service after code changes goes live, and generating risk analysis results including risk scenarios and identifiers of affected upstream callers; and executing a risk immunity deployment strategy for the target service based on the risk analysis results. This application can block the risk propagation path before a failure occurs, ensuring the stability of e-commerce platform service updates and the reliability of the call chain.

Description

Technical Field

[0001] This application relates to the field of e-commerce platform technology, and in particular to an automated deployment method and system for e-commerce platform services based on continuous integration. Background Technology

[0002] With the rapid development of e-commerce, e-commerce platforms generally adopt a microservice architecture to support their business systems. In a microservice architecture, a complete business process often involves the coordinated invocation of dozens of microservices, forming complex dependency relationships between services. For example, the product details page service calls multiple underlying services such as inventory service, price service, and review service to assemble page data.

[0003] To meet the rapid iteration needs of e-commerce operations, continuous integration and continuous deployment have become industry standard practices. Development teams use automated build, testing, and deployment processes to quickly bring code changes online. Currently, the main methods used for service deployment are as follows:

[0004] 1. Isolation environment testing: Perform functional verification and stress testing on the new version of the service in a pre-release or test environment, and only go live after passing the test.

[0005] 2. Gray-scale release: Gradually switch the traffic according to the proportion of users, first let a small number of users use the new version, and expand the scope after observing that there are no abnormalities.

[0006] 3. Circuit breaking and rate limiting mechanism: Configure timeout thresholds, circuit breaking thresholds and degradation strategies for upstream callers in the service mesh, and trigger self-protection when the service response is abnormal.

[0007] However, the above approach has some problems in practical applications: when the code of an underlying service called by multiple upstream services changes, it is difficult to accurately assess the specific impact on each upstream caller after the new version goes live before deployment. Isolation environment testing cannot simulate the real traffic characteristics of the production environment, canary releases essentially expose risks to some users before they are perceived, and statically configured circuit breakers can only respond passively after a failure occurs. This leads to failures caused by service updates often only being exposed after deployment and rapidly spreading along the call chain, making it difficult to control the scope of the impact. Summary of the Invention

[0008] This application proposes an automated deployment method and system for e-commerce platform services based on continuous integration. The purpose is to deeply integrate code analysis in the continuous integration phase with risk control in the continuous deployment phase, predict the specific risk impact of code changes on upstream callers before the service goes live, and execute targeted immune deployment strategies based on the prediction results. This will block the risk propagation path before a failure occurs and ensure the stability of e-commerce platform service updates and the reliability of the call chain.

[0009] Firstly, the technical solution provided in this application includes:

[0010] An automated deployment method for e-commerce platform services based on continuous integration, the method comprising:

[0011] In response to code changes to the target service, obtain historical call pattern data of the target service being called by upstream callers within a historical time period;

[0012] Based on the historical call pattern data, simulation stress test is performed on the target service after code modification to obtain the dynamic call feature information of the target service under the historical call pattern data.

[0013] The dynamic call feature information is matched and analyzed with the call tolerance configuration information pre-configured by each upstream caller to predict the risk impact on each upstream caller after the target service after the code change goes online, and generate risk analysis results including risk scenarios and the identifiers of affected upstream callers.

[0014] Based on the risk analysis results, a risk immunity deployment strategy is implemented for the target service after the code change.

[0015] Furthermore, obtaining historical call pattern data of the target service being called by upstream callers within a historical time period includes:

[0016] Obtain the call logs of the target service within a preset historical window period;

[0017] The call logs are parsed to extract the identity identifiers of each upstream caller, the distribution characteristics of call parameters, and the time-related concurrency pressure model.

[0018] Furthermore, the dynamic invocation feature information includes: the resource consumption curve of the target service under different concurrency pressures, the response time distribution information for different invocation parameter types, and the condition parameter information that induces runtime exceptions.

[0019] Furthermore, the call tolerance configuration information includes a call tolerance threshold and a degradation strategy, wherein the call tolerance threshold includes a timeout threshold and a circuit breaker threshold;

[0020] The step of matching and analyzing the dynamic call feature information with the call tolerance configuration information pre-configured by each upstream caller includes:

[0021] Obtain the pre-configured timeout threshold, circuit breaker threshold, and degradation strategy of each upstream caller;

[0022] Based on the response time distribution information and the timeout threshold, identify the first type of risk scenario where the upstream caller's timeout protection mechanism may be triggered due to response time timeout after the target service goes online;

[0023] Based on the abnormal condition parameter information and the circuit breaker threshold, identify a second type of risk scenario where the upstream caller's circuit breaker protection mechanism may be triggered due to an excessive error rate after the target service goes online;

[0024] Associate the first type of risk scenario and the second type of risk scenario with the corresponding affected upstream caller identifier to generate risk call chain information;

[0025] According to the degradation strategy, local degradation logic is preset for the affected upstream callers when the first type of risk scenario and the second type of risk scenario actually occur.

[0026] Furthermore, the step of implementing a risk immunity deployment strategy for the target service after the code change based on the risk analysis results includes:

[0027] Based on the risk scenarios marked in the risk analysis results, fine-grained routing rules are issued to the gateway; the fine-grained routing rules are used to redirect request traffic that does not trigger the risk scenario to the new version instance of the target service, and to retain request traffic that triggers the risk scenario for processing by the old version instance of the target service.

[0028] Furthermore, the step of implementing a risk immunity deployment strategy for the target service after the code change based on the risk analysis results includes:

[0029] Based on the affected upstream caller identifiers marked in the risk analysis results, adjusted circuit breaker rules and rate limiting rules are issued to the service mesh proxy where the affected upstream caller resides. The adjusted circuit breaker rules and rate limiting rules have lower trigger thresholds than the regular rules based on the call tolerance configuration information, which are used to prevent the spread of faults in advance when the risk scenario is triggered.

[0030] Furthermore, the step of implementing a risk immunity deployment strategy for the target service after the code change based on the risk analysis results also includes:

[0031] During the deployment of the target service, continuously monitor whether the risk scenarios marked in the risk analysis results actually occur;

[0032] When the aforementioned risk scenario actually occurs, a risk warning signal is broadcast to the affected upstream callers through the service mesh;

[0033] According to the preset local degradation logic, the affected upstream caller is triggered to perform local degradation. The preset local degradation logic is pre-configured for the affected upstream caller during the matching analysis phase.

[0034] Furthermore, the method also includes:

[0035] After the new version of the target service is launched and running stably, collect real production environment monitoring data;

[0036] The real production environment monitoring data is fed back to the continuous integration system to calibrate the simulation stress test model.

[0037] Furthermore, the risk analysis results are presented in the form of a risk call chain graph, which identifies the target service as the risk source, the specific call parameter characteristics that induce the risk, and the affected upstream caller paths, including direct caller paths and indirect caller paths.

[0038] Secondly, the technical solution provided in this application includes:

[0039] An automated deployment system for e-commerce platform services based on continuous integration, the system comprising:

[0040] The historical data acquisition module is used to acquire historical call pattern data of the target service being called by upstream callers within a historical time period in response to code changes of the target service;

[0041] The simulation load testing module is used to perform simulation load testing on the target service after code changes based on the historical call pattern data, and obtain the dynamic call feature information of the target service under the historical call pattern data.

[0042] The risk prediction module is used to match and analyze the dynamic call feature information with the call tolerance configuration information pre-configured by each upstream caller, predict the risk impact on each upstream caller after the target service after the code change goes online, and generate risk analysis results including risk scenarios and the identifiers of affected upstream callers.

[0043] The immune deployment module is used to execute a risk immune deployment strategy on the target service after the code change based on the risk analysis results.

[0044] The technical solution provided in this application has at least the following advantages over the prior art:

[0045] This application introduces historical call pattern data during the continuous integration phase to perform simulation stress testing on the target service after code changes, enabling the prediction of potential risks to upstream callers before the service goes live.

[0046] The dynamic call feature information generated by this application includes fine-grained data such as response time distribution and abnormal conditions. By matching and analyzing this data with the call tolerance configuration information pre-configured by the upstream caller, specific risk scenarios and affected upstream callers can be accurately identified.

[0047] This application implements a risk immunization deployment strategy based on risk analysis results, enabling the deployment process to proactively avoid or isolate known risks and achieve pre-emptive intervention in risks.

[0048] This application establishes a complete link from code analysis to deployment prevention through the deep integration of continuous integration and continuous deployment, effectively preventing the upstream spread of faults caused by underlying service updates and ensuring the reliability of the e-commerce platform's call chain. Attached Figure Description

[0049] Figure 1 This is a flowchart illustrating an automated deployment method for e-commerce platform services based on continuous integration, provided in one embodiment of this application.

[0050] Figure 2 This is a structural diagram of an automated deployment system for e-commerce platform services based on continuous integration, provided in one embodiment of this application. Detailed Implementation

[0051] This specific embodiment is merely an explanation of this application and is not intended to limit it. Those skilled in the art, after reading this specification, can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they fall within the scope of the claims of this application. To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of this application.

[0052] The term "comprising" and any variations thereof in the specification and claims of this application are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product or device.

[0053] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0054] The embodiments of this application will now be described in further detail with reference to the accompanying drawings.

[0055] Figure 1 This application provides an exemplary embodiment of an automated deployment method for e-commerce platform services based on continuous integration, characterized in that the method includes:

[0056] Step S1: In response to code changes to the target service, obtain historical call pattern data of the target service being called by upstream callers within a historical time period.

[0057] The purpose of this step is to obtain the actual call characteristics of the target service in the production environment, providing a realistic data source for subsequent simulation load testing. This addresses the technical pain point that existing isolated environment testing cannot simulate real production traffic and call patterns, ensuring the accuracy of subsequent risk prediction and avoiding deployment risks caused by differences between the test and production environments. The target service refers to the specific service that has undergone code changes and needs to be deployed online, such as a product inventory service, a pricing service, or a product review service (in this example, the product inventory service).

[0058] In some embodiments, obtaining historical call pattern data of the target service being called by upstream callers within a historical time period includes:

[0059] Obtain the call logs of the target service within a preset historical window period;

[0060] The call logs are parsed to extract the identity identifiers of each upstream caller, the distribution characteristics of call parameters, and the time-related concurrency pressure model.

[0061] Specifically, a continuous integration system is launched, which can be an existing mature system such as Jenkins or GitLab CI / CD, to respond to code change requests submitted by developers for the product inventory service. For example, code change requests could be common underlying service iteration requirements such as optimizing the inventory deduction algorithm or adding distributed lock granularity. All call logs of the product inventory service within a preset historical window period are obtained through a full-link monitoring system, which can be an existing system such as SkyWalking or Zipkin.

[0062] In this embodiment, the preset historical window period is preferably the most recent 24 hours, which can be flexibly adjusted according to the e-commerce business scenario. For example, if business traffic fluctuates greatly during a major promotion, it can be adjusted to the most recent 12 hours. The call log contains a complete record of all calls made by upstream callers to the inventory service, without omissions. Subsequently, the obtained call log is structured and parsed by a log parsing module, which can be implemented using the ELK log analysis suite.

[0063] During the parsing process, three types of core data are extracted: the identity identifiers of each upstream caller, the distribution characteristics of call parameters, and a time-related concurrency pressure model. The upstream callers can be product detail page services, order placement services, shopping cart services, checkout services, etc., all of which are upper-level services that call the target service (inventory service). During parsing, the unique identifiers of each upstream service, such as service ID and interface path, need to be recorded.

[0064] The parameter distribution characteristics can be used to parse the request parameters of each upstream service when calling the inventory service, such as the product ID when querying inventory, the deduction quantity when deducting inventory, and the query type. Among them, the product ID can be distinguished between hot product IDs and long-tail product IDs, the deduction quantity can be distinguished between single-item deduction and batch deduction, and the query type can be distinguished between real-time query and cached query. After parsing, the parameter distribution statistics are generated.

[0065] The concurrency stress model can statistically analyze the number of concurrent requests in each time period within a preset historical window, generating a concurrency stress curve that clearly defines the peak concurrency period, peak concurrency level, and low concurrency level. For example, the common morning peak for e-commerce is 9:00-10:00, and the evening peak is 20:00-22:00, with the evening peak reaching 1000 QPS. This model can completely replicate the concurrency characteristics of the production environment.

[0066] This embodiment ensures that the acquired data is comprehensive and accurate by acquiring and parsing historical call pattern data, and replicates the call characteristics of the actual production environment as much as possible. This provides reliable input for subsequent simulation and stress testing, and avoids risk prediction deviations caused by missing or distorted data.

[0067] Step S2: Based on the historical call pattern data, perform simulation stress testing on the target service after code modification to obtain the dynamic call feature information of the target service under the historical call pattern data.

[0068] The purpose of this step is to simulate real-world call scenarios in a production environment, test the dynamic behavior of the target service after code changes, capture the performance characteristics and anomaly triggering conditions of the new version service, transform static code changes into dynamic behavioral characteristics, provide data support for subsequent risk matching analysis, and solve the problem that existing technologies cannot know the running status of the new version service in real-world scenarios in advance.

[0069] In some embodiments, the dynamic invocation feature information includes: the resource consumption curve of the target service under different concurrency pressures, the response time distribution information for different invocation parameter types, and the condition parameter information that induces runtime exceptions.

[0070] Specifically, a simulation test environment with configurations largely identical to the production environment is first built. This environment configuration includes network latency, CPU resource limits, memory resource limits, database configuration, and distributed lock configuration. The network latency deviation from the production environment should not exceed 10ms, and the database configuration should use the same database type, data volume, and index configuration as the production environment. This ensures that the simulation environment can replicate the operating conditions of the production environment to the greatest extent possible, avoiding distortion of stress test results due to environmental differences.

[0071] Next, deploy the new version of the product inventory service with the modified code to the aforementioned simulation test environment, and replay the historical call pattern data obtained in the previous step using a load testing tool. The load testing tool can be an existing tool such as JMeter or Locust. During the replay process, the actual call scenarios of each upstream service to the new version of the inventory service are simulated according to the parsed concurrent pressure model and call parameter distribution characteristics.

[0072] The load testing process does not alter the calling logic, parameter distribution, or concurrency patterns, simulating the real-world calling state of a production environment throughout. After the load testing is completed, the load testing monitoring module collects operational data for the new version of the inventory service and extracts three types of core dynamic calling characteristic information.

[0073] The resource consumption curve records the changes in CPU utilization, memory usage, disk I / O, and network I / O under different concurrency pressures for the new version of the inventory service, clearly illustrating the resource consumption patterns under different concurrency scenarios. For example, at a peak concurrency of 1000 QPS, the CPU utilization increases from 30% to 75%.

[0074] Response time distribution information can be used to statistically analyze the response time distribution of the new version of the inventory service for different call parameter types, including average response time, P95 response time, and P99 response time. For example, the P95 response time for popular product inventory queries is 50ms, while the P95 response time for long-tail product inventory queries is 15ms.

[0075] The conditional parameters that trigger runtime exceptions can record the specific conditions under which runtime exceptions such as timeouts, errors, and abnormal exits occur in the new version of the inventory service during load testing. For example, when the batch deduction of inventory exceeds 100 units and the concurrency reaches 800 QPS, a distributed lock conflict exception occurs; when the concurrent query volume of hot product IDs exceeds 500 QPS, a response timeout (exceeding 100ms) occurs.

[0076] This embodiment can comprehensively capture the dynamic operation behavior of the new version of the service, providing accurate and comprehensive data support for subsequent risk matching analysis, and ensuring the pertinence and accuracy of risk prediction.

[0077] Step S3: Match and analyze the dynamic call feature information with the call tolerance configuration information pre-configured by each upstream caller to predict the risk impact on each upstream caller after the target service with the code change goes online, and generate risk analysis results containing risk scenarios and the identifiers of affected upstream callers.

[0078] The purpose of this step is to predict potential risk scenarios and affected upstream services after the launch of a new version of the service by matching dynamic features with the tolerance of upstream services. This breaks the passive mode of "launching first and then discovering risks" in existing technologies, and enables accurate risk prediction in advance, providing clear goals and basis for subsequent risk immunity deployment.

[0079] In some embodiments, the call tolerance configuration information includes a call tolerance threshold and a degradation strategy, wherein the call tolerance threshold includes a timeout threshold and a circuit breaker threshold;

[0080] The step of matching and analyzing the dynamic call feature information with the call tolerance configuration information pre-configured by each upstream caller includes:

[0081] Obtain the pre-configured timeout threshold, circuit breaker threshold, and degradation strategy of each upstream caller;

[0082] Based on the response time distribution information and the timeout threshold, identify the first type of risk scenario where the upstream caller's timeout protection mechanism may be triggered due to response time timeout after the target service goes online;

[0083] Based on the abnormal condition parameter information and the circuit breaker threshold, identify a second type of risk scenario where the upstream caller's circuit breaker protection mechanism may be triggered due to an excessive error rate after the target service goes online;

[0084] Associate the first type of risk scenario and the second type of risk scenario with the corresponding affected upstream caller identifier to generate risk call chain information;

[0085] According to the degradation strategy, local degradation logic is preset for the affected upstream callers when the first type of risk scenario and the second type of risk scenario actually occur.

[0086] Specifically, the service mesh configuration interface is first invoked to obtain the pre-configured call tolerance settings of all upstream callers. The service mesh can be an existing system such as Istio. The upstream callers can be product detail page services, order placement services, etc., and the tolerance settings of different upstream callers may differ.

[0087] For example, the timeout threshold for the product details page service to call the inventory service is 30ms, the circuit breaker threshold is an error rate exceeding 5% (within 1 minute), and the degradation strategy is to display locally cached product inventory data when the call fails. The timeout threshold for the order placement service to call the inventory service is 50ms, the circuit breaker threshold is an error rate exceeding 3% (within 1 minute), and the degradation strategy is to return a "Inventory query error, please retry" message when the call fails and trigger the order temporary storage mechanism.

[0088] Next, the dynamic call feature information obtained in the previous step is compared with the call tolerance configuration information to perform a collision matching analysis. Based on the response time distribution information in the dynamic call feature information, it is compared with the timeout threshold of each upstream caller to identify the first type of risk scenario that may trigger the timeout protection mechanism of the upstream caller due to response time timeout.

[0089] For example, the new version of the inventory service has a P95 response time of 50ms when querying popular products, which exceeds the timeout threshold of 30ms for the product details page service. Therefore, "hot product inventory query" is identified as a Class I risk scenario, and the upstream caller affected is the product details page service.

[0090] Based on the conditional parameters that trigger runtime exceptions in the dynamic call feature information, the circuit breaker thresholds of each upstream caller are compared to identify a second type of risk scenario that may trigger the upstream caller's circuit breaker protection mechanism due to excessive error rate. For example, in the new version of the inventory service, when "batch deducting inventory quantity exceeds 100 units and the concurrency reaches 800 QPS", the error rate is 8%, exceeding the circuit breaker threshold of 3% for the order service. Therefore, "batch deducting inventory (quantity > 100 units, concurrency ≥ 800 QPS)" is determined to be a second type of risk scenario, and the affected upstream caller is the order service.

[0091] Subsequently, the two types of risk scenarios are associated with the corresponding affected upstream caller identifiers to generate risk call chain information. At the same time, based on the degradation strategy of each upstream caller, the local degradation logic for the affected upstream caller when the corresponding risk scenario actually occurs is preset.

[0092] This embodiment achieves accurate identification and association of two types of risk scenarios, and at the same time presets degradation logic to ensure rapid response when risks occur, thereby improving the practicality and operability of risk prediction.

[0093] In some embodiments, the risk analysis results are presented in the form of a risk call chain graph, which identifies the target service as the risk source, the specific call parameter characteristics that induce the risk, and the affected upstream caller paths, including direct caller paths and indirect caller paths.

[0094] Specifically, the aforementioned risk call chain information, risk scenarios, and affected upstream caller identifiers are presented in the form of a risk call chain graph. This graph clearly identifies the target service as the source of the risk, namely the new version of the inventory service; the specific call parameter characteristics that trigger the risk, such as the hot product ID and batch deduction quantity > 100 items; and the affected upstream caller paths.

[0095] The direct caller path is, for example, "Inventory Service → Product Details Page Service" or "Inventory Service → Order Placement Service", while the indirect caller path is, for example, "Inventory Service → Product Details Page Service → User Front-End Page" or "Inventory Service → Order Placement Service", which can fully present the risk propagation path.

[0096] This embodiment uses a visualized risk call chain diagram to clearly and intuitively present the risk distribution and propagation path, making it easy for deployment personnel to quickly grasp the key risks and providing clear guidance for the formulation of subsequent risk immunity deployment strategies, thereby improving deployment efficiency and accuracy.

[0097] Step S4: Based on the risk analysis results, implement a risk immunity deployment strategy for the target service after the code change.

[0098] The purpose of this step is to take proactive protective measures based on the risk analysis results predicted in the previous step, isolate risks during deployment, prevent the spread of faults in advance, avoid affecting user experience and normal business operation when risk scenarios actually occur, realize a closed loop from risk prediction to proactive protection, and solve the shortcomings of the existing canary release and circuit breaker mechanisms in passive response.

[0099] In some embodiments, the step of implementing a risk immunity deployment strategy for the target service after code modification based on the risk analysis results includes: issuing fine-grained routing rules to the gateway based on the risk scenarios marked in the risk analysis results; the fine-grained routing rules are used to redirect request traffic that does not trigger the risk scenario to the new version instance of the target service, and to retain request traffic that triggers the risk scenario for processing by the old version instance of the target service.

[0100] Specifically, based on the risk scenarios marked in the risk analysis results, fine-grained routing rules are issued through the gateway's routing configuration module. The gateway can be an existing system such as Nginx or Kong. These rules can isolate traffic between risky and non-risky scenarios, directing request traffic that does not trigger risky scenarios to a new version instance of the inventory service, thereby verifying the stability of the new version under security conditions.

[0101] The request traffic that does not trigger risk scenarios may include long-tail product inventory queries, single-item inventory deductions, etc., while the request traffic that triggers risk scenarios may include hot-selling product inventory queries, batch deduction of inventory > 100 items, etc. The latter will be handled by the old version instance of the inventory service to avoid premature exposure of risk scenarios.

[0102] This embodiment achieves precise isolation between risky and safe traffic through scenario-based canary rollout, ensuring normal business operation while verifying the stability of the new version service and reducing deployment risks.

[0103] In some embodiments, the step of implementing a risk immunity deployment strategy for the target service after code modification based on the risk analysis results includes: issuing adjusted circuit breaker rules and rate limiting rules to the service mesh proxy where the affected upstream caller is located, based on the affected upstream caller identifier marked in the risk analysis results; wherein the adjusted circuit breaker rules and rate limiting rules have lower trigger thresholds than the regular rules based on the call tolerance configuration information, and are used to prevent the spread of faults in advance when the risk scenario is triggered.

[0104] Specifically, based on the affected upstream caller identifiers marked in the risk analysis results, the adjusted circuit breaker and rate limiting rules are issued to the service mesh proxy where the affected upstream caller resides through the service mesh's policy management module. The affected upstream caller can be a product details page service or an order placement service, and the service mesh proxy can be a Sidecar proxy.

[0105] For example, for the product details page service, the circuit breaker threshold for its call to the inventory service has been adjusted from an error rate of 5% to 3%, and the timeout threshold has been adjusted from 30ms to 40ms. This adjustment adapts to the new version's characteristic of a 50ms response time for hot queries, while also enabling early triggering of the circuit breaker. For the order placement service, the rate limiting rule for its call to the inventory service has been adjusted from 1000 QPS to 800 QPS to prevent the concurrency in batch deduction scenarios from reaching the risk threshold.

[0106] This embodiment achieves early risk protection by dynamically adjusting the circuit breaker and current limiting rules, which can promptly block the spread of faults and reduce the scope of fault impact in the early stages of risk scenarios.

[0107] In some embodiments, the step of implementing a risk immunity deployment strategy for the target service after code modification based on the risk analysis results further includes: continuously monitoring whether the risk scenarios marked in the risk analysis results actually occur during the deployment of the target service; when the risk scenario actually occurs, broadcasting a risk warning signal to the affected upstream callers through the service mesh; and triggering the affected upstream callers to perform local degradation according to preset local degradation logic, wherein the preset local degradation logic is pre-configured for the affected upstream callers during the matching analysis phase.

[0108] Specifically, during the rollout of a new version of the inventory service, a full-link monitoring system continuously monitors whether the risk scenarios marked in the risk analysis results actually occur. This full-link monitoring system can be SkyWalking, Zipkin, or similar providers, and collects real-time data on the response time, error rate, resource consumption, and call status of affected upstream callers for the new version of the inventory service.

[0109] When a risk scenario is detected to actually occur, such as a response time exceeding 40ms for a product details page service call to a new version of the inventory service, with an error rate reaching 3%, a risk warning signal is broadcast to the affected upstream callers via the service mesh. Upon receiving the warning signal, the affected upstream callers immediately trigger the pre-set local degradation logic during the matching analysis phase.

[0110] For example, the product details page service displays locally cached inventory data, and the order placement service triggers an order pausing mechanism to prevent risks from escalating.

[0111] This embodiment enables rapid response and proactive degradation when risks occur, and can proactively cut off the path of fault propagation, preventing risks from spreading along the call chain to more services, thereby further improving the security and stability of the deployment.

[0112] In some embodiments, the method further includes a closed-loop optimization step: after the new version of the target service is launched and runs stably, collect real production environment monitoring data; feed the real production environment monitoring data back to the continuous integration system to calibrate the simulation stress test model.

[0113] The purpose of this step is to calibrate the simulation stress test model using real-world operational data from the production environment, optimize the deployment process for subsequent version iterations, continuously improve the accuracy of risk prediction and the effectiveness of risk immunity deployment, form a complete closed loop of "deployment → monitoring → calibration → optimization", and further enhance the stability and reliability of e-commerce platform service deployment.

[0114] Specifically, once the new version of the inventory service is launched and running stably, it can be defined as running continuously for 72 hours under no-risk scenarios, with response time and error rate meeting preset standards. The system collects operational data of this new version in a real production environment through a full-link monitoring system and production environment monitoring tools. Existing tools such as Prometheus can be used for this production environment monitoring.

[0115] The collected data includes actual response time distribution, resource consumption, error triggering, and the call status of upstream callers. The collected real-world production environment monitoring data is fed back to the continuous integration system to calibrate the simulation load testing model. This includes adjusting the concurrent stress model and call parameter distribution ratio in the simulation load testing, and optimizing the logic for extracting dynamic call feature information, so that subsequent versions of the simulation load testing better reflect the real-world production environment.

[0116] This embodiment forms a complete closed-loop optimization mechanism, which can continuously optimize the accuracy of simulation stress testing and risk prediction, adapt to the dynamic changes of e-commerce business, and improve the long-term applicability of the method.

[0117] like Figure 2 As shown, one embodiment of this application also provides an automated deployment system for e-commerce platform services based on continuous integration, the system comprising:

[0118] The historical data acquisition module is used to acquire historical call pattern data of the target service being called by upstream callers within a historical time period in response to code changes of the target service;

[0119] The simulation load testing module is used to perform simulation load testing on the target service after code changes based on the historical call pattern data, and obtain the dynamic call feature information of the target service under the historical call pattern data.

[0120] The risk prediction module is used to match and analyze the dynamic call feature information with the call tolerance configuration information pre-configured by each upstream caller, predict the risk impact on each upstream caller after the target service after the code change goes online, and generate risk analysis results including risk scenarios and the identifiers of affected upstream callers.

[0121] The immune deployment module is used to execute a risk immune deployment strategy on the target service after the code change based on the risk analysis results.

[0122] Each module in the above system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0123] In summary, this application provides an automated deployment method and system for e-commerce platform services based on continuous integration. By introducing historical call pattern data during the continuous integration phase and performing simulation stress testing on the target service after code changes, it is possible to predict the potential risk impact on upstream callers before the service goes live. The generated dynamic call characteristic information includes fine-grained data such as response time distribution and abnormal conditions. Matching and analyzing this information with the pre-configured call tolerance information of upstream callers can accurately identify specific risk scenarios and affected upstream callers. Based on the risk analysis results, a risk immunity deployment strategy is executed, enabling the deployment process to proactively avoid or isolate known risks, achieving pre-emptive risk intervention. Through the deep integration of continuous integration and continuous deployment, a complete link from code analysis to deployment prevention and control is established, effectively preventing the spread of faults caused by underlying service updates upstream and ensuring the reliability of the e-commerce platform call chain.

[0124] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and substitutions can be made without departing from the technical principles of this application, and these improvements and substitutions should also be considered within the scope of protection of this application.

Claims

1. A method for automated deployment of e-commerce platform services based on continuous integration, characterized in that, The method includes: In response to code changes to the target service, obtain historical call pattern data of the target service being called by upstream callers within a historical time period; Based on the historical call pattern data, simulation stress test is performed on the target service after code modification to obtain the dynamic call feature information of the target service under the historical call pattern data. The dynamic call feature information is matched and analyzed with the call tolerance configuration information pre-configured by each upstream caller to predict the risk impact on each upstream caller after the target service after the code change goes online, and generate risk analysis results including risk scenarios and the identifiers of affected upstream callers. Based on the risk analysis results, a risk immunity deployment strategy is implemented for the target service after the code change.

2. The automated deployment method for e-commerce platform services based on continuous integration according to claim 1, characterized in that, The step of obtaining historical call pattern data of the target service being called by upstream callers within a historical time period includes: Obtain the call logs of the target service within a preset historical window period; The call logs are parsed to extract the identity identifiers of each upstream caller, the distribution characteristics of call parameters, and the time-related concurrency pressure model.

3. The automated deployment method for e-commerce platform services based on continuous integration according to claim 1, characterized in that, The dynamic call feature information includes: the resource consumption curve of the target service under different concurrency pressures, the response time distribution information for different call parameter types, and the condition parameter information that induces runtime exceptions.

4. The automated deployment method for e-commerce platform services based on continuous integration according to claim 3, characterized in that, The call tolerance configuration information includes a call tolerance threshold and a degradation strategy. The call tolerance threshold includes a timeout threshold and a circuit breaker threshold. The step of matching and analyzing the dynamic call feature information with the call tolerance configuration information pre-configured by each upstream caller includes: Obtain the pre-configured timeout threshold, circuit breaker threshold, and degradation strategy of each upstream caller; Based on the response time distribution information and the timeout threshold, identify the first type of risk scenario where the upstream caller's timeout protection mechanism may be triggered due to response time timeout after the target service goes online; Based on the abnormal condition parameter information and the circuit breaker threshold, identify a second type of risk scenario where the upstream caller's circuit breaker protection mechanism may be triggered due to an excessive error rate after the target service goes online; Associate the first type of risk scenario and the second type of risk scenario with the corresponding affected upstream caller identifier to generate risk call chain information; According to the degradation strategy, local degradation logic is preset for the affected upstream callers when the first type of risk scenario and the second type of risk scenario actually occur.

5. The automated deployment method for e-commerce platform services based on continuous integration according to claim 1, characterized in that, The step of implementing a risk immunity deployment strategy for the target service after the code change based on the risk analysis results includes: Based on the risk scenarios marked in the risk analysis results, fine-grained routing rules are issued to the gateway; the fine-grained routing rules are used to redirect request traffic that does not trigger the risk scenario to the new version instance of the target service, and to retain request traffic that triggers the risk scenario for processing by the old version instance of the target service.

6. The automated deployment method for e-commerce platform services based on continuous integration according to claim 1, characterized in that, The step of implementing a risk immunity deployment strategy for the target service after the code change based on the risk analysis results includes: Based on the affected upstream caller identifiers marked in the risk analysis results, adjusted circuit breaker rules and rate limiting rules are issued to the service mesh proxy where the affected upstream caller resides. The adjusted circuit breaker rules and rate limiting rules have lower trigger thresholds than the regular rules based on the call tolerance configuration information, which are used to prevent the spread of faults in advance when the risk scenario is triggered.

7. The automated deployment method for e-commerce platform services based on continuous integration according to claim 1, characterized in that, The step of implementing a risk immunity deployment strategy for the target service after the code change based on the risk analysis results further includes: During the deployment of the target service, continuously monitor whether the risk scenarios marked in the risk analysis results actually occur; When the aforementioned risk scenario actually occurs, a risk warning signal is broadcast to the affected upstream callers through the service mesh; According to the preset local degradation logic, the affected upstream caller is triggered to perform local degradation. The preset local degradation logic is pre-configured for the affected upstream caller during the matching analysis phase.

8. The automated deployment method for e-commerce platform services based on continuous integration according to claim 1, characterized in that, The method further includes: After the new version of the target service is launched and running stably, collect real production environment monitoring data; The real production environment monitoring data is fed back to the continuous integration system to calibrate the simulation stress test model.

9. The automated deployment method for e-commerce platform services based on continuous integration according to claim 1, characterized in that, The risk analysis results are presented in the form of a risk call chain graph, which identifies the target service as the risk source, the specific call parameter characteristics that induce the risk, and the affected upstream caller paths, including direct caller paths and indirect caller paths.

10. An automated deployment system for e-commerce platform services based on continuous integration, characterized in that, The system includes: The historical data acquisition module is used to acquire historical call pattern data of the target service being called by upstream callers within a historical time period in response to code changes of the target service; The simulation load testing module is used to perform simulation load testing on the target service after code changes based on the historical call pattern data, and obtain the dynamic call feature information of the target service under the historical call pattern data. The risk prediction module is used to match and analyze the dynamic call feature information with the call tolerance configuration information pre-configured by each upstream caller, predict the risk impact on each upstream caller after the target service after the code change goes online, and generate risk analysis results including risk scenarios and the identifiers of affected upstream callers. The immune deployment module is used to execute a risk immune deployment strategy on the target service after the code change based on the risk analysis results.

Images