Automatic subsystem configuration method and system for cross-domain unified access platform

Abstract

The invention provides an automatic subsystem configuration method and system for a cross-domain unified access platform, relates to the field of automatic configuration, and improves the automation degree, consistency and reliability of subsystem access configuration. The method comprises the following steps: firstly, carrying out standardized analysis on subsystem basic information based on a uniform resource semantic model, and generating a configuration description object comprising a service end point, a security policy and a dependency relationship; then, a service topology and configuration form is displayed through a visual configuration engine, interactive modification is supported, and a strategy decision engine is driven to generate a final configuration scheme; and finally, converting the scheme into a declarative deployment list, submitting the declarative deployment list to an API gateway in an atomization mode after logic verification to complete automatic deployment, and monitoring the health state of the subsystem in real time. According to the method, semantic modeling, visual configuration, strategy dynamic synthesis and atomization deployment are combined, so that the subsystem access efficiency, the configuration visualization degree and the system operation and maintenance reliability are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of automated configuration, specifically to an automated subsystem configuration method for a cross-domain unified access platform. Background Technology

[0002] In the process of building and operating a cross-domain unified access platform, such as an API gateway platform under a microservice architecture, the traditional subsystem access method usually relies on manual configuration, which has problems such as low configuration efficiency, easy error, and difficulty in adapting to the differentiated security policies and dependencies between cross-domain heterogeneous systems. This results in long platform integration cycles, high operation and maintenance costs, and difficulty in achieving large-scale, agile unified management and collaborative scheduling of subsystems.

[0003] In existing technologies, automated configuration tools and platform-based integration solutions can reduce manual intervention and improve configuration consistency and repeatability through templates or scripts. However, they still have the following shortcomings: lack of unified semantic modeling capabilities for heterogeneous subsystem resources, making it difficult to achieve standardized description and parsing of cross-domain services; low visualization of the configuration process, making it difficult for users to intuitively understand service topology and dependencies, and lacking real-time assessment and early warning of the impact of configuration changes; high coupling between policy generation and deployment processes, lacking flexible and scalable policy decision-making and atomic deployment mechanisms, resulting in insufficient adaptability of the system in complex policy combinations and dynamic adjustment scenarios. Summary of the Invention

[0004] To address the technical problems mentioned in the background section, this invention proposes an automated subsystem configuration method and system for cross-domain unified access platforms.

[0005] Therefore, the technical solution adopted by the present invention is as follows:

[0006] An automated subsystem configuration method for a cross-domain unified access platform, characterized in that the method includes:

[0007] S1: Receive basic information from the subsystem to be connected, parse the basic information based on the predefined unified resource semantic model, and generate a platform-based configuration description object containing standardized service endpoints, security policy requirements, and resource dependencies;

[0008] S2: Load the platform-based configuration description object into the visual configuration engine to display the service topology and configuration form; based on the user's modification operation on the configuration form in the visual interface, update the platform-based configuration description object to further drive the strategy decision engine to form the final configuration scheme to be executed;

[0009] S3: Based on the final configuration scheme, generate a declarative deployment list that can be recognized by the target API gateway, and drive the deployment executor to atomically submit the declarative deployment list to the API gateway to automatically complete the deployment configuration of the subsystem; at the same time, obtain the health status of the subsystem in real time, generate a status verification report and feed it back to the visualization interface.

[0010] Furthermore, the unified resource semantic model includes a base layer, a strategy layer, and a dependency layer.

[0011] The base layer of the Unified Resource Semantic Model is based on the original service address of the subsystem to be accessed. Generate a standardized service endpoint, represented as:

[0012]

[0013] in, Represents a standardized transformation function; Indicates a standardized service endpoint; Indicates the host address; Indicates the port number; Indicates the type of transport protocol; Indicates the base path;

[0014] The policy layer categorizes the security policy requirements into authentication policies, authorization policies, and encryption policies.

[0015] The dependency layer constructs a dependency strength matrix based on the basic information of the subsystem, wherein the subsystem to be connected... The set of dependent subsystems is Then it depends on the intensity matrix elements in Represented as:

[0016]

[0017] in, Representation Subsystem Subsystem Resource dependencies; Representation Subsystem Subsystems within a unit of time The number of calls initiated; Representation Subsystem Total number of calls made to all dependent subsystems.

[0018] Furthermore, the service topology displays the resource dependencies of the subsystems to be connected through a service topology graph.

