Method and system for dynamically upgrading service module of tuberculosis networking platform

Abstract

The invention discloses a method and a system for dynamically upgrading a service module of a tuberculosis networking platform, and relates to the technical field of public health prevention and control platforms, and the method comprises the following steps: collecting operation indexes such as access volume, response time, CPU / memory utilization rate and the like, and service characteristics such as service importance, upgrading complexity and the like; external risk factors are extracted in combination with a public health prevention and control knowledge base, and a multi-dimensional risk assessment system is established; abstracting the dependency relationship of the service modules into a directed acyclic graph, and constructing a cross-module version compatible matrix; and predicting a future time window access load based on historical data, taking the future time window access load, a risk assessment result and platform resource constraints as input together, and generating a module upgrading plan containing an upgrading time window and a target version number through constraint optimization, thereby smoothly completing upgrading. Therefore, the security, the real-time performance and the controllability of the upgrading process of the public health informatization system are realized.

Description

Technical Field

[0001] This application relates to the field of public health prevention and control platform technology, and in particular to a method and system for dynamically upgrading business modules of a tuberculosis network platform. Background Technology

[0002] Tuberculosis (TB) is a chronic infectious disease caused by Mycobacterium tuberculosis. With the development of the "Internet + Public Health" model, disease control institutions at all levels have gradually built TB prevention and control information management platforms. These platforms, through their business modules, enable functions such as patient discovery, diagnosis and treatment, follow-up management, drug supply, and data reporting, providing decision-making support for government departments in formulating prevention and control strategies. To adapt to the expansion of services and policy changes, these functional modules need continuous upgrades, such as adding artificial intelligence diagnostic modules, optimizing patient follow-up processes, and integrating new case reporting standards. Ensuring that these module upgrades do not affect the platform's real-time operation is a crucial issue facing public health informatization.

[0003] In recent years, microservice architecture has been widely used in public health information systems. For example, the Shandong Province Tuberculosis Prevention and Control Integrated Management Smart Platform is built using a microservice architecture, integrating artificial intelligence and big data analysis. This enables it to strengthen the dissemination of tuberculosis prevention and control knowledge, improve patient detection rates, and enhance diagnostic efficiency. By partitioning physical computing, storage, and network resources, the platform uses a cloud architecture to support customers accessing services from any location using their terminals. It features high performance, lightweight design, concurrent programming models, cross-platform compatibility, and integration with containerization technologies.

[0004] However, most current systems focus on modular deployment and static service decomposition, and dynamic upgrades of business modules still rely on manual release or scheduled downtime maintenance, which cannot be smoothly updated during peak business periods, and can easily lead to service interruptions, data inconsistencies or resource waste. Summary of the Invention

[0005] This application provides a method, system, storage medium, computer program product, and electronic device for dynamically upgrading business modules of a tuberculosis network platform, which at least solves the problem that large-scale public health information systems in the current related technologies have difficulty in balancing business continuity and rapid evolution under frequent policy changes and load uncertainties.

[0006] In a first aspect, embodiments of this application provide a method for dynamically upgrading business modules of a tuberculosis network platform. The method includes: acquiring operational metrics and business characteristics of each business module in the tuberculosis network platform; the operational metrics include access volume, response time, CPU utilization, and memory utilization, and the business characteristics include module business importance and module upgrade complexity; representing each business module and its calling relationships as a directed acyclic graph, and establishing a version compatibility matrix; the version compatibility matrix is ​​used to define the compatibility relationships between different versions of cross-business modules; for each business module within a future time window set, predicting the performance of the business module at various time points based on historical operational data. The system calculates the access load within the time window and extracts external public health risk factors from the public health prevention and control knowledge base. It then generates an upgrade risk index distribution corresponding to the time window set by combining the module upgrade complexity and module business importance of the business modules. The system obtains platform resource constraint information of the tuberculosis network platform and analyzes it in conjunction with the upgrade risk index distribution of each business module, the directed acyclic graph, and the version compatibility matrix to generate a business module upgrade plan. The business module upgrade plan includes the upgrade time window and target version number for each business module. Upgrades are then performed on each business module of the tuberculosis network platform according to the upgrade plan.

[0007] Secondly, embodiments of this application provide a dynamic upgrade system for business modules of a tuberculosis network platform. The system includes: a data acquisition unit, used to acquire operational metrics and business characteristics of each business module in the tuberculosis network platform; the operational metrics include access volume, response time, CPU utilization, and memory utilization, and the business characteristics include module business importance and module upgrade complexity; a dependency constraint modeling unit, used to represent each business module and its calling relationships as a directed acyclic graph and establish a version compatibility matrix; the version compatibility matrix is ​​used to define the compatibility relationships between different versions of cross-business modules; and a risk window distribution assessment unit, used to predict the business performance of each business module within a future time window set based on historical operational data. The system analyzes the access load of modules within each time window and extracts external public health risk factors from the public health prevention and control knowledge base. It then combines the module upgrade complexity and business importance of each business module to generate an upgrade risk index distribution corresponding to the time window set. An upgrade plan generation unit acquires platform resource constraint information from the tuberculosis network platform and analyzes it in conjunction with the upgrade risk index distribution of each business module, the directed acyclic graph, and the version compatibility matrix to generate a business module upgrade plan. The business module upgrade plan includes the upgrade time window and target version number for each business module. A module upgrade execution unit performs upgrade processing on each business module of the tuberculosis network platform according to the business module upgrade plan.

[0008] Thirdly, an electronic device is provided, comprising: at least one processor, and a memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the steps of the dynamic upgrade method for the service modules of the tuberculosis network platform according to any embodiment of this application.

[0009] Fourthly, embodiments of this application provide a storage medium storing a computer program thereon, characterized in that, when the program is executed by a processor, it implements the steps of the dynamic upgrade method for the business modules of the tuberculosis network platform according to any embodiment of this application.

[0010] Fifthly, embodiments of this application provide a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the dynamic upgrade method for the business modules of the tuberculosis network platform according to any embodiment of this application.

[0011] The method and system for dynamically upgrading business modules of a tuberculosis network platform provided in this application can achieve at least the following technical effects:

[0012] (1) By collecting the operational indicators and business characteristics of each business module and introducing external public health risk factors, the access load in the future time window is predicted, and then the upgrade risk index distribution is generated, realizing the scientific assessment and forward-looking selection of the upgrade timing, thereby completing the dynamic iteration of business functions while ensuring the stability of the platform.

[0013] (2) By constructing business modules and their calling relationships into a directed acyclic graph and defining the coexistence relationship between different versions in combination with the version compatibility matrix, the correctness of dependency chain calls and data consistency can be ensured during the upgrade process. At the same time, it supports the parallel deployment of multiple versions, thereby realizing smooth upgrade methods such as canary release and blue-green switching, and reducing the risk of business interruption during the upgrade process.

[0014] (3) During the upgrade plan generation process, a comprehensive analysis of platform resource constraints, upgrade risk index, dependencies, and compatibility is conducted. This can avoid performance fluctuations caused by concentrated upgrades of high-resource-consuming modules and rationally arrange modules that can be upgraded in parallel, thereby improving resource utilization and overall upgrade efficiency. In addition, the plan can be adjusted according to dynamic changes in operating indicators or risk factors to prioritize the stable operation of critical business modules in case of emergencies.

[0015] This technical solution, through an upgrade decision-making mechanism driven by operational indicators and risk, combined with dependency and version compatibility control, achieves a dynamic upgrade method for business modules that significantly improves business continuity, data consistency, and resource utilization efficiency. It effectively supports the safe, stable, and efficient operation of the public health information platform during policy adjustments and business expansion. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating an example of a method for dynamically upgrading service modules of a tuberculosis network platform according to an embodiment of this application is shown.

[0018] Figure 2 It shows that according to Figure 1 An example operation flowchart of step S120 in the process;

[0019] Figure 3 It shows that according to Figure 1 An example operation flowchart of step S140 in the process;

[0020] Figure 4 A schematic diagram showing a comparison of system downtime between the baseline upgrade method and the dynamic upgrade method proposed in this paper is presented.

[0021] Figure 5 The example shown is a heatmap of the upgrade risk index for a business module under different time windows;

[0022] Figure 6 This diagram illustrates an example of the comparison between the upgrade success rates of the baseline method and the dynamic upgrade method.

