A method for rapid deployment of an insurance SaaS system under a micro-service architecture

Abstract

The present application relates to the technical field of SaaS system deployment, in particular to a kind of microservice architecture under the fast deployment method of insurance SaaS system, comprising: in the deployment control platform, the general microservice component template library and configuration strategy rule library of insurance industry are preset;Receive the target insurance SaaS system business range selection submitted by user, match out basic service set, call dependency relationship analysis algorithm and assemble initial deployment topology graph automatically;According to the configuration rule, the component configuration parameter is automatically filled and compliance verification, and a complete configuration list is generated;Drive container orchestration engine to pull image instantiation deployment, synchronous start configuration injection and health check, after deployment is completed, perform connectivity test and output deployment ready state report.The method realizes the automation of the whole process of deployment, reduces the human operation error, shortens the deployment cycle, improves the deployment accuracy and stability, adapts to the fast deployment and business iteration needs of insurance SaaS system.

Description

Technical Field

[0001] This invention relates to the field of SaaS system deployment technology, and in particular to a method for rapid deployment of an insurance SaaS system under a microservice architecture. Background Technology

[0002] The deployment of insurance SaaS systems under a microservice architecture needs to adapt to the diverse business needs of the insurance industry. Existing deployment methods mostly use general microservice component templates, without pre-setting exclusive components and configuration rules for the characteristics of the insurance industry. During the deployment process, service components need to be selected manually, deployment topology needs to be drawn manually, configuration parameters need to be filled and verified manually, and health checks and connectivity tests need to be performed manually after deployment.

[0003] General microservice templates have poor adaptability to insurance industry business. Manual component selection and topology drawing are prone to omissions or errors. Relying on manual configuration parameter filling and verification is inefficient and prone to compliance issues. Existing methods lack automated dependency resolution and topology assembly mechanisms, container orchestration and deployment are disconnected from subsequent testing processes, and cannot achieve full-process automation of deployment. Deployment cycles are long and difficult to adapt to the rapid deployment requirements of insurance SaaS systems.

[0004] The lack of insurance industry-specific component templates and configuration rules, low automation in the deployment process, reliance on manual operation leading to insufficient deployment efficiency and accuracy, inability to effectively guarantee configuration compliance, and lack of unified status verification and report output after deployment make it impossible to achieve rapid and accurate deployment of insurance SaaS systems and meet the needs of rapid business iteration in the insurance industry. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by proposing a rapid deployment method for insurance SaaS systems under a microservice architecture.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: a method for rapid deployment of an insurance SaaS system under a microservice architecture, comprising: The deployment and management platform includes a pre-defined library of microservice component templates and configuration policy rules commonly used in the insurance industry. Receive the user's selection of the business scope of the target insurance SaaS system submitted through the deployment and management platform interface, and match the basic service set from the microservice component template library according to the business scope selection; Based on the aforementioned set of basic services, a dependency resolution algorithm is invoked to automatically calculate and assemble the initial deployment topology of the target insurance SaaS system. Based on the rules in the configuration policy rule base, the configuration parameters of each component in the initial deployment topology are automatically populated and compliance verified to generate a complete configuration list to be deployed; Based on the complete configuration list, the container orchestration engine pulls the corresponding service images from the image repository and instantiates and deploys them in the compute resource cluster according to the initial deployment topology. During the instantiation and deployment process, the configuration injection and health check process is started simultaneously. After the instantiation and deployment are completed, the service connectivity test is performed, and finally the deployment ready status report is output.

[0007] As a further aspect of the present invention, based on the aforementioned basic service set, a dependency resolution algorithm is invoked to automatically calculate and assemble the initial deployment topology of the target insurance SaaS system, specifically including: Extract the metadata of each microservice component in the basic service set from the microservice component template library. The metadata includes a service function description, an exposed interface contract, and a list of declared dependent service requirements. Using the microservice components in the basic service set as nodes, construct an initially empty deployment topology graph; The customized service dependency declarations submitted by users through the interface are merged with the list of dependency service requirements extracted from the metadata to form a complete dependency declaration for each microservice component. The dependency resolution algorithm is invoked to traverse the complete dependency declaration of each microservice component and identify whether the other services that the declaration depends on exist in the set of basic services. For dependencies that exist in the set of basic services, add a directed edge to the deployment topology graph from the current microservice component node to the dependent microservice component node; For dependencies that do not exist in the basic service set, try to find a matching public component in the extension area of ​​the microservice component template library. If found, add the public component as a new node to the deployment topology graph and add the corresponding dependency edge. If not found, mark it as an external dependency to be processed. After parsing, check if there are any circular dependency paths in the deployment topology graph. If so, remove edges or decompose services according to the preset cycle de-looping strategy, and finally output an acyclic initial deployment topology graph.

[0008] As a further aspect of the present invention, the dependency resolution algorithm operates based on the principle of separating declarative dependencies from runtime dependencies, specifically including: When resolving the complete dependency declarations of microservice components, the dependency resolution algorithm first divides the declaration content into two categories: strong dependencies at the declaration stage and dynamic dependencies at runtime. For strong dependencies at the declaration period, the dependency resolution algorithm requires that the services it depends on must be explicitly identified and connected during the deployment topology graph construction phase, and that stable connection edges with explicit version constraints be established in the initial deployment topology graph; For runtime dynamic dependencies, the dependency resolution algorithm does not require the establishment of fixed connection edges in the initial deployment topology graph. Instead, it generates a service discovery tag for it and injects the service discovery tag into the configuration of the corresponding microservice component. During the deployment topology graph construction phase, the dependency resolution algorithm only processes declaration-time strong dependencies, thereby simplifying the initial topology structure. In the subsequent step of generating a complete configuration list based on the configuration policy rule base, client policies pointing to the service registry are automatically configured for microservice components with service discovery tags, so that they can dynamically discover and call the services they depend on at runtime.

[0009] As a further aspect of the present invention, the automatic filling and compliance verification of configuration parameters for each component in the initial deployment topology diagram based on rules in the configuration policy rule base specifically includes: From the initial deployment topology diagram, read the identification information of each microservice component node one by one; Based on the identification information of the microservice component node, the configuration rule group that matches it is queried in the configuration policy rule base. The configuration rule group includes environment variable default value rules, resource quota rules, connection string generation rules and security policy rules. Based on the default environment variable rules and the environment identifier of this deployment, the set of environment variable key-value pairs required by the microservice component instance is automatically generated. Based on the resource quota rules and the preset resource pool capacity, the CPU core limit, memory limit and storage volume size of the microservice component instance are automatically calculated and allocated. Based on the connection string generation rules, and according to the node identifier of the dependent service and the deployment network plan, the database connection string and message queue endpoint address are automatically generated. Based on the security policy rules, the application programming interface access key and transport layer security protocol certificate mounting path required for the microservice component instance are automatically generated. The automatically generated configuration parameters are filled into the configuration template of the microservice component node to form the configuration fragment to be verified of the microservice component node; The compliance verification engine is invoked to compare the configuration fragment to be verified with the global compliance policy in the configuration policy rule base. It checks for parameter conflicts, security vulnerabilities, or resource over-provisioning. Configuration items that fail verification are marked and attempts are made to automatically adjust them according to the correction rules.