[0019] The subsystem to be accessed In the service topology graph, it is represented as a node. ,node The position vector is solved using an iterative optimization algorithm; in each iteration, the resultant force on the node is... For gravity and repulsive force The sum of,

[0020] Gravity is represented as:

[0021]

[0022] in, Represents nodes A set of nodes that have dependencies on each other; Indicates the gravitational coefficient; and Representing nodes respectively and The position vector;

[0023] Repulsive force is represented as:

[0024]

[0025] in, Indicates the repulsion coefficient; Represents a node and Euclidean distance;

[0026] node The position vector update is represented as:

[0027]

[0028] in, Indicates the number of iterations; Indicates the first After the second iteration, the node The position vector; This represents the step size coefficient.

[0029] Furthermore, the configuration form generates form controls based on the fields of the platform-based configuration description object.

[0030] Based on standardized service endpoints, the form controls include a host address input box, a port number input box, a protocol type drop-down box, and a basic path input box;

[0031] Based on security policy requirements, the form control includes an authentication method selector, an encryption level slider, and a traffic limit input box.

[0032] Furthermore, the update of the platform-based configuration description object is a field update, and the impact strength is represented as follows:

[0033]

[0034] in, Representation field The intensity of the impact; Indicates the field The set of fields affected by the update; Representation field For fields The influence weight is determined; when the influence intensity exceeds a set threshold, the visual interface issues an alarm.

[0035] Furthermore, the strategy decision engine generates the final configuration scheme through strategy selection, parameter generation, and strategy assembly.

[0036] The strategy selection process involves choosing a strategy template from the strategy library to match the subsystem to be integrated, as shown below:

[0037]

[0038] in, Representation Strategy Template Adaptability; This indicates the number of features of the subsystem; Indicates the first The importance weights of each feature; Representation of features With strategy templates The matching degree; select based on the adaptability of the strategy template;

[0039] The parameter generation generates parameter values ​​for the selected policy template based on the security policy requirements;

[0040] The strategy assembly integrates the selected strategy template and the generated parameter values ​​into a complete strategy document.

[0041] Furthermore, the declarative deployment manifest includes service objects, routing objects, and policy objects;

[0042] The deployment executor submits the service object, routing object, and policy object to the API gateway in that order.

[0043] The status verification report provides visual feedback to the user through the service topology diagram.

[0044] An automated subsystem configuration system for a cross-domain unified access platform, comprising:

[0045] M1: Generation module, receives basic information from the subsystem to be connected, parses the basic information based on the predefined unified resource semantic model, and generates a platform-based configuration description object containing standardized service endpoints, security policy requirements and resource dependencies;

[0046] M2: Visualization-driven module, which loads the platform-based configuration description object into the visualization configuration engine to display the service topology and configuration form; based on the user's modification operations on the configuration form in the visualization interface, it updates the platform-based configuration description object and further drives the strategy decision engine to form the final configuration scheme to be executed;

[0047] M3: The automated execution module generates a declarative deployment list that can be recognized by the target API gateway according to the final configuration scheme, and drives the deployment executor to atomically submit the declarative deployment list to the API gateway, thereby automating the deployment configuration of the subsystem; at the same time, it obtains the health status of the subsystem in real time, generates a status verification report, and feeds it back to the visualization interface.

[0048] Compared with the prior art, the advantages of the present invention are as follows:

[0049] 1. This invention, by constructing a unified resource semantic model, achieves standardized parsing of basic information of cross-domain heterogeneous subsystems and unified representation of service endpoints, significantly improving the consistency and scalability of system integration.

[0050] 2. This invention introduces a visual configuration engine and a dynamic service topology layout mechanism, which supports real-time interaction of configuration forms and visualization of dependencies, and realizes intelligent early warning of configuration changes based on impact intensity assessment, thereby enhancing the transparency and controllability of the configuration process.

[0051] 3. This invention uses a policy decision engine to drive dynamic policy synthesis, and combines a declarative deployment list with an atomic commit mechanism to achieve full-process automation and transaction protection from policy generation to gateway deployment, thereby improving the reliability, security and operational efficiency of configuration execution. Attached Figure Description

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

[0053] Figure 1 This is a flowchart of the automated subsystem configuration method of the present invention;

[0054] Figure 2This is a flowchart illustrating the generation process of the platform-based configuration description object of the present invention.