[0023] Figure 7 A structural block diagram of an example of a dynamic upgrade system for business modules of a tuberculosis network platform according to an embodiment of this application is shown. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of 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 embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] It should be noted that, among the current related technologies, some experts and scholars have proposed some novel technical directions for the information management of public health prevention and control platforms.

[0026] On the one hand, there's the application of microservice architecture in the tuberculosis platform. The Shandong Provincial Intelligent Tuberculosis Management Platform utilizes microservice architecture to achieve lightweight deployment of its functional modules. The platform's overall logical architecture breaks down sub-platforms such as patient discovery, diagnosis and treatment, management, and comprehensive office functions into independent microservices. Through containerized deployment and cloud scheduling, the platform achieves high availability for cross-regional access and services. Simultaneously, the platform integrates artificial intelligence and big data analytics to improve the detection rate and diagnostic efficiency of tuberculosis patients. However, module updates are generally performed manually or through scheduled maintenance windows, without considering actual business load and public health event dynamics, potentially leading to service interruptions during peak periods. Furthermore, the platform fails to quantitatively assess the business risks of different modules when deploying new modules. For example, the patient discovery module and the backend reporting module have different importance, yet the upgrade strategy is uniform, lacking differentiated processing. In addition, data synchronization between microservices relies on a unified data layer, potentially leading to data inconsistencies or old data migration issues during upgrades, and a lack of parallel verification mechanisms.

[0027] On the other hand, there is the infectious disease reporting model based on direct push from electronic medical records (EMRs). The Shanghai Infectious Disease Reporting Management System, through analysis of the current status of existing reporting systems, proposed a reporting management model based on direct push from electronic medical records (EMRs), breaking the traditional manual reporting model and achieving data sharing across regional information platforms. This model improves information reporting efficiency and supports early warning of public health emergencies. However, electronic medical record systems suffer from high heterogeneity; EMR interfaces differ between hospitals, requiring platform upgrades to be adapted individually, lacking a universal method for cross-system upgrades. Furthermore, although data transmission is triggered by EMRs, upgrades to business modules still require manual intervention from administrators, such as updating data parsing modules and interface mappings, lacking automated scheduling. When a public health emergency occurs, new monitoring modules need to be quickly deployed, but the current system cannot automatically activate or upgrade corresponding modules based on public health emergency warnings, resulting in a delayed system response.

[0028] In the fields of cloud computing and microservices, algorithms for service resource scheduling are constantly emerging. For example, by using similar solutions to existing problems as an initial population, historical knowledge and similarity can be leveraged to accelerate scheduling, thereby quickly finding feasible scheduling schemes and optimizing resource utilization and system stability under given time constraints. However, existing research mainly focuses on the scheduling of computing resources and service instances, lacking module upgrade scheduling algorithms for specific public health business scenarios. In particular, it does not consider the impact of public health events on upgrade timing, the processing of sensitive data, and business continuity requirements. Simply relying on system load scheduling cannot meet the business needs of public health management platforms.

[0029] It should be noted that common online upgrade strategies in software engineering include blue-green deployment, canary releases, and hot patching. These are mostly used in internet or enterprise applications and are characterized by running the old and new versions of services in parallel, gradually switching through traffic control. Although some public health information systems have also begun to adopt blue-green deployment, traditional blue-green deployment releases at predetermined times, without considering the impact on data traffic during peak disease seasons or policy release periods. Scheduled tasks or manual decisions by administrators are prone to conflict with public health emergencies and lack intelligent selection based on risk assessment. In addition, public health business modules are often updated promptly according to national policies and local documents, while traditional strategies do not integrate policy knowledge bases, making timely responses difficult.

[0030] In summary, in the current construction of public health information systems, the tuberculosis network platform has achieved modular deployment through microservices, but the dynamic upgrade of business modules remains static or semi-automated. The infectious disease direct reporting system and intelligent platform have made progress in data sharing and early warning, but lack a unified strategy for module upgrades. The existing dynamic scheduling algorithms focus on computing resource management and are difficult to apply directly to the upgrade of public health business modules, thus failing to meet the business needs of the tuberculosis network platform.

[0031] It should be understood that the above description of the relevant technologies is intended only to help the public better understand the inventive spirit and motivation of this application, and is not intended to limit this application. Furthermore, the technical solutions described in the above-mentioned relevant technologies are not prior art, and may also be undisclosed technical solutions, such as those under research or in the laboratory stage.

[0032] The technical solutions in this application, including the collection, storage, use, processing, transmission, provision, and disclosure of users' personal information, comply with relevant laws and regulations and do not violate public order and good morals.

[0033] Figure 1 A flowchart illustrating an example of a method for dynamically upgrading service modules of a tuberculosis network platform according to an embodiment of this application is shown.

[0034] Regarding the execution entity of the method in this application embodiment, it can be any controller or processor with computing or processing capabilities, such as a platform module upgrade management processor. This processor collects real-time data on tuberculosis prevention and control operations, module dependencies, and external public health risk information. Based on risk index calculation and load prediction models, it generates an optimal upgrade plan and utilizes a parallel dual-state deployment mechanism to perform module version switching and consistency checks. This allows for smooth module upgrades and risk-controlled dynamic adjustments without interrupting core business operations. In some examples, it can be integrated into electronic devices or terminals through software, hardware, or a combination of both, and the types of terminals or electronic devices can be diverse.

[0035] like Figure 1 As shown, in step S110, the operating indicators and business characteristics of each business module in the tuberculosis network platform are obtained.

[0036] In the daily operation of the tuberculosis network platform, business modules cover patient discovery, diagnosis and treatment, follow-up management, drug supply, and data reporting. Real-time or periodic data collection can be performed on each business module. Operational metrics reflect the module's load and performance at different times, including access volume (number of requests per unit of time), response time (time from request to result return), CPU utilization, and memory utilization (reflecting the module's usage of server resources). Business characteristics describe the module's importance and upgrade difficulty from a business perspective. Module importance can be assessed based on its core role in the prevention and control process and its data flow location, while module upgrade complexity can be calculated comprehensively based on factors such as the scope of code changes, database structure adjustments, and changes in dependencies.

[0037] In some implementations, operational metrics can be collected in real time through a service monitoring system (such as Prometheus) and historical data can be aggregated and stored to form a time-series dataset. The importance of modules can be weighted by public health experts or system architects; for example, the patient discovery module might be considered more important than the health education module. Module upgrade complexity can be automatically calculated by combining commit records from a code version control system (such as Git), database schema change logs, and unit test coverage assessment tools.

[0038] Regarding the acquisition of business characteristics, in some examples of embodiments of this application, an expert evaluation table is queried based on the module identifier of each business module to determine the corresponding module business importance. The expert evaluation table contains multiple business module identifiers and corresponding importance expert evaluation results. Then, the upgrade package file corresponding to each business module is parsed to determine the upgrade code change amount, database structure change score, and interface change score corresponding to each business module, and the corresponding module upgrade complexity is obtained through weighted fusion calculation.

[0039] This approach introduces a dual-channel quantitative method based on expert evaluation forms and upgrade package analysis. The expert evaluation forms solidify the long-term experience-based judgments of public health experts and system architects regarding the importance of each business module, avoiding reliance solely on system operational data. Additionally, the upgrade package analysis addresses the technical changes required for the current version upgrade, accurately assessing the technical investment and potential risks associated with its implementation.

[0040] Specifically, the system obtains the identifiers of the target upgrade business modules, such as "TB-Patient-Discovery" (patient discovery module) and "TB-Drug-Supply" (drug supply module). It then queries the expert evaluation table for records of the corresponding module identifiers. The table stores pre-set importance levels or scores (e.g., a scale of 1 to 10). These scores are determined by public health experts, platform maintenance personnel, and data analysts after comprehensively considering factors such as the module's impact on diagnosis rates, treatment adherence, and public health decision-making.

[0041] To determine the complexity of module upgrades, the process begins by parsing the upgrade package files (e.g., JAR files, Docker images, ZIP source code packages) for each business module to extract the changed content. Then, the number of newly added, modified, and deleted lines of code is counted (using Git diff or code analysis tools), and categorized according to the functional scope affected by the changes. Database migration scripts (e.g., Liquibase, Flyway scripts) involved in the upgrade package are analyzed, and scored based on the number and importance of added / modified / deleted fields, index changes, and table structure adjustments. API documentation (Swagger, OpenAPI definitions) in the upgrade package undergoes version comparison to identify the number and impact of newly added, modified, and deprecated interfaces, and scores them according to business sensitivity. Finally, the scores for code changes, database structure changes, and interface changes are weighted according to preset weights to obtain the module upgrade complexity score. For example, the weight for database structure changes can be higher than that for code changes to reflect their higher potential upgrade risk.

