Micro-service architecture system based on business function and data double isolation

Abstract

The invention relates to a micro-service architecture system based on business function and data double isolation, and the system comprises a business function splitting module which splits a single application into independent micro-services; the data physical isolation module is used for distributing an independent database instance for each micro-service; the dynamic routing control module is used for dynamically distributing flow through a load sensing strategy and integrating a fusing mechanism; and the gray release module supports flow hierarchical diversion and abnormal automatic rollback, and ensures safe switching of service versions. According to the invention, by realizing double isolation of service functions and data, the independence and the expandability of the system are improved, and the data coupling degree and the maintenance cost are reduced; the stability and reliability of the system are ensured, and the risk in the migration process is reduced; according to the method, rapid iteration and continuous delivery can be realized, the development and deployment period of new functions is accelerated, and the user experience is improved through efficient service governance and data consistency guarantee, so that the system can better cope with challenges of high concurrent access and distributed transaction processing.

Description

Technical Field

[0001] This invention relates to the field of distributed system architecture technology, specifically a microservice architecture system based on dual isolation of business functions and data. Background Technology

[0002] Microservice architecture technology is widely used in the field of distributed systems. It breaks down traditional monolithic applications into multiple small, independent services (each running in an independent process) and uses lightweight communication mechanisms (such as HTTP APIs) to achieve inter-service collaboration. Common technology stacks (such as Spring Cloud and Kubernetes) provide core functionalities such as service registration and discovery, configuration management, and load balancing, but they still have significant shortcomings in the following aspects:

[0003] Performance and scalability issues caused by data coupling

[0004] Although services are split according to business functions, high coupling still exists at the data level. For example, the order service and the inventory service may share the same database table (such as the inventory table), leading to lock contention in high-frequency write scenarios and causing performance bottlenecks. When services are expanded, the data access logic of multiple services needs to be modified synchronously, significantly increasing development complexity and potential error risks.

[0005] Migration and Restructuring Risks

[0006] Data coupling necessitates coordinating data changes across multiple services during service migration or restructuring, potentially leading to system stability issues. For instance, migrating a user service that involves adjusting the data table structure of the order service could trigger a chain reaction of failures.

[0007] Distributed transaction complexity

[0008] Existing solutions (such as two-phase commit) sacrifice system throughput due to strong consistency requirements and struggle to achieve rapid fault recovery. For example, in distributed transaction scenarios, the latency and failure rate of cross-service data operations increase significantly.

[0009] Lax traffic management

[0010] Traditional load balancing strategies (such as round-robin) cannot detect the status of service instances, and may route requests to overloaded nodes in high-concurrency scenarios.

[0011] Difficulties in canary release and deployment

[0012] The existing architecture relies on manual operations to achieve canary releases and lacks automated rollback capabilities.

[0013] The information disclosed in this background section is intended only to enhance the understanding of the general background of the invention and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art. Summary of the Invention

[0014] To address the shortcomings of existing technologies, the present invention aims to provide a microservice architecture system based on dual isolation of business functions and data. By achieving dual isolation of business functions and data, the system's independence and scalability are improved, data coupling and maintenance costs are reduced, system stability and reliability are ensured, and risks during migration are reduced. Rapid iteration and continuous delivery are enabled, accelerating the development and deployment cycle of new features. Furthermore, through efficient service governance and data consistency assurance, user experience is improved, enabling the system to better cope with the challenges of high-concurrency access and distributed transaction processing.

[0015] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0016] A microservice architecture system based on dual isolation of business functions and data is characterized by including:

[0017] The business function decomposition module is used to divide the monolithic application into multiple independent microservices according to the domain model, clarify service boundaries based on domain-driven design, sort out core business processes through event storming, and define bounded contexts and interface contracts.

[0018] Based on ShardingSphere's database sharding and table partitioning physical isolation module, each microservice is allocated an independent database instance through the database middleware. By default, the order service exclusively uses the order_db instance, and the inventory service exclusively uses the stock_db instance.

[0019] The dynamic routing control module, combined with the API gateway and service mesh, enables dynamic traffic allocation, specifically including:

[0020] The API gateway serves as a unified entry point for external requests, handling north-south traffic, i.e., external requests, and defining static routing rules, JWT authentication, and Redis rate limiting strategies.