[0010] As a further aspect of the present invention, the step of invoking the compliance verification engine to compare the configuration fragment to be verified with the global compliance policy in the configuration policy rule base specifically includes: The compliance verification engine loads the global compliance policies defined in the configuration policy rule base, which include naming convention policies, port conflict detection policies, security baseline policies, and resource compliance policies. The compliance verification engine extracts all custom configuration item names from the configuration fragment to be verified, checks whether they conform to the predefined naming pattern according to the naming convention strategy, and records the configuration item names that do not conform to the pattern. The compliance verification engine extracts all network port numbers declared in the configuration fragment to be verified, checks whether there are duplicate port numbers declared in the same host node or network namespace according to the port conflict detection strategy, and records all conflicting ports. The compliance verification engine extracts security-related configurations from the configuration fragments to be verified, checks whether there are cases of using default passwords, not enabling transport layer security protocols, or having excessively broad authorization scopes based on the security baseline policy, and records all configuration items that violate the security baseline. The compliance verification engine extracts the resource request and limit declared in the configuration fragment to be verified, checks whether it exceeds the single instance resource limit set for the current deployment environment according to the resource compliance policy, and records all resource types and values ​​that exceed the limit. All inspection records are compiled into a compliance verification report. For items that can be automatically corrected, the corrected configuration values ​​are generated according to the correction rules attached to the policy. For items that cannot be automatically corrected, alarm information is generated for user processing.

[0011] As a further aspect of the present invention, the driving container orchestration engine pulls the corresponding service image from the image repository and instantiates and deploys it in the computing resource cluster according to the initial deployment topology, specifically including: The complete configuration manifest is converted into a set of deployment description files that can be recognized by the container orchestration engine. The set of deployment description files defines the number of replicas of each microservice component, the container image address, resource limits, configuration volume mount points, and service exposure methods. Submit the deployment description file set to the container orchestration engine's application programming interface server; The scheduler of the container orchestration engine selects a suitable physical host or virtual machine as the deployment target node in the computing resource cluster based on the resource requests and node affinity rules in the deployment description file set. On the selected deployment target node, the container orchestration engine pulls the corresponding version of the microservice component image from the specified image repository based on the container image address; After the image is pulled, the container orchestration engine creates an independent container runtime environment on the deployment target node, instantiates the microservice component image into one or more container instances, and mounts configuration volumes and sets environment variables according to the set of deployment description files; The network component of the container orchestration engine configures virtual network devices for the container instances, assigns network addresses, and configures network access rules between containers according to the network policies defined in the initial deployment topology diagram.

[0012] As a further aspect of the present invention, the synchronous startup configuration injection and health check process specifically includes: During the process of creating a container instance by the container orchestration engine, the configuration injection tool obtains the identifier of the newly created container instance by listening to the container instance creation event; The configuration injection tool queries the final configuration information belonging to the microservice component in the complete configuration list based on the container instance identifier; The configuration injection tool writes the final configuration information into the specified configuration file path or environment variable inside the container instance through the container instance's file system interface or environment variable interface; Once the configuration information injection is complete, the health check agent begins to periodically send requests to the health check endpoint within the container instance, based on the predefined health check strategy for each microservice component. The health check agent analyzes the response status code, response content, and response latency of the health check endpoint to determine whether the application process inside the container instance has started normally and is in a ready state. The configuration injection result is associated with the health check result and recorded. Only container instances that have successfully injected configuration and passed the health check will be marked as available to provide services.

[0013] As a further aspect of the present invention, the health check agent analyzes the response status code, response content, and response latency of the health check endpoint to determine whether the application process inside the container instance has started normally and is in a ready state, specifically including: The health check agent sends a Hypertext Transfer Protocol (HTTP) GET request to the health check endpoint that the application process within the container instance is listening for. The health check agent receives the response returned by the application process and records the response delay time for this request; The health check agent verifies whether the Hypertext Transfer Protocol status code of the response is a success code. If it is a success code, proceed to the next step; otherwise, the health check is deemed to have failed. After the status code verification is successful, the health check agent parses the response message body and extracts the key fields that represent the application status. The health check agent compares the extracted key field values ​​with the predefined expected status values ​​to determine whether the application's core functional modules have been initialized and whether key dependency connections are ready. The health check agent determines the final health status by considering whether the response delay is within the threshold, whether the status code is successful, and whether the application status meets expectations.

[0014] As a further aspect of the present invention, the step of performing a service connectivity test after instantiation and deployment specifically includes: The deployment management platform waits for all container instances to be reported as running by the container orchestration engine, and for the configuration injection and health check processes to be reported as passed. The deployment management platform obtains the call relationships between services defined in the initial deployment topology diagram, which serves as the basis for service connectivity test cases. The service connectivity tester of the deployment management platform initiates simulated call requests to its dependent services from each container instance where the microservice component, which acts as a service caller, resides. The service connectivity tester monitors whether the simulated call request successfully reaches the container instance of the dependent service and obtains the response returned by the dependent service. The service connectivity tester verifies whether the returned response conforms to the expected interface contract, including the response data structure, status code, and necessary message headers; Record the results of each simulated call, including network latency, success or failure, and whether the response conforms to the contract, and generate a service connectivity test matrix.

[0015] As a further aspect of the present invention, the final output deployment readiness status report specifically includes: It summarizes the instantiation deployment status reported by the container orchestration engine, the injection and health status reported by the configuration injection and health check process, and the service connectivity test results. The summarized status and results are organized and aggregated according to multiple dimensions such as microservice components, deployment nodes, and dependent services; Based on the preset report template, the aggregated status information is converted into a structured document, which includes a deployment overview, component details, configuration summary, health status statistics, connectivity test result summary, and a list of discovered anomalies or warnings; Output structured documents as deployment readiness status report files in a specified format; The deployment readiness status report file is stored in the deployment log database, and the interface service of the deployment management platform is notified to update the status of the deployment task for users to view.

[0016] Compared with the prior art, the advantages and positive effects of the present invention are as follows: The deployment management platform pre-configures a library of microservice component templates and configuration policy rules commonly used in the insurance industry. It receives user-submitted selections of the target insurance SaaS system's business scope, matches a set of basic services from the microservice component template library, and uses a dependency resolution algorithm to automatically calculate and assemble the initial deployment topology of the target insurance SaaS system. The industry-specific component template library directly matches insurance business needs, eliminating the need for manual selection of generic components. The automated calculation method using the dependency resolution algorithm avoids the biases and omissions inherent in manual topology drawing, shortens topology assembly time, and improves the adaptability and accuracy of the initial deployment topology. Compared to generic templates and manual operations, this significantly improves the efficiency of pre-deployment preparation.

[0017] Based on the rules in the configuration policy rule base, the configuration parameters of each component in the initial deployment topology are automatically populated and validated for compliance, generating a complete configuration list to be deployed. This complete configuration list drives the container orchestration engine to pull the corresponding service images from the image repository and instantiate them in the computing resource cluster according to the initial deployment topology. During deployment, configuration injection and health checks are initiated simultaneously. After deployment, service connectivity tests are performed and a deployment readiness report is output. Automatic population and compliance validation reduce errors from manual configuration, ensuring that configuration parameters meet industry rules and system requirements. The automated deployment of the container orchestration engine improves deployment efficiency, synchronous configuration injection and health checks promptly detect anomalies during deployment, and connectivity tests and status reports clearly present the deployment results, achieving full automation of the deployment process, shortening the deployment cycle, and improving deployment quality and stability. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating a rapid deployment method for an insurance SaaS system under a microservice architecture, as described in this invention. Figure 2 A flowchart illustrating how the dependency resolution algorithm works; Figure 3 This is a flowchart for compliance verification engine comparison. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0020] In the description of this invention, it should be understood that the terms "length," "width," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships, are based on the orientation or positional relationships shown in the accompanying drawings and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, in the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0021] See Figure 1 This invention patent provides a method for rapid deployment of an insurance SaaS system under a microservice architecture, implemented through a deployment management platform. The deployment management platform pre-configures a microservice component template library and a configuration policy rule library commonly used in the insurance industry. When a user submits the business scope selection for the target insurance SaaS system through the platform's interface, the platform matches a set of basic services from the microservice component template library based on this selection. Based on this set of basic services, the platform uses a dependency resolution algorithm to automatically calculate and assemble the initial deployment topology of the target insurance SaaS system. According to the rules in the configuration policy rule library, the platform automatically populates and verifies the configuration parameters of each component in the initial deployment topology, generating a complete configuration list to be deployed. Based on this complete configuration list, the platform drives the container orchestration engine to pull the corresponding service images from the specified image repository and instantiates and deploys them in the computing resource cluster according to the initial deployment topology. During the instantiation and deployment process, the platform simultaneously initiates configuration injection and health check processes. After instantiation and deployment are completed, service connectivity tests are performed, and a deployment-ready status report is output, thus completing the entire rapid deployment process.

