Micro-service and distributed database collaborative deployment system for edge computing network

Abstract

This invention relates to a microservice and distributed database collaborative deployment system for edge computing networks, comprising: a database replica number dynamic optimization unit that obtains a dynamic optimization strategy for the number of database replicas based on a queuing-based gradient projection elastic scaling algorithm; a deployment strategy dynamic adjustment unit that calculates end-to-end latency based on microservice routing paths and database routing paths; calculates data inconsistency metrics based on the number of each database replica; and dynamically adjusts the deployment strategy based on resource constraints between end-to-end latency and data inconsistency metrics, as well as the dynamic optimization strategy for the number of database replicas. The deployment strategy includes: microservice instance deployment, database replica deployment, and optimal routing path selection. This invention provides a distributed database design and fine-grained collaborative deployment optimization method for MEC scenarios, integrating message queues, queuing theory, and the Canal database incremental update mechanism to improve microservice application performance and data query efficiency / reliability.

Description

Technical Field

[0001] This invention relates to the field of edge computing technology, and in particular to a microservice and distributed database collaborative deployment system for edge computing networks. Background Technology

[0002] Microservice architecture, with its modular design, high scalability, and flexibility, has rapidly become a mainstream solution in modern software development. Meanwhile, MEC (Mobile Edge Computing) pushes computing and storage resources to the network edge to reduce latency and improve responsiveness, demonstrating a natural fit with microservices in modern distributed computing and network architectures. Leveraging containerization technology, MEC enables flexible, large-scale deployment of microservices across distributed, heterogeneous edge nodes to achieve low latency and efficient resource utilization. Internet giants such as Amazon and Microsoft have developed dedicated microservice edge deployment platforms like AWS Greengrass and Azure IoT Edge to address the needs of latency-sensitive applications.

[0003] In microservice architectures, database design and management systems are key factors affecting performance and QoS (Quality of Service). Ideal design principles advocate for each service to have its own dedicated database and exclusive access permissions. However, under the massive service traffic of MEC (Multi-access Edge Computing), data dependencies between microservices inevitably create cross-node database access requirements, forming performance bottlenecks. Traditional centralized database management models cannot meet the operational needs of microservices, necessitating distributed databases to address high concurrency challenges. However, distributed databases maintain multiple replicas across different server nodes, with microservices selectively accessing the optimal replica during execution. When user requests trigger service call chains across multiple edge devices, insufficient data locality leads to frequent remote synchronization operations, generating additional communication / computing pressure that competes with microservices for server resources. The strong coupling between service orchestration and data distribution makes simultaneously ensuring service response time constraints and cross-node data version consistency a unique deployment challenge in edge environments.

[0004] The CAP theorem (Consistency, Availability, Partition tolerance) establishes that distributed systems cannot simultaneously guarantee consistency, availability, and partition tolerance. This necessitates a trade-off between data consistency and system availability during the design of distributed databases. Strong consistency models ensure timely data retrieval but may increase system response time; weak consistency improves availability / response speed by tolerating the risk of data inconsistency. Distributed transactions spanning multiple services and database instances require effective management solutions. Researchers have proposed various consistency models, such as eventual consistency and causal consistency, along with timestamp-based synchronization algorithms to balance consistency and performance. However, these solutions still require expert-driven selection due to their respective limitations.

[0005] Furthermore, the deployment location of microservice instances and database replicas has a decisive impact on overall application performance. Specifically, microservice deployment consumes CPU / memory resources while triggering replica synchronization traffic, creating resource contention at the physical layer. This contention exhibits spatiotemporal coupling characteristics: the time-sequential cascading data access demands triggered by the service chain are intertwined with the spatial constraints between cross-edge synchronization latency and service response latency. Given the cumulative latency amplification effect of multi-stage service calls and data processing chains, precise optimization of service latency and distributed data consistency becomes crucial for performance improvement. Although microservice orchestration technology enables automated management and scheduling, how to effectively coordinate large-scale microservices with reliable data read / write mechanisms remains an unsolved problem in current research.

[0006] First, in high-concurrency environments, microservices must respond quickly to massive requests while ensuring high availability and low latency. Fine-grained latency calculation and optimization have become core tasks for improving the performance of microservice applications. Latency optimization involves multi-dimensional technical challenges, including service dependency analysis, dynamic load balancing strategies, and real-time monitoring and feedback mechanisms. The key deployment difficulty lies in the mutual constraints between request routing and deployment configuration—microservice deployment affects routing strategies, while request distribution, in turn, affects deployment effectiveness. In distributed systems where microservice instances are distributed across multiple servers / data centers, efficiently routing requests to minimize network latency and bandwidth consumption is significantly complex. This requires a comprehensive consideration of the joint optimization of request routing, load balancing, and resource allocation, which is currently a hot research topic and a challenge.

[0007] Meanwhile, existing research neglects the joint optimization of database deployment strategies and microservice orchestration. Optimal database replica layout requires microservice deployment as a prerequisite and also affects service chain performance, creating a tightly coupled optimization challenge. In a MEC environment, striking a trade-off between data consistency and latency caused by synchronization becomes an urgent need. Traditional, fragmented optimization of service deployment and database management often leads to local optima—over-deploying replicas may reduce access latency but deprives microservices of computing resources.

[0008] Furthermore, effective replica management requires dynamically adjusting the number and distribution of replicas based on data access / update frequency to adapt to dynamically changing load and network conditions. Ultimately, the management and layout of the database at edge nodes has a significant impact on microservice orchestration. Existing research on database layout strategies in microservice architectures remains insufficient; most studies only acknowledge the impact of the database without specifically addressing layout optimization. Therefore, there is an urgent need to construct a joint optimization model to coordinate service instance layout, database replica distribution, and request routing under resource constraints, while simultaneously satisfying SLA (Service-Level Agreement) and data consistency requirements. Summary of the Invention

[0009] This invention addresses the technical problems existing in the prior art by providing a microservice and distributed database collaborative deployment system for edge computing networks. By designing a distributed data query, routing, and synchronization mechanism based on the DaaS paradigm, it solves the bottleneck of database design and access on microservice performance in existing edge computing scenarios. Furthermore, through fine-grained modeling, it jointly optimizes the joint deployment and routing of microservices and databases, thus resolving resource contention issues in multi-objective optimization.

[0010] According to a first aspect of the present invention, a microservice and distributed database collaborative deployment system for edge computing networks is provided, comprising: a database layer, a microservice layer, a user layer, and a deployment module;

[0011] The database layer includes multiple databases in a distributed architecture, each database having multiple replicas; the microservice layer includes multiple microservice instances; the deployment module includes: a database replica number dynamic optimization unit and a deployment strategy dynamic adjustment unit.

[0012] After receiving microservice requests from various users, the user layer selects a routing path to access a copy of the database corresponding to the microservice user request; the routing path includes the microservice routing path and the database routing path through which the information between the user sending the microservice request and receiving the processing result is traversed.

[0013] After the microservice requests to perform a write operation to any replica of the database, the database layer generates incremental events carrying operation semantics among multiple replicas of the database for incremental synchronization by parsing the database binary log in real time.