[0055] Figure 3 A flowchart is generated for the final configuration scheme of this invention. Detailed Implementation

[0056] To achieve the above objectives, this invention provides an automated subsystem configuration method for a cross-domain unified access platform. Please refer to [link to relevant documentation]. Figures 1-3 The method includes:

[0057] S1: Receives basic information from the subsystem to be connected, parses the basic information based on a predefined unified resource semantic model, and generates a platform-based configuration description object containing standardized service endpoints, security policy requirements, and resource dependencies.

[0058] The core objective of this step is to convert the basic information of the subsystems to be integrated into standardized configuration description objects that the platform can understand. By parsing and standardizing the basic information through a predefined unified resource semantic model, key configuration elements such as service endpoints, security policy requirements, and resource dependencies are extracted, laying the data foundation for subsequent visual configuration and automated deployment. This step ensures that subsystem information from different sources and in different formats can be uniformly converted into the platform's standard format, eliminating integration barriers caused by information heterogeneity.

[0059] The basic information of the subsystem is provided by the subsystem administrator or automation tools, including but not limited to core configuration parameters such as subsystem name, access address, protocol type, port information, authentication method, resource path, and dependent service list. Specifically, the subsystem name is used to uniquely identify the subsystem in the platform, the access address defines the network location of the subsystem, the protocol type specifies the communication protocol, the port information determines the service listening port, the authentication method describes the access control requirements, the resource path defines the API endpoints or resource paths provided by the subsystem, and the dependent service list clarifies the other service components that the subsystem depends on. This basic information constitutes the raw dataset for subsystem access, providing complete input for subsequent standardization processing.

[0060] The Unified Resource Semantic Model defines a standardized representation of subsystems within the platform. This model adopts a layered design, comprising three parts: the base layer, the policy layer, and the dependency layer. The base layer describes the physical and network attributes of the subsystems, the policy layer defines access control and security policy requirements, and the dependency layer depicts the calling relationships and resource dependencies between the subsystems and other services.

[0061] During the parsing process, the service addresses of the subsystems are first standardized, and the original input service address is set to... This address contains various formats such as IP address, domain name, port number, and path; each component is extracted using regular expressions and then normalized. The process of generating a standardized server endpoint is represented as follows:

[0062]

[0063] in, Represents a standardized transformation function; Indicates a standardized service endpoint; Indicates the host address; Indicates the port number; Indicates the type of transport protocol; This represents the basic path; through this standardized representation, endpoint information of cross-domain subsystems and intra-domain subsystems is uniformly converted into a platform-recognizable format, eliminating the diversity of original information formats.

[0064] After obtaining the standardized service endpoint, the security policy requirements of the subsystem are further analyzed. These requirements describe the subsystem's requirements for security mechanisms such as authentication, access control, and data encryption. Based on the Unified Resource Semantic Model (URS), the security policy requirements are structured into three dimensions: authentication policy, authorization policy, and encryption policy. The authentication policy defines the authentication method and required credential types; the authorization policy specifies the granularity of access permissions and control rules; and the encryption policy specifies the encryption requirements for data transmission. These three dimensions together constitute the subsystem's security policy requirements. ;

[0065] In a cross-domain unified access platform, there are often complex call relationships and data dependencies between subsystems. By analyzing the interface description files and historical call logs of the subsystems, a dependency graph is constructed, and the subsystems to be connected are defined. The set of dependent subsystems is Then it depends on the intensity matrix elements in Represented as:

[0066]

[0067] in, Representation Subsystem Subsystem Resource dependencies; Representation Subsystem Subsystems within a unit of time The number of calls initiated; Representation Subsystem The total number of calls made to all dependent subsystems;

[0068] After parsing, all information is integrated into a platform-based configuration description object. This object is stored in a structured data format and contains the following core fields: standardized server endpoint. Security strategy requirements Resource dependency and subsystem metadata This configuration description object becomes the core data carrier for subsequent visual configuration and automated deployment, ensuring the consistency and integrity of configuration information throughout the entire platform process.

[0069] In this embodiment, the enterprise needs to connect its internally developed order management system to the cross-domain unified access platform. The order management system provides a RESTful API, with basic information including the service address https: / / order.xxx.com:8080 / api / v1, requiring OAuth 2.0 authentication, and depending on the user service and inventory service. Standardized service endpoints are generated through the unified resource semantic model, namely the host address order.xxx.com, port 8080, protocol HTTPS, and basic path / api / v1. At the same time, the strategy layer identifies the authentication strategy as OAuth 2.0, and the dependency layer constructs a dependency strength matrix with the user service and inventory service.