[0022] In one embodiment of the present invention, the deployment management platform extracts metadata for each microservice component in the basic service set from the microservice component template library. This metadata includes service function descriptions, exposed interface contracts, and a list of declared dependent service requirements. The platform constructs an initially empty deployment topology graph using the microservice components in the basic service set as nodes. The platform merges the customized service dependency declarations submitted by the user through the interface with the dependent service requirement list extracted from the metadata to form a complete dependency declaration for each microservice component. The platform calls a dependency resolution algorithm to traverse the complete dependency declaration for each microservice component and identify whether the other services depended upon in the declaration exist in the basic service set. For dependencies existing in the basic service set, a directed edge is added to the deployment topology graph from the current microservice component node to the dependent microservice component node. For dependencies not existing in the basic service set, an attempt is made to find a matching common component in the extension area of ​​the microservice component template library. If found, the common component is added as a new node to the deployment topology graph, and a corresponding dependency edge is added. If not found, it is marked as an external dependency to be processed. After parsing, check if there are any circular dependency paths in the deployment topology graph. If so, remove edges or decompose services according to the preset cycle de-looping strategy, and output an acyclic initial deployment topology graph.

[0023] See Figure 2 The dependency resolution algorithm operates based on the principle of separating declarative dependencies from runtime dependencies. When parsing the complete dependency declarations of microservice components, the algorithm categorizes the declarations into two types: declarative strong dependencies and runtime dynamic dependencies. For declarative strong dependencies, the algorithm requires that the services they depend on be explicitly identified and integrated during the deployment topology graph construction phase, establishing stable connections with clear version constraints in the initial deployment topology graph. For runtime dynamic dependencies, the algorithm does not require the establishment of fixed connections in the initial deployment topology graph; instead, it generates a service discovery tag and injects this tag into the configuration of the corresponding microservice component. During the deployment topology graph construction phase, the algorithm only processes the connections of declarative strong dependencies, thus simplifying the initial topology structure. In the subsequent step of generating a complete configuration list based on the configuration policy rule base, client policies pointing to the service registry are automatically configured for microservice components with service discovery tags, enabling them to dynamically discover and invoke their dependent services at runtime.

[0024] In practical implementation, the deployment and management platform uses a pre-set microservice component template library common to the insurance industry, which includes standard components such as "Core Policy Service," "Premium Calculation Service," "Underwriting Rule Engine," "Claims Processing Service," and "Reinsurance Inbound Service." When a user submits the business scope of the target insurance SaaS system through the interface and selects "Group Health Insurance Underwriting," the platform selects a set of basic services from the microservice component template library that includes "Core Policy Service," "Underwriting Rule Engine," and "Customer Information Management Service." The deployment and management platform extracts the metadata of each microservice component in the basic service set from the microservice component template library. The metadata is carried in a structured description file. For example, the metadata of the "Underwriting Rule Engine" component declares that it depends on the "Core Policy Service" to obtain policy details and on an external "Risk Control Scoring Service." The platform then uses the microservice components in the basic service set as nodes to begin building an initially empty deployment topology. Users can supplement their declarations through the interface that the "Underwriting Rules Engine" also needs to call the "Document Generation Service" to generate an underwriting notice. The platform will merge this customized service dependency declaration with the dependency service requirement list extracted from the "Underwriting Rules Engine" metadata to form a complete dependency declaration for the "Underwriting Rules Engine", which includes "Policy Core Service", "Risk Control Scoring Service" and "Document Generation Service".

[0025] The deployment management platform invokes a dependency resolution algorithm to traverse the complete dependency declarations of each microservice component. For the "Underwriting Rules Engine" which declares a dependency on the "Policy Core Service," the algorithm identifies its existence in the basic service set and adds a directed edge from the "Underwriting Rules Engine" node to the "Policy Core Service" node in the deployment topology graph. For the "Underwriting Rules Engine" which declares a dependency on the "Risk Control Scoring Service," the algorithm identifies that it does not exist in the basic service set and attempts to search in the extension area of ​​the microservice component template library. If a common component named "General Risk Control Scoring Service" is found, it is added as a new node to the deployment topology graph, and a dependency edge from the "Underwriting Rules Engine" node to the "General Risk Control Scoring Service" node is added. For the user-declared "Document Generation Service," the dependency resolution algorithm does not find a matching component in either the basic service set or the extension area, so this dependency is marked as an external dependency to be processed. After parsing, the dependency resolution algorithm checks whether there are circular dependency paths in the deployment topology graph. For example, if it finds a situation where "service A" depends on "service B", and "service B" depends on "service A", it will process it according to the preset cycle resolution strategy and finally output an acyclic directed graph as the initial deployment topology graph.

[0026] In some embodiments, the dependency resolution algorithm operates based on the principle of separating declarative dependencies from runtime dependencies. When resolving the complete dependency declaration of the "Policy Core Service," the algorithm categorizes the declaration into two types: declarative strong dependencies and runtime dynamic dependencies. For example, the "Policy Core Service's" connection requirement to the "Database" is classified as a declarative strong dependency, while its call requirement to the "Rate Cache Service" is classified as a runtime dynamic dependency. For declarative strong dependencies, the dependency resolution algorithm requires that the dependent services be explicitly identified and integrated during the deployment topology graph construction phase, and that stable connection edges with explicit version constraints be established in the initial deployment topology graph. For example, the edge between the "Policy Core Service" and the "Database" node will be labeled with the database version number.

[0027] For runtime dynamic dependencies, the dependency resolution algorithm does not require establishing fixed connections in the initial deployment topology graph. Instead, it generates a service discovery tag, such as "Dynamic Dependency: Rate Cache Service" for the "Policy Core Service," and injects this tag into the configuration metadata of the "Policy Core Service" component. During the deployment topology graph construction phase, the dependency resolution algorithm only processes declaratively strong dependencies, resulting in a clear initial topology. In the subsequent step of generating a complete configuration manifest based on the configuration policy rule base, the deployment management platform automatically adds client connection policies pointing to the service registry center to the configuration manifest for microservice components with service discovery tags. This allows the "Policy Core Service" to dynamically discover and invoke the "Rate Cache Service" through the service registry center at runtime.