[0014] The database replica number dynamic optimization unit obtains a dynamic optimization strategy for the number of database replicas based on a queuing gradient projection elastic scaling algorithm.

[0015] The deployment strategy dynamic adjustment unit calculates end-to-end latency based on the microservice routing path and the database routing path; calculates data inconsistency metrics based on the number of each database replica; and dynamically adjusts the deployment strategy based on resource constraints between the end-to-end latency and the data inconsistency metrics, as well as the dynamic optimization strategy for the number of database replicas. The deployment strategy includes: microservice instance deployment, database replica deployment, and optimal routing path selection.

[0016] Based on the above technical solution, the present invention can also be improved as follows.

[0017] Optionally, the process of selecting a routing path after the user layer receives microservice requests from various users includes:

[0018] Step 101, represent the set of microservice requests issued by users in the mobile edge computing network as follows: ; Each service request Defined as a microservice chain sequence ,in, Each is a subset of microservice instances with strict execution dependencies, and the output of the preceding subset of microservice instances serves as the input of the subsequent subset of preceding microservice instances.

[0019] Step 102: Model the request flow generated by the microservice requests issued by users in each region u as triples. ;

[0020] in, For the maximum tolerable latency, To meet coverage requirements First-reach edge node, request arrival rate It follows a Poisson process;

[0021] Step 103, the request stream Generate a microservice chain sequence based on path selection probability. set of feasible paths ;

[0022] Among them, any path Path selection probability , Indicates a service request Deployment nodes in the middle microservice instances Transfer to deployment node microservice instances The probability, and satisfying the probability normalization condition. , For each deployment node;

[0023] Feasible paths in the set of feasible paths Meet physical deployment constraints , Represents a microservice instance On the deployment node Deployment status on;

[0024] Step 104: Dynamically select the optimal database replica based on queue pressure and communication latency, and select the replica based on routing constraints and routing path optimization objectives from the set of feasible paths. Determine the optimal route path;

[0025] The routing constraints include: for any deployed node The sum of the path selection probabilities of downstream microservices is 1; when the service chain is executed, it is only allowed to flow to the specified successor microservice, otherwise the path selection probability is set to zero; the routing path optimization objective is to minimize the expected value of the end-to-end latency.

[0026] Optionally, the end-to-end delay includes: access delay. , return delay And path delay accumulation;

[0027] The path delay accumulation item includes: queue delay. Processing delay Transmission delay and database query latency .

[0028] Optionally, the database replica number dynamic optimization unit obtains the dynamic optimization strategy for the database replica number, including:

[0029] The utilization rate of the collaborative deployment system is calculated in real time, and the utilization rate is... Increase the number of database replicas as needed;

[0030] A comprehensive cost gradient function is constructed that includes query latency, synchronization pressure, and resource contention. Based on the comprehensive cost gradient function, the rounding projection method is used to adjust the number of replicas in the discrete database.

[0031] When making the final decision on the number of database replicas, the upper limit of computing power is forcibly verified based on the resource constraints between the end-to-end latency and the data inconsistency metric.

[0032] Optionally, the comprehensive cost function is:

[0033] ;

[0034] in, Indicates the database query queue latency; This represents the global synchronous traffic of multi-master asynchronous replication; Indicates the intensity of resource competition among edge nodes. This represents a custom upper limit on the intensity of resource contention on edge nodes. These are the weighting coefficients;

[0035] Calculated using Erlang C formulas;

[0036] ; This indicates the number of replicas of database d on node e. This represents the traffic to database d on node e. Represents a set of writable database replicas. This represents a set of heterogeneous edge nodes that have deployed replicas of the current database d.

[0037] Optionally, the process of generating incremental events carrying operational semantics for incremental synchronization among multiple replicas of the database includes:

[0038] The Canal component parses the database binary logs in real time to generate incremental events carrying operation semantics. The event stream is routed to the target replica node through the message queue, and the order of operations with the same key is maintained based on key-value partitioning. The event is routed to the Kafka topic partition through the composite partitioning function, realizing the coordinated optimization of data locality and load balancing.

[0039] Optionally, the deployment strategy dynamic adjustment unit includes: a dual-agent system; the dual-agent system includes: a microservice orchestration agent and a database management agent;

[0040] The microservice orchestration agent generates a routing probability matrix of microservice instance deployment sequences and microservice routing paths through a dynamic masking strategy.

[0041] The database management agent is used to adjust the database replica distribution and database routing paths;

[0042] The dual-agent system captures the dynamic coupling characteristics of microservice orchestration and database management by designing a state-space hierarchical observation mechanism, and dynamically adjusts the deployment strategy by combining reinforcement learning methods of policy gradient and value function estimation.

[0043] Optionally, the process of dynamically adjusting the deployment strategy includes:

[0044] Step 201, Construct the global state ;

[0045] Where G represents the topology of the mobile edge computing scenario, D represents the propagation delay matrix between heterogeneous edge nodes, E represents the set of heterogeneous edge nodes, and C represents... The set of CPU core counts of the nodes in the data. This indicates the number of replicas of database d on node e. Indicates the intensity of resource competition among edge nodes;

[0046] Step 202: Construct the state space of the microservice orchestration agent based on the global state. ;

[0047] in, Indicates user request characteristics, This indicates the deployment characteristics of microservice instances;

[0048] Step 203: Construct the state space of the database management agent based on the global state. ;

[0049] in, Decision variables representing data access efficiency and latency. The observations representing the data consistency maintained by the database management agent include inconsistency time windows and synchronization flows;

[0050] Step 204: The service orchestration agent uses a probabilistic sequence generation method, based on the target number of microservice instances. Build a microservice instance deployment sequence The deployment sequence of the microservice instances is randomized before each training cycle based on the Fisher-Yates shuffle algorithm. To eliminate topology bias; in the decision step, select the current microservice instance. And execute two-dimensional joint actions: deployment location selection ,in Dynamically mask based on resource availability; adjust the original route probability to... This indicates the probability that a request will be routed to this microservice instance;

[0051] Step 205, the database management agent relocates the replicas. Use policy gradient and learning rate Update the routing weights to achieve fine-grained control over the distribution of database replicas and database routing paths;

[0052] Step 206: Set a reward function to achieve coordinated incentives for microservice latency optimization and database consistency maintenance through multi-objective decomposition and constraint-aware penalty mechanism; the reward function includes: service latency reward, data consistency reward and resource efficiency reward.

[0053] Optionally, the dual agents adopt a centralized training and distributed execution paradigm;

[0054] During the centralized training phase, the central controller manages the value network and the target network, while each agent maintains its local policy network.

[0055] After training convergence, the system switches to distributed execution mode, where the central controller and value network are deprecated, and each edge node retains the optimized policy network to generate autonomous decisions.