[0042] In step S120, each business module and its calling relationship are represented as a directed acyclic graph, and a version compatibility matrix is ​​established.

[0043] It should be noted that the various business modules in the tuberculosis network platform do not operate independently, but rather have complex calling relationships. For example, the diagnosis module may call data from the patient record module, and the drug supply module may depend on the output of the diagnosis result module. Abstracting these dependencies into a Directed Acyclic Graph (DAG) clearly represents the calling order and dependency direction, thus avoiding circular dependencies or broken call chains during upgrades. Simultaneously, a version compatibility matrix is ​​established, using a two-dimensional table to define whether different business modules can coexist in parallel within the same upgrade time window and their respective selected target versions (i.e., cross-module, cross-version parallel runnability / call availability).

[0044] In some implementations, DAG modeling can be automatically generated based on module API call logs and interface documentation, and updated and verified before each version iteration. Furthermore, the version compatibility matrix can be maintained by the system development team or determined based on historical interface definition version comparisons, data format validation, and simulated call tests to assess the compatibility of different version combinations. This matrix defines the compatibility relationships between different versions across business modules. For example, each cell in the matrix records the compatibility status (fully compatible, partially compatible requiring adaptation, incompatible) between "version X of module A" and "version Y of module B," thus providing a basis for deployment strategies such as upgrade order and parallelism.

[0045] By using DAG constraint design, the switching order of modules can be arranged in an orderly manner during the upgrade process, avoiding business logic errors caused by the interruption of the dependency chain. In addition, through compatibility matrix control, the compatibility between different versions of different modules is clearly defined, allowing more modules to be upgraded in parallel without breaking the dependency chain, thus shortening the overall upgrade time.

[0046] In step S130, for each business module, the access load of the business module in each time window is predicted based on historical operation data within the future time window set. External public health risk factors are extracted from the public health prevention and control knowledge base. The upgrade risk index distribution of the corresponding time window set is generated by combining the module upgrade complexity and module business importance of the business module.

[0047] It should be noted that the risks of module upgrades are not only related to the current operational status but also closely related to potential future business fluctuations. For example, platform traffic will increase significantly during peak tuberculosis seasons, school enrollment physical examination periods, or policy data reporting deadlines. To implement upgrades at the optimal time, the access load for each future time window can be predicted, and combined with external risk factors and the importance and complexity of the module itself, a quantifiable upgrade risk index distribution can be formed.

[0048] In some implementations, historical load forecasting can be performed using time series models (such as ARIMA) or machine learning methods (such as LSTM neural networks). The forecast granularity can be refined to the daily or weekly level and can be adjusted according to system configuration or business needs. External risk factors can be derived from a public health prevention and control knowledge base, such as recent reports of major public health emergencies, screening plans for key populations, and policy adjustment announcements, and converted into quantitative weights through function processing. Furthermore, the escalation risk index can be calculated by weighting the forecast load weight, business importance weight, escalation complexity weight, and external risk factor weights, forming a distribution curve across different time windows.

[0049] This allows for a quantitative assessment of the upgrade risks of each business module at different time windows, enabling the selection of upgrade timing to no longer rely on manual experience, but to accurately locate low-risk windows through a data-driven approach, thereby minimizing the impact on business continuity.

[0050] In step S140, the platform resource constraint information of the tuberculosis network platform is obtained, and the upgrade risk index distribution, directed acyclic graph and version compatibility matrix of each business module are analyzed to generate a business module upgrade plan.

[0051] Here, platform resource constraint information can include various metrics describing the resource status of the tuberculosis network platform, such as available CPU, memory, network bandwidth, and container orchestration resource limits. After obtaining the resource constraint information, the resource status can be combined with risk index distribution, dependencies, and compatibility matrices to generate a comprehensive upgrade plan. Thus, while meeting resource constraints, the overall upgrade process is minimized in time and risk, while ensuring the consistency of the upgrade order and dependency chain for critical modules.

[0052] In some implementations, various constraint optimization algorithms can be used to generate the upgrade plan, such as scheduling models based on Integer Linear Programming (ILP) or genetic algorithms. The objective function can simultaneously consider minimizing risk and maximizing resource utilization. The upgrade plan output is a structured table of "module identifier - target version number - upgrade time window" with priority markers. Furthermore, modules that can be upgraded in parallel can be scheduled to perform upgrades within the same time window to shorten the overall upgrade cycle; while high-risk modules will be assigned to low-load windows.

[0053] This ensures that upgrade tasks are executed in an orderly manner within the limits of available resources, avoids performance fluctuations caused by resource contention, and improves the overall efficiency and security of system upgrades, thereby achieving controllability and optimization of the multi-module upgrade process.

[0054] In step S150, upgrade processes are performed on each business module of the tuberculosis network platform in accordance with the business module upgrade plan.

[0055] Specifically, in accordance with the business module upgrade plan, the upgrade package files of each business module to be upgraded are sent to the tuberculosis network platform within the corresponding time window, thereby realizing the upgrade of the business modules.

[0056] In some implementations, maintaining business availability during the upgrade process and supporting rapid rollback in the event of anomalies can be driven by an automated operations and maintenance platform (such as Kubernetes + Jenkins Pipeline), encompassing code building, image deployment, container scheduling, and traffic switching. This achieves a smooth transition during the upgrade process, ensuring the tuberculosis network platform can continuously provide stable services for public health prevention and control during the upgrade.

[0057] Figure 2 It shows that according to Figure 1 An example operation flowchart of step S120 in the process.

[0058] like Figure 2 As shown, in step S210, the dependency strength is calculated for any ordered module pair (m,n) based on the interface gateway call log, database access audit record and message bus subscription and publication record.

[0059] In the tuberculosis network platform, interactions between different business modules include not only direct API calls but also database data sharing or message queue subscriptions. For example, the "patient discovery module" may frequently call the interface of the "laboratory testing module" or receive laboratory test result events through a message queue. To accurately characterize the strength of these dependencies, the following dependency strength calculation formula can be used:

[0060] s m→n =αf call (m→n)+βf data (m,n)+γf event (m,n), Equation (1)

[0061] In the formula, f call (m→n) is the normalized value of the frequency of calls from n to m per unit time; f data (m,n) represents the data coupling strength between business modules m and n on the database schema object; f event (m,n) represents the publish / subscribe coupling strength of business modules m and n on the message topic; α,β,γ∈[0,1], and α+β+γ=1 represents the channel weight.

[0062] Here, α, β, and γ can be adjusted according to platform characteristics or business needs. For example, in modules where real-time data synchronization is frequent, the data dependency weight β can be increased.

[0063] In some implementations, access logs from API gateways and service registries are used to count the number of requests from module m to module n within a given period, normalized to the range of 0 to 1. Regarding data dependencies, database audit logs are analyzed to detect the frequency of cross-module access to the same data table or field, and weights are calculated based on the data table's sensitivity and update frequency. Then, message queue (such as Kafka, RabbitMQ) topic publish / subscribe records are analyzed to count the frequency of event interactions between modules, and weights are applied considering the business importance of message types.

[0064] In step S220, when the dependency strength exceeds the edge-forming threshold, the corresponding directed edges are constructed to generate a weighted directed graph. The weighted directed graph is then decomposed into strongly connected components, and each strongly connected component is aggregated into a super node to obtain a directed acyclic graph.

[0065] Specifically, when s m→n When ≥θ, construct the corresponding directed edge e. m→n A weighted directed graph is generated, with θ as the edge-forming threshold. After the dependency strength is calculated, module pairs with strength values ​​exceeding the threshold θ need to be connected as directed edges to form the dependency graph. Furthermore, to ensure the upgrade order can be resolved, this dependency graph must be acyclic; otherwise, the upgrade order cannot be determined. For example, if the generated dependency graph contains cycles, a strongly connected component decomposition algorithm is used to delete edges with lower dependency strengths within the cycle, ensuring the graph structure is a DAG. DAGs can be directly used to deduce the upgrade order, ensuring that the dependency chains are not closed loops, thus enabling the safe formulation of an upgrade plan based on topological sorting.

[0066] In step S230, based on the parsing results of the upgrade package file and the usage profile on the calling side, an interface compatibility submatrix and a database compatibility submatrix are constructed.