[0021] The service mesh manages east-west traffic, i.e., inter-service communication, through sidecar proxies. It dynamically adjusts traffic weights based on the load status of service instances and integrates a circuit breaker mechanism. The load status includes CPU utilization and response latency.

[0022] API gateways and service meshes share circuit breaker status to achieve layered traffic management;

[0023] The canary release module specifically includes:

[0024] Traffic coloring, through reverse proxy or front-end SDK to automatically inject HTTP request header tags, directs specific traffic to the new version of the service instance;

[0025] When deploying a canary instance, gradually redirect no more than 10% of requests to the new instance, monitor error rate and response time in real time, and dynamically adjust the traffic ratio.

[0026] Automatic rollback: When the failure rate of new instances exceeds a preset threshold, the container orchestration platform is triggered to automatically roll back to the old version and send an alarm notification; the preset threshold is 5% by default.

[0027] Based on the above technical solution, each microservice has its own complete business logic, and its deployment is isolated by managing code in an independent Git repository and using an independent Docker container, prohibiting direct calls to non-public interfaces across services.

[0028] Based on the above technical solutions, database sharding and table partitioning rules are defined in the database middleware to restrict cross-service database access; through the SQL firewall function of the database middleware, direct cross-service access to other services' databases is prohibited, and data interaction is forced through API interfaces or message queues.

[0029] Based on the above technical solutions, dynamic registration and instance discovery of microservices are achieved through a registry center, supporting automatic load balancing of inter-service communication;

[0030] The registry center employs a health check mechanism, periodically sending heartbeat checks to microservice instances and automatically removing unavailable nodes;

[0031] The registration center adopts a load balancing strategy, supports weight allocation and region-aware strategies, and uses a round-robin algorithm by default.

[0032] The registry center supports multi-datacenter deployment, enabling cross-cluster service discovery and traffic scheduling;

[0033] The registration center works in conjunction with the dynamic routing control module to automatically update the routing policies of the API gateway and service mesh when service instances are scaled up or down, ensuring dynamic traffic distribution and load balancing.

[0034] Based on the above technical solutions, a configuration center is set up to uniformly manage microservice configuration information, supporting dynamic updates, version rollback, and canary releases;

[0035] The configuration center pushes configuration changes to microservice instances in real time based on long polling or event listening mechanisms, without requiring service restarts;

[0036] Retains historical configuration versions and supports one-click rollback to a specified version;

[0037] Configure development, testing, and production environments separately to avoid parameter contamination between environments;

[0038] Record configuration modification logs, including the operator, time, and changes, and support hierarchical access control.

[0039] Based on the above technical solutions, service dependencies are decoupled through message queues, and data eventual consistency is ensured by combining a best-effort compensation mechanism.

[0040] Message queues use persistent storage to ensure that messages are not lost after being sent by the producer and before being confirmed by the consumer.

[0041] It supports a tiered retry strategy, retrying immediately on the first attempt, with subsequent intervals gradually increasing to 30 seconds, 5 minutes, and 10 minutes, with a maximum of 3 retries. After failure, it is transferred to a dead letter queue.

[0042] Consumers use a unique business ID to achieve idempotency verification, avoiding duplicate processing.

[0043] The producer sends transactional messages to ensure the atomicity of local transactions and message sending;

[0044] Integrate Prometheus and Grafana to monitor message backlog and consumption latency metrics, and trigger Slack alerts when anomalies occur.

[0045] Based on the above technical solution, after the message is transferred to the dead letter queue, the compensation scheduler scans the dead letter queue once per hour and triggers the compensation logic based on the unique business ID in the message.

[0046] Based on the above technical solutions, automated deployment, elastic scaling, and fault self-healing are achieved using a containerization platform, specifically including:

[0047] Automated deployment, defining the number of microservice replicas and resource quotas through YAML files;

[0048] Elastic scaling dynamically adjusts the number of instances based on CPU and memory utilization.

[0049] Self-healing: When a service instance fails, the container is automatically restarted or migrated to a healthy node.

[0050] Based on the above technical solutions, a secure inter-service communication module is also included to achieve end-to-end encryption and dynamic authentication of data transmission between microservices, specifically including:

