A palm social security business optimization method based on distributed and micro-service architecture

Abstract

This invention proposes a method for optimizing mobile social security services based on a distributed and microservice architecture. Its technological breakthroughs are manifested in three core aspects: Elastic Service Cloud Network: Based on the self-developed PDFC framework, Spring Cloud microservice architecture, and Kubernetes containerization technology, microservices are deployed in a split manner, enabling dynamic scaling of microservice container nodes and second-level fault self-healing. Intelligent Data Hub: A cross-domain data channel is built based on Apache Kafka, collecting social security business data and health record data in real time with millisecond-level transmission efficiency. Intelligent Reporting Engine: An innovative three-dimensional intelligent reporting system is constructed. Pre-event reports are generated by parsing physical examination information; during-event reports are generated through dynamic monitoring of risk warnings; and post-event reports are generated based on actual business processing, achieving an upgrade and transformation of the governance model from "people seeking services" to "services benefiting people."

Description

Technical Field

[0001] This invention belongs to the field of social security business system architecture design technology, specifically involving a mobile social security business optimization method based on distributed and microservice architecture. Background Technology

[0002] As a core infrastructure in the public service sector, the social security system faces increasing challenges due to its traditional monolithic architecture, which is no longer sufficient to meet the high-concurrency processing needs of provincial-level unified management areas as digital transformation accelerates. In response, a distributed social security business processing system has been constructed through the collaborative operation of Spring Cloud microservice architecture, Kubernetes containerized deployment, and Kafka message queues. Specifically, this system covers the entire process from service registration and discovery (Eureka), API gateway routing (Zuul), to data persistence (Gaussian Database), including key aspects such as RESTful API communication, Spark data cleaning engine, and Redis caching mechanism. Domestic adaptation has become a crucial direction for technological evolution, with the combined application of the PDFC framework and Gaussian Database driving breakthroughs in data security and self-controllability within the social security system.

[0003] However, existing technical solutions directly adopt the traditional monolithic architecture pattern, failing to achieve deep decoupling of service modules. This leads to technical bottlenecks such as system response delays (service unavailability during peak hours), inefficient development and maintenance (code conflict rate reaches 30%, and full build takes more than 2 hours). Based on existing technology, as the integration of medical insurance systems is promoted in various cities and districts, the mobile social security system is experiencing increasingly slower response times, impacting user experience. The monolithic application technology results in low development efficiency (developers modify code in a unified project, waiting for each other, and constant conflicts), difficult maintenance (code and functions are tightly coupled), inflexibility (long build times, any small modification requires a complete project refactoring), poor stability (a minor problem can cause the entire application to crash), and insufficient scalability (unable to meet business needs under high concurrency), among other technical architectural bottlenecks. Summary of the Invention

[0004] The present invention aims to at least partially solve one of the technical problems in the related art.

[0005] Therefore, the first objective of this invention is to propose a method for optimizing mobile social security services based on a distributed and microservice architecture.

[0006] The second objective of this invention is to propose a mobile social security service optimization device based on a distributed and microservice architecture.

[0007] The third objective of this invention is to provide a computer device.

[0008] A fourth objective of this invention is to provide a non-transitory computer-readable storage medium.

[0009] To achieve the above objectives, a first aspect of the present invention proposes a method for optimizing mobile social security services based on a distributed and microservice architecture, comprising: S1, based on the self-developed PDFC framework and SpringCloud microservice architecture, splits the social security business system into independently deployed user information service, business processing service and data query service modules to achieve decoupling of business functions; S2 uses Kubernetes containerization technology to dynamically scale up and down each microservice node, and combines Zuul gateway and Nginx load balancing components to build an elastic service cloud network, improving the system's concurrent processing capabilities. S3 employs a circuit breaker mechanism to implement dedicated circuit breaker strategies for high-frequency business modules such as changes in insurance status and benefit calculations. It also monitors the service health status in real time through the service registration center and automatically isolates faulty nodes. S4 establishes a cross-domain data channel based on Kafka message queues, and combines TCC distributed transactions and event-driven architecture to ensure data consistency between microservices, completing the real-time synchronization of social security business data and health record data.

[0010] In one embodiment of the present invention, S1 includes: S11 deploys the user information microservice, social security business processing microservice, and data query microservice on independent Kubernetes container nodes, and performs service discovery and health checks through the service registry center. S12 uses the PDFC framework's configuration center to implement independent configuration management for each microservice, and distributes user requests to the corresponding microservice instances through the routing rules of the Zuul gateway.

[0011] In one embodiment of the present invention, S2 includes: S21 dynamically adjusts the number of Kubernetes container nodes based on CPU utilization and memory usage. When the resource utilization of any node exceeds 85% for 5 consecutive minutes, a scaling operation is triggered. S22 uses the Nginx load balancing component to distribute request traffic using a weighted round-robin algorithm, combined with the Zuul gateway's minimum connection count algorithm to achieve two-layer load balancing.

[0012] In one embodiment of the present invention, S3 further includes: S31, for the insurance status change module, the circuit breaker threshold is set to trigger when the failure rate of 10 consecutive requests exceeds 30%, and the circuit breaker duration is dynamically adjusted according to the service recovery status; S32 collects the response time and error rate metrics of each microservice in real time through the health check interface of the service registry, and automatically removes a service instance from the service list when it is detected that the instance is unavailable.