[0056] This invention provides a microservice and distributed database collaborative deployment system for edge computing networks. It constructs a microservice deployment topology model based on the computing power characteristics of edge computing nodes, extracts containerized service dependency chains, network latency matrices, and resource contention indicators, and establishes a decision space for dynamic orchestration of microservice instances. A distributed database multi-replica synchronization mechanism is built to address the performance constraints of monolithic databases on microservice applications and ensure eventual database consistency. Read / write traffic characteristics are modeled using queue theory, and an asynchronous multi-master replication strategy is adopted to optimize the balance between cross-node synchronization overhead and query latency. A joint strategy initialization method based on greedy-projection is designed to generate an initial solution for elastic scaling of data replicas in a three-dimensional decision space encompassing container deployment location, service routing paths, and database replica distribution. A distributed dual-agent reinforcement learning optimization engine is established, where the service orchestration agent generates deployment sequences and routing probability matrices through a dynamic masking strategy, and the database management agent adjusts the database replica distribution. A multi-objective value evaluation network is constructed by integrating end-to-end latency penalties, data inconsistency metrics, and resource constraint indicators, and Pareto policy gradients are used to achieve online dynamic optimization of the deployment strategy. Attached Figure Description

[0057] Figure 1 This is a schematic diagram of an embodiment of a microservice and distributed database collaborative deployment system for edge computing networks according to the present invention;

[0058] Figure 2 A schematic diagram illustrating an embodiment of a microservice deployment and request routing case provided by the present invention;

[0059] Figure 3 This is a schematic diagram of an embodiment of fine-grained microservice and database joint orchestration modeling based on queuing process provided by the present invention. Detailed Implementation

[0060] The principles and features of the present invention are described below with reference to the accompanying drawings. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0061] Figure 1 A schematic diagram of an embodiment of the present invention, which is a microservice and distributed database collaborative deployment system for edge computing networks, is shown below. Figure 1 As shown, the deployment system includes: a database layer, a microservice layer, a user layer, and a deployment module.

[0062] The database layer includes multiple databases in a distributed architecture, each with multiple replicas; the microservice layer includes multiple microservice instances; the deployment module includes a dynamic optimization unit for the number of database replicas and a dynamic adjustment unit for deployment strategies.

[0063] After receiving microservice requests from various users, the user layer selects a routing path to access a copy of the database corresponding to the microservice user request. The routing path includes the microservice routing path and the database routing path through which the information between the user sending the microservice request and receiving the processing result is traversed.

[0064] After a microservice requests a write operation to any replica of any database, the database layer generates incremental events carrying operation semantics among multiple replicas of the database by parsing the database binary log in real time for incremental synchronization.

[0065] The database replica number dynamic optimization unit obtains a dynamic optimization strategy for the number of database replicas based on the queuing gradient projection elastic scaling algorithm.

[0066] The deployment strategy dynamic adjustment unit calculates end-to-end latency based on microservice routing paths and database routing paths; calculates data inconsistency metrics based on the number of database replicas; and dynamically adjusts the deployment strategy based on resource constraints between end-to-end latency and data inconsistency metrics, as well as dynamic optimization strategies for the number of database replicas. The deployment strategy includes: microservice instance deployment, database replica deployment, and optimal routing path selection.

[0067] During the execution of a microservice instance, access to a specific database is required. Using a monolithic database can easily lead to performance bottlenecks. Therefore, a distributed database is used, splitting the monolithic database into N types, with each microservice accessing only the required database. Furthermore, each database has multiple replicas. Replicating multiple times reduces the access pressure on a single database and improves disaster recovery capabilities. A microservice can access data from any one replica. However, updating one replica requires synchronizing the updated data to all replicas, thus introducing a data consistency metric: the update latency between replicas. During this latency, other requests may read outdated data, reducing service reliability.

[0068] This invention optimizes both data consistency and microservice latency using reinforcement learning algorithms. These two metrics are contradictory because each node in edge computing has limited resources. Allocating more resources to microservice containers reduces execution pressure and lowers queuing and processing latency, but increases database access pressure and extends read / write latency. Therefore, it's crucial to rationally plan the resources allocated to microservices and the database to minimize the total request latency. Edge computing employs a distributed architecture, pushing computing and storage capabilities down to the network edge closer to end users. Cross-node communication is achieved through a service mesh, providing low-latency services for scenarios such as real-time control in the Industrial Internet of Things and autonomous driving.

[0069] The integration of microservice architecture and MEC brings new opportunities for building efficient, low-latency distributed applications. This invention addresses the bottleneck of database design and access constraints on microservice performance in existing edge computing scenarios by designing a distributed data query, routing, and synchronization mechanism based on the DaaS paradigm. Furthermore, it solves the resource contention problem in multi-objective optimization by jointly optimizing the joint deployment and routing of microservices and databases through fine-grained modeling.

[0070] Example 1

[0071] Embodiment 1 provided by this invention is an embodiment of a microservice and distributed database collaborative deployment system for edge computing networks provided by this invention, combined with... Figure 1 It can be seen that the embodiments include:

[0072] The collaborative deployment system includes: a database layer, a microservice layer, a user layer, and a deployment module.

[0073] The database layer includes multiple databases in a distributed architecture, each with multiple replicas; the microservice layer includes multiple microservice instances; the deployment module includes a dynamic optimization unit for the number of database replicas and a dynamic adjustment unit for deployment strategies.

[0074] This invention uses a distributed database in a microservice architecture to address high concurrency challenges.

[0075] After receiving microservice requests from various users, the user layer selects a routing path to access a copy of the database corresponding to the microservice user request. The routing path includes the microservice routing path and the database routing path through which the information between the user sending the microservice request and receiving the processing result is traversed.

[0076] After a microservice requests a write operation to any replica of any database, the database layer generates incremental events carrying operation semantics among multiple replicas of the database by parsing the database binary log in real time for incremental synchronization.

[0077] In practical implementation, this invention employs read / write mode classification optimization and implements differentiated synchronization strategies based on the heterogeneous access characteristics of data services. Incremental synchronization is performed when a microservice performs write operations, but no synchronization is performed when a microservice performs read operations. This addresses the performance limitations of monolithic databases on microservice applications and ensures eventual database consistency.

[0078] The database replica number dynamic optimization unit obtains a dynamic optimization strategy for the number of database replicas based on the Queued Gradient Projection Elastic Scaling (QES-GP) algorithm.

[0079] The deployment strategy dynamic adjustment unit calculates end-to-end latency based on microservice routing paths and database routing paths; calculates data inconsistency metrics based on the number of database replicas; and dynamically adjusts the deployment strategy based on resource constraints between end-to-end latency and data inconsistency metrics, as well as dynamic optimization strategies for the number of database replicas. The deployment strategy includes: microservice instance deployment, database replica deployment, and optimal routing path selection.

[0080] Precise optimization can be achieved by using fine-grained computational latency and synchronization data inconsistency windows; resource allocation problems can be solved by using projection gradient algorithms; and metric optimization can be achieved by using reinforcement learning algorithms.

[0081] Edge computing adopts a distributed architecture, pushing computing and storage capabilities down to the network edge closer to end users. It enables cross-node communication through service mesh, providing low-latency services for scenarios such as real-time control of industrial IoT and autonomous driving.