[0067] When dependencies exist between modules, upgrading a module to a new version requires verifying whether its interactions with other dependent modules remain compatible at the interface and database levels. Here, version compatibility is broken down into two sub-matrices: interface compatibility and database compatibility, and then combined to form the final version compatibility matrix.

[0068]

[0069]

[0070] Based on this, a version compatibility matrix is ​​synthesized:

[0071] Compat m,n (vi ,v j ) = A m,n (v i ,v j )∧D m,n (v i ,v j Equation (4)

[0072] In the formula, v i ,v j These represent the current version and target version of module m, respectively; U n→m For the actual interface and fields of n to m, R uses a profile. n←m For n pairs of read / write profiles of data fields managed by m; and These are the interface contract differences and database schema differences under profile constraints, respectively; ε api ,ε db This corresponds to the allowable threshold for differences; is an indicator function; ∧ is a logical AND.

[0073] Regarding equation (2), the module upgrade package is decompressed and statically analyzed to extract the new version's API definitions (such as Swagger / OpenAPI documentation) and database operation scripts. For the interface compatibility submatrix A... m,n Compare the differences between the old and new API contracts (parameter types, field names, return structures, etc.) to obtain the degree of difference. If the difference is less than the interface tolerance threshold ε api If the value is 1, the module is considered to be compatible with calls to dependent modules, and the matrix element value is 1; otherwise, it is 0.

[0074] Regarding the explanation of equation (3), analyze the changes to database read / write operations in the new version (adding / deleting fields, indexes, data type changes, etc.) and calculate the degree of difference. If the difference is less than the database tolerance threshold ε db If so, it is determined that the database access is compatible.

[0075] In the calculation of the final compatibility matrix provided by equation (4), only when both the interface and the database are compatible will the Compatibility matrix be calculated. m,n (v i ,v j The value is 1 only when the interface and database are both checked for compatibility. Therefore, the feasibility of cross-module version combinations can be accurately determined through dual-dimensional compatibility testing, supporting the parallel deployment of multiple version combinations during the upgrade process. This allows for early identification of potential incompatibility risks, thereby reducing the probability of business interruption during the upgrade process.

[0076] In this embodiment, the upgrade order is determined by the topology of the DAG, prioritizing strongly coupled links to avoid deployment deadlocks caused by circular dependencies. A compatibility matrix ensures that versions can coexist or be upgraded in parallel only when both interface and data access meet compatibility conditions; incompatibility triggers order adjustments to avoid parallel processing, reducing the probability of cross-module call failures and data inconsistencies. Because weakly coupled modules can be identified and processed in parallel, the overall upgrade cycle is compressed, while disturbances to critical links are minimized, making it easier to maintain stable response latency and failure rates during the upgrade process.

[0077] In some examples of embodiments of this application, the extraction of external public health risk factors includes:

[0078] Based on the public health prevention and control knowledge base, an external risk sequence is constructed within a time window set.

[0079] Specifically, the diagnosis, treatment, and prevention of tuberculosis are significantly influenced by the external public health situation. For example, an increase in the number of new cases, a escalating transmission trend, and tightening of government emergency control measures all directly affect the platform's access pressure and business priorities. Therefore, it is necessary to quantify the external situation into a calculable risk sequence E(t) as an important input for upgrading risk assessment.

[0080]

[0081] In the formula, t represents the index of the time window, and E(t) represents the comprehensive public health risk value outside the time window t. case (t) represents the number of newly added tuberculosis cases in the public health prevention and control knowledge base during time window t, k E (t) represents the slope of the trend in the number of cases, R P (t) represents the quantified value of policy urgency extracted from the public health prevention and control knowledge base within time window t. γ1, γ2, and γ3 represent the normalized value of the corresponding variable x; γ1, γ2, and γ3 are the weighting coefficients of the number of cases, trend slope, and policy urgency in the comprehensive calculation of external risks, respectively, satisfying γ1 + γ2 + γ3 = 1.

[0082] By closely integrating case numbers, trend changes, and policy adjustments, the platform can dynamically reflect the external public health situation in upgrade decisions, thereby avoiding triggering upgrade operations that may affect business continuity during high-risk periods.

[0083] For predicting access load, including:

[0084] A load forecasting model based on quantile regression is used to output load quantiles for each business module and each time window, and to calculate the predicted bandwidth.

[0085] Even if the external situational risks are low, a significant increase in platform access volume within a certain time window in the future can still put pressure on upgrades. Therefore, it is necessary to predict the access load of each business module at the time window granularity and calculate the range of uncertainty in the prediction (predicted bandwidth) to assess the risk of overload.

[0086] b m (t)=Q 0.9,m (t)-Q 0.1,m (t), Equation (6)

[0087] In the formula, Q p,m (t) represents the p-th quantile of the access load prediction value of service module m in time window t, where p∈{0.1,0.5,0.9} represent the low-order, middle-order, and high-order prediction values, respectively; b m (t) represents the predicted bandwidth of module m in time window t.

[0088] The quantile model can be adapted to the characteristics of different business modules. For example, the patient follow-up module may have periodic peaks, while the laboratory testing module may be affected by seasonal fluctuations. This allows the platform to not only focus on the average load, but also to quantify and predict uncertainty, thereby taking into account the possibility of extreme traffic shocks in risk calculation.

[0089] It should be noted that the external public health situation may bring the risk of sudden traffic surges, while the comparison between predicted bandwidth and safe load threshold can assess the probability of overload. Both of these risks need to be avoided during the upgrade.

[0090] Furthermore, the calculation of the upgrade risk index distribution includes:

[0091] Mapping external risk sequences to external shock risk rates:

[0092]

[0093] In the formula, λ0 is the baseline value of the external shock risk rate, representing the fixed hazard rate when there is no change in public health risk; λ E This is the coefficient representing the impact of the external public health risk value E(t) on the shock risk rate. Let m be the probability of external public health shock risk to module m within time window t;

[0094] Estimating the risk of overload based on quantile results and safe load threshold:

[0095]

[0096] In the formula, V safe (m) represents the safe load threshold of module m, ζ represents the value stability term against division by zero, and b maxη represents the maximum predicted bandwidth of all modules in historical data. b This represents the amplification factor of forecast uncertainty on load risk. This represents the probability of module m exceeding the load threshold during time window t;

[0097] clip(x,0,1) is a clipping function used to restrict the variable x to the range of 0 to 1.

[0098] Here, the difference between the predicted high quantile value and the module's safe load threshold is compared, and the probability of exceeding the limit is calculated based on the predicted bandwidth, maximum bandwidth, and amplification factor. The clip function is used to limit the result to the range [0,1] to avoid the risk of outlier amplification. By separating the calculations, the platform can distinguish between the impact risk caused by external conditions and the capacity risk caused by internal load instability.

[0099] By performing a non-linear mapping between module upgrade complexity and module business importance, the corresponding component risk probabilities are obtained:

[0100]

[0101] In the formula, U m and C m Let a0 and a1 represent the upgrade complexity and business importance of module m, respectively; a0 and a1 are the logical function bias and scaling factor used to map the normalized upgrade complexity to risk probability, respectively; c0 and c1 are the logical function bias and scaling factor used to map the normalized business importance to risk probability, respectively; σ(·) is the logical function, such as... Used to map input values ​​to the [0,1] interval as probabilities; Let m be the complexity risk probability of module m. Let m be the probability of business importance risk.

[0102] It should be noted that the upgrade complexity and business importance of a module directly affect the potential impact and recovery difficulty of the upgrade. Therefore, these two dimensions need to be mapped to probabilistic risk values. Specifically, through the non-linear mapping of σ(·), the platform can assign higher risk weights to modules with high complexity and high importance, avoiding the underestimation of upgrade risks when their risk values ​​are not significantly higher than the average level.

[0103] The upgrade risk index for each time window is obtained by aggregating data in a probabilistic concurrent manner.

[0104]

[0105] In the formula, R m (t) represents the comprehensive upgrade risk index of module m within the time window t;

[0106] For {Rm (t)} is time-series smoothed to suppress adjacent window jitter, resulting in the corresponding upgrade risk index distribution:

[0107]

[0108] In the formula, This represents the comprehensive upgrade risk index after time-series smoothing, used to reduce fluctuations between time windows; μ represents the smoothing weight coefficient, which preserves trend changes while suppressing abnormal spikes.

[0109] Here, to obtain a single, comparable upgrade risk indicator, the external shock risk rate, overload risk rate, complexity risk rate, and business importance risk rate are integrated into a comprehensive upgrade risk index. Smoothing is then applied to reduce the interference of temporary fluctuations on decision-making. Thus, the comprehensive upgrade risk index reflects the cumulative effect of multi-dimensional risk factors under a unified dimension, and the smoothing process ensures that the upgrade plan does not fluctuate frequently due to momentary anomalies, improving response stability.

[0110] Based on the above modeling, the system can quantitatively prioritize each module according to risk within future consecutive time windows during plan generation. When external conditions or predicted load indicate increased risk, the corresponding window is automatically avoided or downgraded. When complexity or business importance is high, the plan tends to adopt a more conservative release strategy and provide more sufficient resource guarantees. As a result, upgrades are less likely to be triggered during potential impact periods or near capacity limits, the stability of critical links is prioritized, and the scope of parallel upgrades is expanded under the premise of controllable risk. At the same time, the decision-making process is auditable and explainable (derived from clearly defined risk components and thresholds), reducing reliance on experience-based judgments and improving the executability and consistency of the plan.

[0111] Figure 3 It shows that according to Figure 1 An example operation flowchart for step S140.

[0112] like Figure 3 As shown, in step S310, the platform resource capacity and the database migration concurrency limit are obtained.

[0113] It should be noted that tuberculosis network platforms typically operate in multi-tenant cloud environments or distributed resource pools, where resources such as CPU, memory, network bandwidth, and database I / O need to be shared with other services or external systems. Therefore, before generating an upgrade plan, it is necessary to determine the maximum resource capacity that the platform can allocate to upgrade tasks, as well as the maximum number of migration tasks that the database can handle within a unit time window, to avoid impacting online services due to excessive resource consumption during the upgrade.

[0114] In step S320, based on the parsing results of the upgrade package files corresponding to each business module, the upgrade code change amount, database structure change score and interface change score are mapped to resource requirement vectors, and the database migration indicator is calculated at the same time.

[0115] Upgrading different business modules consumes varying types and amounts of resources, especially when database structure changes are involved, which incur additional migration overhead. Therefore, it is necessary to quantify the upgrade change characteristics into resource requirement indicators based on the upgrade package parsing results, and determine whether to trigger a database migration flag.

[0116] ρ m,r =g r (△LOC m D db (m),D api (m)), Equation (12)

[0117] In the formula, △LOC m D represents the percentage of code changes in the upgrade package file of module m. db (m) and D api (m) represents the scores for database structure changes and interface changes involved in the upgrade package file of module m, respectively. r (·) is a monotonic nonlinear function used to map the multidimensional variation characteristics of the upgrade package to execution requirements on resource type r, ρ m,r This indicates the amount of resources required for module m to perform an upgrade operation on resource type r.

[0118] Calculate the database migration indicator:

[0119]

[0120] In the formula, This represents a database migration indicator variable, when D db When (m)>0, the value is 1, indicating that the upgrade of module m involves changes to the database structure; otherwise, the value is 0.

[0121] Equations (12) and (13) allow resource requirements and migration indicators to be derived directly from specific upgrade changes rather than estimates, thereby enabling precise control of resource consumption and database migration times during plan generation and reducing the impact range.

[0122] In step S330, a windowing variable is established using the directed acyclic graph and the upgrade risk index distribution as inputs, and multiple constraints are established.

[0123] It should be noted that the core of the upgrade plan is to determine in which time window t each module m should be upgraded, i.e., the binary variable y. m,tThe value of needs to be determined. To ensure upgrade security and reasonable resource utilization, various constraints need to be introduced based on this variable, including one-time selection constraints, dependency order constraints, resource capacity constraints, and database migration constraints.

[0124] One-time selection constraint is:

[0125]

[0126] This ensures that each module must be upgraded only once within a single time window.

[0127] The dependency order constraint is:

[0128]

[0129] By using DAG edge set E, we can ensure that dependent modules are upgraded in the correct order.

[0130] Resource capacity constraints are:

[0131]

[0132] Database migration constraints are:

[0133]

[0134] In the formula, y m,t This is a binary decision variable, with a value of 1 indicating that module m is upgraded in time window t, and a value of 0 indicating that it is not upgraded in that window. This represents the upgrade risk index of module m within the time window t;

[0135] To ensure that each module is scheduled for upgrade only once within the entire time window set, a one-time selection constraint is imposed. To enforce dependency order constraints, ensure that dependent module n is upgraded before the dependent module m; To constrain resource capacity, ensure that the total resource requirement of the upgrade task in window t does not exceed the available capacity of the corresponding resource; To impose concurrency constraints on database migration, control the number of database change and upgrade tasks within the same window; The objective function for window selection programming is to prioritize upgrading windows with lower risk indices; M is the set of business modules, and E is the set of dependency edges in a directed acyclic graph, where (n→m)∈E indicates that business module m depends on the output of business module n; Cap r Cap represents the maximum capacity available on resource type r on the platform. MIG This indicates the maximum number of module upgrade tasks that the platform allows to execute concurrently;

[0136] Thus, multiple constraints ensure the feasibility of the upgrade plan: there will be no resource overload, incorrect dependency order, or too many databases being migrated at the same time, thereby reducing potential upgrade risks.

[0137] In step S340, the constraints are solved with the goal of minimizing the decision upgrade risk index of each window, thereby obtaining the upgrade time window of each business module.

[0138] Here, assuming all constraints are met, an optimization objective needs to be chosen to determine the upgrade order. Specifically, this involves minimizing the sum of risk indices across all module upgrade time windows. Solving for the objective yields the optimal time window for variable allocation. in This indicates that module m will be scheduled within the target time window t. * Upgrade the module, and set the other windows to 0 to obtain the upgrade time window for each business module.

[0139] In some implementations, the optimization problem can be solved using the ILP method or Constraint Programming (CP) to obtain the optimal upgrade time window t for each module m. * ,Right now

[0140] It should be noted that, given the objective characteristics of the platform, such as multi-module coupling, limited resources, and risk distribution that changes with the external situation, the modeling scheme proposed in this application embodiment is not "greedily selecting the lowest risk window for each module", but rather global optimization: when resources or dependencies conflict, the solver finds the combination with the minimum total risk within the feasible region.

[0141] Through global optimization, the output upgrade schedule minimizes the cumulative risk indicators among feasible solutions while remaining executable (without exceeding resource limits, migration limits, and dependencies). Therefore, when conditions permit, the plan naturally schedules tasks to relatively safer windows, while when some high-risk windows are unavoidable, their number and impact are minimized according to the objective function. Simultaneously, capacity constraints promote a more even distribution of upgrade tasks over time and enable parallel processing where permitted by the DAG, thereby reducing jitter caused by resource contention. Furthermore, the above global optimization result is a deterministic solution for given inputs and constraints, without the black-box processing of deep learning, meeting the auditing and recalculation needs of medical information systems, and can be quickly recalculated to adaptively adjust when risk distribution or capacity parameters change.

[0142] In some examples of embodiments of this application, after completing the above-mentioned upgrade module window selection operation, it is also possible to further identify whether there are incompatible conflicts between the version upgrades of different business modules.

[0143] In the tuberculosis network platform, various interaction relationships exist between business modules. For example, the diagnosis module calls the data interface of the patient record module, and the drug supply module relies on the status information of the treatment management module. When multiple modules are scheduled to be upgraded in parallel within the same time window, incompatibility at the interface or database level between their target versions may cause call failures, data format errors, or transaction exceptions. Therefore, after initially determining the upgrade window, a version compatibility matrix is ​​needed to perform compatibility checks on all modules within the same window.

[0144] Specifically, the target version number of each business module is determined based on the version identifier of the upgrade package file corresponding to each business module.

[0145] For any selected module pair (m,n) within the same upgrade time window, based on the version compatibility matrix... Apply parallel constraints:

[0146] if This allows for parallel upgrades of module pairs (m,n) directly.

[0147] and These represent the target version numbers of modules m and n, respectively.

[0148] if Then, the business modules with higher comprehensive upgrade risk in the module pair (m,n) will be postponed to the next available time window that meets the window selection constraint. Through iterative rearrangement, this process continues until all selected modules meet the version compatibility constraint.

[0149] Specifically, for conflicting module pairs, based on their comprehensive upgrade risk index calculated in the previous steps, the module with higher risk is prioritized for delay; the delayed module is moved to the next time window that meets all constraints (resources, dependencies, migration limits); the detection and adjustment process is repeated until all module pairs within the window meet the version compatibility conditions.

[0150] At this point, by adjusting the upgrade order, higher-risk modules can be postponed to the next available time window to eliminate incompatibility conflicts. This resolves cross-module version conflicts before actual deployment, preventing call failures or data corruption due to differences in interfaces, data structures, or protocols. Furthermore, because version incompatibility issues have been addressed in advance during the upgrade planning phase, the likelihood of triggering a large-scale rollback during the upgrade process is significantly reduced.

[0151] Regarding the specific details of the module upgrade execution in step S150, in some instances of the embodiments of this application, a parallel dual-state upgrade can be adopted. According to the upgrade plan, the upgrade is performed for each business module using a parallel dual-state deployment mechanism, including shadow deployment of the new version and consistency checks on it, gradually switching real traffic according to the canary strategy, and completing the switch if key indicators are stable, otherwise rolling back.

[0152] It should be noted that in public health systems like the tuberculosis network platform, many modules operate under real-time high concurrency. Upgrading would involve a complete switchover, posing an extremely high risk. To mitigate the impact, this implementation method introduces a parallel, gradual upgrade strategy during the execution phase: within the same time window, the old version is maintained to stably handle business operations, while a portion of production traffic is redirected to the target version. The consistency of key business indicators is monitored, and once no significant deviations are confirmed, the proportion of traffic to the new version is gradually increased. The core criterion is the consistency index, which reflects whether the differences between the old and new versions in key business indicators are within acceptable thresholds. If consistency requirements are met for multiple consecutive monitoring periods, the traffic proportion is increased; if anomalies occur, the process is paused or even reverted to the old version.

[0153] Specifically, within the upgrade time window determined by the business module upgrade plan, each business module m scheduled for upgrade and its target version number are... Prepare for execution by reserving corresponding processing resources (such as computing power, database connection count, cache space, etc.) based on platform resource constraints, and verifying that all prerequisite modules have been upgraded according to the directed acyclic graph.

[0154] Without switching outward traffic, production request images are sent to both the old and target versions, and consistency metrics are calculated.

[0155]

[0156] In the formula, Q is the set of key business indicators specified in the business module upgrade plan, △ q (T) represents the difference between the old and new versions in the key business metric q, ψ q λ is the tolerance threshold for the key business indicator q. q Here, Cons(T) represents the consistency index within the monitoring period T, with weights assigned to it.

[0157] It should be understood that key business metrics can be diverse, including functional correctness metrics, performance stability metrics, and data consistency metrics. Functional correctness metrics determine whether the new version's output in core functions is consistent with the old version, such as patient registration success rate and case query result consistency rate. Performance stability metrics check whether the new version maintains acceptable levels of response speed and processing capacity, such as differences in average response time and throughput. Data consistency metrics ensure that data records are not lost or conflicted during the upgrade process, such as drug inventory synchronization consistency rate and follow-up record write consistency rate.

[0158] When Cons(T)≥δ is satisfied for K consecutive monitoring cycles, the flow is switched; K is the number of stability judgment cycles, and δ is the consistency threshold.

[0159] Following the canary strategy, the actual traffic is gradually switched to the target version according to the proportion η. Initially, η = η0. When Cons(T) ≥ δ is still satisfied in each monitoring period, η is increased by step Δη until η = 1. If Cons(T) < δ occurs in any period, η is reversed by Δη and entered into observation.

[0160] If Cons(T) < δ is detected for J consecutive monitoring periods, a rollback is triggered, all traffic is switched back to the old version, and the reason for the rollback is recorded; and

[0161] If η = 1, then the upgrade of the business module is confirmed to be complete and the reserved processing resources are released.

[0162] Considering that the core modules of the tuberculosis network platform need to continuously provide services, and that offline testing is insufficient to cover all behaviors under real data and cross-module dependencies, the preferred implementation method of "parallel gray-scale + consistency gating" is more suitable during the upgrade execution phase: the old version continues to carry the business, while the new version only receives mirrors or small traffic; consistency indicators are calculated for pre-selected key business indicators, and the traffic of the new version is gradually increased only after reaching the threshold for several consecutive monitoring periods; if the threshold is not reached within a monitoring period, the traffic ratio is reduced or rolled back.

[0163] Under the aforementioned gating mechanism, the switchover process is broken down into small, reversible steps: anomalies are detected and their impact limited during low-traffic phases, and the process only proceeds to the next step when certain conditions are met. This makes it easier to maintain the availability and stability of critical business links. Simultaneously, the recording of rollback trigger conditions and causes makes the upgrade process auditable and reproducible. Resource reservation and parallel execution avoid the instantaneous impact of a full switchover. The result is an interpretable, risk-controlled, and reversible upgrade execution process that meets the stringent requirements of the healthcare information platform for continuous service and data consistency.

[0164] To verify the effectiveness of the proposed dynamic upgrade method, we constructed an experimental environment based on real-world operational data to simulate the business operation of the tuberculosis network platform over 30 days and compared it with the traditional static upgrade scheme. The experiment focused on evaluating the following metrics:

[0165] System downtime: The total time during which services are unavailable due to each upgrade;

[0166] Upgrade Risk Index: A risk value calculated using a formula to measure the disruption of an upgrade to the business;

[0167] Upgrade success rate: The percentage of upgrades that do not require rollback after dual-state deployment.

[0168] The experimental setup is as follows:

[0169] Baseline solution: Adopt the traditional scheduled upgrade strategy, with system downtime for upgrades every Sunday morning, without considering business load and risk assessment.

[0170] The RAMUA (Risk-Aware Module Upgrade Algorithm) scheme dynamically selects the upgrade window according to the algorithm proposed in this paper and adopts a parallel dual-state upgrade mechanism.

[0171] Data source: Simulates three core business modules (patient discovery, patient management, and report statistics), and sets average access volume, importance, and upgrade complexity based on public literature and practical experience.

[0172] Indicator calculations: Downtime was estimated by simulating the time required for the upgrade; patient detection accuracy was calculated using a simulation model; and the upgrade risk index was calculated according to the formula in this paper.

[0173] The following section will elaborate on this topic based on relevant experimental results.

[0174] 1) Comparison of system downtime

[0175] Figure 4 A comparative diagram illustrating the system downtime of the baseline upgrade method and the proposed dynamic upgrade method is shown, illustrating the daily downtime variations of the two methods during a 30-day continuous upgrade simulation. The horizontal axis represents the date of the upgrade simulation, and the vertical axis represents the system downtime (in hours) for the corresponding date.

[0176] like Figure 4As shown, the baseline upgrade method performs upgrades within a fixed time window, failing to consider business load fluctuations and external risk factors, resulting in generally long downtime, averaging approximately 4 hours. The dynamic upgrade method, based on historical operational data and external risk factors, generates upgrade plans, prioritizing upgrades within time windows with lower business loads. Combined with parallel dual-state deployment and canary flow switching strategies, the average downtime is reduced to approximately 1.8 hours. When the risk index is high within the predicted window, the dynamic upgrade method can delay upgrade tasks, thereby avoiding operations during high-load or high-risk periods and effectively reducing the impact on system availability.

[0177] Figure 5 This example shows a heatmap of the upgrade risk index for a business module under different time windows. The horizontal axis represents the date (time window) of the upgrade simulation, and the vertical axis represents the business module index (0 for the patient discovery module, 1 for the management module, and 2 for the reporting module in this example). The color intensity indicates the risk index of the corresponding module in that time window; the closer the color is to yellow, the higher the risk, and the closer it is to purple, the lower the risk.

[0178] like Figure 5 As shown, the risk levels of different business modules vary significantly across different time periods. The patient discovery module, due to its high workload and importance, exhibits a high risk index in most time windows, while the reporting module has a relatively low risk index. The Dynamic Upgrade Method (RAMUA) in this paper uses the risk index distribution calculated by fusing historical operational data predictions, module business importance, module upgrade complexity, and external public health risk factors as the window selection criterion when generating upgrade plans. It prioritizes upgrading in lighter-colored areas (low-risk time windows) to avoid executing upgrade tasks during high-risk periods, thereby reducing system downtime risk and improving upgrade success rates.

[0179] Figure 6 This diagram illustrates a comparison of upgrade success rates between the baseline method and the dynamic upgrade method. The horizontal axis represents the simulation dates (from day 1 to 30), and the vertical axis represents the upgrade success rate (the proportion of days without rollback, ranging from 0 to 1) for each day.

[0180] like Figure 6As shown, the RAMUA method exhibits a high success rate throughout the simulation cycle, demonstrating particularly stable performance during high-risk periods, avoiding rollbacks, and maintaining a high success rate for most of the time. In contrast, the baseline approach shows greater fluctuations in success rate, constrained by a fixed time window and insufficient consideration of load fluctuations, leading to more frequent rollbacks. The RAMUA approach, through bi-state deployment and a canary strategy, effectively avoids rollbacks, improving the upgrade success rate, especially during high-risk periods, where its success rate is significantly higher than the baseline approach, with an improvement of 6%-8%.

[0181] This paper addresses issues such as manual judgment, downtime maintenance, lack of risk assessment, and data consistency guarantees during the upgrade of business modules in a tuberculosis network platform. It analyzes the current status and shortcomings of microservice architecture, infectious disease direct reporting systems, and resource scheduling algorithms. Based on the characteristics of public health services, a risk-aware module dynamic upgrade algorithm, RAMUA, is proposed. This algorithm constructs an upgrade risk index by collecting operational data, business importance, upgrade complexity, and external risks; it uses a lightweight prediction model to predict load and public health emergency risks; it generates upgrade plans based on dependency graphs and risk assessments; and it utilizes parallel bi-state deployment to ensure uninterrupted service while continuously optimizing through a feedback mechanism. Simulation experiments show that this method significantly reduces downtime, improves patient detection accuracy, and increases upgrade success rate.

[0182] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of combined actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Secondly, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application. In the above embodiments, the descriptions of each embodiment have their own emphasis; for parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0183] Figure 7 A structural block diagram of an example of a dynamic upgrade system for business modules of a tuberculosis network platform according to an embodiment of this application is shown.