[0028] Optionally, circular dependency detection can be abstracted through a formulaic process. A function C(T) is defined to detect whether circular dependencies exist in the deployment topology graph T. The logic can be represented as performing a depth-first traversal of each node in the graph and marking its state. Let T=(V,E) be a directed graph, where V is the set of microservice component nodes and E is the set of dependent edges. For any node v in the graph, its state state(v)∈{unvisited, visiting, visited}. Starting from any unvisited node v, its state is marked as "visiting", and each of its direct successor nodes u is recursively visited (i.e., there exists an edge (v,u)). If a node with a state of "visiting" is reached during the visit, a circular dependency is determined, and the path is recorded. If all successor nodes originating from node v have been visited and no node with a state of "visiting" is found, then the state of node v is marked as "visited". When C(T) outputs true, it indicates the existence of a circular dependency path in the graph. The deployment management platform will use preset strategies, such as removing the newly introduced dependency edge or suggesting splitting a service forming the loop into two independent services, to resolve the loop and re-detect it until C(T) outputs false, thus ensuring that the final initial deployment topology graph is acyclic. It can be understood that the dependency resolution algorithm employs a hierarchical strategy for handling external dependencies when constructing the topology graph: first matching from the basic service set, then matching common components from the template library extension area, and finally marking them as external dependencies to be processed. This order ensures the manageability and standardization of the deployed content.

[0029] In some embodiments, customized service dependency declarations submitted by users through the interface can be presented in list form. When the deployment management platform merges this list with the dependency service requirement list extracted from the metadata, it performs deduplication and conflict verification operations. For example, if the metadata declaration depends on "Message Queue Service A," while the user declaration depends on "Message Queue Service B," the platform will prompt the user to select or confirm the priority. The merged complete dependency declarations will be presented as a unified list for the dependency resolution algorithm to use. When attempting to find matching common components in the extension area of ​​the microservice component template library, the dependency resolution algorithm performs similarity matching based on the component's functional description and interface contract. For example, when searching for "Risk Control Scoring Service," it will match common components whose functional descriptions contain "Risk Scoring" or "Credit Assessment." It can be understood that the initial deployment topology map serves as the blueprint for all subsequent deployment activities, and its acyclic characteristic is forcibly guaranteed by the detection and decyclication steps in the dependency resolution algorithm. This provides a correct structural foundation for subsequent resource scheduling and service startup order coordination based on the topology map.

[0030] In one embodiment of the present invention, configuration parameters of each component in the initial deployment topology are automatically populated and validated for compliance based on rules in the configuration policy rule base. The identification information of each microservice component node is read sequentially from the initial deployment topology. Based on the identification information of the microservice component node, a matching configuration rule group is queried in the configuration policy rule base. This configuration rule group includes environment variable default value rules, resource quota rules, connection string generation rules, and security policy rules. Based on the environment variable default value rules and the environment identifier of this deployment, the set of environment variable key-value pairs required by the microservice component instance is automatically generated. Based on the resource quota rules and the preset resource pool capacity, the CPU core limit, memory limit, and storage volume size of the microservice component instance are automatically calculated and allocated. Based on the connection string generation rules, and based on the node identifier of the dependent service and the deployment network plan, the database connection string and message queue endpoint address are automatically generated. Based on the security policy rules, the application programming interface access key and transport layer security protocol certificate mounting path required by the microservice component instance are automatically generated. The automatically generated configuration parameters are then populated into the configuration template of the microservice component node to form the configuration fragment to be validated for the microservice component node.

[0031] The compliance verification engine is invoked to compare the configuration fragment to be verified with the global compliance policies in the configuration policy rule base. (See also...) Figure 3 The compliance verification engine loads the global compliance policies defined in the configuration policy rule base. These global compliance policies include naming convention policies, port conflict detection policies, security baseline policies, and resource compliance policies. The compliance verification engine extracts all custom configuration item names from the configuration fragment to be verified, checks whether they conform to the predefined naming pattern according to the naming convention policy, and records any configuration item names that do not conform to the pattern. The compliance verification engine extracts all network port numbers declared in the configuration fragment to be verified, checks whether there are duplicate port numbers declared within the same host node or network namespace according to the port conflict detection policy, and records all conflicting ports. The compliance verification engine extracts security-related configurations from the configuration fragment to be verified, checks whether there are cases of using default passwords, not enabling transport layer security protocols, or having excessively broad authorization scopes according to the security baseline policy, and records all configuration items that violate the security baseline. The compliance verification engine extracts the resource request volume and limit declared in the configuration fragment to be verified, checks whether they exceed the single-instance resource limit set for the current deployment environment according to the resource compliance policy, and records all resource types and values ​​that exceed the limit. All inspection records are compiled into a compliance verification report. For items that can be automatically corrected, the corrected configuration values ​​are generated according to the correction rules attached to the policy. For items that cannot be automatically corrected, alarm information is generated for user processing.

[0032] In practice, the configuration parameters of each component in the initial deployment topology are automatically populated and their compliance verified based on the rules in the configuration policy rule base. The deployment management platform reads the identification information of each microservice component node from the initial deployment topology. For example, when the "policy core service" node with the identification "policy-core-service-v1.2" is read, the deployment management platform queries the configuration rule base for the matching configuration rule group based on this identification information.

[0033] The configuration rule set returned by the configuration policy rule base includes environment variable default value rules, resource quota rules, connection string generation rules, and security policy rules. Based on the environment variable default value rules and the environment identifier "prod" (production environment) for this deployment, the set of environment variable key-value pairs required for the "Policy Core Service" instance is automatically generated, for example, generating SPRING_PROFILES_ACTIVE=prod and LOG_LEVEL=INFO. Based on the resource quota rules and the preset resource pool capacity, the CPU core limit for the "Policy Core Service" instance is automatically calculated and allocated to 2 cores, 4096MB of memory, and a 10GB storage volume. Based on the connection string generation rules, and according to the database service node identifier "mysql-primary" that the "Policy Core Service" depends on in the initial deployment topology diagram and the deployment network plan, the database connection string jdbc:mysql: / / mysql-primary:3306 / policy_db and the message queue endpoint address amqp: / / message-bus:5672 are automatically generated. Based on security policy rules, the application programming interface access key ENC (ABC123…) and the transport layer security protocol certificate mount path / etc / certs / policy-core-service.pem required for the "Policy Core Service" instance are automatically generated. The deployment management platform fills the automatically generated configuration parameters into the configuration template of the "Policy Core Service" node, forming a configuration fragment to be verified for the "Policy Core Service" node. This fragment is a structured data block containing resource limits, environment variables, connection strings, and key paths.

[0034] The compliance verification engine is invoked to compare the configuration fragment to be verified with the global compliance policies in the configuration policy rule base. The compliance verification engine loads the global compliance policies defined in the configuration policy rule base. The global compliance policies include naming convention policies, port conflict detection policies, security baseline policies, and resource compliance policies. The compliance verification engine extracts all custom configuration item names from the configuration fragment to be verified in the "Policy Core Service" node. For example, it extracts the service instance name configuration item spring.application.name with the value of policy-core-service-prod-01. It checks whether it conforms to the predefined naming pattern ^[az-]+-prod-\d+$ according to the naming convention policy, and records the configuration item names that do not conform to the pattern. The compliance verification engine extracts all network port numbers declared in the configuration fragment to be verified. For example, it extracts the network port 8080 that the "Policy Core Service" listens on. According to the port conflict detection policy, it checks whether there are duplicate declarations of port numbers in the same host node or network namespace.

[0035] If another service instance on the same host node is detected to be occupying port 8080, a port conflict is recorded. The compliance verification engine extracts security-related configurations from the configuration fragment to be verified. For example, if the value of the database password configuration item db.password is found to be plaintext admin123, it checks for the use of a default password, failure to enable transport layer security protocols, or excessively broad authorization scope according to the security baseline policy. The security baseline policy stipulates that passwords cannot be default values ​​or weak passwords; therefore, the db.password configuration item is recorded as violating the security baseline. The compliance verification engine extracts the declared resource request and limit amounts from the configuration fragment to be verified. For example, if the memory request amount memory.request is found to be 2048MB and the memory limit amount memory.limit is found to be 4096MB, it checks whether these exceed the single-instance resource limit set for the current deployment environment according to the resource compliance policy. If the resource compliance policy sets the single-instance memory limit for the production environment to be 8192MB, the configuration passes the check; if the memory limit is set to 10240MB, the memory resource exceeds the limit.