[0082] In practical implementation, mobile edge computing scenarios are constructed. ;in, For E heterogeneous edge nodes A set, i = 1, 2, ..., E; Let be the adjacency matrix representing the connection relationships between nodes.

[0083] gather any i-th node Limited computing power computing power This is represented by the number of CPU cores on a node, with each CPU core hosting only one microservice instance for resource isolation, ensuring workload independence between instances.

[0084] Adjacency Matrix , Represents a node and There is a physical connection.

[0085] The topology model adopts a distributed architecture with a non-fully connected topology. Nodes communicate internally via memory / bus operations, and the latency is negligible. Network characteristic parameters include a bandwidth matrix. (Unit: Gbps) and propagation delay matrix (Unit: ms), for all ,satisfy .

[0086] Service interaction is achieved through reachable paths, and cross-node communication is realized through service mesh, providing low-latency services for scenarios such as real-time control of industrial IoT and autonomous driving.

[0087] Given that storage resources can be elastically supplied through horizontal scaling of storage devices, this invention prioritizes computational resource constraints as the core optimization dimension. Computational power This is directly mapped to the number of CPU cores on a node, ensuring through hard constraints that each core runs only a single microservice instance or database replica. This design effectively isolates the workloads of different instances, avoids performance fluctuations caused by resource contention, and provides deterministic resource guarantees for real-time services.

[0088] Microservice architecture defines a collection of various independent microservices. ,in This indicates the total number of microservice types. Each microservice is deployed on a node's CPU core using containerization technology, and each microservice instance... At the edge nodes, at the processing rate Service-related requests. Heterogeneous edge nodes exhibit differentiated processing capabilities for the same microservice, enabling abstract and coordinated management of heterogeneous computing resources.

[0089] Defining service deployment decisions involves binary variables. Characterizing microservice instances At the edge node The deployment status, and integer variables This indicates the number of computing cores allocated to microservice m for node e. Geographically distributed instances of the same type of microservice constitute a reusable service pool, possessing shared processing capabilities across request flows.

[0090] In one possible implementation, after the user layer receives microservice requests from various users, the process of selecting a routing path includes:

[0091] Step 101, represent the set of microservice requests issued by users in the mobile edge computing network as follows: ; Each service request Defined as a microservice chain sequence ,in, Each microservice instance subset has a strict execution dependency relationship. The output of the preceding microservice instance subset serves as the input of the subsequent preceding microservice instance subset, forming the data processing pipeline necessary for edge applications.

[0092] Step 102: Model the request flow generated by the microservice requests issued by users in each region u as triples. .

[0093] in, For the maximum tolerable latency, To meet coverage requirements First-reach edge node, request arrival rate It follows a Poisson process.

[0094] In practice, user requests are defined and their spatiotemporal distribution characteristics are presented. When a user moves to the coverage boundary, it may trigger service migration or database synchronization between adjacent nodes, directly affecting the resource optimization effect. Let... It is a collection of geographical radiation areas, each area The request follows a Poisson process. Edge nodes are identified via binary cover indicators. Provides regional coverage, of which Represents a node Coverage area User requests are preferentially routed to the set of coverage nodes. .

[0095] Step 103, request stream Generate a microservice chain sequence based on path selection probability. set of feasible paths .

[0096] Here, the path selection probability is the product of the transition probabilities between adjacent microservice pairs, i.e., any path Path selection probability , Indicates a service request Deployment nodes in the middle microservice instances Transfer to deployment node microservice instances The probability, and satisfying the probability normalization condition. , For each deployment node.

[0097] Feasible paths in the set of feasible paths Meet physical deployment constraints , Represents a microservice instance On the deployment node The deployment status on the platform.

[0098] Step 104: Dynamically select the optimal database replica based on queue pressure and communication latency, and optimize the feasible path set based on routing constraints and routing path optimization objectives. Determine the optimal route path.

[0099] The routing constraints include: for any deployed node The sum of the path selection probabilities of downstream microservices is 1; when the service chain is executed, it is only allowed to flow to the specified successor microservice, otherwise the path selection probability is set to zero; the goal of routing path optimization is to minimize the expected value of end-to-end latency.

[0100] This invention establishes a fine-grained end-to-end latency calculation method for microservice service chains. Each microservice is deployed on a node's CPU core using containerization technology, and each microservice instance... At the edge nodes, at the processing rate Service-related requests. Heterogeneous edge nodes exhibit differentiated processing capabilities for the same microservice, enabling abstract and coordinated management of heterogeneous computing resources.

[0101] In one possible implementation, the end-to-end latency includes: access latency. , return delay And the cumulative path delay item.

[0102] The cumulative path delay includes: queue delay. Processing delay Transmission delay and database query latency .

[0103] Each node deploys a limited-capacity first-in-first-out queue, with a service rate of... Linearly correlated with the number of allocated cores. Processing time. Queuing delay adopts The system's Erlang C formula calculation includes system utilization. and stability conditions .

[0104] Transmission delay , i.e., path The sum of latency between each deployed node is used to calculate the expected end-to-end latency based on the sum of the individual latencies. This formula also guarantees the worst-case QoS constraints. .

[0105] In microservice architectures, database design and management are key factors affecting performance and Quality of Service (QoS). Ideal design principles advocate providing dedicated databases for individual services with exclusive access. However, under massive MEC service traffic, data dependencies between microservices inevitably generate cross-node database access requirements, creating performance bottlenecks. Traditional centralized database management models cannot meet the operational requirements of microservices. Distributed databases maintain multiple replicas on different server nodes, with microservices selectively accessing the best replica during execution. However, when user requests trigger service call chains across multiple edge devices, insufficient data locality leads to frequent remote synchronization operations. This creates additional communication / computing pressure, competing with microservices for server resources. The strong coupling between service orchestration and data distribution presents unique deployment challenges in edge environments, particularly in simultaneously ensuring service response time constraints and cross-node data version consistency. This invention designs a distributed database query and synchronization mechanism based on the DaaS (Database as a Service) paradigm.

[0106] This invention employs a layered, decoupled database architecture design. Building upon DaaS, it constructs a layered, decoupled distributed database architecture, splitting monolithic database tables into independent data services (DS), and encapsulating them into isolated instances using containerization technology. This abstraction layer ensures decoupling between microservice call interfaces and the underlying database deployment, supports dynamic reorganization of data tables into lightweight logical groups called "micro-databases," and defines an access relation matrix. ,in microservices Accessing the database This matrix quantifies the dependencies between microservices and the database, providing a topological constraint basis for joint resource optimization.

[0107] In one possible implementation, the process of dynamically selecting the optimal database replica based on queue pressure and communication latency includes:

[0108] Construct a weighted optimization model for normalized network latency and load intensity. This addresses the adaptability limitations of traditional static routing in edge environments.

[0109] Establish service intensity constraints This ensures that the computing resources of candidate nodes meet stability conditions, providing a feasibility boundary for routing decisions.

[0110] The optimal replica selection strategy addresses the adaptability shortcomings of traditional static routing in edge environments by using a weighted optimization model that normalizes network latency and load intensity.