[0051] Dynamic key management: Generates independent encryption keys for each microservice through the Key Management Service (KMS) and implements real-time key rotation for inter-service communication based on the TLS 1.3 protocol;

[0052] Zero Trust Authentication: Integrate role-based access control (RBAC) into API gateways and service meshes, using JWT tokens to carry service identity and permission information, and prohibit unauthorized services from accessing non-public interfaces;

[0053] Sensitive data masking: Define automatic masking rules for sensitive fields in the database middleware to ensure that only the masked logical identifier is returned when data is exchanged across services; sensitive fields include user mobile phone numbers and payment information.

[0054] Based on the above technical solutions, a hybrid cloud deployment module is also included to achieve unified service scheduling across public clouds, private clouds and edge nodes.

[0055] The microservice architecture system based on dual isolation of business functions and data described in this invention has the following beneficial effects:

[0056] 1. By using a data physical isolation module (based on ShardingSphere database sharding and table partitioning) and an asynchronous message queue (such as RocketMQ), storage layer decoupling and eventual consistency are achieved, avoiding cross-service lock contention.

[0057] 2. By implementing dual isolation of business functions and data storage, we ensure independent service migration. Combined with the automated rollback mechanism of the canary release module, we reduce the risk of refactoring.

[0058] 3. By adopting a best-effort compensation mechanism and RocketMQ transactional messages, cross-service data changes are processed asynchronously, avoiding the throughput loss of strong consistency protocols (such as two-phase commit) and achieving eventual consistency.

[0059] 4. By using the service mesh (Istio) and dynamic routing control module, traffic weights are dynamically adjusted based on instance load status, which solves the problem that traditional load balancing strategies cannot perceive instance status and optimizes resource allocation.

[0060] 5. By using traffic coloring and canary release mechanisms, anomalies are automatically detected and Kubernetes rolling rollback is triggered to ensure release security. Attached Figure Description

[0061] The present invention includes the following figures:

[0062] The accompanying drawings are provided to better understand the invention and are not intended to unduly limit the scope of the invention. Wherein:

[0063] Figure 1 The system architecture diagram of Embodiment 1 of the microservice architecture system based on dual isolation of business functions and data described in this invention. Detailed Implementation

[0064] The present invention will be further described in detail below with reference to the accompanying drawings. This detailed description is an illustration in conjunction with exemplary embodiments of the invention, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0065] like Figure 1 As shown, the microservice architecture system based on dual isolation of business functions and data according to the present invention includes:

[0066] The business function decomposition module is used to divide the monolithic application into multiple independent microservices according to the domain model, clarify service boundaries based on domain-driven design, sort out core business processes through event storming, and define bounded contexts and interface contracts.

[0067] Each microservice has its own complete business logic and uses an independent Git repository to manage the code and an independent Docker container to achieve deployment isolation, prohibiting direct cross-service calls to non-public interfaces;

[0068] Example: The order service and inventory service manage the order generation and inventory deduction logic respectively. The order service calls the public inventory deduction interface of the inventory service through the Feign client, and direct access to the internal API or database of the inventory service is prohibited.

[0069] By using fine-grained domain decomposition and strict interface contracts, the code coupling between services is reduced, supporting independent development and deployment, and significantly improving the maintainability and scalability of the system.

[0070] Based on ShardingSphere's database sharding and table partitioning physical isolation module, each microservice is allocated an independent database instance through the database middleware. By default, the order service exclusively uses the order_db instance, and the inventory service exclusively uses the stock_db instance.

[0071] Example: order_db and stock_db are independent MySQL cluster instances, not logical shards within the same database cluster;

[0072] Define database sharding and table partitioning rules in the database middleware to restrict cross-service database access; use the SQL firewall function of the database middleware to prohibit direct cross-service access to other services' databases and force data interaction through API interfaces or message queues.

[0073] Example: Define database sharding rules in the database middleware configuration file. The order service can only read and write tables in the order_db instance, and the inventory service can only access the stock_db instance. If the order service needs to obtain user information, it must call the public interface of the user service.

[0074] By physically isolating database instances, cross-service database lock contention and resource contention are completely avoided (e.g., high-frequency writes to order services do not affect inventory query performance), thereby improving system stability and high-concurrency processing capabilities.