[0013] In one embodiment of the present invention, S4 includes: S41 uses Kafka's partitioning strategy to store social security data and health record data in separate topics, with each topic configured with 3 replicas to ensure data reliability; S42 achieves eventual consistency by pre-allocating resources in the Try phase, committing the transaction in the Confirm phase, and rolling back operations in the Cancel phase of the TCC transaction, combined with an event-driven architecture.

[0014] To achieve the above objectives, a second aspect of the present invention proposes a mobile social security service optimization device based on a distributed and microservice architecture, comprising: The microservice decomposition and registration module is used to decompose the social security business system into multiple independent microservice units based on the self-developed PDFC framework and Spring Cloud microservice architecture, and to realize the automatic registration and health check of each microservice through the service registry center. The containerized dynamic deployment module is used to dynamically scale up and down the microservice unit using Kubernetes containerization technology, and to achieve second-level elastic adjustment of container nodes by combining real-time monitoring data. The request routing and circuit breaker control module is used to perform routing filtering and access control on user requests through the Zuul gateway, realize lightweight asynchronous communication between microservices using RESTful API and Kafka message queue, and configure the circuit breaker component to establish dedicated circuit breaker strategies for changes in insurance status and benefit calculation. The transaction consistency and CICD management module is used to ensure the consistency of social security data and health record data across microservices based on a distributed transaction management mechanism and event-driven architecture, and to realize the independent construction, deployment and version update of each microservice through the CICD pipeline.

[0015] The present invention discloses a method and apparatus for optimizing mobile social security services based on a distributed and microservice architecture, which can effectively improve the scalability, stability and response efficiency of the social security service system, realize modular deployment and elastic scaling, ensure business processing capabilities and data consistency in high-concurrency scenarios, and enhance the intelligence level of business processing through an intelligent reporting engine, significantly reducing development and maintenance costs and the scope of failure impact.

[0016] To achieve the above objectives, a third aspect of this application provides a computer device, including a processor and a memory; wherein the processor reads executable program code stored in the memory to run a program corresponding to the executable program code, so as to implement a mobile social security business optimization method based on a distributed and microservice architecture as described in the first aspect embodiment.

[0017] To achieve the above objectives, the fourth aspect of this application proposes a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements a mobile social security business optimization method based on a distributed and microservice architecture as described in the first aspect embodiment.

[0018] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0019] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart of a mobile social security service optimization method based on a distributed and microservice architecture according to an embodiment of the present invention; Figure 2 This is an architecture diagram of a mobile social security service optimization method based on a distributed and microservice architecture according to an embodiment of the present invention. Figure 3 This is a structural diagram of a mobile social security business optimization device based on a distributed and microservice architecture according to an embodiment of the present invention. Figure 4 It is a computer device according to an embodiment of the present invention. Detailed Implementation

[0020] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

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

[0022] The following description, with reference to the accompanying drawings, describes a method and apparatus for optimizing mobile social security services based on a distributed and microservice architecture, according to an embodiment of the present invention.

[0023] Figure 1 This is a flowchart of a mobile social security service optimization method based on a distributed and microservice architecture according to an embodiment of the present invention, such as... Figure 1 As shown, it includes: S1, based on the self-developed PDFC framework and Spring Cloud microservice architecture, splits the social security business system into independently deployed user information service, business processing service and data query service modules, thereby achieving decoupling of business functions.

[0024] In some implementations, the system adopts the Spring Cloud component architecture, including Eureka as the service registry center to implement automatic service registration and discovery mechanisms. Inter-service communication is based on RESTful APIs, with unified routing, authentication, and request filtering through the Zuul gateway to ensure lightweight and secure inter-service interactions. Simultaneously, Nginx is used for load balancing to improve service call stability and response efficiency. For service fault tolerance, the Hystrix circuit breaker mechanism is introduced, with custom circuit breaker policies set for high-frequency operations in the social security system (such as changes in insurance status and benefit calculations) to prevent system-wide unavailability due to single points of failure.

[0025] Specifically, after service decomposition, each microservice can be deployed and scaled independently, supporting dynamic resource scheduling via the Kubernetes container orchestration platform. Overall system availability reaches 99.99%, with annual downtime controlled within 5 minutes. Service response time remains at the millisecond level under high-concurrency scenarios, and business processing throughput reaches 600 TPS, more than three times that of traditional architectures, meeting the processing needs of the provincial social security system during peak periods.

[0026] Furthermore, S1 includes: S11 deploys the user information microservice, social security business processing microservice, and data query microservice on separate Kubernetes container nodes, and uses the service registry Eureka for service discovery and health checks.

[0027] In some implementations, each microservice is encapsulated as a Docker container and deployed and exposed through Kubernetes Deployment and Service resource objects. The user information microservice is responsible for user authentication, permission management, and basic information maintenance; the social security business processing microservice handles core business logic such as enrollment registration and benefit calculation; and the data query microservice provides a unified access interface for social security data and health record data. Each microservice registers its own service metadata (such as IP address, port, health status, etc.) through the Eureka Server and periodically sends heartbeats to maintain its registration status. Service callers obtain a list of service instances through the Eureka Client and implement service calls using load balancing strategies (such as Ribbon).