[0184] like Figure 7 As shown, the business module dynamic upgrade system 700 of the tuberculosis network platform includes a data acquisition unit 710, a dependency constraint modeling unit 720, a risk window distribution assessment unit 730, an upgrade plan generation unit 740, and a module upgrade execution unit 750.

[0185] The data acquisition unit 710 is used to acquire the operating indicators and business characteristics of each business module in the tuberculosis network platform; the operating indicators include access volume, response time, CPU utilization and memory utilization, and the business characteristics include the importance of the module business and the complexity of module upgrades.

[0186] The dependency constraint modeling unit 720 is used to represent each business module and its calling relationship as a directed acyclic graph and to establish a version compatibility matrix; the version compatibility matrix is ​​used to define the compatibility relationship between different versions of cross-business modules.

[0187] The risk window distribution assessment unit 730 is used to predict the access load of each business module in each time window set in the future based on historical operating data, extract external public health risk factors from the public health prevention and control knowledge base, and generate an upgrade risk index distribution corresponding to the time window set by combining the module upgrade complexity and module business importance of the business module.

[0188] The upgrade plan generation unit 740 is used to obtain the platform resource constraint information of the tuberculosis network platform, and analyze it in combination with the upgrade risk index distribution of each business module, the directed acyclic graph and the version compatibility matrix to generate a business module upgrade plan; the business module upgrade plan includes the upgrade time window and target version number of each business module;

