SofaArk-based contract process fault rapid processing method and device

Abstract

The invention relates to the technical field of computer information processing, and discloses a SofaArk-based contract process fault rapid processing method, device and equipment and a medium, and the method comprises the steps: receiving insurance application information, health data and living habits of a customer, classifying and analyzing the insurance application information, health data and living habits of the customer, and determining the insurance application information, health data and living habits of the customer; establishing a SofaArk micro server framework according to an analysis result; based on a SofaArk micro-server framework, development of implementation codes, service registration and service discovery of each micro-service, and storage of the micro-services in a SofaArk service registration center; when it is detected that the response time of the micro-service exceeds a preset fusing threshold value, an automatic fusing mechanism is triggered, and the fusing threshold value is adjusted. The method can be applied to the development of business systems such as financial science and technology, medical health, old-age care and the like, and the response speed and the processing efficiency of the system are improved through a SofaArk load balancing algorithm.

Description

Technical Field

[0001] This invention relates to the field of computer information processing technology, and in particular to a method, apparatus, device and medium for rapid handling of contract process faults based on SofaArk. Background Technology

[0002] In the development of business systems for fintech, healthcare, and elderly care, health insurance is a crucial component of the insurance industry. Its contract process involves multiple stages, including application, underwriting, policy issuance, and policy generation. Traditional health insurance contract processes are typically based on monolithic architectures or simple distributed systems, resulting in inefficiencies. When handling complex contract processes, traditional systems suffer from slow response times and low processing efficiency due to high coupling between services. For example, an application requires review and data processing by multiple departments, easily leading to information silos and processing delays. Summary of the Invention

[0003] This invention provides a method, apparatus, computer equipment, and medium for rapid handling of contract process faults based on SofaArk, in order to solve the technical problem of slow response speed and low processing efficiency in traditional systems when handling complex contract processes due to the high coupling between services.

[0004] Firstly, a method for rapid handling of contract process failures based on SofaArk is provided, including...

[0005] It receives customer insurance application information, customer health data, and lifestyle habits; classifies and analyzes customer insurance application information, customer health data, and lifestyle habits; and establishes the SofaArk microserver framework based on the analysis results.

[0006] Based on the SofaArk microserver framework, we develop the implementation code for each microservice, service registration, and service discovery, and store the microservices in the SofaArk service registry.

[0007] When the response time of a microservice is detected to exceed the preset circuit breaker threshold, the automatic circuit breaker mechanism is triggered, the circuit breaker threshold is adjusted, and requests to the microservice are routed to a backup service or degraded for processing.

[0008] Once the circuit breaker is adjusted to normal, the circuit breaker status will be automatically lifted, and normal calling logic will be gradually restored.

[0009] Secondly, a rapid contract process fault handling device based on SofaArk is provided, including:

[0010] The receiving module is used to receive customer insurance application information, customer health data and lifestyle habits, classify and analyze customer insurance application information, customer health data and lifestyle habits, and build the SofaArk microserver framework based on the analysis results.

[0011] Develop a storage module to develop implementation code for each microservice, service registration, and service discovery based on the SofaArk microserver framework, and store the microservices in the SofaArk service registry center;

[0012] The triggering module is used to trigger the automatic circuit breaker mechanism when the response time of a microservice exceeds the preset circuit breaker threshold, adjust the circuit breaker threshold, and route requests to the microservice to a backup service or perform degradation processing.

[0013] The adjustment module is used to automatically release the circuit breaker from its fault state and gradually restore normal operation once the circuit breaker has been adjusted to normal.

[0014] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described fast contract flow fault handling method based on SofaArk.

[0015] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the aforementioned SofaArk-based method for rapid handling of contract flow faults.

[0016] The aforementioned solution, implemented using the SofaArk-based method, apparatus, computer equipment, and storage medium for rapid handling of contract process failures, involves receiving customer insurance application information, health data, and lifestyle habits. This information is then categorized and analyzed, and a SofaArk microserver framework is established based on the analysis results. Implementation code for each microservice, service registration, and service discovery are developed within this framework, and the microservices are stored in the SofaArk service registry. When a microservice's response time exceeds a preset circuit breaker threshold, an automatic circuit breaker mechanism is triggered, adjusting the threshold and routing requests to backup or degraded services. Once the circuit breaker is restored to normal, it is automatically deactivated, and normal call logic is gradually restored. In this invention, by dividing the health insurance contract process into multiple independent microservices, the coupling between services is reduced, improving system response speed and processing efficiency. Based on the SofaArk service registry, service consumers can quickly discover available services, reducing service call latency and improving overall system throughput. SofaArk's load balancing algorithm evenly distributes requests across multiple service instances, avoiding single points of overload and improving system processing capacity. In high-concurrency scenarios, when a service experiences a performance bottleneck or failure, the circuit breaker mechanism can quickly isolate the faulty service, preventing system-wide crashes. Once the circuit-broken service recovers, the system automatically unblocks and gradually restores normal call logic, ensuring stable system operation. Attached Figure Description

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

[0018] Figure 1 This is a schematic diagram of an application environment for a fast contract process fault handling method based on SofaArk in one embodiment of the present invention;

[0019] Figure 2 This is a flowchart illustrating a method for rapid handling of contract process faults based on SofaArk in one embodiment of the present invention.

[0020] Figure 3 This is a schematic diagram of a contract process fault rapid processing device based on SofaArk in one embodiment of the present invention;

[0021] Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention;

[0022] Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

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

[0024] The fast contract process fault handling method based on SofaArk provided in this invention can be applied to, for example... Figure 1 In this application environment, the client receives customer insurance application information, health data, and lifestyle habits. It then categorizes and analyzes these data, establishing a SofaArk microserver framework based on the analysis results. Implementation code for each microservice, service registration, and service discovery are developed within this framework, and the microservices are stored in the SofaArk service registry. When a microservice's response time exceeds a preset circuit breaker threshold, an automatic circuit breaker mechanism is triggered, adjusting the threshold and routing requests to backup or degraded services. Once the circuit breaker is restored to normal, it is automatically deactivated, and normal call logic is gradually restored. This invention breaks down the health insurance contract process into multiple independent microservices, reducing coupling between services and improving system response speed and processing efficiency. Based on the SofaArk service registry, service consumers can quickly discover available services, reducing service call latency and improving overall system throughput. SofaArk's load balancing algorithm evenly distributes requests across multiple service instances, avoiding single-point overload and enhancing system processing capacity. In high-concurrency scenarios, when a service experiences a performance bottleneck or failure, the circuit breaker mechanism can quickly isolate the faulty service, preventing system-wide crashes. Once the circuit-broken service recovers, the system automatically unblocks and gradually restores normal call logic, ensuring stable system operation. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0025] Please see Figure 2 As shown, Figure 2A flowchart illustrating a fast contract process fault handling method based on SofaArk provided in this embodiment of the invention includes the following steps:

[0026] S10: Receive customer insurance application information, customer health data, and lifestyle habits; classify and analyze customer insurance application information, customer health data, and lifestyle habits; and base decisions on the analysis results.

[0027] We receive customer insurance application information, health data, and lifestyle habits through multiple channels: online channels, including insurance apps, official website forms, and third-party platforms (such as Alipay and WeChat mini-programs) to receive structured data, including basic personal information (name, ID number, contact information), insurance product type, and coverage amount in the application; health data can be obtained by connecting to medical examination institutions' APIs and smart devices (such as exercise data from smart bracelets and monitoring data from blood pressure monitors); and lifestyle habits are collected through questionnaires filled out by users (such as smoking history, drinking frequency, and exercise habits).

[0028] Data is acquired through offline channels, including scanned copies of paper forms entered into the system by agents and materials submitted at offline counters. These are then converted into structured data using OCR and integrated into the system, ensuring that the offline and online data formats are consistent.

[0029] For supplementary data acquisition, we connect with medical insurance platforms and hospital electronic medical record systems (user authorization required) to supplement health data; we also obtain indirect data related to lifestyle habits (such as consumption records related to daily routines) through credit reporting platforms. We adopt standardized data formats (such as JSON) and define a unified data field dictionary to ensure consistency in field names and value ranges (such as "none / occasionally / long-term") for similar data from different channels. The access layer filters invalid data through validation rules (such as ID number format validation and health data range validation), and provides real-time prompts for missing key information (such as the ID number required for insurance and past medical history in health data), requiring the data to be supplemented before resubmission.

[0030] The transmission process uses HTTPS encryption to prevent data leakage; sensitive information (such as health data and ID numbers) is anonymized during storage (e.g., only the first 6 and last 4 digits of the ID number are retained). Based on the user authorization mechanism, the scope of data use is clearly defined, and relevant data is only accessed during the insurance application review process, with data access logs recorded to meet compliance requirements (such as the Personal Information Protection Law).

[0031] The purpose of classifying and analyzing the received information is to provide a basis for risk assessment and underwriting decisions. This is specifically divided into two parts: classification dimensions and analytical logic. The information classification dimensions are categorized by: By application information: "Basic Information," "Insurance Needs," and "Compliance Information." Basic information includes personal identity and contact information; insurance needs include product type (e.g., critical illness insurance, medical insurance), coverage period, and payment method; compliance information includes whether the applicant meets basic conditions such as age and occupational restrictions. By health data: "Physiological Indicators," "Medical History Records," and "Current Health Status." Physiological indicators include height, weight, blood pressure, and blood sugar; medical history records include past major illnesses, surgical history, and family history of hereditary diseases; current health status includes recent abnormal physical examination results and chronic disease management (e.g., blood sugar control in diabetic patients). By lifestyle habits: "Health-Related Behaviors" and "Risk Behaviors." Health-related behaviors include exercise frequency, dietary structure (e.g., preference for high-salt, high-fat diets), and sleep patterns; risk behaviors include smoking, drinking, frequency of staying up late, and occupational risk level (e.g., working at heights, chemical industry).

[0032] Information analysis logic includes basic compliance analysis, which initially screens insurance applications to eliminate those that do not meet basic eligibility requirements (e.g., age exceeding the product limit, occupation falling within the exclusion range), reducing the unnecessary costs of subsequent analysis. Health risk assessment involves building a health scoring model using health data. For example, comparing physiological indicators such as blood pressure and blood sugar with standard values; the greater the deviation, the higher the health risk score. Clients with a history of serious illness or family history of hereditary diseases automatically have an increased risk level. Lifestyle habit correlation analysis establishes a model linking lifestyle habits to claim risk. For example, clients who smoke long-term (≥10 cigarettes per day) and drink alcohol (≥2 liang per day) have a 30% higher risk of claiming critical illness insurance compared to clients without these habits; clients who exercise ≥3 times per week (≥30 minutes each time) have a 15% lower risk of claiming medical insurance. Comprehensive risk rating combines insurance applications (e.g., whether the coverage amount matches income), health data, and lifestyle habits to categorize clients into "standard risk," "substandard risk," and "rejected risk," providing a basis for underwriting decisions (e.g., standard risk is normally insured, substandard risk is insured with additional premiums).

[0033] Based on the business needs of information reception and classification analysis, a microservice framework was built on SofaArk to solve problems such as multi-service collaboration, data isolation, and flexible expansion. The specific architecture is as follows: Microservice decomposition: Information Reception Service, responsible for connecting to information access from multiple channels, including data format verification, encrypted transmission, and preliminary cleaning (such as removing invalid characters), pushing standardized data to a message queue (such as RocketMQ). Data Classification Service, retrieving data from the message queue, performing structured classification into three categories: "Insurance Application," "Health Data," and "Lifestyle Habits," labeling data source, timestamps, and other metadata, and storing it in the corresponding data table (e.g., storing health data in a MySQL health table). Risk Analysis Service, calling the classified structured data, running health risk models and lifestyle habit association models, outputting comprehensive risk rating results, and synchronizing them to the underwriting system. Data Synchronization Service, responsible for real-time data synchronization with third-party platforms (such as medical examination institutions and medical insurance systems) to ensure that the data used for analysis is the latest version. Log Monitoring Service, collecting operation logs and data processing logs from each service for problem investigation and process auditing.

[0034] The application of SofaArk's microservice framework features, including class isolation to resolve multi-framework conflicts: Risk analysis services may use machine learning frameworks (such as TensorFlow), data synchronization services may rely on database connection pool frameworks (such as HikariCP), and different services may have version conflicts in their dependent libraries (e.g., versions 1.0 and 2.0 of the same library). SofaArk uses "PluginClassLoader" to create an independent class loader for each service, achieving library isolation and avoiding conflicts. Plugin-based deployment supports feature expansion. If a new "genetic testing data" analysis dimension is added, there's no need to modify the existing service code. The genetic data processing logic can be encapsulated as an Ark Plugin and deployed to the SofaArk container. The plugin is loaded through "FrameworkClassLoader," sharing the basic class library (such as Java core classes) with the main service, reducing resource consumption. Integrating the SOFAJRaft protocol enables clustered deployment and master-slave failover of the risk analysis service, avoiding single points of failure. SofaArk's rate limiting feature restricts the concurrency of the information receiving service (e.g., processing a maximum of 1000 data entries per second), preventing upstream request overload and improving stability through unified service governance. When the health risk model iterates (e.g., adding a "sleep duration" metric), only the risk analysis service plugin needs to be updated; the entire framework does not need to be restarted. SofaArk manages the service lifecycle through the Capsule pattern, supports hot plugin deployment, reduces business downtime, and dynamic updates lower maintenance costs.