[0070] S2: Load the platform-based configuration description object into the visual configuration engine to display the service topology and configuration form; based on the user's modifications to the configuration form on the visual interface, update the platform-based configuration description object, and further drive the strategy decision engine to form the final configuration scheme to be executed.

[0071] The core task of this step is to load the platform-based configuration description object into the visual configuration engine, display the service topology and configuration form in a graphical way, and dynamically update the configuration object according to the user's interaction. At the same time, it drives the policy decision engine to synthesize identity authentication and access control policies, and finally form a complete configuration scheme to be executed.

[0072] The design of the visual configuration engine follows the principle of ease of use in human-computer interaction, transforming complex configuration information into intuitive graphical elements and form controls. The service topology graph uses a directed graph to display the dependencies between subsystems. Nodes in the graph represent each subsystem, the direction of the edges indicates the call direction, and the thickness of the edges indicates the dependency strength. The topology graph layout algorithm uses force-directed layout, which simulates the attraction and repulsion between nodes, making subsystems with close dependencies appear more visually clustered.

[0073] Subsystem In the service topology graph, it is represented as a node. ,node The position vector is solved using an iterative optimization algorithm; in each iteration, the resultant force on the node is... By gravity and repulsive force A joint decision, expressed as:

[0074]

[0075] Gravity originates from nodes with dependencies, represented as:

[0076]

[0077] in, Represents nodes A set of nodes that have dependencies on each other; Indicates the gravitational coefficient; and Representing nodes respectively and The position vector; gravity causes nodes with high dependency strength to move closer to each other, making it easier for users to identify core dependency paths;

[0078] The repulsive force comes from all nodes and prevents excessive overlap of nodes, represented as:

[0079]

[0080] in, Indicates the repulsion coefficient; Represents a node and The Euclidean distance; the repulsive force is inversely proportional to the square of the distance, ensuring that nodes maintain an appropriate spacing and improving the readability of the topology graph;

[0081] node The position vector is updated in each iteration according to the direction of the resultant force, expressed as:

[0082]

[0083] in, Indicates the number of iterations; This represents the step size coefficient, which controls the update magnitude of each iteration. After multiple iterations, the node positions tend to stabilize, forming a clear service topology.

[0084] The configuration form is designed with a responsive layout, dynamically generating form controls based on the fields of the configuration description object. For server endpoint configuration, the form includes a host address input box, a port number input box, a protocol type dropdown box, and a base path input box. For security policy configuration, the form provides an authentication method selector, an encryption level slider, and a traffic limit input box. The display order and grouping of form controls follow configuration dependencies; for example, the specific authentication method configuration will only be displayed after an option requiring authentication is selected.

[0085] When users modify the configuration form on the visual interface, the change event is captured in real time, and the platform-based configuration description object is updated; when the user modifies a field... The value, from the original value Change to new value First, the new value is validated for legality. The validation rules include data type checks, value range validation, and dependency constraint checks. For example, the port number must be an integer between 1 and 65535, the protocol type must be a valid value in a predefined set, and the encryption level cannot be lower than the minimum security requirement.

[0086] The scope of the update's impact is determined using a dependency analysis algorithm, with fields defined. Changes will affect the field set The system calculates the propagation path of the impact and highlights the affected configuration items on the visualization interface. The impact strength is calculated by accumulating the dependency weights.

[0087]

[0088] in, Representation field The intensity of the impact; Representation field For fields The influence weight, with a value range of ;when When the preset threshold is exceeded, the visual interface will issue an alert, reminding the user that the change may cause configuration conflicts or service abnormalities, and that caution should be exercised.

[0089] In this embodiment, the payment service needs to add a risk control service due to business expansion, and the port is changed from 8443 to 9443. The user modifies the dependency list and port field in the visual configuration interface, and then calculates the impact strength in real time. It is found that the change may affect the routing matching and load balancing strategy. The impact strength exceeds the threshold, and the interface pops up a warning: the port change may cause the existing client connection to be interrupted. It is recommended to release in batches.