[0111] An iterative routing coordination algorithm is designed to achieve load balancing through three stages: traffic allocation initialization, optimal node selection, and constraint detection.

[0112] In one possible embodiment, the database replica number dynamic optimization unit obtains a dynamic optimization strategy for the database replica number, including:

[0113] The utilization rate of the real-time computing collaborative deployment system, in terms of utilization rate Increase the number of database replicas as needed to prevent queue waiting time from entering a superlinear growth zone.

[0114] A comprehensive cost gradient function incorporating query latency, synchronization pressure, and resource contention is constructed. Based on this comprehensive cost gradient function, a rounding projection method is used to adjust the number of replicas in the discrete database. Through derivation using Lyapunov optimization theory, convergence within 5 control cycles can be ensured under typical edge node configurations.

[0115] The final decision on the number of database replicas is based on resource constraints between end-to-end latency and data inconsistency metrics, which forcefully verifies the upper limit of computing power and controls the cycle. The minute setting balances algorithm response speed and system stability.

[0116] To address the distributed access characteristics of microservices that rely on database replicas during execution, this invention proposes a dynamic weighted routing strategy. At edge nodes... Executing microservices During this process, it must access its dependent databases. Specific replicas are selected. These replicas may be distributed across multiple edge nodes, and their selection directly impacts end-to-end service chain latency and system stability. The core challenge of optimal replica selection lies in the real-time load status of the replica nodes, which determines the queuing latency of data services. These factors together constitute a composite latency metric, requiring routing decisions to consider both spatial location and instantaneous load conditions.

[0117] This strategy utilizes a weighted optimization model that normalizes network latency and load intensity. This addresses the adaptability limitations of traditional static routing in edge environments. Service strength constraints are established synchronously. This ensures that the computing resources of candidate nodes meet stability conditions, providing a feasibility boundary for routing decisions.

[0118] An iterative routing coordination algorithm is designed to achieve load balancing through three phases: traffic allocation initialization, optimal node selection, and constraint detection. When node resource utilization approaches a threshold, an incremental adjustment of the weight parameter ω is triggered. Based on the weighted formula mentioned above, traffic is dynamically redistributed.

[0119] Establish a composite query latency model to supplement the calculation formula for database query latency. It accurately captures the "weakest link" effect in parallel access to multiple databases. It coordinates replica deployment and resource scheduling through a bidirectional coupling optimization mechanism and integrates a version vector optimistic locking protocol.

[0120] Based on this modeling, this invention designs a queuing-based gradient projection elastic scaling (QES-GP) algorithm to optimize the number of replicas in each distributed database, seeking a dynamic balance between data access efficiency and system stability. Under the aforementioned joint resource allocation constraints, increasing the number of replicas can distribute query traffic, effectively reducing the load pressure on individual replicas and thus significantly reducing query latency. However, each additional replica introduces additional data synchronization traffic. In a multi-master asynchronous replication mechanism, the propagation of incremental logs between replica nodes generates communication overhead, which grows exponentially with the number of replicas. This not only consumes limited bandwidth resources but may also extend the time window of data inconsistency due to synchronization delays.

[0121] In one possible implementation, the comprehensive cost function is:

[0122] .

[0123] in, Indicates the database query queue latency; This represents the global synchronous traffic of multi-master asynchronous replication; Indicates the intensity of resource competition among edge nodes. This represents a custom upper limit on the intensity of resource contention on edge nodes; when R_compete exceeds this parameter τ, a certain cost (i.e., a penalty value) will be incurred. These are the weighting coefficients.

[0124] The calculation is performed using Erlang C formulas.

[0125] ; This indicates the number of replicas of database d on node e. This represents the traffic to database d on node e. Represents a set of writable database replicas. This represents a set of heterogeneous edge nodes that have deployed replicas of the current database d.

[0126] The QES-GP algorithm employs a projective gradient descent strategy to dynamically optimize the number of database replicas. This is achieved by mapping continuous gradient updates to a discrete integer solution space, while strictly adhering to edge node resource constraints. Specifically, we first derive the objective function for the number of replicas. The partial derivative of is composed of three parts:

[0127]

[0128] The queuing delay gradient term was obtained through sensitivity analysis of the Erlang-C model, the synchronization pressure term captured the quadratic relationship between the number of replicas and the multi-master traffic, and the resource contention penalty term implemented linear constraints through an indicator function.

[0129] In one possible implementation, the process of determining the resource constraints between end-to-end latency and data inconsistency metrics includes:

[0130] Establish nodes and End-to-end synchronization delay model It consists of three parts: queue backlog, processing time, and network propagation.

[0131] Define the data inconsistency window as , representing the delay of the largest version divergence.

[0132] Define a collaborative deployment system to meet the following requirements: Strictly ensure final consistency.

[0133] This property is achieved through the total order propagation of incremental event streams and conflict resolution protocol, avoiding the high latency bottleneck of traditional two-phase commit protocols and adapting to the high concurrency requirements of edge networks.

[0134] To address the distributed access characteristics of microservices that rely on database replicas during execution, this invention proposes a dynamic weighted routing strategy. At edge nodes... Executing microservices During this process, it must access its dependent databases. Specific replicas are selected. These replicas may be distributed across multiple edge nodes, and their selection directly impacts end-to-end service chain latency and system stability. The core challenge of optimal replica selection lies in the real-time load status of the replica nodes, which determines the queuing latency of data services. These factors together constitute a composite latency metric, requiring routing decisions to consider both spatial location and instantaneous load conditions.

[0135] Based on the Poisson flow additivity, different requests flowing through the same microservice instance can be merged and processed at edge nodes, forming a hierarchical queue network. The traffic aggregated by microservice m at node e... Includes locally generated traffic With forwarding traffic It follows the principle of flow conservation.

[0136] , This indicates the number of microservice instances m on node e. This indicates the number of CPU cores on node e.

[0137] Through weighting coefficients Achieve a dynamic balance between query latency, synchronization overhead, and resource contention.

[0138] A queuing-based gradient projection elastic scaling algorithm optimizes the number of replicas in each distributed database, seeking a dynamic balance between data access efficiency and system stability. Its key features are:

[0139] In the mobile edge computing microservice architecture, the QES-GP algorithm of this invention adopts the projected gradient descent strategy to achieve dynamic optimization of the number of database replicas. It maps continuous gradient updates to the discrete integer solution space while strictly adhering to the resource constraints of edge nodes.

[0140] In one possible implementation, the process of generating incremental events carrying operational semantics for incremental synchronization among multiple copies of the database includes:

[0141] The Canal component parses the database binary logs in real time to generate incremental events carrying operation semantics. The event stream is routed to the target replica node through the message queue, and the order of operations with the same key is maintained based on key-value partitioning. The event is routed to the Kafka topic partition through the composite partitioning function, realizing the coordinated optimization of data locality and load balancing.