[0189] The module upgrade execution unit 750 is used to perform upgrade processing on each of the business modules of the tuberculosis network platform in accordance with the business module upgrade plan.

[0190] In some embodiments, this application provides a non-volatile computer-readable storage medium storing one or more programs including execution instructions. The execution instructions can be read and executed by electronic devices (including but not limited to computers, servers, or network devices) to perform the steps of the dynamic upgrade method for the business modules of any of the tuberculosis network platforms described above.

[0191] In some embodiments, this application also provides a computer program product, the computer program product including a computer program stored on a non-volatile computer-readable storage medium, the computer program including program instructions, which, when executed by a computer, cause the computer to perform the steps of any of the above-described methods for dynamically upgrading the business modules of the tuberculosis network platform.

[0192] In some embodiments, this application also provides an electronic device, comprising: at least one processor, and a memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the steps of the dynamic upgrade method for the business modules of the tuberculosis network platform.

[0193] The above-described product can perform the methods provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for performing the methods. Technical details not described in detail in this embodiment can be found in the methods provided in the embodiments of this application.

[0194] The electronic devices in this application can exist in various forms, including but not limited to: mobile communication devices, ultra-mobile personal computer devices, portable entertainment devices, or other airborne electronic devices with data interaction functions.

[0195] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0196] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0197] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for dynamically upgrading business modules of a tuberculosis network platform, characterized in that, The method includes: Obtain the operational metrics and business characteristics of each business module in the tuberculosis network platform; the operational metrics include access volume, response time, CPU utilization, and memory utilization, and the business characteristics include the importance of the module business and the complexity of module upgrades; Each business module and its calling relationship are represented as a directed acyclic graph, and a version compatibility matrix is ​​established; the version compatibility matrix is ​​used to define the compatibility relationship between different versions of cross-business modules; For each business module, based on historical operating data, the access load of the business module in each time window is predicted within the future time window set. External public health risk factors are extracted from the public health prevention and control knowledge base. Combined with the module upgrade complexity and module business importance of the business module, an upgrade risk index distribution corresponding to the time window set is generated. The platform resource constraint information of the tuberculosis network platform is obtained and analyzed in conjunction with the upgrade risk index distribution of each business module, the directed acyclic graph, and the version compatibility matrix to generate a business module upgrade plan; the business module upgrade plan includes the upgrade time window and target version number of each business module. According to the business module upgrade plan, upgrade processes are performed on each of the business modules of the tuberculosis network platform.