[0036] In some embodiments, the review of resource compliance policies may incorporate a quantitative compliance score calculation to comprehensively assess the reasonableness of resource allocation. Optionally, the resource compliance policy defines a resource compliance score function. The resource allocation scheme for a microservice component node S is evaluated. Suppose component S declares... The first type of resource request, for the second The resource type has a request volume of 100,000. The limit is The maximum number of single instances set for this resource type in the deployment environment is [number]. The preset baseline request volume for this resource type is Resource compliance scoring function The calculation formula is: in: Representing the The weighting coefficients for each resource type, and . Representative resource type The maximum number of single instances. Represents resource type The number of requests. Represents resource type The quantity is limited. Representative resource type The preset baseline request volume. It is a penalty factor used to deduct from the request volume when it exceeds the baseline. (Function) Indicates taking and The smaller value in the function. Indicates when Greater than If the ratio exceeds the limit, the score is calculated; otherwise, it is 0. The resource compliance policy sets a compliance score threshold. ,like If the resource configuration scheme is deemed non-compliant, it will be recorded. The compliance verification engine summarizes all inspection records for the "Policy Core Service" node, including the inspection results for naming conventions, port conflicts, security baselines, and resource compliance, and forms a compliance verification report for that node. For items that can be automatically corrected, such as port conflicts, if the correction rule attached to the policy is "automatically increment the port number by 1 when there is a conflict," then the corrected port number 8081 will be generated.

[0037] For entries that cannot be automatically corrected, such as those using weak passwords, an alert message "Security baseline violation: Insufficient password strength" is generated for user intervention. In some embodiments, the naming convention policy can specify different prefixes for service instance names in different environments: the development environment uses the `dev-` prefix, the testing environment uses the `test-` prefix, and the production environment uses the `prod-` prefix. The compliance verification engine applies the corresponding naming pattern for verification based on the environment identifier of this deployment. It can be understood that the comparison operation of the compliance verification engine is executed serially or in parallel on a node-by-node basis. The configuration fragment to be verified on each microservice component node will undergo the complete compliance verification process described above, generating an independent verification report. These reports will ultimately be aggregated to guide the finalization of configuration parameters or issue remediation.

[0038] In one embodiment of the present invention, the container orchestration engine pulls the corresponding service image from the image repository based on the complete configuration manifest, and instantiates and deploys it in the computing resource cluster according to the initial deployment topology. The complete configuration manifest is converted into a set of deployment description files that the container orchestration engine can recognize. The set of deployment description files defines the number of replicas of each microservice component, the container image address, resource limits, configuration volume mount points, and service exposure methods. The set of deployment description files is submitted to the application programming interface server of the container orchestration engine. The scheduler of the container orchestration engine selects a suitable physical host or virtual machine as the deployment target node in the computing resource cluster according to the resource requests and node affinity rules in the set of deployment description files. On the selected deployment target node, the container orchestration engine pulls the corresponding version of the microservice component image from the specified image repository according to the container image address. After the image is pulled, the container orchestration engine creates an independent container runtime environment on the deployment target node, instantiates the microservice component image into one or more container instances, and mounts configuration volumes and sets environment variables according to the set of deployment description files. The network component of the container orchestration engine configures virtual network devices for the container instances, assigns network addresses, and configures network access rules between containers according to the network policies defined in the initial deployment topology diagram.

[0039] In practice, the container orchestration engine pulls the corresponding service image from the image repository based on the complete configuration manifest and instantiates and deploys it in the computing resource cluster according to the initial deployment topology. The deployment management platform converts the complete configuration manifest into a set of deployment description files that the container orchestration engine can recognize. The set of deployment description files is defined in YAML format. Each microservice component in the initial deployment topology contains an independent deployment description file. Each deployment description file defines the number of replicas of the corresponding microservice component, the container image address, resource limits, configuration volume mount point, and service exposure method. For example, for the "insurance core service", its deployment description file defines the number of replicas as 3, the container image address as "registry.company.com / insurance / policy-core:1.2", the CPU resource limit as 2 cores, the memory resource limit as 4GiB, the configuration volume mount point as " / app / config", and exposes port 8080 to external cluster access through a service of type "LoadBalancer". For the complete set of deployment description files, see Table 1. Table 1: Microservice Component Deployment Description Parameters The deployment management platform submits a set of deployment description files to the container orchestration engine's API server via an API client. After receiving the set of deployment description files, the scheduler component of the container orchestration engine selects a suitable physical host or virtual machine as the deployment target node in the computing resource cluster based on the resource requests and node affinity rules in the set of deployment description files. Node affinity rules can specify that microservice components should be scheduled to nodes with specific tags. For example, the deployment description file of "policy-core-service" may contain the rule nodeSelector:disktype:ssd. The scheduler will schedule the instance of this service to a node with the tag disktype=ssd. The resource requests include the minimum requirements of each container instance for CPU and memory. The scheduler will filter out nodes with currently available resources that meet the requirements.

[0040] In some embodiments, when the scheduler selects among multiple nodes that meet basic criteria, it may use a priority scoring function to determine the optimal deployment target node. Optionally, the node selection priority scoring function... Used to calculate candidate nodes For services to be deployed Priority score, function Defined as: in: Represents a candidate node in the computing resource cluster. This represents microservice components that are yet to be deployed. Representative candidate nodes Currently available central processing unit resources, Representative services Requested CPU resource quantity Representative candidate nodes Currently available memory resources, Representative services The amount of memory resources requested. Representative candidate nodes With runtime dependent services Estimated network latency between nodes It is a baseline network latency value used to make the latency dimensionless. This indicates that the service directly depends on the initial deployment topology. Other service collections, Indicates service The nodes that have been scheduled , and These are the weighting coefficients for resource utilization and network latency, which the scheduler calculates for each candidate node. The value is used to select the node with the highest score as the service. The target node for deployment.

[0041] On the deployment target node selected by the scheduler, the container orchestration engine pulls the corresponding version of the microservice component image from the specified image repository according to the container image address defined in the deployment description file. For example, on the node "k8s-node-05", the container orchestration engine executes the command `docker pull registry.company.com / insurance / policy-core:1.2` to pull the image of "policy core service" from the image repository. After the image is pulled, the container orchestration engine calls the container runtime interface on the deployment target node to create an independent container runtime environment, instantiating the microservice component image into one or more container instances, and mounting configuration volumes and setting environment variables according to the definitions in the deployment description file set. For example, three container instances are created for "policy core service", and each instance mounts a container named "policy-core". The configuration volume of "-config" is moved to the " / app / config" path inside the container, and the environment variable SPRING_PROFILES_ACTIVE=prod is set. It can be understood that the network component of the container orchestration engine configures virtual network devices for these container instances, assigns unique network addresses within the cluster, and configures network access rules between containers according to the network policies defined in the initial deployment topology diagram. For example, by defining the NetworkPolicy resource, only traffic from the "Underwriting Rules Engine" is allowed to access port 8080 of the "Policy Core Service", thereby achieving network-level isolation and access control. In some embodiments, for microservice components whose service exposure method is "LoadBalancer", the network component of the container orchestration engine will also automatically configure the load balancer provided by the cloud service provider to guide external traffic to the container instance of that service.