[0028] Specifically, Eureka's health check mechanism performs a heartbeat check every 30 seconds by default. If there are three consecutive unresponsive attempts, the service instance is deemed unavailable and removed from the registry. Kubernetes health checks (Liveness / Readiness Probe) can be configured with parameters such as the HTTP interface path, response timeout (e.g., timeoutSeconds=5), and failure threshold (failureThreshold=3) to ensure that services can be restarted promptly or isolated from traffic in case of anomalies. The availability metric of the service registry should reach above 99.99% to ensure the overall stability of the system.

[0029] S12 uses the PDFC framework's configuration center to implement independent configuration management for each microservice, and distributes user requests to the corresponding microservice instances through the routing rules of the Zuul gateway.

[0030] In some implementations, this invention combines the PDFC framework's configuration center with the Zuul gateway to achieve independent configuration management and request routing distribution for each microservice. The PDFC framework, a distributed service governance platform developed by PICC, supports dynamic configuration loading and hot updates in its configuration center module. This allows each microservice instance to obtain corresponding configuration information based on its own business needs at runtime, thereby achieving service decoupling and flexible management. Configuration information is typically stored in the configuration center in YAML or Properties format and synchronized in real time through the service instance's configuration retrieval interface (e.g., ` / config / {service-name} / {profile}`), ensuring that configuration changes take effect without requiring a service restart.

[0031] As the unified entry point of the system, the Zuul gateway is responsible for receiving external user requests and distributing them to the corresponding microservice instances according to predefined routing rules. Routing rules are typically configured based on service name, path matching, and load balancing strategies (such as round-robin, weighted round-robin, or consistent hashing). During request processing, the Zuul gateway first performs authentication and authorization, verifying the user token using the OAuth 2.0 protocol to ensure the request originates legitimately. Subsequently, the gateway forwards the request to the corresponding microservice's load balancer (such as Ribbon) according to the routing rules, whereby the load balancer selects a healthy instance for processing. This process supports timeout control (e.g., a default timeout of 1000ms), retry mechanisms (e.g., a maximum of 3 retries), and circuit breaker strategies (e.g., a Hystrix circuit breaker threshold of 50% error rate and a recovery time of 5000ms after a circuit breaker).

[0032] S2 uses Kubernetes containerization technology to dynamically scale up and down each microservice node, and combines Zuul gateway and Nginx load balancing components to build an elastic service cloud network, thereby improving the system's concurrent processing capabilities.

[0033] In some implementations, Kubernetes clusters use the HPA (Horizontal Pod Autoscaler) mechanism to automatically scale up and down based on CPU utilization, memory usage, or custom metrics (such as request queue length). Specifically, the system sets threshold parameters; for example, when the CPU utilization of a microservice exceeds 80% for more than 5 minutes, Kubernetes automatically increases the number of Pod replicas according to a preset scaling strategy, and decreases it otherwise. Furthermore, the Zuul gateway, as the unified entry point of the system, is responsible for request routing, filtering, and authentication. Its routing rules are dynamically loaded through YAML configuration files, supporting routing strategies based on paths, headers, or cookies. Nginx, acting as a reverse proxy and load balancer, is deployed on top of Zuul and uses round-robin or weighted round-robin algorithms to evenly distribute requests to backend microservice instances, improving overall throughput.

[0034] Specifically, in the Kubernetes HPA configuration, the minimum number of replicas for scaling is set to 2, the maximum number of replicas is set to 20, the target CPU utilization is 70%, and the update cycle is 30 seconds. The Zuul gateway's timeout parameter is set to `zuul.timeout=5000ms`, the circuit breaker threshold is `hystrix.command.default.circuitBreaker.requestVolumeThreshold=20`, and the circuit breaker error rate threshold is `hystrix.command.default.circuitBreaker.errorThreshold=50%`. In the Nginx load balancing configuration, the `upstream` module defines the IPs and ports of multiple microservice instances, the load balancing algorithm uses `least_conn`, and `keepalive_timeout=65s` is set to optimize long-connection performance.

[0035] Furthermore, S2 includes: S21 dynamically adjusts the number of Kubernetes container nodes based on CPU utilization and memory usage. When the resource utilization of any node exceeds 85% for 5 consecutive minutes, a scaling operation is triggered.

[0036] In some implementations, this invention achieves elastic scaling of Kubernetes container nodes through a dynamic resource scheduling mechanism based on CPU utilization and memory usage, thereby ensuring the stable operation and optimized resource utilization of the mobile social security service system under high-concurrency scenarios. The technical implementation principle of this step is based on containerized resource monitoring and automated orchestration strategies, and the specific operation method is as follows: In a Kubernetes cluster, the resource usage (including CPU and memory) of each container node is collected in real time by the cluster's built-in monitoring components (such as Metrics Server) and aggregated for analysis using monitoring systems like Prometheus. The system sets a resource usage threshold of 85% and requires this threshold to be exceeded continuously for 5 minutes to avoid unintended scaling due to sudden load fluctuations. Specifically, the system calculates the average CPU usage over a time window using a Prometheus query, while memory usage is normalized using `container_memory_usage_bytes / container_memory_limit_bytes` and also assessed using a moving average over a 5-minute window.