[0075] The dynamic routing control module, combined with the API gateway and service mesh, enables dynamic traffic allocation, specifically including:

[0076] The API gateway serves as a unified entry point for external requests, handling north-south traffic, i.e., external requests, and defining static routing rules, JWT authentication, and Redis rate limiting strategies.

[0077] The service mesh manages east-west traffic, i.e., inter-service communication, through sidecar proxies. It dynamically adjusts traffic weights based on the load status of service instances and integrates a circuit breaker mechanism. The load status includes CPU utilization and response latency.

[0078] API gateways and service meshes share circuit breaker status to achieve layered traffic management;

[0079] Example: Configure static routing rules in the API gateway (such as Spring Cloud Gateway) to route requests for ` / api / order / **` to the order service cluster; the service mesh (such as Istio) monitors the status of inventory service instances, and when the response latency of an instance exceeds 500ms or the error rate exceeds 5%, the circuit breaker mechanism is triggered to switch traffic to healthy nodes;

[0080] By combining static rules and dynamic strategies, layered traffic governance is achieved, request distribution efficiency is optimized, cascading failure propagation is avoided, and the system's adaptability to high-concurrency scenarios is enhanced.

[0081] The canary release module specifically includes:

[0082] Traffic coloring, through reverse proxy or front-end SDK, automatically injects HTTP request header tags to direct specific traffic to a new version of the service instance; for example, testing user traffic by adding the HTTP request header X-User-Group:canary tag; this tag is preferably a unique tag, for example, traffic coloring generates user ID tags through a consistent hashing algorithm to ensure that requests from the same user are evenly distributed and always routed to the same version instance, avoiding inconsistencies in state;

[0083] When deploying a canary instance, gradually redirect no more than 10% of requests to the new instance, monitor error rate and response time in real time, and dynamically adjust the traffic ratio.

[0084] Automatic rollback: When the failure rate of new instances exceeds a preset threshold, the container orchestration platform is triggered to automatically roll back to the old version and send an alarm notification; the preset threshold is 5% by default.

[0085] Example: The frontend adds the X-User-Group:beta request header to test users, and the API gateway routes such requests to the new version of the order service; if the error rate of the new version exceeds the threshold, Kubernetes automatically triggers a rolling back operation;

[0086] By employing a gradual traffic switching and automated rollback mechanism, the risk of launching a new version is reduced, ensuring the continuous availability of the system.

[0087] This embodiment reduces code coupling by splitting business functions and achieves storage layer decoupling by combining an independent database instance strategy. This ensures that order service failures only affect its dedicated database instance (such as order_db) and do not lead to database lock contention in the inventory service. Specifically:

[0088] Business functions are broken down into modules, and based on domain-driven design, the monolithic application is split into independent microservices, clearly defining service boundaries and interface contracts.

[0089] The data physical isolation module allocates an independent database instance to each microservice through database sharding and table partitioning, prohibiting direct access to the database across services;

[0090] The dynamic routing control module integrates the API gateway and service mesh, dynamically allocates traffic based on instance load, and implements a circuit breaker mechanism.

[0091] The canary release module ensures safe switching between service versions through traffic coloring, canary release, and automatic rollback mechanisms.

[0092] Based on the above technical solutions, dynamic registration and instance discovery of microservices are achieved through a registry center, supporting automatic load balancing of inter-service communication;

[0093] The registry center employs a health check mechanism, periodically (e.g., every 30 seconds) sending heartbeat checks to microservice instances and automatically removing unavailable nodes;

[0094] The registration center adopts a load balancing strategy, supports weight allocation and region-aware strategies (such as prioritizing calls within the same data center), and uses a round-robin algorithm by default.

[0095] The registry center supports multi-datacenter deployment, enabling cross-cluster service discovery and traffic scheduling;

[0096] The registration center works in conjunction with the dynamic routing control module to automatically update the routing policies of the API gateway and service mesh when service instances are scaled up or down, ensuring dynamic traffic distribution and load balancing.

[0097] Example: Service registration and discovery are implemented using a registry center (such as Nacos). When the order service starts, it automatically registers instance information (IP, port, weight). The inventory service discovers the instance list through the registry center and completes the call based on a client-side load balancing component (such as Ribbon).