[0090] While the configuration is being updated, the policy decision engine dynamically synthesizes authentication and access control policies based on the updated configuration description object. The policy decision engine adopts a rule engine architecture, with a series of predefined policy templates and decision rules built in. The policy synthesis process is divided into three stages: policy selection, parameter generation, and policy assembly.

[0091] During the policy selection phase, based on the subsystem's security level and access characteristics, a suitable policy template is selected from the policy library, and the policy library is configured to include... A strategy template Each template corresponds to a different security scenario; the adaptability of the policy template is calculated using a feature matching function, expressed as:

[0092]

[0093] in, This indicates the number of features of the subsystem; Indicates the first The importance weights of each feature; Representation of features With template The matching degree takes a value of 0 or 1, where 1 is a perfect match and 0 is a no-match; the strategy template with the highest matching degree is selected as the base strategy.

[0094] During the parameter generation phase, specific parameter values ​​are generated for the policy template based on the security policy requirements in the configuration description object. Taking the identity authentication policy as an example, policy parameters include authentication protocol, token validity period, refresh mechanism, and number of retries on failure, etc.; token validity period... The calculation takes into account the access frequency and security level of the subsystem, and is expressed as:

[0095]

[0096] in, This indicates the validity period of the base token, set to 30 minutes. The influence coefficient representing the safety level, with a value range of [value missing]. The higher the security level, the shorter the token's validity period; Indicates safety strength; The influence coefficient representing the frequency of visits, with a value range of [value missing]. ; This represents the average number of accesses per unit of time. The higher the access frequency, the longer the token validity period should be to reduce authentication overhead. This formula achieves a dynamic balance between security and user experience.

[0097] The policy assembly phase integrates the selected policy template and the generated parameter values ​​into a complete policy document. The policy document uses a declarative syntax and includes information such as policy type, scope of application, rule set, and execution order. The consistency of the policies is checked through formal verification tools to ensure that there are no conflicts or contradictions between policies. For example, conflicting rules such as blocking all access and allowing access from specific IPs are not allowed to be configured at the same time.

[0098] The final configuration scheme is a unified representation of configuration description objects and policy documents, containing complete access information and security policies for subsystems; the completeness of the configuration scheme is measured by coverage metrics. Measurement, expressed as:

[0099]

[0100] in, Represents the set of configured fields; This represents the set of fields that must be configured; when Reaching 100% indicates that the configuration scheme meets all necessary conditions and can proceed to the next deployment and execution phase.

[0101] S3: Based on the final configuration scheme, generate a declarative deployment manifest that the API gateway can recognize, and drive the deployment executor to atomically submit the declarative deployment manifest to the API gateway, automatically completing the deployment configuration of the subsystem; at the same time, obtain the health status of the subsystem in real time, generate a status verification report and feed it back to the visualization interface.

[0102] Declarative deployment manifests are a standardized expression of configuration information, using a structured language to describe the desired state of the gateway. Unlike traditional imperative configuration, declarative configuration only requires specifying the target state, and the gateway automatically calculates the sequence of operations required to achieve the target state, thereby simplifying the configuration process and improving reliability. The deployment manifest generation process converts the final configuration scheme into a gateway-specific configuration format. The conversion function maps the final configuration scheme into a collection of service objects, routing objects, and policy objects.

[0103] After generating a complete deployment manifest, the deployment executor submits the declarative deployment manifest to the API gateway using an atomic commit mechanism. Atomic commits ensure that all configuration operations succeed or are rolled back, avoiding inconsistencies caused by partial configuration success. The executor commits configurations sequentially in the order of service objects, route objects, and policy objects, following dependency relationships to ensure that route objects are correctly associated with service objects.

[0104] Configuration commits employ a transaction mechanism, recording the execution result of each configuration operation, and defining the configuration operation sequence as follows. The success rate of a transaction is expressed as:

[0105]

[0106] in, Indicates a pointer function, when the operation Returns 1 on success and 0 on failure; only returns 0 on failure. A transaction is considered successful only if the completion rate is 100%. Otherwise, the executor triggers a rollback operation, performing the reverse operation in the reverse order of the deployment manifest submission, restoring the gateway to its state before the submission.

[0107] After successful configuration submission, the health status of the subsystem is obtained in real time. The health status is obtained through the gateway's health check mechanism, including service availability, response time, and error rate.

[0108] Service availability is defined as the percentage of successful health checks within the observation time window. When service availability is lower than a preset threshold, the service is deemed abnormal, an alarm is triggered, and the error is marked on the visualization interface.