[0037] When the CPU or memory utilization of any node continuously exceeds a threshold within 5 minutes, the system triggers a horizontal scaling mechanism via HPA (Horizontal Pod Autoscaler). HPA dynamically increases the number of Pod replicas based on preset scaling policies (e.g., `scaleTargetRef` specifies the target microservice, and `minReplicas` and `maxReplicas` set the minimum and maximum number of container instances), thereby improving system processing capacity. In this invention, the HPA scaling policy can be configured as follows: `minReplicas=3`, `maxReplicas=20`, `scaleUpPolicy` set to add a maximum of 2 Pods per minute, and `scaleDownPolicy` set to remove a maximum of 1 Pod per minute, to avoid resource waste and system instability caused by frequent scaling.

[0038] S22 uses the Nginx load balancing component to distribute request traffic using a weighted round-robin algorithm, combined with the Zuul gateway's minimum connection count algorithm to achieve two-layer load balancing.

[0039] Specifically, in some implementations, this invention achieves a two-layer load balancing mechanism through the collaborative work of the Nginx load balancing component and the Zuul gateway, thereby improving the overall throughput and service response efficiency of the system. Specifically, Nginx, as a front-end load balancer, uses a weighted round-robin algorithm to initially distribute request traffic. This algorithm dynamically adjusts the request distribution ratio based on the processing capacity of each backend service node by configuring a weight parameter (such as `weight=10` or `weight=20`), thus achieving optimal resource utilization. In Nginx configuration, the service cluster is typically defined through the `upstream` module, and the `least_conn` or `weight` parameter is set to control the traffic distribution strategy.

[0040] Furthermore, as the API gateway in a microservice architecture, the Zuul gateway employs the Least Connections algorithm for secondary load balancing. This algorithm calculates the current number of connections for each microservice instance in real time and distributes new requests to the instance with the fewest connections, thereby reducing service response latency and improving resource utilization. Zuul's load balancing strategy is typically integrated into the Ribbon client and implemented by configuring `NFLoadBalancerRuleClassName` to `com.netflix.loadbalancer.LeastConnectionsRule`.

[0041] S3 employs a circuit breaker mechanism to implement dedicated circuit breaker strategies for high-frequency business modules such as changes in insurance status and benefit calculations. It also monitors the health status of services in real time through the service registration center and automatically isolates faulty nodes.

[0042] In some implementations, this invention employs a circuit breaker mechanism to implement dedicated circuit breaking strategies for high-frequency business modules such as insurance status changes and benefit calculations, thereby improving the system's stability and fault tolerance in high-concurrency scenarios. This mechanism is implemented based on Hystrix or Resilience4j components in the Spring Cloud ecosystem. It monitors the health status of each microservice node in real time through a service registry (such as Eureka), including key indicators such as response time, failure rate, and thread pool utilization. When the failure rate of a service instance exceeds a preset threshold (e.g., 10 consecutive failed requests or a failure rate exceeding 50%), the circuit breaker automatically triggers its circuit breaking logic, isolating the node from the service list to prevent the fault from spreading and reduce the impact on overall system performance.

[0043] Furthermore, the circuit breaker strategy has been customized to address the specific characteristics of social security operations. For example, in the benefits calculation module, the circuit breaker can be set with a timeout threshold. milliseconds, failure rate threshold is After a circuit breaker is triggered, degradation logic can be enabled, such as returning cached results or default values, to ensure user experience. Simultaneously, the circuit breaker supports an automatic recovery mechanism; when the service health status returns to a normal threshold (e.g., 5 consecutive successful requests), it automatically reconnects to the service pool, achieving dynamic service governance.

[0044] Furthermore, S3 includes: S31 sets the circuit breaker threshold for the insurance status change module to trigger circuit breaking when the failure rate of 10 consecutive requests exceeds 30%, and the duration of circuit breaking is dynamically adjusted according to the service recovery status.

[0045] Specifically, a circuit breaker threshold is set for the insurance status change module: a circuit breaker is triggered when the failure rate of 10 consecutive requests exceeds 30%. This mechanism is based on the service fault tolerance design in a microservice architecture, aiming to improve the stability and availability of the system under high concurrency or service anomalies. In the specific technical implementation, the circuit breaker strategy uses mainstream circuit breaker components such as Hystrix or Sentinel, and a monitoring module performs real-time statistics and evaluation of the request status of the insurance status change interface. The threshold is set when the number of failures in 10 consecutive requests exceeds 30%. Meet the conditions When the circuit breaker switches to the "open" state, subsequent requests will no longer directly call the service, but will instead enter the circuit breaker degradation logic, returning a preset default response or error message, thereby avoiding the cascading failure effect.