[0142] A read / write pattern classification optimization is adopted, and a differentiated synchronization strategy is implemented based on the heterogeneous access characteristics of data services. This applies to read-intensive services (such as product catalog queries). Static, asynchronous replicas are used for write-intensive services (such as inventory updates). An asynchronous multi-master replication topology is constructed to support concurrent writes across nodes. Incremental log propagation and conflict resolution mechanisms maintain microservice autonomy while ensuring eventual consistency.

[0143] The process of constructing a multi-objective value assessment network based on resource constraint metrics between end-to-end latency and data inconsistency measures includes:

[0144] Joint resource allocation constraints for building microservice instances and database replicas .

[0145] This joint resource allocation constraint reflects the zero-sum competition relationship of CPU core resources between the microservice engine and the database replica. It needs to be optimized collaboratively to avoid cascading latency degradation caused by local optimization, which would worsen end-to-end latency.

[0146] In one possible embodiment, the deployment strategy dynamic adjustment unit includes a dual agent; the dual agent includes a microservice orchestration agent (SOA) and a database management agent (DMA).

[0147] The microservice orchestration agent generates a routing probability matrix of microservice instance deployment sequences and microservice routing paths through a dynamic masking strategy.

[0148] Database management agents are used to adjust the distribution of database replicas and database routing paths.

[0149] The dual-agent approach captures the dynamic coupling characteristics of microservice orchestration and database management by designing a state-space hierarchical observation mechanism, and dynamically adjusts the deployment strategy by combining reinforcement learning methods of policy gradient (Actor) and value function estimation (Critic).

[0150] The dual-agent framework achieves a dynamic balance between deployment strategies and resource constraints through collaborative decision-making between a microservice orchestration agent (SOA) and a database management agent (DMA). The necessity of the dual-agent architecture stems from the strong coupling between microservices and the database across three dimensions: physical resource competition, objective conflict, and decision-making timing. The deployment location of microservice instances directly determines the local advantage of database access, while the distribution of database replicas, in turn, constrains the optimal path for microservice request routing. Traditional single-agent models struggle to decouple these two decision-making processes with different time scales. This invention's dual-agent multi-objective Actor Critic (DAMAC) algorithm, based on a multi-agent reinforcement learning framework, separates the policy network from the shared value function. DAMAC allows SOA to focus on service chain latency optimization, DMA to emphasize data consistency maintenance, and achieves cross-objective reward fusion through a Coordinated Critic network.

[0151] In one possible implementation, the process of dynamically adjusting the deployment strategy includes:

[0152] Step 201, Construct the global state .

[0153] Where G represents the topology of the mobile edge computing scenario, D represents the propagation delay matrix between heterogeneous edge nodes, E represents the set of heterogeneous edge nodes, and C represents... The set of CPU core counts of the nodes in the data. This indicates the number of microservice instances m on node e. This indicates the number of replicas of database d on node e. This indicates the intensity of resource competition among edge nodes.

[0154] By integrating distributed MEC scenario attributes, microservice and database deployment matrices, and resource contention coefficients, a global awareness of the overall system load is achieved. Local states are designed for SOA and DMA, respectively.

[0155] Step 202: Construct the state space of the microservice orchestration agent based on the global state. .

[0156] in, Indicates user request characteristics, This indicates the deployment characteristics of microservice instances.

[0157] Microservice orchestration agents focus on end-to-end latency in the service chain. Optimize and integrate user request characteristics with microservice deployment characteristics. User request characteristics Includes request stream collection Geographical reach rate following a Poisson process , and by the overwrite indicator Defined user-edge node geographic relationships. Microservice deployment characteristics. By binary deployment matrix Routing probability distribution Calculate the number of kernels allocated heterogeneous edge node service rate And the queuing delay derived from the Erlang C formula. Together they constitute.

[0158] Step 203: Construct the state space of the database management agent based on the global state. .

[0159] in, Decision variables representing data access efficiency and latency. This refers to the observations that the database management agent maintains for data consistency, including inconsistency time windows and synchronization flows.

[0160] Database Management Agent (DMA) focuses on data access efficiency and latency while maintaining data consistency across replicas, integrating multi-dimensional observations. The decision variables for data access efficiency and latency can be represented as follows: This represents service dependencies, request traffic, replica servicing rate, and replica count. Simultaneously, it allows... The observations representing the data consistency maintained by DMA include inconsistency time windows and synchronization traffic.

[0161] Step 204: The service orchestration agent uses a probabilistic sequence generation method, based on the target number of microservice instances. Build a microservice instance deployment sequence Randomize the microservice instance deployment sequence before each training cycle based on the Fisher-Yates shuffle algorithm. To eliminate topology bias; in the decision step, select the current microservice instance. And perform two-dimensional joint actions: 1) Deployment location selection ,in 1) Dynamic mask based on resource availability; 2) Adjust the original route probability to This indicates the probability that a request will be routed to this microservice instance.

[0162] The service orchestration agent achieves collaborative optimization of microservice deployment and data routing through a layered action space with a dynamic masking mechanism.

[0163] Step 205, the database management agent achieves fine-grained control through a three-action mechanism: 1) Replica relocation Use policy gradient and learning rate Update route weights .

[0164] Decoupling the action space of the two agents will originally The joint action space is decomposed into two orthogonal subspaces. The discrete-continuous hybrid action space is made differentiable by using a parameterized Beta distribution and Gumbel-Softmax reparameterization technique, which solves the policy oscillation problem caused by mixed action types in traditional single-agent models.

[0165] Step 206: Set the reward function to achieve coordinated incentives for microservice latency optimization and database consistency maintenance through multi-objective decomposition and constraint-aware penalty mechanism; the reward function includes: service latency reward, data consistency reward and resource efficiency reward.

[0166] The dual-agent system shares a composite reward signal comprising three key components: the service latency reward component optimizes end-to-end response time by normalizing latency violations using a hyperbolic tangent, as shown in the formula:

[0167]

[0168] in This represents the total request strength, and QoS constraints for prioritizing high-traffic services are implemented through a weighted average.

[0169] The data consistency reward component proportionally penalizes synchronization latency and replica synchronization traffic:

[0170]

[0171] in This indicates the maximum allowed synchronization delay as defined.

[0172] The resource efficiency reward component enhances computing resource stability through secondary overload penalties and core allocation incentives:

[0173]

[0174] In one possible implementation, the two agents employ a centralized training and distributed execution (CTDE) paradigm.

[0175] Central controller manages the value network during the centralized training phase. With the target network Each agent maintains its local policy network. .

[0176] The observation data stream uses an interactive transmission mode, where the agent sends observations to the controller. And receive timing differential error through feedback channel This bidirectional communication achieves collaborative policy updates through gradient calculation:

[0177]

[0178]

[0179] The QES-GP replica controller, acting as an auxiliary module during training, periodically transmits real-time resource contention metrics. To improve the accuracy of gradient calculation, parameter synchronization between agents uses coefficients. Soft update mechanism:

[0180]

[0181] After training convergence, the system switches to distributed execution mode, where the central controller and value network are deprecated, and each edge node retains the optimized policy network. Generate autonomous decision-making.