2. The method according to claim 1, characterized in that, The acquisition of the aforementioned business characteristics includes: The importance of each business module is determined by querying the expert evaluation table based on its module identifier. The expert evaluation table contains multiple business module identifiers and corresponding expert evaluation results on their importance. The upgrade package files corresponding to each business module are analyzed to determine the amount of upgrade code changes, database structure change scores, and interface change scores for each business module. The corresponding module upgrade complexity is obtained through weighted fusion calculation.

3. The method according to claim 1, characterized in that, The process of representing each business module and its calling relationships as a directed acyclic graph and establishing a version compatibility matrix includes: Based on interface gateway call logs, database access audit records, and message bus publish / subscribe records, the dependency strength of any ordered module pair (m,n) is calculated. s m→n =αf call (m→n)+βf data (m,n)+γf event (m,n), In the formula, f call (m→n) is the normalized value of the frequency of calls from n to m per unit time; f data (m,n) represents the data coupling strength between business modules m and n on the database schema object; f event (m,n) represents the publish / subscribe coupling strength between business modules m and n on the message topic; α,β,γ∈[0,1], and α+β+γ=1 are the channel weights; When s m→n When ≥θ, construct the corresponding directed edge e. m→n A weighted directed graph is generated, with θ as the edge-forming threshold; the weighted directed graph is decomposed into strongly connected components and each strongly connected component is aggregated into a super node to obtain a directed acyclic graph; Based on the parsing results of the upgrade package file and the usage profile on the calling side, construct an interface compatibility sub-matrix and a database compatibility sub-matrix: Based on this, a version compatibility matrix is ​​synthesized: Compat m,n (in i ,v j )=A m,n (in i ,v j )∧D m,n (in i ,v j ), In the formula, v i ,v j These represent the current version and target version of module m, respectively; U n→m For the actual interface and fields of n to m, R uses a profile. n←m For n pairs of read / write profiles of data fields managed by m; and These are the interface contract differences and database schema differences under profile constraints, respectively; ε api ,ε db This corresponds to the allowable threshold for differences; is an indicator function; ∧ is a logical AND.

4. The method according to claim 1, characterized in that, The extraction of the aforementioned external public health risk factors includes: Based on the public health prevention and control knowledge base, an external risk sequence is constructed within the set of time windows: In the formula, t represents the index of the time window, and E(t) represents the comprehensive public health risk value outside the time window t. case (t) represents the number of newly added tuberculosis cases in the public health prevention and control knowledge base during time window t, k E (t) represents the slope of the trend in the number of cases, R P (t) represents the quantified value of policy urgency extracted from the public health prevention and control knowledge base within time window t. γ1, γ2, and γ3 represent the normalized value of the corresponding variable x; γ1, γ2, and γ3 are the weighting coefficients of the number of cases, trend slope, and policy urgency in the comprehensive calculation of external risks, respectively, satisfying γ1 + γ2 + γ3 = 1; The prediction of the access load includes: A load forecasting model using quantile regression is used to output load quantiles for each service module and each time window, and to calculate the predicted bandwidth. b m (t)=Q 0.9,m (t)-Q 0.1,m (t), In the formula, Q p,m (t) represents the p-th quantile of the access load prediction value of service module m in time window t, where p∈{0.1,0.5,0.9} represent the low-order, middle-order, and high-order prediction values, respectively; b m (t) represents the predicted bandwidth of module m in time window t.