[0046] Circuit break duration A dynamic adjustment mechanism is employed, adaptively controlling the system based on the service recovery status. After the circuit breaker is opened, the system initiates a half-open probe window, typically set to... Within a few seconds, a small number of requests (e.g., 3 times) are allowed to attempt to call the original service. If the number of successful requests is [number missing], [the service will be terminated]. satisfy If the circuit breaker closes, normal service calls resume; otherwise, it remains in the circuit-broken state until the service stabilizes. This mechanism complies with the Service Level Agreement (SLA) standard in microservice governance, ensuring a rapid response in the event of service anomalies while avoiding business interruptions caused by accidental circuit breakers.

[0047] S32 collects the response time and error rate metrics of each microservice in real time through the health check interface of the service registry, and automatically removes a service instance from the service list when it is detected that the instance is unavailable.

[0048] In some implementations, real-time collection of key metrics such as response time and error rate of each microservice through the health check interface of the service registry is a crucial mechanism for ensuring high system availability and elastic service scheduling. This step, based on the Spring Cloud microservice architecture and combined with the health check interface provided by the service registry (such as Eureka or Nacos), enables monitoring and automatic removal of service instances from the runtime environment. Specifically, the health check interface typically returns the health status code of the service instance (HTTP 200 indicates healthy, HTTP 503 indicates unavailable) via an HTTP endpoint (such as ` / actuator / health`), and can be extended to return detailed health metrics, such as response time (in milliseconds), error rate (in percentage), memory usage, and thread pool status.

[0049] Specifically, the service registry periodically sends health probe requests to each registered microservice instance, with the probe frequency configurable as follows: seconds, timeout threshold seconds. If continuous If the health check fails, the service instance is deemed unavailable and automatically removed from the service registry, thus preventing requests from being routed to the faulty node. The system also supports an automatic recovery mechanism after a health check failure; once the service instance recovers, it can be re-registered and added back to the service list.

[0050] S4 establishes a cross-domain data channel based on Kafka message queues, and combines TCC distributed transactions and event-driven architecture to ensure data consistency between microservices, completing the real-time synchronization of social security business data and health record data.

[0051] In some implementations, Kafka, as a message broker, is deployed in a dedicated, highly available cluster, employing partitioning and replication mechanisms to ensure message order and reliability. Message producers encapsulate social security business data (such as changes in insurance status and benefit calculation results) and health record data (such as physical examination reports and chronic disease records) into structured event messages, publishing them to designated topics via a RESTful API or Kafka production interface. Consumers subscribe to relevant topics through Kafka consumer groups and, during consumption, execute the Try phase of a TCC transaction, attempting local resource locking (such as database row locks and cache pre-emption). If all participants successfully complete the Try phase, the data is committed in the Confirm phase; if any participant fails, the Cancel phase is triggered to roll back the transaction, thus preventing data inconsistency.

[0052] Specifically, in the Kafka cluster configuration, message persistence uses the `acks = all` strategy, ensuring that a write is considered successful only after all replicas have acknowledged receipt. On the consumer side, `enable.auto.commit = false` is set, combined with a manual offset commit mechanism, to prevent message duplication or loss due to abnormal interruptions. In TCC transactions, Confirm and Cancel operations must be performed within... Completed within the time window to ensure eventual consistency of the transaction, where The timeout is typically set to 300ms to 500ms, depending on the service response latency and network environment.

[0053] Furthermore, S4 includes: S41 uses Kafka's partitioning strategy to store social security data and health record data in separate topics, with each topic configured with 3 replicas to ensure data reliability.

[0054] To ensure high data reliability and fault tolerance, each topic is configured with 3 replicas (replicationfactor = 3), distributed across different Kafka nodes. Kafka's replica management mechanism enables data synchronization and failover. In Kafka, replicas are divided into leaders and followers. The leader handles read and write operations, while followers asynchronously replicate the leader's data. When the leader node fails, the system automatically elects a follower as the new leader, thus ensuring continuous data availability. This mechanism conforms to Kafka's high availability standards (such as the ISR mechanism supported by Kafka 0.11+) and meets the social security system's requirements for data persistence and consistency.

[0055] Specifically, the number of partitions (`num.partitions`) for each topic can be dynamically configured based on business throughput, typically set to a value matching the number of consumer threads to achieve load balancing. The replication factor (`replication.factor`) is set to 3 to ensure data recovery even if any two nodes fail. Furthermore, Kafka's `min.insync.replicas` parameter can be set to 2 to guarantee that at least two replicas are synchronized before confirming a successful write, further improving data reliability.

[0056] S42 achieves eventual consistency by pre-allocating resources in the Try phase, committing the transaction in the Confirm phase, and rolling back operations in the Cancel phase of the TCC transaction, combined with an event-driven architecture.

[0057] In some implementations, this invention achieves eventual consistency guarantees across microservice scenarios through a collaborative mechanism between the TCC (Try-Confirm-Cancel) transaction mode and event-driven architecture. The TCC transaction mode is a typical compensatory transaction mechanism, suitable for business scenarios in distributed systems with high requirements for transaction consistency but where traditional ACID transactions cannot be used. In the Try phase, the system first performs resource pre-deduction operations on each participating service, such as pre-deducting user account balances and locking enrollment status in social security business processing, ensuring that subsequent operations have the necessary conditions for execution. This phase uses an idempotency verification mechanism to prevent resource conflicts caused by duplicate commits, and simultaneously records transaction context information for use in the subsequent Confirm or Cancel phases.