[0182] Microservice orchestration parameters Database routing weights Local computation through direct policy inference:

[0183]

[0184] This architecture eliminates the communication overhead between agents, reducing decision latency from Down to In dynamic request mode It achieves real-time adaptation while maintaining Pareto optimal resource allocation.

[0185] This invention provides a microservice and distributed database collaborative deployment system for edge computing networks. It constructs a microservice deployment topology model based on the computing power characteristics of edge computing nodes, extracts containerized service dependency chains, network latency matrices, and resource contention indicators, and establishes a decision space for dynamic orchestration of microservice instances. A distributed database multi-replica synchronization mechanism is built to address the performance constraints of monolithic databases on microservice applications and ensure eventual database consistency. Read / write traffic characteristics are modeled using queue theory, and an asynchronous multi-master replication strategy is adopted to optimize the balance between cross-node synchronization overhead and query latency. A joint strategy initialization method based on greedy-projection is designed to generate an initial solution for elastic scaling of data replicas in a three-dimensional decision space encompassing container deployment location, service routing paths, and database replica distribution. A distributed dual-agent reinforcement learning optimization engine is established, where the service orchestration agent generates deployment sequences and routing probability matrices through a dynamic masking strategy, and the database management agent adjusts the database replica distribution. A multi-objective value evaluation network is constructed by integrating end-to-end latency penalties, data inconsistency metrics, and resource constraint indicators, and Pareto policy gradients are used to achieve online dynamic optimization of the deployment strategy.

[0186] This invention designs a distributed database query and synchronization mechanism based on the DaaS (Database as a Service) paradigm. It adopts a layered, decoupled database architecture, building a layered, decoupled distributed database architecture on top of DaaS. Monolithic database tables are split into independent data services (DS), which are then encapsulated into isolated instances using containerization technology. This abstraction layer ensures that the microservice call interface is decoupled from the underlying database deployment, supporting the dynamic reorganization of data tables into lightweight logical groups called "micro-databases."

[0187] Establish joint resource allocation constraints for microservices and database replicas ,in This represents the number of replicas of database d on node e. This constraint reflects the zero-sum competition for CPU core resources between the microservice engine and database replicas, requiring collaborative optimization to avoid cascading latency degradation caused by local optimizations.

[0188] This invention provides a microservice and distributed database collaborative deployment system for edge computing networks. Based on a distributed fog computing network model, it quantifies the computing power (number of CPU cores), storage resources, network bandwidth and propagation latency of edge nodes into topology parameters to form a heterogeneous resource pool.

[0189] The geographic distribution characteristics of user requests are modeled using a Poisson process and dynamically mapped to edge nodes using coverage indicators. Nodes that meet the geographic coverage conditions are selected as service entry points.

[0190] To address the containerization characteristics of microservice architectures, a fine-grained resource isolation mechanism is established—each CPU core hosts only a single microservice instance or database copy, eliminating performance fluctuations caused by resource contention through hard constraints.

[0191] The end-to-end latency model of the service chain integrates multiple dimensions such as access latency, queue waiting, processing time, cross-node transmission, and database query. It uses Erlang-C formulas to accurately calculate queuing latency under different loads and achieves traffic aggregation and routing optimization through path probability matrix.

[0192] To address the performance bottlenecks of traditional databases in microservice architectures, a layered and decoupled Database-as-a-Service (DaaS) architecture is proposed. This involves splitting database tables into lightweight micro-databases and constructing a service-database access association matrix to quantify data dependencies. Different synchronization strategies are designed to cater to the characteristics of read and write operations: read-intensive services use static, asynchronous replicas, while write-intensive services utilize an asynchronous multi-master replication topology, allowing concurrent writes across nodes.

[0193] An incremental event stream generation mechanism and conflict resolution protocol are constructed. The Canal component is used to parse database logs in real time to generate event streams carrying operation semantics. Key-value routing is implemented through Kafka topic partitioning to ensure the sequentiality of operations with the same key.

[0194] The synchronous delay model integrates three factors: queue backlog, processing time, and network propagation. It rigorously guarantees eventual consistency through mathematical proof, thus avoiding the high latency defects of the traditional two-phase commit protocol.

[0195] We design a dual-agent reinforcement learning framework that decouples service orchestration and database management into two collaborative decision-making modules.

[0196] The Service Orchestration Agent (SOA) generates microservice deployment sequences through a dynamic masking mechanism and dynamically adjusts the routing probability matrix to optimize service chain latency; the Database Management Agent (DMA) uses an elastic scaling algorithm to regulate replica distribution and balance query efficiency with synchronization overhead.

[0197] The two work together through a shared multi-objective value evaluation network, with evaluation metrics covering dimensions such as end-to-end latency penalty, data inconsistency measurement, and resource contention intensity. The algorithm introduces Pareto policy gradient optimization techniques to find non-dominated solution sets among conflicting objectives, avoiding system imbalance caused by over-optimization of a single objective.

[0198] A queuing-based gradient projection elastic scaling algorithm is proposed to achieve real-time control of the number of database replicas. This algorithm maps continuous optimization results to a discrete integer solution space through projective gradient descent, and dynamically balances query latency, synchronization traffic, and resource utilization by combining an emergency scaling mechanism with resource safety constraints.

[0199] By designing a multi-objective cost function, the impact of the number of replicas on Erlang queue latency, multi-master synchronization traffic, and node resource contention is quantified. Gradient sensitivity analysis is used to derive the nonlinear response characteristics of queuing latency to the number of replicas. Lyapunov stability guarantees are employed to optimize the control period and learning rate, ensuring system convergence. During the training phase, a centralized collaborative evaluation network integrates observation data from two agents, updating policy parameters through backpropagation of temporal differential errors. During the execution phase, a decentralized mode is switched, with each node making autonomous decisions based on its local policy network, reducing decision latency to the O(|E|) order of magnitude.

[0200] The core breakthrough of this invention lies in resolving the inherent contradictions of edge computing through multi-layered technical coupling: 1) Dynamically linking service migration needs caused by user mobility with database synchronization operations, and reducing cross-node communication overhead through joint optimization of coverage indicators and routing weights; 2) Utilizing the additivity of Poisson flow to achieve hierarchical aggregation of microservice traffic, and dynamically adjusting replica distribution in conjunction with real-time queue pressure feedback; 3) Embedding resource validity masks and stability checks in the reinforcement learning action space to ensure that policy generation always conforms to physical resource boundaries; 4) Ensuring version consistency between microservice calls and database access through version vector optimistic locking protocol, avoiding the performance loss of traditional distributed transactions.