[0035] SofaArk's service registry is one of the core components of this invention, used to dynamically manage the various microservices in the health insurance contract process. The following is the specific implementation of dynamic service discovery and registration: Each microservice, upon startup, registers its metadata information with SofaArk's service registry, including service name, version number, IP address, port number, etc. The service registry stores this information in a distributed configuration center (such as Nacos or Consul).

[0036] When a service consumer needs to invoke a microservice, it queries the service registry for available service instances. The service registry returns the address of the optimal service instance based on a load balancing algorithm (such as round-robin, weighted round-robin, least connections, etc.). During operation, the service registry can dynamically detect changes in service instances (such as added services, service shutdowns, service failures, etc.) and update the service list in real time. Service consumers can then dynamically adjust their invocation strategies based on the latest service list, ensuring high system availability.

[0037] The SofaArk microservice framework boasts advantages such as high scalability, high availability, and compliance assurance. High scalability means that when new channels are integrated (e.g., connecting to new smart health check devices), only the information receiving service plugin needs to be extended, while other services remain unaffected. High availability is ensured by class isolation preventing a single service failure from escalating to the entire system; cluster deployment and governance functions ensure the stable operation of core services (such as risk analysis). Compliance assurance is achieved through the log monitoring service collecting data via SofaArk's unified log interface, meeting regulatory requirements for traceable data processing; class isolation ensures the independence of sensitive data processing logic (such as encryption algorithms), reducing the risk of data leakage.

[0038] Specifically, the S10 steps include: receiving customer insurance application information and performing preliminary verification and classification of the application information; assessing the customer's health risk based on the application information and generating underwriting results by calling external health assessment systems or internal rule engines; deciding whether to underwrite based on the underwriting results and generating corresponding underwriting plans; generating formal policy documents based on the underwriting plans and notifying the customer via email, SMS, or client; analyzing the customer's health data and lifestyle habits based on machine learning models to predict the customer's future health risks; calculating the premium amount based on the customer's health status, age, and occupation; setting up separate microservices for the application information, underwriting results, underwriting plans, policy documents, the customer's future health risks, and premium amounts, and combining these microservices to build the SofaArk microserver framework.

[0039] The receipt, verification, and classification of insurance application information are handled by the "Insurance Application Information Receiving Microservice." This microservice receives information through multiple channels, including official website forms, mobile apps, third-party platform interfaces, and offline agent data entry systems. Standardized data formats (such as JSON) are used during reception, and a unified field dictionary is defined. Fields such as "Name," "ID Number," and "Insurance Product Type" have clear formats and value specifications. Simultaneously, the received information is encrypted in real-time (e.g., HTTPS), and sensitive information (such as ID numbers) is anonymized during storage, retaining only the necessary visible portions.

[0040] Verification is conducted from two aspects: compliance and completeness. Compliance verification checks the format of the ID number (using regular expression matching), whether the insured's age is within the product's specified range (e.g., a critical illness insurance policy requires 20-55 years old), and whether the occupation is covered (excluding high-risk occupations such as war correspondents). Completeness verification confirms whether key information is missing, such as name, ID number, and the insured product. If any is missing, the customer will be prompted to supplement it in real time. Information that passes verification proceeds to the classification stage, while information that fails verification returns an error message.

[0041] Information is categorized by attributes into basic information (name, ID number, etc.), insurance requirement information (product type, coverage amount, coverage period, etc.), and compliance-related information (age, occupation, etc.). After categorization, the microservice stores the structured categorization information in the corresponding database and synchronizes it to the service registry for subsequent microservice calls. This microservice, deployed via SofaArk's plug-in architecture, can flexibly adapt to new information receiving channels; for example, when adding a new third-party platform, only the corresponding access plugin needs to be added.