[0058] In the Confirm phase, after all Try operations succeed, the system executes the formal transaction commit operation, such as completing social security payments or updating insurance records. This phase requires finality in business execution, meaning that once successful, it is irreversible. The Confirm operation is typically triggered through an asynchronous message queue (such as Kafka) to ensure the reliability and order of transaction commits. In the Cancel phase, if any service fails in the Try phase or the entire transaction is rolled back, resource release or state recovery operations are performed, such as refunding pre-deducted amounts or releasing state locks. The Cancel operation is also idempotent to handle network retries or duplicate message consumption.

[0059] By combining an event-driven architecture, the system publishes transaction state change events through Kafka. Each microservice subscribes to relevant events and executes local transaction processing, thereby achieving eventual data consistency across services. For example, after social security transactions are completed, the health record service can update the user's health status label by subscribing to the "transaction submitted successfully" event. This mechanism demonstrates good scalability and reliability in high-concurrency scenarios, with transaction processing latency controlled within 50ms and message queue throughput reaching 100,000 messages / second, meeting the processing needs of the provincial social security system during peak periods. Through the integrated design of TCC transactions and event-driven architecture, the system improves service response speed and system stability while ensuring data consistency, which is a significant innovation of this invention in distributed transaction processing.

[0060] This invention provides a method for optimizing mobile social security services based on a distributed and microservice architecture. This method can effectively improve the scalability, stability, and response efficiency of the social security service system, achieve modular deployment and elastic scaling, ensure business processing capabilities and data consistency in high-concurrency scenarios, and enhance the intelligence level of business processing through an intelligent reporting engine, thereby significantly reducing development and maintenance costs and the scope of failure impact.

[0061] Example 2 The following describes in detail, with reference to the accompanying drawings, an embodiment of the present invention for optimizing mobile social security services based on a distributed and microservice architecture.

[0062] The implementation of the embodiments of the present invention is based on the following prior art: 1. Distributed microservice architecture design: Service decomposition: Based on PICC's self-developed PDFC framework, and relying on Spring Cloud microservice technology, the system is decomposed into multiple microservices, each responsible for specific business functions. The architecture design also employs a registry center, configuration center, Zuul gateway, Nginx load balancer, circuit breaker, monitoring and tracing, and distributed message queue Kafka component services.

[0063] Service communication: Microservices communicate with each other via RESTful APIs, ensuring loose coupling and high flexibility.

[0064] Data consistency: Use distributed transaction management or event-driven architecture to ensure data consistency.

[0065] Automated Deployment: The system employs CICD (Continuous Integration / Continuous Delivery) automated pipeline deployment technology, combined with container cloud technology for service management, enabling rapid scaling and fault tolerance. Each service is deployed, upgraded, expanded, and replaced independently, ensuring the flexibility of continuous delivery and horizontal scaling, effectively reducing operational costs.

[0066] 2. Intelligent integration of social security data and health management services: Data collection: The mobile social security system provides API interfaces to realize data exchange between systems based on the RESTful protocol, and relies on OAuth authentication in the PDFC framework to ensure the security of interface transmission; combined with Kafka message queues, a high-throughput data transmission pipeline is built to complete the archival data collection work.

[0067] Data cleaning (Spark processing engine): Integrated cleaning of social security and health record data is achieved using Spark. Schema inference is used to detect field type conflicts in social security and health record data, and the distribution of missing values / outliers is statistically analyzed. Standardization processing is performed using dropna() / fillna() to handle missing values ​​(supporting mean / median / mode filling), time series data interpolation is implemented using window functions, and regular expressions are used to unify the format (e.g., 15 / 18-digit ID number conversion). Precise deduplication is achieved using a combination of distinct() and row_number().

[0068] Data storage (distributed database): The database selected is the domestic distributed Gaussian database, which realizes master-slave and read-write separation, and is used to store the integrated business data.

[0069] 3. Intelligent Reporting Engine: Pre-approval report: Combining user health record data and social security business data, a unique report engine generation framework is implemented. After a user submits a business application, the system automatically generates a pre-approval report based on the user's business-related record data and social security data, including business processing guidelines and expected results.

[0070] Post-processing report: After the business is completed, the system will automatically generate a post-processing report based on the actual results, including processing details, health indicator analysis, and recommendations for health management services.

[0071] Report formats: Supports multiple report formats, such as PDF and Excel, for easy download and sharing by users.

[0072] Through the above technical solutions, the present invention can realize efficient and convenient social security business processing and health management services, and improve user experience and system performance.

[0073] This invention employs a cutting-edge distributed microservice architecture, based on PICC's self-developed PDFC framework and Spring Cloud technology. Services are divided into multiple independent microservices, achieving efficient collaboration through a registry center, configuration center, Zuul gateway, Nginx load balancer, circuit breaker, and Kafka message queue. Services communicate via RESTful APIs to ensure loose coupling, and data consistency is guaranteed through distributed transactions or event-driven mechanisms. A CI / CD pipeline combined with container cloud technology enables automated deployment and elastic scaling. For data fusion, a unique social security and archive data collection framework is implemented through RESTful APIs and Kafka. Spark is used for integrated data cleaning (including missing value handling, format standardization, and precise deduplication), and the data is ultimately stored in a domestically developed distributed Gaussian database. The intelligent reporting engine, based on social security and archive data, automatically generates pre-event prediction reports (including business guidelines and expected results) and post-event analysis reports (including processing details and data analysis), achieving intelligent services throughout the entire process.