[0201] It should be noted that the descriptions of each embodiment in the above embodiments have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0202] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0203] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0204] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0205] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0206] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0207] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A microservice and distributed database collaborative deployment system for edge computing networks, characterized in that, The collaborative deployment system includes: a database layer, a microservice layer, a user layer, and a deployment module; The database layer includes multiple databases in a distributed architecture, each database having multiple replicas; the microservice layer includes multiple microservice instances; the deployment module includes: a database replica number dynamic optimization unit and a deployment strategy dynamic adjustment unit. After receiving microservice requests from various users, the user layer selects a routing path to access a copy of the database corresponding to the microservice user request; the routing path includes the microservice routing path and the database routing path through which the information between the user sending the microservice request and receiving the processing result is traversed. After the microservice requests to perform a write operation to any replica of the database, the database layer generates incremental events carrying operation semantics among multiple replicas of the database for incremental synchronization by parsing the database binary log in real time. The database replica number dynamic optimization unit obtains a dynamic optimization strategy for the number of database replicas based on a queuing gradient projection elastic scaling algorithm; the dynamic optimization strategy for the number of database replicas obtained by the database replica number dynamic optimization unit includes: The utilization rate of the collaborative deployment system is calculated in real time, and the utilization rate is... Increase the number of database replicas as needed; A comprehensive cost gradient function is constructed that includes query latency, synchronization pressure, and resource contention. Based on the comprehensive cost gradient function, the rounding projection method is used to adjust the number of replicas in the discrete database. When making the final decision on the number of database replicas, the upper limit of computing power is forcibly verified based on the resource constraints between end-to-end latency and the data inconsistency metric. The deployment strategy dynamic adjustment unit calculates end-to-end latency based on the microservice routing path and the database routing path; calculates data inconsistency metrics based on the number of each database replica; and dynamically adjusts the deployment strategy based on resource constraints between the end-to-end latency and the data inconsistency metrics, as well as the dynamic optimization strategy for the number of database replicas. The deployment strategy includes: microservice instance deployment, database replica deployment, and optimal routing path selection.

2. The collaborative deployment system according to claim 1, characterized in that, After receiving microservice requests from various users, the user layer selects a routing path through the following process: Step 101, represent the set of microservice requests issued by users in the mobile edge computing network as follows: ; Each service request Defined as a microservice chain sequence ,in, Each is a subset of microservice instances with strict execution dependencies, and the output of the preceding subset of microservice instances serves as the input of the subsequent subset of microservice instances. Step 102: Model the request flow generated by the microservice requests issued by users in each region u as triples. ; in, For the maximum tolerable latency, To meet coverage requirements First-reach edge node, request arrival rate It follows a Poisson process; Step 103, the request stream Generate a microservice chain sequence based on path selection probability. set of feasible paths ; Among them, any path Path selection probability , Indicates a service request Deployment nodes in the middle microservice instances Transfer to deployment node microservice instances The probability, and satisfying the probability normalization condition. , For each deployment node; among them Indicates a path; Feasible paths in the set of feasible paths Meet physical deployment constraints , Represents a microservice instance On the deployment node Deployment status on; Step 104: Dynamically select the optimal database replica based on queue pressure and communication latency, and select the replica based on routing constraints and routing path optimization objectives from the set of feasible paths. Determine the optimal route path; The routing constraints include: for any deployed node The sum of the path selection probabilities of downstream microservices is 1; when the service chain is executed, it is only allowed to flow to the specified successor microservice, otherwise the path selection probability is set to zero; the routing path optimization objective is to minimize the expected value of the end-to-end latency.

3. The collaborative deployment system according to claim 2, characterized in that, The end-to-end delay includes: access delay. , return delay And path delay accumulation; The path delay accumulation item includes: queue delay. Processing delay Transmission delay and database query latency .

4. The collaborative deployment system according to claim 1, characterized in that, The comprehensive cost function is: ； in, Indicates the database query queue latency; This represents the global synchronous traffic of multi-master asynchronous replication; Indicates the intensity of resource competition among edge nodes. This represents a custom upper limit on the intensity of resource contention on edge nodes. These are the weighting coefficients; Calculated using Erlang C formulas; ; This indicates the number of replicas of database d on node e. This represents the traffic to database d on node e. Represents a set of writable database replicas. This represents a set of heterogeneous edge nodes that have deployed replicas of the current database d.

5. The collaborative deployment system according to claim 1, characterized in that, The process of incrementally synchronizing multiple replicas of a database by generating incremental events carrying operational semantics includes: The Canal component parses the database binary logs in real time to generate incremental events carrying operation semantics. The event stream is routed to the target replica node through the message queue, and the order of operations with the same key is maintained based on key-value partitioning. The event is routed to the Kafka topic partition through the composite partitioning function, realizing the coordinated optimization of data locality and load balancing.

6. The collaborative deployment system according to claim 1, characterized in that, The deployment strategy dynamic adjustment unit includes: a dual-agent system; the dual-agent system includes: a microservice orchestration agent and a database management agent; The microservice orchestration agent generates a routing probability matrix of microservice instance deployment sequences and microservice routing paths through a dynamic masking strategy. The database management agent is used to adjust the database replica distribution and database routing paths; The dual-agent system captures the dynamic coupling characteristics of microservice orchestration and database management by designing a state-space hierarchical observation mechanism, and dynamically adjusts the deployment strategy by combining reinforcement learning methods of policy gradient and value function estimation.

7. The collaborative deployment system according to claim 6, characterized in that, The process of dynamically adjusting the deployment strategy includes: Step 201, Construct the global state ; Where G represents the topology of the mobile edge computing scenario, D represents the propagation delay matrix between heterogeneous edge nodes, E represents the set of heterogeneous edge nodes, and C represents... The set of CPU core counts of the nodes in the data. This indicates the number of replicas of database d on node e. Indicates the intensity of resource competition among edge nodes. This indicates the number of microservice instances m on node e. This indicates the number of CPU cores on node e; Step 202: Construct the state space of the microservice orchestration agent based on the global state. ; in, Indicates user request characteristics, This indicates the deployment characteristics of microservice instances; Step 203: Construct the state space of the database management agent based on the global state. ; in, Decision variables representing data access efficiency and latency. The observations representing the data consistency maintained by the database management agent include inconsistency time windows and synchronization flows; Step 204: The service orchestration agent uses a probabilistic sequence generation method, based on the target number of microservice instances. Build a microservice instance deployment sequence The deployment sequence of the microservice instances is randomized before each training cycle based on the Fisher-Yates shuffle algorithm. To eliminate topology bias; in the decision step, select the current microservice instance. And execute two-dimensional joint actions: deployment location selection ,in Dynamically mask based on resource availability; adjust the original route probability to... This indicates the probability that a request will be routed to this microservice instance; Step 205, the database management agent relocates the replicas. Use policy gradient and learning rate Update the routing weights to achieve fine-grained control over the distribution of database replicas and database routing paths; Step 206: Set a reward function to achieve coordinated incentives for microservice latency optimization and database consistency maintenance through multi-objective decomposition and constraint-aware penalty mechanism; the reward function includes: service latency reward, data consistency reward and resource efficiency reward.

8. The collaborative deployment system according to claim 6, characterized in that, The dual-agent system adopts a centralized training and decentralized execution paradigm. During the centralized training phase, the central controller manages the value network and the target network, while each agent maintains its local policy network. After training convergence, the system switches to distributed execution mode, where the central controller and value network are deprecated, and each edge node retains the optimized policy network to generate autonomous decisions.

Images