[0042] The assessment of health risks and generation of underwriting results based on insurance application information is completed collaboratively by the "Health Risk Assessment Microservice" and the "Underwriting Result Generation Microservice." The former focuses on risk assessment, while the latter is responsible for generating the final underwriting conclusion. After obtaining the insurance application information, the "Health Risk Assessment Microservice" first checks whether there is any health-related information that can be directly used for assessment (such as past medical history filled in during the application). If so, it calls the internal rule engine and conducts a preliminary assessment based on preset rules (such as marking customers with a history of diabetes as substandard risk when applying for critical illness insurance). If there is no information or the information is insufficient, it calls an external health assessment system (such as connecting to a medical examination institution's system) to obtain the customer's health data and generates a health risk assessment report based on the internal rules.

[0043] The "Underwriting Result Generation Microservice" receives health risk assessment reports and, combined with the underwriting rules of the insurance product (e.g., a certain medical insurance policy has specific underwriting requirements for customers with hypertension), makes a comprehensive judgment. If the assessment is completed through the internal rule engine, the underwriting result (e.g., normal underwriting, underwriting with increased premium, or rejection) is generated directly based on the rules. If an external health assessment system is called, the validity of the external data must be verified first before combining it with the internal rules to generate the result. After the underwriting result is generated, it is synchronized to the service registry center for the "Underwriting Plan Generation Microservice" to call. This microservice uses SofaArk's class isolation mechanism to avoid class conflicts between the internal rule engine and external system interface dependencies.

[0044] The decision to underwrite and generate a plan based on the underwriting results is handled by the "Underwriting Decision Microservice" and the "Underwriting Plan Generation Microservice." The "Underwriting Decision Microservice" receives the underwriting results. If the underwriting result is "underwritten" (normal underwriting, underwriting with additional fees, etc.), the underwriting process begins; if it is "rejected," a rejection explanation is generated. The decision-making process must consider the risk tolerance range of the insured product. For example, a product may have an upper limit on the underwriting ratio for high-risk occupations; if this limit is exceeded, underwriting is rejected. The decision results are synchronized to the service registration center in real time, triggering subsequent processes.

[0045] The "Insurance Plan Generation Microservice" is activated after the underwriting decision is deemed acceptable. It generates a plan based on the underwriting results, the type of insured product, and customer needs. The plan includes the type of insurance, sum insured, coverage period, and payment method. If it involves additional premiums, the premium percentage and reason must be clearly stated. The generated plan undergoes internal compliance verification before being stored and synchronized to the service registry. This microservice supports plug-in extensions, allowing for the rapid addition of plan generation logic based on new product rules.

[0046] Generating the official policy and notifying the customer is the crucial final step in the insurance application process, completed by the "Policy Document Generation Microservice" and the "Customer Notification Microservice." The "Policy Document Generation Microservice" obtains the underwriting plan and generates the official policy according to a standardized policy template, containing all the contents of the underwriting plan and relevant terms and conditions from the insurance company. During the generation process, the accuracy of the information (such as the customer's name and the sum insured, which must match the underwriting plan) must be verified to ensure the policy's legality and validity. After the policy is generated, it is stored on a file server, and the storage address is synchronized to the service registry center.

[0047] The "Customer Notification Microservice" receives the policy file storage address and selects the notification method based on the customer's pre-registered contact information (email, SMS, or mobile app). The notification content includes policy generation information and the path to view the policy. If a notification fails (e.g., email delivery fails), it will automatically retry. After multiple failed retries, the failure is recorded and a manual intervention prompt is displayed. This microservice leverages SofaArk's dynamic extensibility to flexibly add new notification channel plugins.

[0048] The "Customer Future Health Risk Prediction Microservice" is responsible for predicting future health risks based on customer health data and lifestyle habits. This microservice retrieves customer health data (such as medical examination reports) and lifestyle information (such as smoking and exercise habits) from a data storage center and inputs it into a trained machine learning model (such as a decision tree-based health risk prediction model). After analyzing the data, the model predicts the probability of the customer developing a specific disease within a certain period (e.g., 5 years) and generates a risk prediction report. During the prediction process, if the data is incomplete, missing items are marked and explained in the report. Once generated, the report is synchronized to the service registry for insurance companies to use in developing customer service strategies. This microservice utilizes SofaArk's resource isolation to ensure that the machine learning model operates with independent resources and does not affect other microservices.

[0049] Premium calculation based on customer information is handled by the "Premium Amount Calculation Microservice." This microservice obtains information such as the customer's health status (from a health risk assessment report), age, and occupation, and calculates the premium based on the premium rate table of the insured product (e.g., different rates for different ages and occupations). If the customer has health risks (e.g., additional premiums are required for coverage), a proportional increase is added to the base premium; if there are preferential conditions (e.g., discounts for healthy customers), a corresponding reduction is applied. After calculation, a detailed premium calculation statement (including the calculation basis) is generated and synchronized to the service registry center for use in the underwriting plan generation and policy generation processes. This microservice utilizes SofaArk's unified service governance to achieve dynamic updates of the calculation rules, taking effect without requiring a service restart.

[0050] Six independent microservices (insurance application information, underwriting result, insurance plan, policy document, customer future health risk, and premium amount) are integrated to build a microservice framework based on SofaArk. All microservices register with the SofaRegistry service registry at startup via SofaArk's service registration mechanism, with registration information including service identifier, interface information, and version. When a microservice needs to call other services (e.g., the insurance plan generation microservice calls the underwriting result microservice), it obtains a list of instances of the target service from the registry through the service discovery mechanism, enabling dynamic invocation. The registry synchronizes service status in real time, and automatically notifies the caller to switch to another instance if a service is abnormal. Each microservice is deployed as an independent plugin, with class isolation achieved through SofaArk's class loader system (PluginClassLoader). For example, the machine learning library that the customer future health risk prediction microservice depends on is isolated from the dependency libraries of other microservices to avoid class conflicts. When a microservice needs to be updated (such as adjusting premium calculation rules), the update logic is encapsulated as a plugin, and hot updates are achieved through plugin deployment without restarting the entire framework.

[0051] The first step in building a microservice framework based on SofaArk is to decompose microservices by business domain and define the interaction specifications between services through the SPI interface. First, microservices are decomposed according to business boundaries. Based on the core steps of the insurance application process, the overall business is broken down into independent microservices, such as the application information service (responsible for receiving and verifying applications), the underwriting service (generating underwriting results), the premium calculation service (calculating premium amounts), and the policy generation service (generating policy files). This decomposition must follow the principle of "high cohesion and low coupling"—each service focuses on a single business function (e.g., the underwriting service only handles underwriting logic and does not involve premium calculation). Clearly defined service boundaries reduce inter-service dependencies. Interaction contracts are defined based on the SPI interface. An SPI interface is designed for each microservice (e.g., UnderwritingService corresponds to the underwriting service), specifying input parameters (e.g., UnderwritingRequest includes customer health data and insurance product information), output results (e.g., UnderwritingResult includes underwriting conclusions and reasons), and exception handling rules (e.g., "insured age mismatch" corresponds to BusinessException). The interface must be marked with the @SP annotation of SofaArk to ensure that the framework can recognize it as an extensible service; at the same time, the ServiceResult provides a unified output format (including status code, data, and description), so that the caller does not need to care about the internal implementation of the service, but only needs to interact according to the interface specification.

[0052] Each microservice needs to be encapsulated as an Ark Plugin: package the service implementation class, dependency libraries, and configuration files (such as ark-plugin.xml), and use PluginClassLoader to achieve class isolation (to avoid dependency conflicts between different services, such as loading the model library of the underwriting service and the form validation library of the insurance application service independently). The plugin needs to declare the service identifier (such as underwriting-plugin) and version for easy dynamic deployment and version management.

[0053] Leveraging SofaArk's containerized deployment capabilities, a service runtime environment is built, and service registration and discovery are achieved through a service registry, ensuring that services can be dynamically invoked. A SofaArk container is deployed as the microservice runtime platform: the container automatically loads pluggable microservices upon startup and manages common dependencies (such as Java core libraries) through "FrameworkClassLoader," reducing resource consumption. Simultaneously, SofaRegistry is deployed as the service registry, used to store storage metadata (service name, instance address, status, interface information), supporting cluster deployment (ensuring data consistency based on the SOFAJRaft protocol), avoiding single points of failure. When a microservice plugin starts, it automatically registers with the registry through SofaArk's ServiceRegistry component: the registration information includes the service interface (such as UnderwritingService), instance IP:port, and health status (initially "UP"). The registry periodically receives heartbeats from service instances (once every 30 seconds by default). If the heartbeat is interrupted (e.g., instance crash), the instance status is automatically marked as "DOWN," and the caller is notified. For services deployed in a cluster (such as an underwriting service with 3 instances), the registry center will record all instance information for the caller to choose from.

[0054] The calling service (such as the policy generation service) declares its dependent service interface (such as UnderwritingService) through the @Reference annotation. When the framework starts, it automatically obtains a list of available instances corresponding to the interface from the registry center. During the call, the built-in load balancer (which supports round-robin, weighted, and other strategies) selects the instance. For example, the three instances of the underwriting service are allocated requests in a 1:1:1 ratio. If an instance is in a "DOWN" state, the load balancer will automatically exclude it, ensuring that requests are only routed to healthy instances.

[0055] By integrating Sentinel, a circuit breaker threshold can be set (e.g., for underwriting services, "circuit breaker if 10 requests within 5 seconds have an average response time exceeding 3 seconds"). Once triggered, the caller will directly return a downgraded result (e.g., "Underwriting in progress, please check later"), preventing continuous calls to the abnormal service. Simultaneously, rate limiting rules are configured: limiting the concurrent request volume of the service (e.g., the insurance application service can process a maximum of 1000 requests per second), with excess requests queued or rejected (prioritizing non-core requests, such as historical policy queries), preventing sudden traffic surges from overwhelming the service. The default load balancing strategy is "weighted round-robin": weights are dynamically adjusted based on instance health status and load (CPU, memory utilization)—for example, in the underwriting service, instance A (CPU utilization 30%) has a weight of 1.5, while instance B (CPU utilization 70%) has a weight of 0.5, allowing healthy instances to handle more requests. When instance load changes (e.g., instance A's CPU rises to 80%), the framework automatically reduces its weight, achieving load shaving and valley filling.

[0056] If customized governance rules are required (such as "relaxing the flow restriction threshold for insurance services on the 1st of each month"), the rules can be encapsulated as ArkPlugin plugins (such as insurance-governance-plugin) and deployed to the SofaArk container. The plugins connect to the framework via the GovernanceSPI interface and take effect without modifying the core code. For example, the plugin can dynamically adjust the circuit breaker threshold for underwriting services during specific periods to adapt to peak business periods.

[0057] The design incorporates data interaction methods between services, leveraging SofaArk's features to ensure reliable data transmission while handling distributed transaction scenarios. Synchronous interaction is suitable for scenarios with high real-time requirements (such as underwriting services calling health assessment services to obtain results), via direct calls using HTTP or RPC (based on SOFARPC), with traceId used to trace the call chain (facilitating troubleshooting). Asynchronous interaction is suitable for non-real-time scenarios (such as notifying customers after policy generation), implemented through message queues (such as RocketMQ): the service sends a message to the queue and returns immediately, while consumer services (such as notification services) process asynchronously, avoiding synchronous waiting and blocking processes. SofaArk integrates message queues through a "message plugin" to ensure reliable message delivery (automatic retries on failure).

[0058] For cross-service transaction scenarios (such as "deducting premium after underwriting approval + generating policy"), an "eventual consistency" approach is adopted: the transaction status is recorded through a local message table. After the underwriting service is completed, a "deduct premium" message is sent. After the premium service is successfully processed, a "generate policy" message is sent. If any step fails, a scheduled task is used to retry (implemented using SofaArk's SchedulePlugin) until all steps are completed. The framework records transaction logs to facilitate tracking anomalies (such as "premium deduction successful but policy generation failed").

[0059] Based on SofaArk's monitoring components, a full-link monitoring system is built to achieve service status visualization, anomaly alerts, and rapid fault location. Service call data is collected through the ArkTracer component: recording the service name, instance, response time, and result (success / failure) for each call, and combining this with the traceId to connect the call chain (e.g., "insurance application → underwriting → premium calculation"). Simultaneously, resource metrics (CPU, memory) and business metrics (underwriting approval rate, policy generation volume) are collected, aggregated on a minute-by-minute basis, and stored (e.g., in Elasticsearch).

[0060] Connect the collected data to a monitoring platform (such as a self-developed platform or Grafana): Display service status through dashboards (such as the response time trend of underwriting services and instance health status), and use color to mark anomalies (red indicates CPU exceeding the threshold, yellow indicates increased response time). Configure alarm rules (such as "Trigger a level 1 alarm if the underwriting service error rate exceeds 5%)" and push alarm information (including abnormal service, cause, and recommended solution) via SMS and DingTalk. Administrators can click the link to jump to the monitoring details page.

[0061] S20: Based on the SofaArk microserver framework, develop the implementation code for each microservice, service registration, and service discovery, and store the microservices in the SofaArk service registry.

[0062] When developing microservices based on SofaArk, it's essential to adhere to its pluggable and class-isolation design principles. The core principle is to encapsulate service logic as independent pluggables and implement service adaptation through the framework's interfaces. The following example demonstrates the implementation logic using "Information Receiving Service" and "Risk Analysis Service":

[0063] Each microservice needs to be developed as an independent Maven / Gradle module, introducing the SofaArk core dependency (such as sofa-ark-spi defining the service interface, and sofa-ark-container providing runtime container support), and adding specific dependencies according to the service characteristics (such as the information receiving service needing to introduce spring-web to handle HTTP requests, and the risk analysis service needing to introduce sofa-jraft to support distributed computing).

[0064] The configuration file (ark-plugin.xml) declares the plugin's metadata, including the plugin ID (a unique identifier, such as info-receive-plugin), version, dependent underlying framework (such as Spring), and the service interfaces that need to be exposed (for other services to call).

[0065] The information receiving service is implemented by annotating plugin classes with the `@ArkPlugin` annotation. The `start()` method initializes the HTTP request handler (e.g., based on Netty or Spring MVC) and defines the interface.

[0066] The ` / api / receive` interface receives data from multiple channels. Upon receiving the data, it calls internal validation methods (such as regular expression matching for ID card formats and health data range checks), loads the data masking component using the Class isolation utility class provided by SofaArk (to avoid conflicts with masking logic in other services), and processes sensitive information. After processing, the standardized data is published to an internal message queue (such as RocketMQ) through SofaArk's ServicePublisher interface, and logs are recorded (using SofaArkLogger to ensure consistent log format).

[0067] The risk analysis service is implemented by loading machine learning models (such as TensorFlow model files) through the FrameworkClassLoader in the init() method. Leveraging SofaArk's class isolation features, it avoids model dependency conflicts with other services. It subscribes to categorized data in the message queue using the @ArkConsumer annotation, calls the HealthRiskCalculator class to calculate health scores (e.g., accumulating risk values ​​when blood pressure exceeds the standard range), and combines this with lifestyle association models (e.g., the combined risk coefficients of smoking and drinking) to generate a rating result. It calls the data synchronization service through SofaArk's ServiceReference interface to supplement third-party health data (such as medical insurance records) to ensure the completeness of the analysis; finally, it pushes the rating results to the underwriting system via ResultSender.

[0068] All services must implement the ArkService interface of SofaArk, declaring the externally exposed interface (such as InfoReceiveService) through the getServiceInterface() method to ensure correct identification during service registration and discovery. Internally, the proxy object of the target service is obtained through the ServiceLocator provided by the framework, avoiding direct dependence on concrete implementation classes and reducing coupling.

[0069] Registering microservices with the SofaArk service registry is crucial. SofaArk relies on service registries within the SOFA ecosystem (such as SofaRegistry) and automates service registration through a plug-in mechanism. The core function is to synchronize service metadata (address, interface, status) to the registry for discovery by other services. When the SofaArk container starts, the registry address (e.g., sofa.registry.address = 192.168.1.100:9603), registration interval (default 30-second heartbeat check), and data storage type (memory or persistent) are configured in `registry-config.properties`. The registry must be deployed and started beforehand, supporting cluster mode (data consistency achieved through SOFAJRaft) to ensure high availability.

[0070] When a microservice plugin (such as an information receiving service) starts through ArkContainer, SofaArk's RegistrationService automatically detects the ArkService implementation class in the plugin and extracts service metadata, including the service ID (plugin ID + interface name), IP:port (local address assigned by the container), and supported protocols (such as HTTP and Dubbo). If the service needs to expose multiple protocol interfaces (such as providing both HTTP and RPC calls), the protocols node can be configured in ark-plugin.xml, and the registry center will record the access addresses for different protocols respectively.

[0071] During registration, RegistrationService encapsulates service information into ServiceInstance objects, including a unique service identifier (serviceId), node address (host:port), status (UP / DOWN), and tags (such as service version v1.0). It sends a registration request to the registry center via SOFAJRaft's RpcClient, and subsequently sends a heartbeat request every 30 seconds to update the service status. If a service stops abnormally (e.g., the stop() method is called), it will proactively send an unregister request. Since each service is loaded through an independent PluginClassLoader, SofaArk uses FrameworkClassLoader to uniformly manage the registry center clients (such as SofaRegistryClient), avoiding duplicate connection creation for each service and saving resources.

[0072] Service discovery is the process by which consumers obtain a list of service instances from a registry. SofaArk dynamically detects changes in registry data to automatically update service addresses and achieve load balancing. When a consumer service (such as a risk analysis service) starts, it declares the services it needs to call (such as the InfoReceiveService interface of the information receiving service) using the @Reference annotation, specifying the service version and load balancing strategy (such as round-robin or weighted). The registry address is configured in ark-consumer.xml (consistent with the service registry) along with a caching strategy (such as caching the service list locally for 5 minutes to reduce registry access pressure). When the consumer starts, it sends a subscription request (SubscribeRequest) to the registry via DiscoveryClient, specifying the target service ID; the registry returns a list of currently available service instances (including IP, port, and status). SofaArk's ServiceWatcher component monitors service changes in the registry in real time (such as adding or removing nodes). When an update to the service list is detected, it automatically refreshes the local cache and notifies the consumer to retrieve available instances again. If the target service has multiple instances (cluster deployment), the consumer selects one instance to initiate the call through a built-in load balancer (such as a weighted LoadBalancer) to avoid excessive pressure on a single node. If a call to a service instance fails (e.g., timeout, connection refused), the consumer marks that instance as "temporarily unavailable" and excludes it from the available list, while triggering a retry mechanism (selecting another instance). Through SofaArk's circuit breaker mechanism (integrated with Sentinel), when the failure rate of a service exceeds a threshold (e.g., 50%), calls to that service are automatically stopped, and a degradation result (e.g., default risk rating) is returned to prevent cascading failures.

[0073] SofaArk service registry (such as SofaRegistry) employs a distributed storage design, storing microservice information in a three-tiered structure of "service cluster - instance - metadata," supporting high-concurrency read / write operations and data consistency. Storage structure and data format: Level 1: Service Cluster: Stores all cluster information for the service (e.g., development environment cluster, production environment cluster) using the service ID (e.g., info-receive-plugin:InfoReceiveService) as the key. Level 2: Instance Nodes: Each cluster is divided into nodes by instance IP:port, storing node status (UP / DOWN), startup time, and load (e.g., current concurrent requests). Level 3: Metadata: Each instance node is associated with metadata, including supported protocols, plugin versions, dependent frameworks (e.g., Spring Boot 2.7), and custom tags (e.g., "East China region node"). Data is stored in key-value pairs, and multi-replica synchronization is achieved through the SOFAJRaft Raft protocol, ensuring data consistency within the registry cluster (no data loss even if any node fails).

[0074] When a service instance registers, the registry center verifies its legitimacy (e.g., service ID format, signature verification) before allowing it to be added to the service list. It also records the registration time for subsequent monitoring (e.g., statistics on service online duration). When a service stops normally, it actively deletes its registration information via a deregistration request. If a service crashes abnormally (without sending a deregistration request), the registry center marks it as DOWN via heartbeat detection (if no heartbeat is received for more than 1 minute) and notifies all subscribers to remove the instance. The registry center retains historical registration records for services (e.g., instance online / offline logs for the past 7 days), which can be queried by operations personnel through the SofaArk Console for issue tracing (e.g., analyzing the reasons for frequent service outages during a certain period). Even if different services depend on different versions of the registry center client (e.g., sofa-registry-client 1.0 and 2.0), SofaArk's PluginClassLoader ensures that each client runs independently, avoiding conflicts. When a service is hot-deployed as a plugin (e.g., upgrading a plugin for the risk analysis service), the registry center automatically identifies the service instance of the new plugin and marks the old instance as offline, achieving a zero-aware upgrade. The registry center works in conjunction with SofaArk's rate limiting and circuit breaker components. When a service is rate-limited, the registry center will reduce the number of instances of that service pushed to consumers, thereby indirectly reducing the call pressure.

[0075] S30: When the response time of a microservice is detected to exceed the preset circuit breaker threshold, the automatic circuit breaker mechanism is triggered, the circuit breaker threshold is adjusted, and requests to the microservice are routed to backup services or degraded.

[0076] In the SofaArk framework, the circuit breaker mechanism is implemented by integrating components such as Sentinel. It monitors the response time of microservices in real time and automatically cuts off the call chain when a preset threshold is exceeded, preventing the spread of failures. First, the circuit breaker threshold must be defined in the SofaArk governance configuration file (sofa-ark-governance.xml): using "response time" as the core metric. For example, setting "10 requests within 5 seconds, with an average response time exceeding 1 second" as the circuit breaker trigger condition (this can be adjusted according to service characteristics; for example, if a risk analysis service relies on model calculations, the threshold could be set to 2 seconds). Second, the framework collects service call data in real time through the ArkTracer component: for each request, it records the initiation time, response time, and result status (success / timeout), and uses MetricCollector to summarize and statistically analyze the data by time window (e.g., every 5 seconds), generating metrics such as response time distribution and timeout rate.

[0077] The circuit breaker triggering process after the response time exceeds the threshold is as follows: When the MetricCollector finds that the response time of a service exceeds the preset threshold (e.g., 1 second) for three consecutive time windows (e.g., 15 seconds), and the request volume reaches the minimum trigger condition (e.g., ≥ 5 requests per second), the service is determined to have entered an "unstable state," triggering a circuit breaker warning. SofaArk's CircuitBreaker component switches the service state from "closed (normal call)" to "open (circuit breaker)": at this time, all new requests are directly intercepted and no longer sent to the target service, avoiding continuous timeouts and resource consumption. The circuit breaker state change is synchronized to the service registry (SofaRegistry) in real time. The registry marks the service instance as "under circuit breaker" and notifies all consumers to update their service lists (temporarily excluding this instance).

[0078] Because each service runs independently through the PluginClassLoader, ArkTracer assigns a separate monitoring context to each service, ensuring that the response time data of service A is not mixed with that of service B, resulting in more accurate circuit breaker judgments. If custom circuit breaker logic is required (such as combining error rate and concurrency for comprehensive judgment), the custom rules can be encapsulated as a CircuitBreakerPlugin plugin and integrated through SofaArk's plugin registration mechanism without modifying the core framework code.

[0079] The circuit breaker threshold is not a fixed value and needs to be dynamically adjusted according to service load, business scenarios, and resource changes. SofaArk optimizes the threshold through a combination of "automatic adaptation and manual intervention": SofaArk's LoadMonitor component monitors the resource utilization (CPU, memory, network I / O) of the node where the service is located in real time: when the node's CPU utilization exceeds 80%, the response time threshold is automatically reduced by 20% (e.g., from 1 second to 0.8 seconds) - because when resources are scarce, the service response capability decreases, and the circuit breaker needs to be triggered earlier to protect the node.

[0080] By using the ScheduleAdjuster component to associate with peak business periods (such as the peak insurance application season from 9:00 to 11:00), the threshold can be relaxed in advance (e.g., from 1 second to 1.5 seconds): allowing the service to have a certain response delay under high concurrency, avoiding accidental triggering of circuit breakers and affecting business continuity.

[0081] The historical data learning framework retains circuit breaker records and service performance data from the past 30 days. It analyzes the "optimal threshold range" using the ThresholdLearner component (e.g., if a service's response time is consistently around 0.5 seconds under normal load, setting the threshold to 1 second would be more reasonable), and automatically updates the threshold configuration during off-peak hours each week. Operations personnel can manually modify the circuit breaker threshold for a specific service through the "Service Governance" module in the SofaArk Console (e.g., temporarily adjusting the threshold for the information receiving service from 1 second to 1.2 seconds). The adjustment takes effect immediately without requiring a service restart. After modifying the threshold, the framework first applies the new threshold to 10% of requests and compares the number of circuit breakers and request success rate before and after the adjustment using the EffectVerifier component. If the new threshold causes an abnormal increase in the number of circuit breakers (e.g., a 50% increase), it automatically rolls back to the original configuration to avoid human error.

[0082] The adjusted thresholds are synchronized to the service metadata in the registry center, ensuring that all consumers receive the latest rules. For example, if the threshold for service A is adjusted from 1 second to 0.8 seconds, the registry center will write the new threshold to the service instance's metadata tag, and consumers will perceive and apply the new rules through the service discovery mechanism. For services deployed in a cluster, threshold adjustments adopt a "batch synchronization" strategy: through the SOFAJRaft consistency protocol, it is ensured that all nodes complete the threshold update within 3 seconds, avoiding inconsistencies in circuit breaker judgments caused by some nodes using the old thresholds.

[0083] During a circuit breaker event, SofaArk needs to ensure business continuity through "request routing" or "degradation processing." The core of this is to combine instance information from the service registry with pre-defined policies to achieve seamless failover. When designing services, "backup service instances" need to be deployed for core services (such as risk analysis services). These instances have the same interface as the primary service but may use simplified logic (e.g., a lightweight version of the risk model), and are distinguished by "tags" in the registry (e.g., primary service tag = primary, backup service tag = backup).

[0084] When the primary service triggers a circuit breaker, the consumer's Router component retrieves a list of service instances from the registry, automatically filters out the primary services "under circuit breaker," selects backup service instances with the tag "role=backup," and forwards requests via load balancing (e.g., round-robin). If the backup service also has response latency (not triggered but close to the threshold), the Router adjusts the weights based on the backup service's real-time response time—for example, if backup instance A has a response time of 0.5 seconds and backup instance B has a response time of 1 second, then 60% of requests will be routed to A and 40% to B, preventing the backup service from being overwhelmed.

[0085] Configure fallback logic for each service in ark-fallback.xml. For example, the information receiving service can be downgraded to only receive key fields (such as ID card and core health indicators) and ignore unnecessary data (such as details of lifestyle habits) to reduce processing time. The risk analysis service can be downgraded to use a preset "basic risk scoring table" (such as age + underlying disease directly corresponding to the score) to replace complex model calculations, reducing the response time from 2 seconds to 0.3 seconds.

[0086] When no backup service is available, the FallbackExecutor component automatically executes the degradation logic: after intercepting the original request, it calls the local degradation method (such as RiskAnalysisFallback.calculateBasicScore()), returns a simplified result, and marks it as "degraded" in the log. The degradation result must be consistent with the normal response format (e.g., both return a RiskResult object), only the content is simplified (e.g., lacking detailed risk factor descriptions), ensuring that downstream underwriting systems are compatible without modification.

[0087] After the circuit breaker is open for a period of time (e.g., 30 seconds), the CircuitBreaker will switch the state to "half-open": allowing a small number of requests (e.g., 10) to attempt to call the original service. If the response time of these requests recovers to within the threshold (e.g., ≤1 second) and the success rate is ≥90%, the service is considered to have recovered, and the state is switched back to "closed". After recovery, the Router will not immediately switch all requests back to the primary service, but will adopt a "gradual weighting" strategy: first, 30% of requests will be routed to the primary service, and after observing for 1 minute without any anomalies, the percentage will be increased to 70%, and finally, a complete switch will be made to avoid sudden traffic surges that could cause service instability again. Throughout the recovery process, the AlertManager component will monitor the primary service response time in real time. If the circuit breaker is triggered again after the switchback, an alert will be immediately issued and the service will be switched back to the backup / degraded state, while simultaneously notifying operations personnel to investigate the root cause.

[0088] SofaArk's circuit breaker mechanism is not an independent module, but rather works in conjunction with features such as the registry center, class isolation, and plug-in architecture to improve reliability: Degradation methods (such as the Fallback class) are loaded via PluginClassLoader, isolated from the main service logic, avoiding dependency conflicts affecting degradation execution (e.g., the main service uses Jackson 2.10, while the degradation logic uses Jackson 2.9, ensuring no interference). After the circuit breaker status is synchronized to the registry center, the registry center proactively reduces instance pushes to the circuit breaker service, eliminating the need for frequent queries from consumers and reducing network overhead; simultaneously, metadata tags (such as circuitBreaker=open) make routing decisions more efficient. If new routing rules need to be added (such as prioritizing routing to local backup services based on region), the rules can be encapsulated as RouterPlugin plugins and integrated into the framework via hot deployment, without requiring a restart of the entire service cluster.

[0089] S40: Once the circuit breaker is adjusted to normal, the circuit breaker state will be automatically released, and the normal calling logic will be gradually restored.

[0090] Once the microservice recovers, SofaArk uses a "half-open" state as a transition to gradually verify service availability, eventually automatically releasing the circuit breaker. The entire process relies on real-time monitoring and dynamic judgment: After the circuit breaker remains in the "open" state for a configurable period (e.g., 30 seconds, typically set based on the service recovery cycle), the CircuitBreaker component automatically switches the state to "half-open." At this point, requests are no longer completely blocked; instead, a small number of exploratory requests (e.g., 10) are allowed to be sent to the original service to verify the recovery status. Priority is given to non-core business requests (e.g., query requests, rather than write requests for insurance applications), and these are distributed over 10 seconds to avoid putting pressure on the newly recovered service due to concentrated calls. The MetricCollector monitors the response data of the exploratory requests in real time: if the response time of all requests is below the circuit breaker threshold (e.g., ≤1 second), with no timeouts or errors, and a success rate ≥95%, the service is considered to have recovered stably, triggering the release of the circuit breaker.

[0091] Once the status changes from "half-open" to "closed (normal)," CircuitBreaker immediately writes the status change to its local cache and synchronizes it to the service registry. The registry removes the "circuit breaker in progress" label from the service instance, updates the metadata to "normal," and notifies all consumers who have subscribed to the service.

[0092] Consumers use the ServiceWatcher component to detect state changes, clear the local "circuit breaker" flag for the service, and restore normal call permissions. Simultaneously, the framework generates a state change log (including trigger reasons, recovery time, and trial request results) for subsequent auditing and optimization.

[0093] If a trial request in the half-open state fails verification (e.g., 2 out of 5 requests have response times exceeding the threshold), CircuitBreaker will immediately switch the state back to "open" and extend the circuit breaker duration (e.g., from 30 seconds to 1 minute) to avoid service instability caused by frequent switching. After two consecutive verification failures, AlertManager will trigger an alert (e.g., SMS, DingTalk notification) to prompt operations personnel to manually intervene and investigate (e.g., whether service node resources are sufficient, whether dependent databases have been restored).

[0094] After the circuit breaker is lifted, requests will not be immediately switched back to the original service. Instead, normal calls will be gradually restored through a "progressive traffic distribution" strategy to avoid service overload caused by sudden traffic surges. In the initial recovery phase (e.g., the first minute), the Router component adopts a "hybrid routing of primary and secondary services": 30% of requests are routed to the original service (the restored primary service), while 70% are still routed to the backup service (or remain in a degraded state). LoadMonitor monitors the resource utilization (e.g., CPU, memory) and response time of the primary service.

[0095] If the primary service's response time remains stable within the threshold (e.g., an average of 0.8 seconds) and resource utilization is below 70% (no signs of overload), then proceed to the second phase: increase the traffic weight of the primary service to 70%, reduce the backup service to 30%, and continue observation for 30 seconds. If the primary service remains stable (e.g., no anomalies for another 30 seconds), the traffic weight is adjusted to 100%, all requests are switched back to the original service, and the backup service returns to a "standby" state (only activated when the primary service experiences another circuit breaker).

[0096] For core business requests (such as insurance application review requests for risk analysis services), the rollback speed is more conservative: initially only 20% of the traffic is allocated, and the verification cycle for each step is extended to 2 minutes to ensure the stability of the core process; non-core business requests (such as historical insurance record queries) can be rolled back faster (initially 50% of the traffic). During the recovery process, the Router will prioritize ensuring the routing stability of core requests: if the main service experiences response latency after the rollback of non-core requests (not reaching the circuit breaker threshold but close), the traffic increase for core requests will be suspended until the response of non-core requests returns to normal.

[0097] When the primary service's traffic share reaches 100%, the backup service will not immediately go offline, but will remain "hot standby" for 30 minutes. During this period, if the primary service experiences response latency again (e.g., 5 consecutive requests exceeding the 80% threshold), the backup service can be quickly switched back to avoid a second circuit breaker. If degradation processing is used (in scenarios without a backup service), the FallbackExecutor will gradually exit after recovery: first, it will restore some complex logic (e.g., the risk analysis service will load a simplified model first, then the complete model), and finally, it will disable the degradation method, ensuring a smooth transition from the "simplified version" to the "complete version".

[0098] To prevent circuit breakers from being triggered again due to traffic fluctuations after recovery, SofaArk constructs a multi-layered protection mechanism through dynamic rate limiting, load balancing optimization, and real-time monitoring: Within 10 minutes after the circuit breaker is lifted (the "recovery period"), the FlowController component sets a "recovery rate limiting threshold" for the service: the maximum number of concurrent requests allowed is 80% of the normal threshold (e.g., if it can normally handle 1000 QPS, the recovery period threshold is set to 800 QPS), preventing the service from being overwhelmed by traffic. The rate limiting strategy is dynamically adjusted according to the service status: if the service response time is stable during the recovery period (e.g., consistently below 70% of the threshold), the rate limiting threshold is increased by 10% every 2 minutes until it returns to normal levels; if the response latency increases, the increase is immediately paused and the current threshold is maintained. After recovery, the registry center synchronizes the "recovery status" of the main service instance to the consumer. When selecting an instance, the consumer's LoadBalancer prioritizes routing to nodes with more abundant resources (e.g., nodes with CPU utilization below 60%), avoiding requests being concentrated on newly recovered high-load nodes. For services deployed in a cluster, ClusterManager adjusts the weights of each node based on their recovery status: newly recovered nodes have a lower initial weight (e.g., 0.6), which is increased to 1.0 after running for 5 minutes without any anomalies, ensuring even distribution of traffic.

[0099] The ArkMonitor component increases monitoring frequency during recovery (reduced from 10 seconds / time to 2 seconds / time).

[0100] The system focuses on tracking three key metrics: response time, error rate, and resource utilization, generating real-time trend curves. If any anomalies are detected (e.g., response time suddenly increases from 0.8 seconds to 1.2 seconds), the EarlyWarning component will trigger an alert and automatically implement preventative measures, even if the circuit breaker threshold is not reached. These measures include temporarily reducing the service's traffic weight (from 100% to 80%) and notifying operations personnel. After the recovery period ends (e.g., after 10 minutes), the monitoring frequency returns to normal, but the framework retains data from the recovery phase for 3 days to analyze service recovery patterns (e.g., "traffic peaks are likely to occur 5 minutes after each recovery"), providing a basis for subsequent optimization of the circuit breaker strategy.

[0101] In another embodiment, when the number of requests exceeds a threshold, some requests are automatically rejected or queued for processing; based on historical data and real-time monitoring, the flow control parameters are dynamically adjusted, and normal calling logic is gradually restored.

[0102] When the request volume of a microservice exceeds a preset threshold, SofaArk automates the process through its flow control component. The core principle is to minimize the impact on normal business operations while protecting service stability. The handling methods are divided into "rejecting some requests" and "queuing," dynamically selected based on service characteristics. In SofaArk's flow control configuration, a "maximum concurrent requests" (e.g., a risk analysis service can handle a maximum of 1000 requests per second) and a "request queue length" (e.g., a maximum of 200 queued requests can be cached) are set for each service. When the real-time request volume exceeds the maximum concurrency and the queue is full, the FlowController component automatically intercepts the excess requests.

[0103] During interception, core requests (such as insurance application submissions) are prioritized, while non-core requests (such as historical policy inquiries) are rejected. Priority is identified through request tags (e.g., priority = high / low). High-priority requests will be queued even if they trigger a threshold, while low-priority requests are directly rejected with a "Service busy, please try again later" message. Rejected requests are recorded in the RejectedRequestLog (including request ID, time, and type) for later analysis of traffic peak characteristics. Simultaneously, the framework returns standardized error codes (e.g., 503) and retry suggestions (e.g., "Try again in 1 minute") to the client to avoid user confusion.

[0104] For scenarios where the request volume briefly exceeds the threshold but does not reach the queue limit (e.g., 1200 requests per second, threshold 1000, queue capacity 200), QueueManager will place the excess 200 requests into an in-memory queue, which will then be processed in a "first-in, first-out" order. The queue length will automatically adjust based on the service response speed: if the service processing speed is fast (e.g., an average of 0.5 seconds per request), the queue can be temporarily expanded to 300; if processing slows down, it will shrink to 100 to prevent queue backlog and request timeouts.

[0105] Requests in the queue are marked with a timeout period (e.g., 3 seconds by default). If a request remains unprocessed after this time, the QueueManager will automatically remove it from the queue and treat it as a "rejected request," while recording the timeout reason (e.g., "queue timeout due to service processing delay") to prevent requests from occupying queue resources for extended periods. The queue supports priority sorting; high-priority requests (e.g., underwriting result queries) are inserted at the front of the queue to receive priority processing opportunities; low-priority requests are queued in normal order to ensure that core business operations are not affected by queuing delays.

[0106] SofaArk uses the TrafficAnalyzer component to analyze request characteristics in real time: if the traffic is "bursting and pulse-like" (e.g., the number of requests surges from 500 to 2000 within 10 seconds and then drops rapidly), queuing is prioritized to buffer short-term peaks; if the traffic is "continuously growing" (e.g., the number of requests steadily increases from 800 to 1500 within 3 minutes without any downward trend), the rejection policy is automatically switched to avoid continuous queue backlog leading to overall timeouts.

[0107] The processing method can be preset with biases in the configuration file: for example, the risk analysis service relies on model calculations and takes a long time to process, so it can be set to "reject with priority for shorter queue lengths"; while the insurance application receiving service has simple logic, so it can be set to "queue with priority for longer queue lengths" to adapt to the service characteristics.

[0108] Traffic control parameters (such as maximum concurrency and queue length) are not fixed values. SofaArk dynamically optimizes these parameters by analyzing historical data and real-time monitoring metrics to ensure that it can cope with traffic fluctuations without wasting service resources.

[0109] Historical data references: The HistoricalDataAnalyzer component periodically analyzes traffic data from the past 7 days to extract patterns and characteristics. For example, 9:00-11:00 AM is the peak period for insurance applications, with request volume reaching 1500 QPS; the early morning period only sees 100 QPS. Based on this, preset "time-based parameters" are used—the maximum concurrency during peak periods is set to 1200, and during off-peak periods it is set to 800, avoiding wasted resources during low-peak hours and insufficient protection during peak hours with fixed parameters.

[0110] RealTimeMonitor collects service performance metrics every second (such as current concurrency, response time, and CPU utilization). When it detects a mismatch between the "actual processing capacity" and the "current parameters" (e.g., the parameters allow 1000 QPS, but the service CPU is already at 90%, and it can only process 800 in reality), it triggers immediate adjustments.

[0111] The execution logic is dynamically adjusted. During peak periods, parameter scaling is implemented. If real-time monitoring shows a continuous increase in request volume (e.g., maintaining 1100 QPS for 30 consecutive seconds, approaching the current threshold of 1200), and service resources still have redundancy (CPU ≤ 70%), ParameterAdjuster will automatically increase the maximum concurrency by 10% (to 1320) and the queue length by 20% to adapt to the traffic growth. After adjustment, continuous monitoring continues. If resource utilization subsequently rises to 80%, scaling will stop.

[0112] During off-peak periods, parameter contraction occurs when request volume remains below the threshold for an extended period (e.g., maintaining 500 QPS for 5 consecutive minutes, which is only 60% of the current threshold of 800), and service resources are idle (memory utilization).

[0113] If the concurrency rate is ≤40%, the maximum concurrency will be reduced to 600 to reduce resource consumption (e.g., releasing some thread pool resources). If traffic recovers later, it will be gradually adjusted back.

[0114] In case of abnormal scenarios, if the service response time increases significantly with the increase in the number of requests (e.g., from 0.5 seconds to 1.5 seconds), even if the resource limit is not reached, ParameterAdjuster will actively reduce the threshold (e.g., from 1000 to 800) to prevent the response delay from spreading to the overall timeout.

[0115] Each adjustment should not exceed 20% (e.g., if the current threshold is 1000, adjust it to a maximum of 1200 or 800) to avoid large fluctuations that could cause service disruptions. If a larger adjustment is needed (e.g., from 800 to 1500), it should be done in multiple steps (adjusting by 20% each time, with a 1-minute interval for observation).

[0116] After the new parameters take effect, apply them to 20% of the requests first. If there are no abnormalities within 1 minute (stable response time, no large number of rejections), then apply them to all requests. If the request failure rate increases (e.g., from 1% to 5%), immediately roll back to the original parameters and record the reason for the adjustment failure (e.g., "the database on which the service depends has insufficient performance, and the scaling parameters are invalid").

[0117] Once traffic returns to normal levels or service resources are restored to sufficient levels, SofaArk gradually lifts traffic control and resumes normal calls through a strategy of "gradual parameter callback" and "request ramp-up," preventing a sudden surge in traffic. When the real-time request volume is below 60% of the current threshold for three consecutive minutes (e.g., threshold 1200, actual 600), and service resource utilization remains below 50% (CPU ≤ 50%, memory ≤ 50%), the system will continue to implement traffic control.

[0118] If traffic spikes (≤40%), RecoveryTrigger determines that "traffic control can be released" and initiates the recovery process. If traffic surges due to a temporary event (such as a promotion) and then drops rapidly after the event ends, HistoricalDataAnalyzer will identify "non-periodic peaks" and trigger recovery in advance (without waiting 3 minutes), reducing the time that normal business is affected.

[0119] The parameters are gradually restored using a "reverse adjustment" logic. For example, if the threshold is increased from 1000 to 1320 during peak periods, it is first adjusted back to 1200 during restoration (observe for 2 minutes for any anomalies), then back to 1000. Simultaneously, the queue length is reduced to the default value to avoid unnecessary memory usage. During restoration, low-priority requests that were initially rejected (such as historical policy queries) are restored first, then restrictions on core requests are gradually lifted. A "service restoration notification" is pushed to the client via the RequestReleaser component to guide non-core requests to initiate first, avoiding a concentrated backflow of core requests. If both flow control and circuit breaker mechanisms are in effect (e.g., the service first triggers flow limiting due to traffic overload, then triggers circuit breaker due to response timeout), the circuit breaker status must be lifted first during restoration (refer to the previous circuit breaker restoration logic), then flow control is lifted to ensure service stability before increasing traffic.

[0120] Within 10 minutes of recovery, PostRecoveryMonitor maintains high-frequency monitoring (every 5 seconds), tracking request volume, response time, and resource utilization. Once no rebound is confirmed, the monitoring frequency returns to normal. The framework automatically records the entire process data of this traffic control (trigger time, parameter adjustment records, recovery time, and request processing results), and combines historical data to optimize future strategies.

[0121] In another embodiment, requests are evenly distributed to multiple microservice instances according to a load balancing algorithm, and the load balancing is dynamically adjusted based on the health status and load of the microservice instances; when the load increases, the circuit breaker threshold is automatically increased to reduce the possibility of circuit breaker triggering; when the load decreases, the default configuration is automatically restored.

[0122] In the SofaArk framework, load balancing is implemented through a built-in load balancer. Its core principle is to evenly distribute requests across multiple microservice instances, dynamically adjusting based on instance health and load to ensure efficient resource utilization. SofaArk supports various classic load balancing algorithms, selectable according to the characteristics of the microservice. For example, the round-robin algorithm distributes requests sequentially to instances, with each instance processing requests in turn. This is suitable for scenarios where instances have similar performance, such as multiple instances in an insurance application receiving service, where round-robin can achieve basic load balancing. The weighted round-robin algorithm assigns weights to instances with different performance levels. Instances with higher performance (e.g., higher CPU and memory configurations) receive higher weights and more requests. For example, in a risk analysis service, fast-processing instances might have a weight of 1.5, while ordinary instances might have a weight of 1.0, thus balancing the load across different instances.

[0123] The framework monitors the status of microservice instances in real time through a health check mechanism. Health checks include periodically sending heartbeat requests to check if instances can respond normally, and monitoring the instance's error rate (e.g., a request failure rate exceeding 5% is considered sub-healthy). When an instance's health status is found to be abnormal (e.g., three consecutive heartbeat failures or an excessively high error rate), the load balancer removes it from the list of available instances and stops allocating requests to it, preventing requests from being sent to the faulty instance. If the instance subsequently recovers its health (multiple consecutive normal heartbeats and an error rate below 1%), it is added back to the available list, and requests are gradually allocated to it (initially allocating a small number of requests for verification, and resuming the normal allocation ratio after confirmation of stability).

[0124] The load balancer collects real-time load metrics for each instance, such as CPU utilization, memory usage, and current concurrent requests. Based on these metrics, the load balancer dynamically adjusts its allocation strategy. When an instance's CPU utilization exceeds 80% or its concurrent requests approach the limit, the request allocation to that instance is reduced; while instances with lower loads (CPU utilization below 50% and fewer concurrent requests) are allocated more requests.

[0125] When the overall load on microservices increases, SofaArk dynamically adjusts the circuit breaker threshold to reduce the likelihood of triggering circuit breakers, preventing service interruptions caused by normal fluctuations. The framework monitors the overall load of the cluster in real time, including metrics such as average CPU utilization, average memory usage, and total request volume. When these metrics exceed preset load increase thresholds (e.g., average CPU utilization exceeding 70% for one consecutive minute, or total request volume reaching 120% of the daily peak), it is determined to be a load increase state. Simultaneously, by comparing with historical data, if the current load is significantly higher than the normal level for the same period, a load increase judgment will also be triggered.

[0126] Under increased load, the framework automatically raises the circuit breaker threshold. For example, the original threshold of "average response time of 10 requests exceeding 1 second within 5 seconds" is adjusted to "average response time of 10 requests exceeding 1.5 seconds within 5 seconds," giving the service more processing time. Simultaneously, the number of requests required to trigger the circuit breaker is increased, such as from "10 requests" to "15 requests," reducing false triggers caused by a short-term surge in requests. The adjustment range is determined by the degree of load increase; the higher the load (e.g., CPU utilization reaching 85%), the greater the threshold increase, but an upper limit is set (e.g., a maximum increase of 50%) to prevent the threshold from becoming too high and losing its protective function.

[0127] After adjusting the circuit breaker threshold, continuously monitor service response time and error rate. If it is found that although the load is high, the service can still stably handle requests (response time within the new threshold and error rate is low), then maintain the adjusted threshold; if the response time frequently approaches the new threshold or the error rate increases, further increases to the threshold will be paused, and the request allocation ratio of lower-load instances will be appropriately increased to alleviate the pressure on high-load instances.

[0128] When the load drops to a normal level, SofaArk automatically restores the circuit breaker threshold to the default configuration, ensuring that the service has reasonable circuit breaker protection under normal load. When the cluster's average CPU utilization is below 50% for two consecutive minutes, the overall request volume drops below 80% of the daily peak, and the load of each instance is at a low level (no instance CPU utilization exceeds 60%), the framework determines that the load has dropped to a normal state. If the load reduction is due to a temporary decrease in traffic (such as the end of a promotional activity), a recovery judgment will also be triggered after confirmation based on historical data.

[0129] The recovery process is gradual, avoiding immediate reverting of the adjusted threshold to its default value. For example, the response time threshold is first adjusted from 1.5 seconds to 1.3 seconds, observed for one minute, and if the service remains stable (response time consistently within 1 second with no circuit breaker triggers), then adjusted to 1.1 seconds, and finally restored to the default 1 second. This avoids sudden circuit breaker triggering due to a sharp drop in the threshold. Simultaneously, the request quantity condition for triggering the circuit breaker is also gradually restored to its default value.

[0130] After restoring the default configuration, monitor the service's operation under normal load to confirm that the circuit breaker mechanism is working properly (e.g., triggering the circuit breaker at the default threshold when abnormal requests occur). If it is found that the circuit breaker triggers too frequently after recovery (not due to a problem with the service itself, but possibly due to fluctuations during the recovery process), appropriately slow down the recovery process to ensure service stability. SofaArk's load balancing and circuit breaker threshold adjustment do not operate independently, but are deeply integrated with the service registry, monitoring system, etc. The service registry synchronizes instance health status and load information in real time, providing accurate data for load balancing and circuit breaker adjustments; the monitoring system feeds back load, response time, and other data to relevant components in real time to ensure timely and reasonable adjustments. Furthermore, through a plug-in mechanism, load assessment metrics and circuit breaker threshold adjustment rules can be customized according to business needs. For example, for core underwriting result microservices, more conservative load assessment standards and circuit breaker threshold adjustment ranges can be set to ensure the stability of core business operations.

[0131] In another embodiment, each microservice is defined with a standard SPI interface, and the input parameters, output results, and exception handling logic of the microservice are specified. When a microservice needs to be added or modified, the new microservice is quickly developed and deployed through the extension mechanism of the SPI interface. After the new microservice is registered with the service registry, the new microservice is automatically identified and loaded. When a service needs to be taken offline, the offline service is dynamically unloaded.

[0132] In the SofaArk framework, SPI (Service Provider Interface) is a standardized contract for interaction between microservices. Each microservice must implement a unified SPI interface, specifying input parameters, output results, and exception handling rules to ensure consistency between service expansion and invocation.

[0133] SPI interfaces must be named using the format "Function + Service" (e.g., InsuranceApplicationService corresponds to the insurance application microservice). The core methods of the service must be declared in the interface (e.g., submitApplication is used to receive insurance applications). The interface must be marked with the @SPI annotation by SofaArk, and the framework will automatically scan and recognize it as an extensible service interface.

[0134] Input parameters must be encapsulated as a unified Data Transfer Object (DTO). For example, the InsuranceApplicationDTO for the insurance application service should contain fixed fields (such as userId, productId, and applyTime), and validation rules should be defined using the @Valid annotation (such as userId being non-empty and applyTime being in timestamp format). Parameter types should use common types supported by the framework (such as String and Integer) to avoid compatibility issues caused by custom complex types.

[0135] The output should include three parts: "status code", "data", and "description" (e.g., a ServiceResult object). The status code is represented by "code" (200 for success and 500 for failure); the "data" field stores business data (e.g., UnderwritingResult for underwriting results); and the "message" field describes the result details (e.g., "Application submitted successfully").

[0136] Microservices internally use try-catch blocks to catch exceptions and map them to standardized output results: for example, ParamException corresponds to status code 400, BusinessException to 403, and SystemException to 500. The specific reason for the exception is also entered in the message (sensitive information is masked). For uncaught exceptions, the framework's GlobalExceptionHandler automatically intercepts them and returns the default system exception result (avoiding exposure of stack trace information).

[0137] The exception must include a traceId (global trace ID), which is generated and passed in by the caller. The microservice carries this ID when throwing an exception, which makes it easier to trace the exception chain through logs (such as the exception propagation path from the insurance application service to the underwriting service).

[0138] SofaArk supports the dynamic addition or modification of microservices through its SPI interface extension mechanism. This eliminates the need to modify existing service code; only a new implementation needs to be developed and deployed, and the framework automatically handles registration, identification, and loading. When adding a microservice, a class implementing the corresponding SPI interface must be created (e.g., `NewInsuranceApplicationServiceImpl` implements `InsuranceApplicationService`), and the "service identifier" must be specified using the `@ServiceProvider` annotation (e.g., `provider = new-application`). If modifying an existing service, only a new implementation class needs to be developed (e.g., `OptimizedUnderwritingServiceImpl` optimizes underwriting rules), keeping the interface unchanged and only updating the method logic.

[0139] The implementation class needs to be packaged as an Ark Plugin (including class files, dependency libraries, and the SPI configuration file in the META-INF / services directory—the file content should contain the full path to the implementation class). During deployment, upload the plugin to the SofaArk plugin directory. The framework automatically detects the new plugin through PluginDeployer, without requiring a restart of the entire framework. If service modifications require compatibility with older versions (e.g., adding a "Smart Underwriting" function to the underwriting service while retaining the old "Manual Underwriting" logic), the version can be marked in the implementation class using the @Version annotation (e.g., version=2.0). The caller can specify the service version to call through the version parameter, achieving a smooth transition.

[0140] After plugin deployment, SofaArk's ServiceRegistryClient reads the information of the SPI implementation class (service identifier, version, interface methods) and automatically registers it with the service registry (SofaRegistry). The registration information includes metadata such as "service interface name," "implementation class identifier," and "node address." The registry synchronizes the new service information to all callers. The caller's ServiceDiscoverer component detects the new service instance by listening for changes in the registry's metadata. The framework creates a proxy object for the new service (generated via ProxyFactory). The proxy object implements the corresponding SPI interface. Callers do not need to modify their code; they can directly call the new service through the original interface reference (e.g., insuranceApplicationService.submitApplication() automatically routes to the new implementation). If multiple implementation classes exist (e.g., old service provider = old-application and new service provider = new-application), the framework selects the appropriate one using a "priority" mechanism.

[0141] In the @ServiceProvider annotation, you can set the priority (the larger the value, the higher the priority), or the caller can specify a specific implementation by using the @Reference annotation to select the provider parameter, thus avoiding conflicts.

[0142] When a microservice needs to be taken offline (e.g., for version iteration or fault repair), SofaArk supports dynamic unloading to ensure that the offline process does not affect overall business continuity. The core principle is "gradual traffic migration + safe resource release." Operations personnel mark services to be taken offline via the SofaArk console (specifying the service identifier and version). The framework updates the service status to "DEPRECATED" and synchronizes it to the registry center. The registry center notifies all callers that new requests will no longer be routed to this service instance, and established long-lived connections will be gradually closed. After a service is marked as "DEPRECATED," it will no longer accept new requests but will continue to process currently executing requests (with a maximum wait time set, such as 30 seconds). If the request is not completed within the timeout period, the framework records the ID of the incomplete request and reroutes it to other available instances via the RequestRecovery component to avoid request loss.

[0143] After processing existing requests, the ServiceUnloader component begins unloading: first, it closes external resources such as database connections and cache connections; then, it removes dependencies on other services (e.g., before the underwriting service goes offline, it notifies the insurance service not to send requests to it); finally, it unloads the service class files through PluginClassLoader, releasing memory resources (e.g., unloading the memory occupied by the machine learning model of the model computation service). After unloading, the service instance is removed from the available list in the registry, and its metadata is marked as "OFFLINE". Upon detecting this, the caller's ServiceWatcher clears the local cached service information, and subsequent requests will not attempt to invoke it again.

[0144] The framework uses the ResourceCleaner component to scan and clean up residual resources: deleting temporary files (such as temporary PDF files for the policy generation service), canceling scheduled tasks (such as automatic reconciliation tasks for the premium calculation service), and shutting down thread pools (ensuring all threads terminate gracefully). After cleanup, an unload log (including unload time and the amount of resources released) is generated for operations and maintenance auditing. If any anomalies are detected during unload (such as resource release failure or unprocessed core requests), UnloadMonitor will immediately pause the unload process, roll back the service status to "AVAILABLE," and trigger an alarm to notify operations and maintenance personnel.

[0145] If a problem is found in the new service after it has been taken offline (such as abnormal underwriting results), a "rollback" can be triggered through the console: the registry center reactivates the offline service, and the caller automatically resumes its request routing until the problem is resolved. If multiple related services need to be taken offline (such as insurance application, underwriting, and premium calculation services), the framework supports sorting by "dependency" (taking offline downstream services first, then taking offline upstream services), for example, taking offline the premium calculation service first, then the underwriting service, and finally the insurance application service, to avoid service call failures.

[0146] SofaArk's SPI mechanism works deeply with service registration, class isolation, and plug-in features to ensure efficient and reliable microservice expansion and uninstallation: New service plugins are loaded via PluginClassLoader, completely isolated from existing service libraries (e.g., the rule engine library dependent on the new underwriting service will not affect the old version), avoiding class conflicts caused by expansion. Service registration / deactivation status is synchronized to the registry center in real time, and callers are unaware of it through the service discovery mechanism, completing service switching without restarting the application, achieving "zero-downtime updates." Implementation classes of the SPI interface are deployed as plugins, supporting individual upgrades (e.g., updating only the underwriting service plugin, without affecting other services), and plugins can contain independent configuration files and dependency libraries to meet personalized needs (e.g., rule configurations for different underwriting scenarios). From service registration and invocation to uninstallation, each step is linked to logs via traceId, combined with metadata change records from the registry center, allowing complete traceability of the service lifecycle (e.g., "changes in call volume and response time of a certain underwriting service from launch to deactivation"), facilitating troubleshooting and optimization.

[0147] In another embodiment, the monitoring component based on SofaArk collects the running data of each microservice in real time, including at least CPU utilization, memory usage, response time, and error rate; and outputs the running data to the platform interface to display the running status of each microservice.

[0148] SofaArk's monitoring component uses a lightweight data collection mechanism to acquire core operational metrics for each microservice in real time, covering dimensions such as resource usage, performance, and error status, providing data support for service governance. Its collection logic is deeply integrated with the framework's features, ensuring data accuracy with minimal impact on service performance.

[0149] CPU utilization is obtained by calling the underlying operating system interface (such as / proc / stat in Linux) through the framework's built-in ResourceCollector component to obtain the CPU utilization of the process where the microservice resides. Collection is performed at the "instance level", that is, each microservice instance is counted separately (e.g., the three instances of the underwriting service each have their own CPU utilization data), and it is updated in real time at a frequency of 1 second, balancing real-time performance and resource consumption.

[0150] Also collected by ResourceCollector, it is divided into two categories: "heap memory" and "non-heap memory". Heap memory is obtained through JVM's MemoryMXBean (e.g., used heap memory, maximum heap memory), while non-heap memory (e.g., method area, virtual machine stack) is statistically analyzed through the ManagementFactory interface. During collection, memory usage trends (e.g., memory fluctuations within 5 minutes) are recorded, rather than simply instantaneous values, which facilitates the identification of problems such as memory leaks.

[0151] The TraceCollector component is used to collect data by recording timestamps at the entry and exit points of microservice calls (such as the implementation method of the SPI interface), and the difference between the two is the response time. Simultaneously, statistics are collected at the "interface granularity" (e.g., the submitApplication method of the insurance application service is counted separately), and the response times of successful and failed requests are distinguished to avoid outliers interfering with the overall evaluation.

[0152] The ErrorCollector component monitors the exception output of microservices in real time (based on the unified capture mechanism of ArkBaseException) and calculates the error rate in a "minute-level time window": Error Rate = (Number of exception requests ÷ Total number of requests) × 100%. Error types are further subdivided (business errors, system errors, parameter errors). For example, "incorrect insured age" in the underwriting service is a business error, while "database connection timeout" is a system error, and the percentage of each is calculated separately.

[0153] All data collection operations employ asynchronous, non-blocking mode. The collection logic of ResourceCollector and TraceCollector runs in an independent thread pool (isolated from the business thread pool) to avoid consuming business processing resources. The CPU consumption of a single instance's data collection operations is controlled to within 1%, and memory usage does not exceed 10MB, ensuring no significant impact on microservice performance.

[0154] Under normal conditions, data is collected at the default frequency (1 second / time). When a service anomaly is detected (such as a sudden increase in CPU usage above 80%), the collection frequency is automatically increased to 0.5 seconds / time to capture detailed data during the abnormal period. When the service is idle (such as when the request volume is extremely low in the early morning), the frequency is reduced to 5 seconds / time to reduce resource waste.

[0155] The collected raw data will first be processed by the DataAggregator component: duplicate data will be deduplicated (e.g., if the CPU usage is the same multiple times, the records will be merged), outliers (e.g., 100% CPU usage caused by instantaneous fluctuations) will be marked and temporarily stored (not used directly for display to avoid misleading), and finally the "cleaned" structured data (including indicator name, value, timestamp, instance ID) will be output.

[0156] The collected operational data is output to the monitoring platform interface through a standardized interface, presenting the operational status of each microservice in a visual manner. It supports real-time monitoring, anomaly alerts, and historical data analysis, with an interface design that balances intuitiveness and professionalism. Data transmission and format: SofaArk's DataExporter component outputs the cleaned operational data in "minute-level batches," encapsulated in JSON format (including serviceName, instanceId, metrics, and timestamp). Data is sent to the monitoring platform via HTTP interface or message queue (such as RocketMQ) to ensure reliable transmission (automatic retries upon failure).

[0157] The monitoring platform needs to support SofaArk's standard data format. If using a third-party platform (such as Grafana), the format conversion can be completed through the "adaptation plugin" provided by the framework (such as converting JSON data to the platform-compatible TimeSeries format). If it is a self-developed platform, the native data can be parsed directly, reducing the adaptation cost.

[0158] The service overview panel displays the overall status by "service cluster": health levels are indicated by color (green for normal, yellow for sub-health, and red for abnormal). For example, the insurance service cluster is displayed in green (all instances CPU ≤ 70%, error rate ≤ 1%), while the underwriting service cluster is displayed in yellow (one instance memory usage reaches 85%). The panel includes the "average core metrics" for each service (such as average response time and overall error rate). Clicking on a service name will take you to its details page.

[0159] The instance details panel displays real-time data for a single microservice instance, presented in chart format: Resource metrics: CPU utilization and memory usage are displayed using a "line chart" (horizontal axis is time, vertical axis is percentage), with peak points marked (e.g., "CPU reaches 90% at 10:05"); Response time is displayed using a "bar chart" (distinguishing response time for successful / failed requests); Error rate is displayed using a "stacked area chart" (distinguishing the proportion of different error types); The current status is marked next to the instance name with icons (e.g., "shield" indicates normal, "exclamation mark" indicates attention is needed, and "cross" indicates abnormal).

[0160] When a metric exceeds a preset threshold (e.g., CPU utilization ≥ 85%, error rate ≥ 5%, response time ≥ 2 seconds), the platform interface triggers an automatic "abnormality flag": the chart area of ​​the corresponding metric flashes red, an "alarm icon" is displayed next to the instance name, and the abnormality details (including service name, instance, metric, current value, threshold, and occurrence time) are listed in the "Alarm Center" panel.

[0161] The hierarchical display supports three levels of drill-down: the cluster layer shows the overall health, the service layer shows the key metrics of each service, and the instance layer shows specific problems (such as if the response time of a service becomes longer, you can drill down to the instance to find that the performance of two instances has degraded).

[0162] In historical data and trend analysis, the interface provides a "time range selection" function (such as the last 1 hour, the last 24 hours, and the last 7 days). After selection, the historical data of the corresponding time period is automatically loaded and a trend curve is generated (such as "the CPU usage rate of underwriting services in the last 7 days peaked between 9:00 and 11:00") to help identify periodic patterns.

[0163] When linking and redirecting, abnormal indicators are linked with the "Service Governance Center". For example, clicking on the "High Error Rate" alarm of a certain instance can directly redirect to the "Error Log Details Page" of that instance (displaying error type, traceId, and stack information), realizing a closed loop "from monitoring to investigation".

[0164] Under data update delay control, the overall delay from data collection to interface display is controlled within 30 seconds (e.g., data collected at 10:00:00 will be displayed on the interface before 10:00:20) to ensure real-time performance. If network fluctuations cause a delay of more than 1 minute, the interface will display a "Data synchronization in progress" message to avoid displaying outdated information.

[0165] For fault-tolerant display of abnormal data, if data collection for a certain instance fails (such as due to network interruption), the interface will display a "Data Missing" label (instead of blank) and indicate the time of the last successful collection. If the platform receives data with an abnormal format, it will automatically use the cached data from the previous batch for temporary display and trigger a "Data Verification Alarm" to notify the operations and maintenance personnel.

[0166] In the automatic linkage of alarms and governance, when the monitoring platform detects an anomaly (such as a service error rate that continues to exceed 5%), it can notify SofaArk's governance component through the interface to trigger automatic intervention (such as temporarily suspending the service or adjusting the load balancer weight). At the same time, the "Automatic governance in progress" status is displayed on the interface, realizing the full-process automation of "monitoring to find problems → automatically solving problems → interface feedback of results".

[0167] In another embodiment, when the performance metric of a microservice exceeds a preset alarm threshold, an automatic alarm is triggered to quickly locate the abnormal microservice, analyze the cause of the anomaly and the applicable fault solution, and notify the administrator through communication devices.

[0168] When a microservice's performance metrics exceed preset alarm thresholds, the SofaArk monitoring system triggers alarms through a multi-layered verification mechanism to ensure accurate alarms and avoid false alarms. Alarm thresholds are set based on the microservice's business characteristics and historical operational data, covering core metrics such as CPU utilization (e.g., 85%), memory usage (e.g., 90%), response time (e.g., 2 seconds), and error rate (e.g., 5%). For example, the response time threshold for underwriting services, which involve model calculations, can be set to 3 seconds, while a 1-second threshold is more reasonable for insurance application services. Simultaneously, the framework dynamically calibrates thresholds based on historical data: if a service consistently reaches 80% CPU utilization at 9 AM daily (a normal peak), the threshold for that period is temporarily increased to 85% to prevent normal fluctuations from triggering alarms.

[0169] The monitoring component compares the collected performance metrics with preset thresholds in real time. Only when a metric exceeds the threshold for multiple consecutive collection cycles (e.g., three 10-second cycles), and after excluding instantaneous fluctuations (e.g., a 1-second CPU spike caused by a single complex request), is it considered an "abnormal state" and an alarm is triggered. For example, if the error rate of a microservice is 5.2%, 5.5%, and 5.3% at 10:00, 10:01, and 10:02 respectively, all exceeding the 5% threshold, and these are not occasional errors, then an error rate alarm will be triggered.

[0170] Based on the degree of metric exceedance and the scope of impact, alarms are divided into three levels: Level 1 alarms (urgent) are for core metrics that are severely exceeded (e.g., CPU utilization reaches 95% and continues to rise), which may lead to service interruption; Level 2 alarms (important) are for metrics that are significantly exceeded (e.g., response time reaches 1.5 times the threshold), affecting user experience; Level 3 alarms (notification) are for minor exceedances (e.g., memory usage reaches 85%), which require attention but do not currently affect service. Different levels correspond to different processing priorities and notification methods.

[0171] After an alarm is triggered, the framework quickly locates the abnormal microservice through multi-dimensional data correlation, clarifying the specific instance where the anomaly occurred and the scope of its impact, laying the foundation for subsequent analysis. Each microservice instance has a unique instanceId, which is carried in the alarm information along with the corresponding service name (e.g., "Underwriting Service-instance-03"). Combined with the instance details panel of the monitoring platform, the abnormal instance can be directly located, and its specific performance metric fluctuations can be viewed (e.g., the CPU utilization of this instance has been continuously increasing since 10:00). At the same time, other normal instances of the same service (e.g., the "Underwriting Service-instance-01" has normal metrics) can be excluded, narrowing the scope of the investigation.

[0172] The framework automatically analyzes the call relationships of abnormal instances to determine whether the anomaly has spread. For example, if an instance of the underwriting service times out, the framework checks whether the insurance application service, which depends on that instance, is experiencing request queuing, or whether the downstream policy generation service is delayed due to a lack of underwriting results. By tracing the call chain (connecting request paths based on traceId), the framework clarifies the service chains affected by the anomaly, marking "affected services" and "unaffected services" to help administrators determine the severity of the problem.

[0173] Compare the current performance data of the abnormal instance with historical data from the same period (e.g., the same time yesterday) and data from other instances of the same service to identify discrepancies. For example, if the memory usage of the abnormal instance reaches 90%, while the historical average for the same period is 60% and that of other instances of the same service is 65%, then it can be determined that the instance has a memory-related anomaly, rather than an overall service problem.

[0174] After locating the abnormal microservice, the framework automatically analyzes the cause by combining historical cases and real-time data, and matches applicable fault solutions to provide a basis for rapid recovery. The framework digs for the cause of the anomaly from multiple dimensions: it uses resource indicators (CPU, memory) to determine whether there is insufficient resources (such as memory leaks causing a continuous increase in memory); it analyzes response time and call chain to determine whether it is due to abnormal dependent services (such as slow response of the health assessment system that the underwriting service depends on); and it identifies business logic problems through error logs (combined with traceId) (such as the concentrated occurrence of errors such as "insured amount exceeds product limit"). For example, if the CPU utilization of a microservice suddenly increases and the number of active threads in the thread pool reaches the limit, it can be initially determined that "a sudden increase in request volume has led to the exhaustion of thread resources".

[0175] The framework has a built-in fault solution library that stores historical anomaly handling cases (e.g., "memory leak" corresponds to "restarting the instance + analyzing memory snapshots," and "dependency service timeout" corresponds to "switching to a backup service"). When a new anomaly is detected, it recommends applicable solutions through feature matching (e.g., matching the current anomaly's "high CPU + high thread count" features with historical "sudden request surge" cases). If it is a new type of anomaly (without historical cases), it recommends general troubleshooting steps (e.g., checking error logs and resource usage).

[0176] Based on the implementation difficulty and effectiveness of the solutions, the recommended solutions are ranked as follows: Automation solutions (such as switching instances via load balancing) are preferred, followed by manual quick operations (such as restarting instances), and finally complex troubleshooting (such as code analysis). For example, for "response timeout and dependent service anomalies," "automatic routing to backup dependent services" is preferred; if this is ineffective, "contacting the dependent service maintainer" is recommended.

[0177] After identifying the anomaly and its solution, the framework notifies the administrator of the alarm information and handling suggestions through various communication methods to ensure timely information delivery and support subsequent interactions. The notification information includes core elements: alarm level (e.g., "Level 1 Alarm"), anomalous service (e.g., "Underwriting Service - instance-03"), anomalous metrics (e.g., "CPU utilization 92%)", occurrence time, scope of impact, preliminary cause, and recommended solution. For example: "[Level 1 Alarm] Underwriting Service - instance-03 triggered a CPU alarm at 10:05 (currently 92%, threshold 85%), possibly due to a sudden increase in requests, affecting downstream services in the insurance application process. It is recommended to immediately initiate a load balancer switch to instance-04."

[0178] The notification method is selected based on the alarm level: Level 1 alarms are pushed via SMS, phone, and social media to ensure immediate notification to the administrator; Level 2 alarms are pushed via social media; Level 3 alarms are only displayed on the monitoring platform. For example, after a Level 1 alarm is triggered, an SMS and social media message are sent first. If no confirmation is received from the administrator within 5 minutes, a preset administrator phone number is automatically dialed.

[0179] After receiving the notification, the administrator can provide feedback on the status by replying with messages such as "Processed" or "Assistance Required." The framework will record the feedback and update the alarm status (such as "Processing" or "Resolved"). If no feedback is received within a preset time (such as 30 minutes) and the anomaly is not mitigated, the framework will escalate the notification (such as contacting a backup administrator). Simultaneously, the entire processing (alarm time, notification time, and processing result) will be recorded in the log for subsequent review and optimization.

[0180] As can be seen, in the above solution, for the health insurance contract process in the insurance industry, the system first receives customer application information, health data, and lifestyle habits, classifies and analyzes these data, and establishes a SofaArk microserver framework based on the analysis results. Based on this framework, the implementation code for each microservice, service registration, and service discovery are developed and stored in the SofaArk service registry. When the response time of a microservice exceeds a preset circuit breaker threshold, an automatic circuit breaker mechanism is triggered, adjusting the threshold and routing requests to the microservice to backup services or handling them in a degraded manner. Once the circuit breaker is restored to normal, the circuit breaker is automatically lifted, and normal call logic is gradually restored. In this invention, by splitting the health insurance contract process into multiple independent microservices, the coupling between services is reduced, improving the system's response speed and processing efficiency. Based on the SofaArk service registry, service consumers can quickly discover available services, reducing service call latency and improving the overall system throughput. SofaArk's load balancing algorithm evenly distributes requests across multiple service instances, avoiding single points of overload and improving system processing capacity. In high-concurrency scenarios, when a service experiences a performance bottleneck or failure, the circuit breaker mechanism can quickly isolate the faulty service, preventing system-wide crashes. Once the circuit-broken service recovers, the system automatically unblocks and gradually restores normal call logic, ensuring stable system operation.

[0181] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0182] In one embodiment, a SofaArk-based rapid contract process fault handling device is provided, which corresponds one-to-one with the SofaArk-based rapid contract process fault handling method described in the above embodiments. For example... Figure 3 As shown, the SofaArk-based contract process fault rapid processing device includes a receiving module 101, a development storage module 102, a triggering module 103, and an adjustment module 104. Detailed descriptions of each functional module are as follows:

[0183] The receiving module 101 is used to receive customer insurance application information, customer health data and lifestyle habits, classify and analyze customer insurance application information, customer health data and lifestyle habits, and establish the SofaArk microserver framework based on the analysis results.

[0184] Develop storage module 102 to develop implementation code for each microservice, service registration, and service discovery based on the SofaArk microserver framework, and store the microservices in the SofaArk service registry center;

[0185] Trigger module 103 is used to trigger an automatic circuit breaker mechanism when the response time of a microservice exceeds a preset circuit breaker threshold, adjust the circuit breaker threshold, and route requests to the microservice to a backup service or perform degradation processing.

[0186] The adjustment module 104 is used to automatically release the circuit breaker state and gradually restore normal operation after the circuit breaker is adjusted to normal.

[0187] In one embodiment, the receiving module 101 is specifically used for:

[0188] Receive insurance application information from customers, and conduct preliminary verification and classification of the application information;

[0189] Based on the insurance application information, assess the customer's health risks and generate underwriting results by calling external health assessment systems or internal rule engines;

[0190] Based on the underwriting results, a decision is made on whether to underwrite the insurance and a corresponding underwriting plan is generated.

[0191] Based on the underwriting plan, generate formal policy documents and notify customers via email, SMS, or mobile app.

[0192] Based on machine learning models, we analyze customers' health data and lifestyle habits to predict their future health risks.

[0193] The premium amount is calculated based on the customer's health condition, age, and occupation.

[0194] The SofaArk microserver framework is built by setting up separate microservices for each of the following: insurance application information, underwriting results, insurance plan, policy documents, future health risks of customers, and premium amount.

[0195] In one embodiment, the apparatus further includes:

[0196] The traffic adjustment module is used to automatically reject some requests or queue them when the number of requests exceeds a threshold; it dynamically adjusts traffic control parameters based on historical data and real-time monitoring, and gradually restores normal call logic.

[0197] In one embodiment, the apparatus further includes:

[0198] The load balancing module is used to evenly distribute requests to multiple microservice instances according to the load balancing algorithm, and dynamically adjust the load balancing based on the health status and load of the microservice instances. When the load increases, the circuit breaker threshold is automatically increased to reduce the possibility of circuit breaking. When the load decreases, the default configuration is automatically restored.

[0199] In one embodiment, the apparatus further includes:

[0200] A new module is added to define a standard SPI interface for each microservice and specify the input parameters, output results, and exception handling logic for the microservice. When a microservice needs to be added or modified, the new microservice can be quickly developed and deployed through the extension mechanism of the SPI interface. After registering the new microservice with the service registry, the new microservice is automatically identified and loaded. When a service needs to be taken offline, the offline service is dynamically unloaded.

[0201] In one embodiment, the apparatus further includes:

[0202] The monitoring module is a monitoring component based on SofaArk. It collects the running data of each microservice in real time, including at least CPU utilization, memory usage, response time, and error rate; and outputs the running data to the platform interface to display the running status of each microservice.

[0203] In one embodiment, the apparatus further includes:

[0204] The alarm module is used to trigger automatic alarms when the performance indicators of a microservice exceed the preset alarm threshold, quickly locate the abnormal microservice, analyze the cause of the anomaly and the applicable fault solutions, and notify the administrator through communication devices.

[0205] This invention provides a rapid fault handling device for contract process based on SofaArk. It receives customer insurance application information, health data, and lifestyle habits, categorizes and analyzes these data, and establishes a SofaArk microserver framework based on the analysis results. Implementation code for each microservice, service registration, and service discovery are developed based on this framework, and the microservices are stored in the SofaArk service registry. When the response time of a microservice exceeds a preset circuit breaker threshold, an automatic circuit breaker mechanism is triggered, adjusting the threshold and routing requests to the microservice to backup services or performing fallback processing. Once the circuit breaker is restored to normal, the circuit breaker is automatically lifted, and normal call logic is gradually restored. In this invention, by splitting the health insurance contract process into multiple independent microservices, the coupling between services is reduced, improving system response speed and processing efficiency. Based on the SofaArk service registry, service consumers can quickly discover available services, reducing service call latency and improving overall system throughput. Through SofaArk's load balancing algorithm, requests are evenly distributed across multiple service instances, avoiding single-point overload and improving system processing capacity. In high-concurrency scenarios, when a service experiences a performance bottleneck or failure, the circuit breaker mechanism can quickly isolate the faulty service, preventing system-wide crashes. Once the circuit-breaker service recovers, the system can automatically unblock the circuit and gradually restore normal call logic, ensuring stable system operation.

[0206] Specific limitations regarding the SofaArk-based contract process fault rapid handling device can be found in the limitations of the SofaArk-based contract process fault rapid handling method described above, and will not be repeated here. Each module in the aforementioned SofaArk-based contract process fault rapid handling device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0207] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4As shown. The computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a server-side method for rapid fault handling in a contract flow based on SofaArk.

[0208] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements client-side functions or steps of a fast fault handling method for contract processes based on SofaArk.

[0209] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps:

[0210] It receives customer insurance application information, customer health data, and lifestyle habits; classifies and analyzes customer insurance application information, customer health data, and lifestyle habits; and establishes the SofaArk microserver framework based on the analysis results.

[0211] Based on the SofaArk microserver framework, we develop the implementation code for each microservice, service registration, and service discovery, and store the microservices in the SofaArk service registry.

[0212] When the response time of a microservice is detected to exceed the preset circuit breaker threshold, the automatic circuit breaker mechanism is triggered, the circuit breaker threshold is adjusted, and requests to the microservice are routed to a backup service or degraded for processing.

[0213] Once the circuit breaker is adjusted to normal, the circuit breaker status will be automatically lifted, and normal calling logic will be gradually restored.

[0214] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0215] It receives customer insurance application information, customer health data, and lifestyle habits; classifies and analyzes customer insurance application information, customer health data, and lifestyle habits; and establishes the SofaArk microserver framework based on the analysis results.

[0216] Based on the SofaArk microserver framework, we develop the implementation code for each microservice, service registration, and service discovery, and store the microservices in the SofaArk service registry.

[0217] When the response time of a microservice is detected to exceed the preset circuit breaker threshold, the automatic circuit breaker mechanism is triggered, the circuit breaker threshold is adjusted, and requests to the microservice are routed to a backup service or degraded for processing.

[0218] Once the circuit breaker is adjusted to normal, the circuit breaker status will be automatically lifted, and normal calling logic will be gradually restored.

[0219] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0220] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0221] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0222] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for rapid handling of contract process faults based on SofaArk, characterized in that, include: It receives customer insurance application information, customer health data, and lifestyle habits; classifies and analyzes customer insurance application information, customer health data, and lifestyle habits; and establishes the SofaArk microserver framework based on the analysis results. Based on the SofaArk microserver framework, we develop the implementation code for each microservice, service registration, and service discovery, and store the microservices in the SofaArk service registry. When the response time of a microservice is detected to exceed the preset circuit breaker threshold, the automatic circuit breaker mechanism is triggered, the circuit breaker threshold is adjusted, and requests to the microservice are routed to a backup service or degraded for processing. Once the circuit breaker is adjusted to normal, the circuit breaker status will be automatically lifted, and normal calling logic will be gradually restored.

2. The method for rapid handling of contract process faults based on SofaArk as described in claim 1, characterized in that, After the steps of developing the implementation code for each microservice, registering services, and discovering services based on the SofaArk microserver framework, and storing the microservices in the SofaArk service registry, the method further includes: When the number of requests exceeds the threshold, some requests will be automatically rejected or queued for processing. Based on historical data and real-time monitoring, the flow control parameters are dynamically adjusted, and the normal calling logic is gradually restored.

3. The method for rapid handling of contract process faults based on SofaArk as described in claim 1, characterized in that, After the steps of developing the implementation code for each microservice, registering services, and discovering services based on the SofaArk microserver framework, and storing the microservices in the SofaArk service registry, the method further includes: Requests are evenly distributed to multiple microservice instances based on the load balancing algorithm, and the load balancing is dynamically adjusted based on the health status and load of the microservice instances. When the load increases, the circuit breaker threshold is automatically increased to reduce the likelihood of the circuit breaker being triggered. When the load decreases, the default configuration will be automatically restored.

4. The method for rapid handling of contract process faults based on SofaArk as described in claim 1, characterized in that, The steps of receiving customer insurance application information, customer health data, and lifestyle habits, classifying and analyzing customer insurance application information, customer health data, and lifestyle habits, and establishing the SofaArk microserver framework based on the analysis results include: Receive insurance application information from customers, and conduct preliminary verification and classification of the application information; Based on the insurance application information, assess the customer's health risks and generate underwriting results by calling external health assessment systems or internal rule engines; Based on the underwriting results, a decision is made on whether to underwrite the insurance and a corresponding underwriting plan is generated. Based on the underwriting plan, generate formal policy documents and notify customers via email, SMS, or mobile app. Based on machine learning models, we analyze customers' health data and lifestyle habits to predict their future health risks. The premium amount is calculated based on the customer's health condition, age, and occupation. The SofaArk microserver framework is built by setting up separate microservices for each of the following: insurance application information, underwriting results, insurance plan, policy documents, future health risks of customers, and premium amount.

5. The method for rapid handling of contract flow faults based on SofaArk as described in claim 1, characterized in that, After the step of automatically releasing the circuit breaker state and gradually restoring normal calling logic once the circuit breaker is adjusted to normal, the method further includes: Define a standard SPI interface for each microservice and specify the input parameters, output results, and exception handling logic for the microservice; When a microservice needs to be added or modified, the new microservice can be quickly developed and deployed through the extension mechanism of the SPI interface. After registering the new microservice with the service registry, the new microservice is automatically identified and loaded. When a service needs to be taken offline, the service will be dynamically uninstalled.

6. The method for rapid handling of contract process faults based on SofaArk as described in claim 1, characterized in that, After the step of automatically releasing the circuit breaker state and gradually restoring normal calling logic once the circuit breaker is adjusted to normal, the method further includes: The monitoring component based on SofaArk collects real-time runtime data of each microservice, including at least CPU utilization, memory usage, response time, and error rate. Output runtime data to the platform interface to display the runtime status of each microservice.

7. The method for rapid handling of contract process faults based on SofaArk as described in claim 1, characterized in that, After the step of automatically releasing the circuit breaker state and gradually restoring normal calling logic once the circuit breaker is adjusted to normal, the method further includes: When the performance metric of a microservice exceeds the preset alarm threshold, an automatic alarm is triggered to quickly locate the abnormal microservice, analyze the cause of the anomaly and the applicable fault solution, and notify the administrator through communication devices.

8. A rapid contract process fault handling device based on SofaArk, characterized in that, include: The receiving module is used to receive customer insurance application information, customer health data and lifestyle habits, classify and analyze customer insurance application information, customer health data and lifestyle habits, and build the SofaArk microserver framework based on the analysis results. Develop a storage module to develop implementation code for each microservice, service registration, and service discovery based on the SofaArk microserver framework, and store the microservices in the SofaArk service registry center; The triggering module is used to trigger the automatic circuit breaker mechanism when the response time of a microservice exceeds the preset circuit breaker threshold, adjust the circuit breaker threshold, and route requests to the microservice to a backup service or perform degradation processing. The adjustment module is used to automatically release the circuit breaker from its fault state and gradually restore normal operation once the circuit breaker has been adjusted to normal.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the SofaArk-based fast contract flow fault handling method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the SofaArk-based fast contract flow fault handling method as described in any one of claims 1 to 7.

Images