[0074] like Figure 2 As shown, the present invention specifically includes the following steps: 1. The Spring Cloud microservice architecture is adopted to break down the various functions of the mobile social security app into multiple independent microservices, such as user information microservice, social security business processing microservice, and data query microservice.

[0075] 2. Each microservice can be deployed and scaled independently, and services can be registered and discovered through a service registry (such as Eureka). 3. Automatic registration and health checks of services are performed through the service registry center to ensure service availability.

[0076] 4. An API gateway (such as Zuul) serves as the unified entry point for the system, responsible for routing and filtering user requests and distributing them to the appropriate microservices.

[0077] 5. Define clear API interface specifications to ensure standardized interactions between microservices and with external systems.

[0078] 6. The database selection adopts the Gaussian unified standard, based on the master-slave and read-write separation standardized deployment method, which gets rid of the original database's high hardware requirements, high price, and complex operation and maintenance.

[0079] 7. Use a distributed cache (Redis) to cache frequently used data and improve data access efficiency. 8. Perform user authentication and authorization at the API gateway to ensure that only legitimate users can access the relevant social security functions.

[0080] 9. Utilize Kafka message queues for asynchronous communication between microservices and support data synchronization services to improve the system's concurrency and flexibility. 10. Construct a three-dimensional intelligent reporting system: generate an expected guidance report in advance by analyzing physical examination information, generate a risk warning report during the process by dynamically monitoring, and generate a processing result report afterward based on the actual business processing situation.

[0081] Example 3 To achieve the above embodiments, such as Figure 3 As shown, this embodiment also provides a mobile social security business optimization device 10 based on a distributed and microservice architecture. The device 10 includes a microservice splitting and registration module 100, a containerized dynamic deployment module 200, a request routing and circuit breaker control module 300, and a transaction consistency and CICD management module 400.

[0082] The microservice decomposition and registration module 100 is used to decompose the social security business system into multiple independent microservice units based on the self-developed PDFC framework and Spring Cloud microservice architecture, and to realize the automatic registration and health check of each microservice through the service registry center. The containerized dynamic deployment module 200 is used to dynamically scale up and down the microservice unit using Kubernetes containerization technology, and to achieve second-level elastic adjustment of container nodes by combining real-time monitoring data. The request routing and circuit breaker control module 300 is used to perform routing filtering and access control on user requests through the Zuul gateway, realize lightweight asynchronous communication between microservices using RESTful API and Kafka message queue, and configure the circuit breaker component to establish a dedicated circuit breaker strategy for insurance status changes and benefit calculation. The Transaction Consistency and CICD Management Module 400 is used to ensure the consistency of social security data and health record data across microservices based on a distributed transaction management mechanism and event-driven architecture, and to realize the independent construction, deployment and version update of each microservice through the CICD pipeline.

[0083] Furthermore, the aforementioned microservice decomposition and registration module 100 is also used for: The user information microservice, social security business processing microservice, and data query microservice are deployed on separate Kubernetes container nodes, and service discovery and health checks are performed through the service registry center. The configuration center, based on the PDFC framework, enables independent configuration management for each microservice. User requests are distributed to the corresponding microservice instances via routing rules from the Zuul gateway.

[0084] Furthermore, the containerized dynamic deployment module 200 described above is also used for: The number of Kubernetes container nodes is dynamically adjusted based on CPU utilization and memory usage. When the resource utilization of any node exceeds 85% for 5 consecutive minutes, a scaling operation is triggered. The Nginx load balancing component uses a weighted round-robin algorithm to distribute request traffic, and combines this with the Zuul gateway's minimum connection count algorithm to achieve two-layer load balancing.

[0085] Furthermore, the aforementioned request routing and circuit breaker control module 300 is also used for: For the insurance status change module, the circuit breaker threshold is set to trigger when the failure rate of 10 consecutive requests exceeds 30%. The duration of the circuit breaker is dynamically adjusted according to the service recovery status. The health check interface of the service registry collects the response time and error rate of each microservice in real time, and automatically removes the service instance from the service list when it is detected that the service instance is unavailable.

[0086] Furthermore, the aforementioned transaction consistency and CICD management module 400 is also used for: The Kafka partitioning strategy is used to store social security data and health record data in separate topics, with each topic configured with 3 replicas to ensure data reliability; Eventual consistency is guaranteed by using the Try phase of TCC transactions to pre-allocate resources, the Confirm phase to commit transactions, and the Cancel phase to roll back operations, combined with an event-driven architecture.

[0087] This invention discloses a mobile social security business optimization device based on a distributed and microservice architecture, which can effectively improve the scalability, stability and response efficiency of the social security business system, realize modular deployment and elastic scaling, ensure business processing capabilities and data consistency in high-concurrency scenarios, and enhance the intelligence level of business processing through an intelligent reporting engine, significantly reducing development and maintenance costs and the scope of failure impact.