5. The method according to claim 4, characterized in that, The calculation of the aforementioned upgrade risk index distribution includes: Map the external risk sequence to an external shock risk rate: In the formula, λ0 is the baseline value of the external shock risk rate, representing the fixed hazard rate when there is no change in public health risk; λ E This is the coefficient representing the impact of the external public health risk value E(t) on the shock risk rate. Let m be the probability of external public health shock risk to module m within time window t; Estimating the risk of overload based on quantile results and safe load threshold: In the formula, V safe (m) represents the safe load threshold of module m, ζ represents the value stability term against division by zero, and b max η represents the maximum predicted bandwidth of all modules in historical data. b This represents the amplification factor of forecast uncertainty on load risk. This represents the probability of module m exceeding the load threshold during time window t; clip(x,0,1) is a clipping function used to restrict the variable x to the range of 0 to 1; By performing a non-linear mapping between module upgrade complexity and module business importance, the corresponding component risk probabilities are obtained: In the formula, U m and C m denoted as upgrade complexity and business importance of module m, respectively; a0 and a1 are the logic function bias and scaling factor used to map the normalized upgrade complexity to risk probability, respectively; c0 and c1 are the logic function bias and scaling factor used to map the normalized business importance to risk probability, respectively; σ(·) is a logic function used to map the input value to the [0,1] interval as probability; Let m be the complexity risk probability of module m. The probability of business importance risk for module m; The upgrade risk index for each time window is obtained by aggregating data in a probabilistic concurrent manner: In the formula, R m (t) represents the comprehensive upgrade risk index of module m within the time window t; For {R m (t)} is time-series smoothed to suppress adjacent window jitter, resulting in the corresponding upgrade risk index distribution: In the formula, This represents the comprehensive upgrade risk index after time-series smoothing, used to reduce fluctuations between time windows; μ represents the smoothing weight coefficient.

6. The method according to claim 5, characterized in that, The process of obtaining platform resource constraint information of the tuberculosis network platform and analyzing it in conjunction with the upgrade risk index distribution of each business module, the directed acyclic graph, and the version compatibility matrix to generate a business module upgrade plan includes: Obtain the platform resource capacity and the database migration concurrency limit; Based on the parsing results of the upgrade package files corresponding to each business module, the upgrade code change amount, database structure change score, and interface change score are mapped to a resource requirement vector: ρ m,r =g r (△LOC m ,D db (m),D api (m)), In the formula, △LOC m D represents the percentage of code changes in the upgrade package file of module m. db (m) and D api (m) represents the scores for database structure changes and interface changes involved in the upgrade package file of module m, respectively. r (·) is a monotonic nonlinear function used to map the multidimensional variation characteristics of the upgrade package to execution requirements on resource type r, ρ m,r This indicates the amount of resources required for module m to perform an upgrade operation on resource type r; Calculate the database migration indicator: In the formula, This represents a database migration indicator variable, when D db When (m)>0, the value is 1, indicating that the upgrade of module m involves changes to the database structure; otherwise, the value is 0. Using a directed acyclic graph and the escalation risk index distribution as input, we establish windowing variables and impose the following constraints: In the formula, y m,t This is a binary decision variable, with a value of 1 indicating that module m is upgraded in time window t, and a value of 0 indicating that it is not upgraded in that window. This represents the upgrade risk index of module m within the time window t; To ensure that each module is scheduled for upgrade only once within the entire time window set, a one-time selection constraint is imposed. To enforce dependency order constraints, ensure that dependent module n is upgraded before the dependent module m; To constrain resource capacity, ensure that the total resource requirement of the upgrade task in window t does not exceed the available capacity of the corresponding resource; To impose concurrency constraints on database migration, control the number of database change and upgrade tasks within the same window; The objective function for window selection programming is to prioritize upgrading windows with lower risk indices; M is the set of business modules, and E is the set of dependency edges in a directed acyclic graph, where (n→m)∈E indicates that business module m depends on the output of business module n; Cap r Cap represents the maximum capacity available on resource type r on the platform. MIG This indicates the maximum number of module upgrade tasks that the platform allows to execute concurrently; by Solving for the objective yields the optimal time window for variable allocation. in * This means that module m will be scheduled for upgrade in the target time window t, and the other windows will be set to 0, thus obtaining the upgrade time window for each business module.

7. The method according to claim 6, characterized in that, The process of obtaining platform resource constraint information of the tuberculosis network platform and analyzing it in conjunction with the upgrade risk index distribution of each business module, the directed acyclic graph, and the version compatibility matrix to generate a business module upgrade plan includes: Based on the version identifier of the upgrade package file corresponding to each business module, determine the target version number of each business module. For any selected module pair (m,n) within the same upgrade time window, based on the version compatibility matrix... Apply parallel constraints: if This allows for parallel upgrades of module pairs (m,n) directly. and These represent the target version numbers of modules m and n, respectively. if Then, the business modules with higher comprehensive upgrade risk in the module pair (m,n) will be postponed to the next available time window that meets the window selection constraint. Through iterative rearrangement, this process continues until all selected modules meet the version compatibility constraint.

8. The method according to any one of claims 1-7, characterized in that, The step of performing upgrade processing on each of the business modules of the tuberculosis network platform according to the business module upgrade plan includes: Within the upgrade time window determined by the business module upgrade plan, for each business module m scheduled for upgrade and its target version number... Prepare for execution by reserving corresponding processing resources based on the platform resource constraint information and verifying that all prerequisite modules have been upgraded according to the directed acyclic graph. Without switching outbound traffic, the production request image is sent to both the old version and the target version, and the consistency index is calculated: In the formula, Q is the set of key business indicators specified in the business module upgrade plan, △ q (T) represents the difference between the old and new versions in the key business metric q, ψ q λ is the tolerance threshold for the key business indicator q. q As the weight, Cons(T) represents the consistency index within the monitoring period T; When Cons(T)≥δ is satisfied for K consecutive monitoring cycles, the flow is switched; K is the number of stability judgment cycles, and δ is the consistency threshold. Following the canary strategy, the actual traffic is gradually switched to the target version according to the proportion η. Initially, η = η0. When Cons(T) ≥ δ is still satisfied in each monitoring period, η is increased by step Δη until η = 1. If Cons(T) < δ occurs in any period, η is reversed by Δη and entered into observation. If Cons(T) < δ is detected for J consecutive monitoring periods, a rollback is triggered, all traffic is switched back to the old version, and the reason for the rollback is recorded; and If η = 1, then the upgrade of the business module is confirmed to be complete and the reserved processing resources are released.

9. A dynamic upgrade system for business modules of a tuberculosis network platform, characterized in that, include: The data acquisition unit is used to acquire the operational indicators and business characteristics of each business module in the tuberculosis network platform; The operational metrics include access volume, response time, CPU utilization, and memory utilization, while the business characteristics include module business importance and module upgrade complexity. The dependency constraint modeling unit is used to represent each business module and its calling relationship as a directed acyclic graph and to establish a version compatibility matrix; the version compatibility matrix is ​​used to define the compatibility relationship between different versions of cross-business modules. The risk window distribution assessment unit is used to predict the access load of each business module in each time window set based on historical operation data, and extract external public health risk factors from the public health prevention and control knowledge base. It also generates the upgrade risk index distribution corresponding to the time window set by combining the module upgrade complexity and module business importance of the business module. The upgrade plan generation unit is used to obtain the platform resource constraint information of the tuberculosis network platform, and analyze it in combination with the upgrade risk index distribution of each business module, the directed acyclic graph and the version compatibility matrix to generate a business module upgrade plan. The business module upgrade plan includes the upgrade time window and target version number for each business module; The module upgrade execution unit is used to perform upgrade processing on each of the business modules of the tuberculosis network platform in accordance with the business module upgrade plan.

Images