[0098] By leveraging dynamic awareness and load balancing mechanisms, the reliability of service communication is improved, the request failure rate is reduced, and elastic scaling capabilities are supported (routing policies are automatically updated when instances are scaled up or down).

[0099] Based on the above technical solutions, a configuration center is set up to uniformly manage microservice configuration information, supporting dynamic updates, version rollback, and canary releases;

[0100] The configuration center pushes configuration changes to microservice instances in real time based on long polling or event listening mechanisms, without requiring service restarts;

[0101] Retain historical configuration versions (such as the last 10 versions) and support one-click rollback to a specified version;

[0102] Configure development, testing, and production environments separately to avoid parameter contamination between environments;

[0103] Record configuration modification logs, including the operator, time, and changes, and support hierarchical access control.

[0104] Example: The development environment uses the `dev` namespace, and the production environment uses the `prod` namespace. The configurations are stored independently and do not affect each other. When dynamically updating, the database connection parameters (such as `spring.datasource.url`) of the order service are managed through a configuration center (such as Nacos). After modification, they are automatically pushed to all instances and take effect within 5 seconds. When the new configuration causes an exception, a historical version can be selected through the configuration center console to trigger a full rollback and notify the operations team.

[0105] Configuration changes take effect in real time through the configuration center, reducing downtime caused by service restarts; combined with version rollback and canary release mechanisms (such as applying new configurations to 10% of instances first), the system risks caused by configuration errors are reduced; audit logs and access control effectively prevent accidental operations and unauthorized access.

[0106] Based on the above technical solutions, service dependencies are decoupled through message queues, and data eventual consistency is ensured by combining a best-effort compensation mechanism.