[0109] Response time reflects the performance of a service. By calculating the response time of a health check, the degree of fluctuation in response time is measured by the standard deviation. Stable services have a low standard deviation, while services with large fluctuations in response time may have performance bottlenecks or resource contention.

[0110] Error rate statistics show the proportion of service request failures. Error rate is an important indicator for measuring service quality. A consistently high error rate indicates that there are serious problems with the service, requiring manual intervention for investigation.

[0111] The acquired health status information is output as a status verification report, which is displayed in a hierarchical manner.

[0112] The status verification report is pushed to the visualization interface in real time. The service topology map on the interface dynamically updates the node colors according to the health status. Healthy service nodes are displayed in green, abnormal service nodes are displayed in red, and service nodes with degraded performance are displayed in yellow. Users can click on the nodes to view detailed monitoring data and configuration information, and quickly locate and resolve problems.

[0113] An automated subsystem configuration system for a cross-domain unified access platform, comprising:

[0114] M1: Generation module, receives basic information from the subsystem to be connected, parses the basic information based on the predefined unified resource semantic model, and generates a platform-based configuration description object containing standardized service endpoints, security policy requirements and resource dependencies;

[0115] M2: Visualization-driven module, which loads the platform-based configuration description object into the visualization configuration engine to display the service topology and configuration form; based on the user's modification operations on the configuration form in the visualization interface, it updates the platform-based configuration description object, and further drives the strategy decision engine to form the final configuration scheme to be executed;

[0116] M3: The automated execution module generates a declarative deployment manifest that can be recognized by the target API gateway based on the final configuration scheme, and drives the deployment executor to atomically submit the declarative deployment manifest to the API gateway, automatically completing the deployment configuration of the subsystem; at the same time, it obtains the health status of the subsystem in real time, generates a status verification report and feeds it back to the visualization interface.

[0117] This invention proposes an automated subsystem configuration method and system for cross-domain unified access platforms. It standardizes and uniformly represents subsystem information by constructing a unified resource semantic model, utilizes a visual configuration engine to intuitively display and interactively edit service topologies and configuration forms, and dynamically synthesizes security policies based on a policy decision engine. Finally, it drives the API gateway to automatically complete service registration, route publishing, and policy loading for subsystems by generating a declarative deployment list and an atomic submission mechanism. This method and system achieve a closed-loop process from information parsing, visual configuration, policy generation to automated deployment, effectively solving the problems of low efficiency, poor consistency, and complex operation and maintenance of subsystem access configuration in cross-domain environments.

[0118] In summary, this invention provides an efficient, reliable, and secure automated configuration solution that significantly enhances the capabilities of cross-domain unified access platforms in subsystem integration, policy management, and operation and maintenance monitoring, demonstrating significant practical value and promising prospects for widespread adoption.

[0119] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for configuring an automated subsystem for a cross-domain unified access platform, characterized in that, The method includes: S1: Receive basic information from the subsystem to be connected, parse the basic information based on the predefined unified resource semantic model, and generate a platform-based configuration description object containing standardized service endpoints, security policy requirements, and resource dependencies; S2: Load the platform-based configuration description object into the visual configuration engine, calculate the node positions using the force-oriented algorithm based on the resource dependencies, and generate a service topology diagram; display the service topology and configuration form; update the platform-based configuration description object based on the user's modification operations on the configuration form on the visual interface, and calculate the impact intensity of the change based on the dependency weight between fields. When the impact intensity exceeds the threshold, trigger an early warning, and further drive the strategy decision engine to form the final configuration scheme to be executed. S3: Based on the final configuration scheme, generate a declarative deployment list that the API gateway can recognize, and drive the deployment executor to atomically submit the declarative deployment list to the API gateway in an atomic transaction manner according to the dependency order, thereby automatically completing the deployment configuration of the subsystem; at the same time, obtain the health status of the subsystem in real time, generate a status verification report and feed it back to the visualization interface.