[0088] To implement the methods of the above embodiments, the present invention also provides a computer device, such as... Figure 4 As shown, the computer device 600 includes a memory 601 and a processor 602; wherein, the processor 602 reads executable program code stored in the memory 601 to run a program corresponding to the executable program code, so as to implement the various steps of the method described above.

[0089] To implement the above embodiments, this application also proposes a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the method described in the foregoing embodiments.

[0090] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

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

Claims

1. A method for optimizing mobile social security services based on a distributed and microservice architecture, characterized in that, include: S1, based on the self-developed PDFC framework and SpringCloud microservice architecture, splits the social security business system into independently deployed user information service, business processing service and data query service modules to achieve decoupling of business functions; S2 uses Kubernetes containerization technology to dynamically scale up and down each microservice node, and combines Zuul gateway and Nginx load balancing components to build an elastic service cloud network, improving the system's concurrent processing capabilities. S3 employs a circuit breaker mechanism to implement a dedicated circuit breaker strategy for high-frequency business modules such as changes in insurance status and benefit calculation. It also monitors the service health status in real time through the service registration center and automatically isolates faulty nodes. S4 establishes a cross-domain data channel based on Kafka message queues, and combines TCC distributed transactions and event-driven architecture to ensure data consistency between microservices, completing the real-time synchronization of social security business data and health record data.

2. The method as described in claim 1, characterized in that, S1 includes: S11 deploys the user information microservice, social security business processing microservice, and data query microservice on independent Kubernetes container nodes, and performs service discovery and health checks through the service registry center. S12 uses the PDFC framework's configuration center to implement independent configuration management for each microservice, and distributes user requests to the corresponding microservice instances through the routing rules of the Zuul gateway.

3. The method as described in claim 1, characterized in that, S2 includes: S21 dynamically adjusts the number of Kubernetes container nodes based on CPU utilization and memory usage. When the resource utilization of any node exceeds 85% for 5 consecutive minutes, a scaling operation is triggered. S22 uses the Nginx load balancing component to distribute request traffic using a weighted round-robin algorithm, combined with the Zuul gateway's minimum connection count algorithm to achieve two-layer load balancing.

4. The method as described in claim 1, characterized in that, The S3 further includes: S31, for the insurance status change module, the circuit breaker threshold is set to trigger when the failure rate of 10 consecutive requests exceeds 30%, and the circuit breaker duration is dynamically adjusted according to the service recovery status; S32 collects the response time and error rate metrics of each microservice in real time through the health check interface of the service registry, and automatically removes a service instance from the service list when it is detected that the instance is unavailable.

5. The method as described in claim 1, characterized in that, The S4 includes: S41 uses Kafka's partitioning strategy to store social security data and health record data in separate topics, with each topic configured with 3 replicas to ensure data reliability; S42 achieves eventual consistency by pre-allocating resources in the Try phase, committing the transaction in the Confirm phase, and rolling back operations in the Cancel phase of the TCC transaction, combined with an event-driven architecture.

6. A mobile social security service optimization device based on a distributed and microservice architecture, characterized in that, include: The microservice decomposition and registration module is used to decompose the social security business system into multiple independent microservice units based on the self-developed PDFC framework and Spring Cloud microservice architecture, and to realize the automatic registration and health check of each microservice through the service registry center. The containerized dynamic deployment module is used to dynamically scale up and down the microservice unit using Kubernetes containerization technology, and to achieve second-level elastic adjustment of container nodes by combining real-time monitoring data. The request routing and circuit breaker control module is used to perform routing filtering and access control on user requests through the Zuul gateway, realize lightweight asynchronous communication between microservices using RESTful API and Kafka message queue, and configure the circuit breaker component to establish dedicated circuit breaker strategies for changes in insurance status and benefit calculation. The transaction consistency and CICD management module is used to ensure the consistency of social security data and health record data across microservices based on a distributed transaction management mechanism and event-driven architecture, and to realize the independent construction, deployment and version update of each microservice through the CICD pipeline.

7. The apparatus as claimed in claim 6, characterized in that, The microservice splitting and registration module is also used for: The user information microservice, social security business processing microservice, and data query microservice are deployed on separate Kubernetes container nodes, and service discovery and health checks are performed through the service registry center. The configuration center, based on the PDFC framework, enables independent configuration management for each microservice. User requests are distributed to the corresponding microservice instances via routing rules from the Zuul gateway.

8. The apparatus as claimed in claim 6, characterized in that, The containerized dynamic deployment module is also used for: The number of Kubernetes container nodes is dynamically adjusted based on CPU utilization and memory usage. When the resource utilization of any node exceeds 85% for 5 consecutive minutes, a scaling operation is triggered. The Nginx load balancing component uses a weighted round-robin algorithm to distribute request traffic, and combines this with the Zuul gateway's minimum connection count algorithm to achieve two-layer load balancing.

9. A computer device, characterized in that, Including processor and memory; The processor reads executable program code stored in the memory to run a program corresponding to the executable program code, so as to implement the mobile social security business optimization method based on distributed and microservice architecture as described in any one of claims 1-5.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements a mobile social security service optimization method based on a distributed and microservice architecture as described in any one of claims 1-5.

Images