[0107] Message queues use persistent storage (such as RocketMQ's CommitLog mechanism) to ensure that messages are not lost after being sent by the producer and before being confirmed by the consumer.

[0108] It supports a tiered retry strategy, retrying immediately on the first attempt, with subsequent intervals gradually increasing to 30 seconds, 5 minutes, and 10 minutes, with a maximum of 3 retries. After failure, it is transferred to a dead letter queue.

[0109] Consumers use a unique business ID (such as order number + operation type) to achieve idempotency verification and avoid duplicate processing;

[0110] Producers send transactional messages to ensure the atomicity of local transactions and message sending (such as the RocketMQ transactional message mechanism);

[0111] Integrate Prometheus and Grafana to monitor message backlog and consumption latency metrics, and trigger Slack alerts when anomalies occur; Prometheus is an open-source monitoring and alerting toolkit maintained by the Cloud Native Computing Foundation (CNCF) and widely used in cloud-native and microservice scenarios; Grafana is an open-source metrics visualization and analysis platform, often integrated with data sources such as Prometheus to build monitoring dashboards;

[0112] Example: The order service sends inventory deduction messages via RocketMQ, with the message body containing the order ID and the deduction quantity. When the inventory service fails to process the message, a tiered retry mechanism is triggered (up to 3 times). Upon final failure, the message is moved to a dead-letter queue, and an exception log is recorded. The inventory service verifies the order ID and operation type using a unique database index to prevent duplicate inventory deductions. After the message is moved to the dead-letter queue, a compensation scheduler (such as a scheduled task based on the Quartz framework) scans the queue hourly and triggers compensation logic based on the unique business ID in the message (e.g., order number + operation type), such as rolling back local transactions or notifying manual intervention. The introduction of the compensation scheduler and the scheduled task's period balances the real-time nature of fault recovery with system resource overhead.

[0113] By employing asynchronous processing and compensation mechanisms, system performance and data consistency are balanced; tiered retry and dead-letter queue mechanisms reduce the frequency of manual intervention; and a full-link monitoring system improves fault location efficiency and avoids the complexity of distributed transactions.

[0114] Based on the above technical solutions, automated deployment, elastic scaling, and fault self-healing are achieved using a containerization platform, specifically including:

[0115] Automated deployment, defining the number of microservice replicas and resource quotas through YAML files;

[0116] Elastic scaling dynamically adjusts the number of instances based on CPU and memory utilization.

[0117] Self-healing: When a service instance fails, the container is automatically restarted or migrated to a healthy node.

[0118] Based on the above technical solutions, a secure inter-service communication module is also included to achieve end-to-end encryption and dynamic authentication of data transmission between microservices, specifically including:

[0119] Dynamic key management: Generates independent encryption keys for each microservice through the Key Management Service (KMS) and implements real-time key rotation for inter-service communication based on the TLS 1.3 protocol;

[0120] Zero Trust Authentication: Integrate role-based access control (RBAC) into API gateways and service meshes, using JWT tokens to carry service identity and permission information, and prohibit unauthorized services from accessing non-public interfaces;

[0121] Sensitive data masking: Define automatic masking rules for sensitive fields in the database middleware to ensure that only the masked logical identifier is returned when data is exchanged across services; sensitive fields include user mobile phone numbers and payment information.

[0122] Example: When the order service calls the user service, it must carry an encrypted JWT token (containing the service identity identifier service_id=order). The user service verifies the token's validity through KMS, allowing it to access only the user's basic information interface and prohibiting access to the user's payment password interface. If the order service requests user payment information, the database middleware automatically returns a de-identified logical ID (such as payment_id=***) instead of plaintext data.

[0123] Based on the above technical solutions, a hybrid cloud deployment module is also included to achieve unified service scheduling across public clouds, private clouds and edge nodes.

[0124] Example: When a user initiates a request on an edge device, the API gateway prioritizes routing traffic to an edge node service instance in the same region; if the edge node is unavailable, it automatically switches to a public cloud instance and synchronizes edge data to the central database via a message queue.

[0125] Specifically, it includes:

[0126] Cross-cloud service discovery: Supports multi-cloud instance registration (such as AWS, Alibaba Cloud, edge nodes) through the registry center, and enables nearest routing based on geographical location tags (such as region=us-east);

[0127] Intelligent traffic scheduling: Integrate a latency and cost-based weighting algorithm into the service mesh to dynamically select the optimal service instance (prioritizing low-latency instances in the same region and using high-cost cloud instances as alternatives);

[0128] Edge computing adaptation: Design lightweight microservice containers (such as WebAssembly-based runtimes) for edge nodes to support local data processing and asynchronous synchronization in offline scenarios.

[0129] The contents not described in detail in this specification are existing technologies known to those skilled in the art.

[0130] The above description is only a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. Any equivalent modifications or changes made by those skilled in the art based on the content disclosed in the present invention should be included in the scope of protection set forth in the claims.

Claims

1. A microservice architecture system based on dual isolation of business functions and data, characterized in that, include: The business function decomposition module is used to divide the monolithic application into multiple independent microservices according to the domain model, clarify service boundaries based on domain-driven design, sort out core business processes through event storming, and define bounded contexts and interface contracts. Based on ShardingSphere's database sharding and table partitioning physical isolation module, each microservice is allocated an independent database instance through the database middleware. By default, the order service exclusively uses the order_db instance, and the inventory service exclusively uses the stock_db instance. The dynamic routing control module, combined with the API gateway and service mesh, enables dynamic traffic allocation, specifically including: The API gateway serves as a unified entry point for external requests, handling north-south traffic, i.e., external requests, and defining static routing rules, JWT authentication, and Redis rate limiting strategies. The service mesh manages east-west traffic, i.e., inter-service communication, through sidecar proxies. It dynamically adjusts traffic weights based on the load status of service instances and integrates a circuit breaker mechanism. The load status includes CPU utilization and response latency. API gateways and service meshes share circuit breaker status to achieve layered traffic management; The canary release module specifically includes: Traffic coloring, through reverse proxy or front-end SDK to automatically inject HTTP request header tags, directs specific traffic to the new version service instance; When deploying a canary instance, gradually redirect no more than 10% of requests to the new instance, monitor error rate and response time in real time, and dynamically adjust the traffic ratio. Automatic rollback: When the failure rate of new instances exceeds a preset threshold, the container orchestration platform is triggered to automatically roll back to the old version and send an alarm notification; the preset threshold is 5% by default.

2. The microservice architecture system based on dual isolation of business functions and data as described in claim 1, characterized in that, Each microservice has its own complete business logic, and its deployment is isolated by managing code in an independent Git repository and using an independent Docker container, prohibiting direct calls to non-public interfaces across services.

3. The microservice architecture system based on dual isolation of business functions and data as described in claim 1, characterized in that, Define database sharding and table partitioning rules in the database middleware to restrict cross-service database access; use the SQL firewall function of the database middleware to prohibit direct cross-service access to other services' databases and force data interaction through API interfaces or message queues.

4. The microservice architecture system based on dual isolation of business functions and data as described in claim 1, characterized in that, Dynamic registration and instance discovery of microservices are achieved through a registry center, supporting automatic load balancing for inter-service communication; The registry center employs a health check mechanism, periodically sending heartbeat checks to microservice instances and automatically removing unavailable nodes; The registration center adopts a load balancing strategy, supports weight allocation and region-aware strategies, and uses a round-robin algorithm by default. The registry center supports multi-datacenter deployment, enabling cross-cluster service discovery and traffic scheduling; The registration center works in conjunction with the dynamic routing control module to automatically update the routing policies of the API gateway and service mesh when service instances are scaled up or down, ensuring dynamic traffic distribution and load balancing.

5. The microservice architecture system based on dual isolation of business functions and data as described in claim 1, characterized in that, Set up a configuration center to uniformly manage microservice configuration information, supporting dynamic updates, version rollback, and canary releases; The configuration center pushes configuration changes to microservice instances in real time based on long polling or event listening mechanisms, without requiring service restarts; Retains historical configuration versions and supports one-click rollback to a specified version; Configure development, testing, and production environments separately to avoid parameter contamination between environments; Record configuration modification logs, including the operator, time, and changes, and support hierarchical access control.

6. The microservice architecture system based on dual isolation of business functions and data as described in claim 1, characterized in that, Decouple service dependencies through message queues and ensure eventual data consistency by combining a best-effort compensation mechanism; Message queues use persistent storage to ensure that messages are not lost after being sent by the producer and before being confirmed by the consumer. It supports a tiered retry strategy, retrying immediately on the first attempt, with subsequent intervals gradually increasing to 30 seconds, 5 minutes, and 10 minutes, with a maximum of 3 retries. After failure, it is transferred to a dead letter queue. Consumers use a unique business ID to achieve idempotency verification, avoiding duplicate processing. The producer sends transactional messages to ensure the atomicity of local transactions and message sending; Integrate Prometheus and Grafana to monitor message backlog and consumption latency metrics, and trigger Slack alerts when anomalies occur.

7. The microservice architecture system based on dual isolation of business functions and data as described in claim 6, characterized in that, After a message is transferred to the dead-letter queue, the compensation scheduler scans the dead-letter queue once an hour and triggers the compensation logic based on the unique business ID in the message.

8. The microservice architecture system based on dual isolation of business functions and data as described in claim 1, characterized in that, Automated deployment, elastic scaling, and fault self-healing based on a containerized platform are achieved, specifically including: Automated deployment, defining the number of microservice replicas and resource quotas through YAML files; Elastic scaling dynamically adjusts the number of instances based on CPU and memory utilization. Self-healing: When a service instance fails, the container is automatically restarted or migrated to a healthy node.

9. The microservice architecture system based on dual isolation of business functions and data as described in claim 1, characterized in that, It also includes a secure inter-service communication module, used to implement end-to-end encryption and dynamic authentication for data transmission between microservices, specifically including: Dynamic key management: Each microservice generates an independent encryption key through the Key Management Service (KMS), and real-time key rotation for inter-service communication is achieved based on the TLS 1.3 protocol; Zero Trust Authentication: Integrate role-based access control (RBAC) into API gateways and service meshes, using JWT tokens to carry service identity and permission information, and prohibit unauthorized services from accessing non-public interfaces; Sensitive data masking: Define automatic masking rules for sensitive fields in the database middleware to ensure that only the masked logical identifier is returned when data is exchanged across services; sensitive fields include user mobile phone numbers and payment information.

10. The microservice architecture system based on dual isolation of business functions and data as described in claim 9, characterized in that, It also includes a hybrid cloud deployment module, which enables unified scheduling of services across public clouds, private clouds, and edge nodes.

Images