2. The automated subsystem configuration method for a cross-domain unified access platform according to claim 1, characterized in that, The unified resource semantic model includes a base layer, a strategy layer, and a dependency layer. The base layer of the Unified Resource Semantic Model is based on the original service address of the subsystem to be accessed. Generate a standardized service endpoint, represented as: in, Represents a standardized transformation function; Indicates a standardized service endpoint; Indicates the host address; Indicates the port number; Indicates the type of transport protocol; Indicates the base path; The policy layer categorizes the security policy requirements into authentication policies, authorization policies, and encryption policies. The dependency layer constructs a dependency strength matrix based on the basic information of the subsystem, wherein the subsystem to be connected... The set of dependent subsystems is Then it depends on the intensity matrix elements in Represented as: in, Representation Subsystem Subsystem Resource dependencies; Representation Subsystem Subsystems within a unit of time The number of calls initiated; Representation Subsystem Total number of calls made to all dependent subsystems.

3. The automated subsystem configuration method for a cross-domain unified access platform according to claim 2, characterized in that, The service topology graph displays the resource dependencies of the subsystems to be connected. The subsystems to be connected are represented as nodes in the service topology graph, and the position vectors of the nodes are solved by an iterative optimization algorithm. The net force on a node in each iteration The sum of attraction and repulsion, where the attraction is positively correlated with the strength of the dependency between nodes, is expressed as: in, Represents nodes A set of nodes with dependencies. Indicates the gravitational coefficient; and Representing nodes respectively and nodes The position vector; Repulsive force is represented as: in, Indicates the repulsion coefficient; Represents a node and nodes Euclidean distance; node The position vector update is represented as: in, Indicates the number of iterations; Indicates the first After the next iteration, the node The position vector; This represents the step size coefficient.

4. The automated subsystem configuration method for a cross-domain unified access platform according to claim 2, characterized in that, The configuration form generates form controls based on the fields of the platform-based configuration description object. Based on standardized service endpoints, the form controls include a host address input box, a port number input box, a protocol type drop-down box, and a basic path input box; Based on security policy requirements, the form control includes an authentication method selector, an encryption level slider, and a traffic limit input box.

5. The automated subsystem configuration method for a cross-domain unified access platform according to claim 4, characterized in that, The update of the platform-based configuration description object involves changes to fields. The calculation of the impact intensity of the changes includes: traversing the set of related fields affected by the changed fields, and calculating the cumulative impact score based on a preset dependency weight matrix; the impact intensity is expressed as: in, Representation field The intensity of the impact; Indicates the field The set of fields affected by the update; Representation field For fields Influence weight; This indicates the magnitude of change in field k; when the intensity of the impact exceeds a set threshold, the visualization interface issues an alert.

6. The automated subsystem configuration method for a cross-domain unified access platform according to claim 5, characterized in that, The strategy decision engine generates the final configuration scheme through strategy selection, parameter generation, and strategy assembly. The strategy selection process involves choosing a strategy template from the strategy library to match the subsystem to be integrated, as shown below: in, Representation Strategy Template Adaptability; This indicates the number of features of the subsystem; Indicates the first The importance weights of each feature; Representation of features With strategy templates The matching degree; select based on the adaptability of the strategy template; The parameter generation generates parameter values ​​for the selected policy template based on the security policy requirements; The strategy assembly integrates the selected strategy template and the generated parameter values ​​into a complete strategy document.

7. The automated subsystem configuration method for a cross-domain unified access platform according to claim 6, characterized in that, The declarative deployment manifest includes service objects, routing objects, and policy objects; The deployment executor submits the service object, routing object, and policy object to the API gateway in that order. Before submission, the declarative deployment manifest is subjected to syntax validation and logical conflict detection. The status verification report provides visual feedback to the user through the service topology map, including dynamically updating the color labels of nodes based on their health status.

8. An automated subsystem configuration system for a cross-domain unified access platform, characterized in that: The system includes: M1: Generation module, receives basic information from the subsystem to be connected, parses the basic information based on the predefined unified resource semantic model, and generates a platform-based configuration description object containing standardized service endpoints, security policy requirements and resource dependencies; M2: Visualization-driven module, which loads the platform-based configuration description object into the visualization configuration engine to display the service topology and configuration form; based on the user's modification operations on the configuration form in the visualization interface, it updates the platform-based configuration description object and further drives the strategy decision engine to form the final configuration scheme to be executed; M3: The automated execution module generates a declarative deployment list that can be recognized by the target API gateway according to the final configuration scheme, and drives the deployment executor to atomically submit the declarative deployment list to the API gateway, thereby automating the deployment configuration of the subsystem; at the same time, it obtains the health status of the subsystem in real time, generates a status verification report, and feeds it back to the visualization interface.

Images