[0042] In one embodiment of the present invention, configuration injection and health check processes are initiated simultaneously during instantiation and deployment. During the container orchestration engine's creation of a container instance, the configuration injection tool listens for container instance creation events to obtain the identifier of the newly created container instance. Based on the container instance identifier, the configuration injection tool queries the final configuration information belonging to the microservice component in the complete configuration list. The configuration injection tool writes the final configuration information into a specified configuration file path or environment variable within the container instance through the container instance's file system interface or environment variable interface. Simultaneously with the completion of configuration information injection, the health check agent, based on a predefined health check strategy for each microservice component, begins periodically sending requests to the health check endpoint within the container instance. The health check agent analyzes the response status code, response content, and response latency of the health check endpoint to determine whether the application process within the container instance has started normally and is in a ready state. The results of configuration injection and health checks are correlated and recorded. Only container instances that have successfully undergone configuration injection and passed the health check are marked as having a service-ready state.

[0043] The health check agent analyzes the response status code, response content, and response latency of the health check endpoint to determine whether the application process inside the container instance has started normally and is in a ready state. The health check agent sends a Hypertext Transfer Protocol (HTTP) GET request to the health check endpoint listened to by the application process inside the container instance. The health check agent receives the response returned by the application process and records the response latency of this request. The health check agent verifies whether the HTTP status code of the response is a success code. If it is a success code, it proceeds to the next step; otherwise, the health check is considered to have failed. After the status code verification is successful, the health check agent parses the response message body and extracts key fields representing the application status. The health check agent compares the extracted key field values ​​with predefined expected status values ​​to determine whether the application's core functional modules have been initialized and whether critical dependency connections are ready. The health check agent comprehensively considers whether the response latency is within the threshold, whether the status code is successful, and whether the application status meets expectations to make a final health status judgment.

[0044] In practice, configuration injection and health checks are initiated simultaneously during the instantiation and deployment process. The configuration injection tool obtains the identifier of the newly created container instance by listening to the container instance creation event of the container orchestration engine. For example, when the container orchestration engine creates a container instance with the identifier "pod / policy-core-7d8f9b6c4-abc12" on the node "k8s-node-03", the configuration injection tool will capture the events related to the creation of this container instance. Based on the container instance identifier "pod / policy-core-7d8f9b6c4-abc12", the configuration injection tool queries the final configuration information of the "policy core service" microservice component in the complete configuration manifest. This final configuration information includes environment variables, database connection strings, and key file contents. The configuration injection tool accesses the container instance's file system interface to write the key file content from the final configuration information into the specified configuration file path " / app / config / application-secret.properties" inside the container instance. At the same time, it sets the environment variable key-value pair "SPRING_PROFILES_ACTIVE=prod" and "DB_URL=jdbc:mysql: / / mysql-primary:3306 / policy_db" into the container's runtime environment through the container instance's environment variable interface.

[0045] Upon completion of configuration information injection, the health check agent begins periodically sending requests to the health check endpoint within the container instance, based on the predefined health check policy for each microservice component. For example, the predefined health check policy for the "Policy Core Service" is to send an HTTP GET request to the " / health" endpoint within the service container every 5 seconds. The health check agent analyzes the response status code, response content, and response latency of the health check endpoint to determine whether the application process within the container instance has started normally and is in a ready state. The health check agent correlates and records the results of configuration injection with the results of health checks. Only when the configuration injection tool reports a successful write operation of the configuration information to the container instance "pod / policy-core-7d8f9b6c4-abc12", and the health check agent reports that the container instance has passed three consecutive health checks, will this container instance be marked as available for service. See Table 2 for the health check policies of the microservice components. Table 2: Microservice Component Health Check Strategy Table In some embodiments, the health check agent can quantify the health status of a container instance using a comprehensive scoring function. Optionally, the health status scoring function... Used in time window Internally, it performs a quantitative assessment of the health status of container instances. (Function) Defined as: in: This represents a preset evaluation time window. Represents the time window Within, the average latency for the health check agent to receive a response. This represents the preset maximum acceptable average latency threshold. Represents the time window The pattern of HTTP status codes returned by the health check endpoint. This represents the expected HTTP status code. Represents the time window Inside, the values ​​of specific application status key fields are parsed from the response message body. This represents the expected value of a key field representing the application's status. It is an indicator function, when the condition is met. The function value is 1 when it is true, and 0 otherwise. , and These are the weighting coefficients for response latency, status code matching, and application status key field matching, respectively, and they satisfy... Health checkup agency calculation The value, if Greater than or equal to the preset health threshold Then determine if the container instance is within the time window. Internally, it is in a healthy state.

[0046] The health check agent analyzes the response status code, response content, and response latency of the health check endpoint to determine whether the application process inside the container instance has started normally and is in a ready state. The health check agent sends an HTTP GET request to the health check endpoint listened to by the application process inside the container instance, for example, sending a request to port 8080 of the container with the IP address "pod / policy-core-7d8f9b6c4-abc12" at the path " / health / ready". The health check agent receives the response returned by the application process and records the response latency of this request, for example, recording the time elapsed from sending the request to receiving the response headers as 150 milliseconds. The health check agent verifies whether the HTTP status code of the response is a success status code. If the status code is 200, it proceeds to the next step of analysis; if the status code is 503 or the request timed out, it is determined that this health check has failed. After the status code verification is successful, the health check agent parses the response message body and extracts the key fields that represent the application status. For example, it extracts the value "UP" of the top-level status field and the value "UP" of the db.status field from the JSON format response body {"status":"UP","db":{"status":"UP"}}.

[0047] The health check agent compares the extracted key field values ​​with predefined expected status values ​​to determine whether the application's core functional modules have been initialized and whether critical dependency connections are ready. For example, the predefined expected status requires that the values ​​of the key fields `status` and `db.status` both be "UP". The health check agent compares the extracted "UP" values ​​with the expected values. The health check agent then considers whether the response latency is within the threshold, whether the status code is successful, and whether the application status meets the expectations to make a final health status judgment. For example, if the response latency is 150 milliseconds, less than the threshold of 2000 milliseconds, the status code is 200 (success), and all application status fields match the expected value "UP", then the health check is considered successful. It can be understood that the configuration injection and health check processes work in parallel and collaboratively. The configuration injection tool ensures that the configuration required for the container instance to run is in place, while the health check agent verifies whether the application processes within the container instance can provide the expected services after obtaining the configuration. The results of both jointly determine the final ready state of the container instance. In some embodiments, the health check agent can be configured to perform the first check after an initial delay of several seconds after the container instance starts, in order to avoid misjudgments caused by the application process still in the startup process.

[0048] In one embodiment of the present invention, after instantiation and deployment are completed, service connectivity testing is performed. The deployment management platform waits for all container instances to be reported as running by the container orchestration engine, and for the configuration injection and health check processes to be reported as passed. The deployment management platform obtains the call relationships between services defined in the initial deployment topology diagram, using this as the basis for service connectivity test cases. The service connectivity tester of the deployment management platform initiates simulated call requests to the dependent services from each container instance where the microservice component, acting as a service caller, resides. The service connectivity tester monitors whether the simulated call requests successfully reach the container instance of the dependent service and obtains the response returned by the dependent service. The service connectivity tester verifies whether the returned response conforms to the expected interface contract, including the response data structure, status code, and necessary message headers. The results of each simulated call are recorded, including network latency, success or failure, and whether the response conforms to the contract, generating a service connectivity test matrix.

[0049] The final output is a deployment readiness status report, summarizing the instantiation deployment status reported by the container orchestration engine, the injection and health status reported by the configuration injection and health check processes, and the service connectivity test results. The summarized status and results are organized and aggregated according to multiple dimensions, including microservice components, deployment nodes, and dependent services. Based on a preset report template, the aggregated status information is converted into a structured document, which includes a deployment overview, component details, configuration summary, health status statistics, connectivity test result summary, and a list of discovered anomalies or warnings. This structured document is output as a deployment readiness status report file in a specified format. The deployment readiness status report file is stored in the deployment log database, and the deployment management platform's interface service is notified to update the deployment task status for user review.

[0050] In practice, after instantiation and deployment are completed, service connectivity testing is performed. The deployment management platform waits for all container instances to be reported as running by the container orchestration engine, and for the configuration injection and health check processes to be reported as passed. The deployment management platform obtains the call relationships between services defined in the initial deployment topology diagram, using this as the basis for service connectivity test cases. For example, it parses the "Underwriting Rules Engine" service calling the "Policy Core Service" and the "Customer Information Management Service" from the initial deployment topology diagram. The service connectivity tester of the deployment management platform initiates simulated call requests to the dependent services from each container instance where the microservice component acts as the service caller resides. The service connectivity tester monitors whether the simulated call requests successfully reach the container instance of the dependent service and obtains the response returned by the dependent service. The service connectivity tester verifies whether the returned response conforms to the expected interface contract, including the response data structure, status code, and necessary message headers. The service connectivity tester records the results of each simulated call, including network latency, success or failure, and whether the response conforms to the contract, generating a service connectivity test matrix.

[0051] The final output is a deployment readiness report. The deployment management platform aggregates the instantiation deployment status reported by the container orchestration engine, the injection and health status reported by the configuration injection and health check processes, and the service connectivity test results reported by the service connectivity tester. The deployment management platform organizes and aggregates the aggregated status and results according to multiple dimensions, including microservice components, deployment nodes, and dependent services. Based on a preset report template, the deployment management platform converts the aggregated status information into a structured document, which includes a deployment overview, component details, configuration summary, health status statistics, connectivity test result summary, and a list of discovered anomalies or warnings. The deployment management platform outputs the structured document as a deployment readiness report file in a specified format, which can be JSON or PDF. The deployment management platform stores the deployment readiness report file in the deployment log database and notifies the deployment management platform's interface service to update the deployment task status for user review.

[0052] In some embodiments, the evaluation of service connectivity test results can incorporate a comprehensive connectivity scoring model; optionally, the service connectivity scoring function... Used for quantitative evaluation of the entire microservice system after a single deployment. The internal service connectivity quality. Function Defined as: in: This represents a microservice system that has been deployed successfully. It represents the set of edges that represent all service call relationships defined in the initial deployment topology graph. and These represent the calling service and the dependent service in a call relationship, respectively. This is a connection success indicator function; if from the service... To Service If the simulated call is successful (i.e., the network is reachable, the response status code is successful, and the response structure conforms to the contract), its value is 1; otherwise, it is 0. Representative from service To Service Network latency of simulated calls. It is the preset maximum tolerable network latency threshold. and These are the weighting coefficients for connectivity success rate and network latency, respectively, and satisfy the following conditions: . This represents the total number of edges involved in the function call. The calculated result is a score between 0 and 1, used to comprehensively characterize the success rate and efficiency of inter-service calls within the system. This score can be included in the connectivity test result summary to provide users with a quantitative overall view of connectivity.

[0053] In some embodiments, the structured document of the deployment readiness status report is organized in sections. The deployment overview section summarizes the total number of services involved in this deployment, the total number of nodes, the overall percentage of healthy instances, and the service connectivity score. The Component Details section displays the name, node, running status, resource configuration, and health check results of each microservice component in a list format. The Configuration Summary section lists the hash or masked values ​​of all injected key configuration items. The Health Status Statistics section displays the number of container instances in healthy, unhealthy, and unknown states as a count and percentage. The Connectivity Test Result Summary section displays the core part of the service connectivity test matrix and the connectivity score. The Anomaly or Warning List section lists all issues found during configuration verification, health checks, or connectivity testing, categorized by severity. Optionally, the deployment management platform can trigger a callback notification while generating the deployment readiness status report file, sending a key summary of the report to designated operations personnel via a messaging channel. Each deployment readiness status report file stored in the deployment log database is associated with a unique deployment task identifier, allowing users to retrieve and compare historical reports based on time, project, or status through the deployment management platform interface.

[0054] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A method for rapid deployment of an insurance SaaS system under a microservice architecture, characterized in that, Includes the following steps: The deployment and management platform includes a pre-defined library of microservice component templates and configuration policy rules commonly used in the insurance industry. Receive the user's selection of the business scope of the target insurance SaaS system submitted through the deployment and management platform interface, and match the basic service set from the microservice component template library according to the business scope selection; Based on the aforementioned set of basic services, a dependency resolution algorithm is invoked to automatically calculate and assemble the initial deployment topology of the target insurance SaaS system. Based on the rules in the configuration policy rule base, the configuration parameters of each component in the initial deployment topology are automatically populated and compliance verified to generate a complete configuration list to be deployed; Based on the complete configuration list, the container orchestration engine pulls the corresponding service images from the image repository and instantiates and deploys them in the compute resource cluster according to the initial deployment topology. During the instantiation and deployment process, the configuration injection and health check processes are started simultaneously. After the instantiation and deployment are completed, service connectivity tests are performed, and a deployment ready status report is finally output.

2. The method for rapid deployment of an insurance SaaS system under a microservice architecture according to claim 1, characterized in that, Based on the aforementioned set of basic services, a dependency resolution algorithm is invoked to automatically calculate and assemble the initial deployment topology of the target insurance SaaS system, specifically including: Extract the metadata of each microservice component in the basic service set from the microservice component template library. The metadata includes a service function description, an exposed interface contract, and a list of declared dependent service requirements. Using the microservice components in the basic service set as nodes, construct an initially empty deployment topology graph; The customized service dependency declarations submitted by users through the interface are merged with the list of dependency service requirements extracted from the metadata to form a complete dependency declaration for each microservice component. The dependency resolution algorithm is invoked to traverse the complete dependency declaration of each microservice component and identify whether the other services that the declaration depends on exist in the set of basic services. For dependencies that exist in the set of basic services, add a directed edge to the deployment topology graph from the current microservice component node to the dependent microservice component node; For dependencies that do not exist in the basic service set, try to find a matching public component in the extension area of ​​the microservice component template library. If found, add the public component as a new node to the deployment topology graph and add the corresponding dependency edge. If not found, mark it as an external dependency to be processed. After parsing, check if there are any circular dependency paths in the deployment topology graph. If so, remove edges or decompose services according to the preset cycle de-looping strategy, and finally output an acyclic initial deployment topology graph.

3. The method for rapid deployment of an insurance SaaS system under a microservice architecture according to claim 2, characterized in that, The dependency resolution algorithm operates based on the principle of separating declarative dependencies from runtime dependencies, and specifically includes: When resolving the complete dependency declarations of microservice components, the dependency resolution algorithm first divides the declaration content into two categories: strong dependencies at the declaration stage and dynamic dependencies at runtime. For strong dependencies at the declaration period, the dependency resolution algorithm requires that the services it depends on must be explicitly identified and connected during the deployment topology graph construction phase, and that stable connection edges with explicit version constraints be established in the initial deployment topology graph; For runtime dynamic dependencies, the dependency resolution algorithm does not require the establishment of fixed connection edges in the initial deployment topology graph. Instead, it generates a service discovery tag for it and injects the service discovery tag into the configuration of the corresponding microservice component. During the deployment topology graph construction phase, the dependency resolution algorithm only processes declaration-time strong dependencies, thereby simplifying the initial topology structure. In the subsequent step of generating a complete configuration list based on the configuration policy rule base, client policies pointing to the service registry are automatically configured for microservice components with service discovery tags, so that they can dynamically discover and call the services they depend on at runtime.

4. The method for rapid deployment of an insurance SaaS system under a microservice architecture according to claim 1, characterized in that, The automatic population and compliance verification of configuration parameters for each component in the initial deployment topology based on rules in the configuration policy rule base includes: From the initial deployment topology diagram, read the identification information of each microservice component node one by one; Based on the identification information of the microservice component node, the configuration rule group that matches it is queried in the configuration policy rule base. The configuration rule group includes environment variable default value rules, resource quota rules, connection string generation rules and security policy rules. Based on the default environment variable rules and the environment identifier of this deployment, the set of environment variable key-value pairs required by the microservice component instance is automatically generated. Based on the resource quota rules and the preset resource pool capacity, the CPU core limit, memory limit and storage volume size of the microservice component instance are automatically calculated and allocated. Based on the connection string generation rules, and according to the node identifier of the dependent service and the deployment network plan, the database connection string and message queue endpoint address are automatically generated. Based on the security policy rules, the application programming interface access key and transport layer security protocol certificate mounting path required for the microservice component instance are automatically generated. The automatically generated configuration parameters are filled into the configuration template of the microservice component node to form the configuration fragment to be verified of the microservice component node; The compliance verification engine is invoked to compare the configuration fragment to be verified with the global compliance policy in the configuration policy rule base. It checks for parameter conflicts, security vulnerabilities, or resource over-provisioning. Configuration items that fail verification are marked and attempts are made to automatically adjust them according to the correction rules.

5. The method for rapid deployment of an insurance SaaS system under a microservice architecture according to claim 4, characterized in that, The process of invoking the compliance verification engine compares the configuration fragment to be verified with the global compliance policies in the configuration policy rule base, specifically including: The compliance verification engine loads the global compliance policies defined in the configuration policy rule base, which include naming convention policies, port conflict detection policies, security baseline policies, and resource compliance policies. The compliance verification engine extracts all custom configuration item names from the configuration fragment to be verified, checks whether they conform to the predefined naming pattern according to the naming convention strategy, and records the configuration item names that do not conform to the pattern. The compliance verification engine extracts all network port numbers declared in the configuration fragment to be verified, checks whether there are duplicate port numbers declared in the same host node or network namespace according to the port conflict detection strategy, and records all conflicting ports. The compliance verification engine extracts security-related configurations from the configuration fragments to be verified, checks whether there are cases of using default passwords, not enabling transport layer security protocols, or having excessively broad authorization scopes based on the security baseline policy, and records all configuration items that violate the security baseline. The compliance verification engine extracts the resource request and limit declared in the configuration fragment to be verified, checks whether it exceeds the single instance resource limit set for the current deployment environment according to the resource compliance policy, and records all resource types and values ​​that exceed the limit. All inspection records are compiled into a compliance verification report. For items that can be automatically corrected, the corrected configuration values ​​are generated according to the correction rules attached to the policy. For items that cannot be automatically corrected, alarm information is generated for user processing.

6. The method for rapid deployment of an insurance SaaS system under a microservice architecture according to claim 1, characterized in that, The container orchestration engine pulls the corresponding service image from the image repository and instantiates and deploys it in the computing resource cluster according to the initial deployment topology. Specifically, this includes: The complete configuration manifest is converted into a set of deployment description files that can be recognized by the container orchestration engine. The set of deployment description files defines the number of replicas of each microservice component, the container image address, resource limits, configuration volume mount points, and service exposure methods. Submit the deployment description file set to the container orchestration engine's application programming interface server; The container orchestration engine's scheduler selects a suitable physical host or virtual machine as the deployment target node from the computing resource cluster based on resource requests and node affinity rules in the deployment description file set. On the selected deployment target node, the container orchestration engine pulls the corresponding version of the microservice component image from the specified image repository based on the container image address; After the image is pulled, the container orchestration engine creates an independent container runtime environment on the deployment target node, instantiates the microservice component image into one or more container instances, and mounts configuration volumes and sets environment variables according to the set of deployment description files; The network component of the container orchestration engine configures virtual network devices for the container instances, assigns network addresses, and configures network access rules between containers according to the network policies defined in the initial deployment topology diagram.

7. The method for rapid deployment of an insurance SaaS system under a microservice architecture according to claim 1, characterized in that, The synchronous startup configuration injection and health check process specifically includes: During the process of creating a container instance by the container orchestration engine, the configuration injection tool obtains the identifier of the newly created container instance by listening to the container instance creation event; The configuration injection tool queries the final configuration information belonging to the microservice component in the complete configuration list based on the container instance identifier; The configuration injection tool writes the final configuration information into the specified configuration file path or environment variable inside the container instance through the container instance's file system interface or environment variable interface; Once the configuration information injection is complete, the health check agent begins to periodically send requests to the health check endpoint within the container instance, based on the predefined health check strategy for each microservice component. The health check agent analyzes the response status code, response content, and response latency of the health check endpoint to determine whether the application process inside the container instance has started normally and is in a ready state. The configuration injection result is associated with the health check result and recorded. Only container instances that have successfully injected configuration and passed the health check will be marked as available to provide services.

8. The method for rapid deployment of an insurance SaaS system under a microservice architecture according to claim 7, characterized in that, The health check agent analyzes the response status code, response content, and response latency of the health check endpoint to determine whether the application process inside the container instance has started normally and is in a ready state, specifically including: The health check agent sends a Hypertext Transfer Protocol (HTTP) GET request to the health check endpoint that the application process within the container instance is listening for. The health check agent receives the response returned by the application process and records the response delay time for this request; The health check agent verifies whether the Hypertext Transfer Protocol status code of the response is a success code. If it is a success code, proceed to the next step; otherwise, the health check is deemed to have failed. After the status code verification is successful, the health check agent parses the response message body and extracts the key fields that represent the application status. The health check agent compares the extracted key field values ​​with the predefined expected status values ​​to determine whether the application's core functional modules have been initialized and whether key dependency connections are ready. The health check agent determines the final health status by considering whether the response delay is within the threshold, whether the status code is successful, and whether the application status meets expectations.

9. The method for rapid deployment of an insurance SaaS system under a microservice architecture according to claim 1, characterized in that, After instantiation and deployment are completed, the service connectivity test is performed, which specifically includes: The deployment management platform waits for all container instances to be reported as running by the container orchestration engine, and for the configuration injection and health check processes to be reported as passed. The deployment management platform obtains the call relationships between services defined in the initial deployment topology diagram, which serves as the basis for service connectivity test cases. The service connectivity tester of the deployment management platform initiates simulated call requests to its dependent services from each container instance where the microservice component, which acts as a service caller, resides. The service connectivity tester monitors whether the simulated call request successfully reaches the container instance of the dependent service and obtains the response returned by the dependent service. The service connectivity tester verifies whether the returned response conforms to the expected interface contract, including the response data structure, status code, and necessary message headers; Record the results of each simulated call, including network latency, success or failure, and whether the response conforms to the contract, and generate a service connectivity test matrix.

10. A method for rapid deployment of an insurance SaaS system under a microservice architecture according to claim 1, characterized in that, The final output deployment readiness status report specifically includes: It summarizes the instantiation deployment status reported by the container orchestration engine, the injection and health status reported by the configuration injection and health check process, and the service connectivity test results. The summarized status and results are organized and aggregated according to multiple dimensions such as microservice components, deployment nodes, and dependent services; Based on the preset report template, the aggregated status information is converted into a structured document, which includes a deployment overview, component details, configuration summary, health status statistics, connectivity test result summary, and a list of discovered anomalies or warnings; Output structured documents as deployment readiness status report files in a specified format; The deployment readiness status report file is stored in the deployment log database, and the interface service of the deployment management platform is notified to update the status of the deployment task for users to view.

Images