Intelligent Service Discovery and Automated Integration System and Method Based on Microservice Architecture

Abstract

This invention provides an intelligent service discovery and automated integration system and method based on a microservice architecture, relating to enterprise-level software integration, distributed systems, and intelligent operation and maintenance technologies. The system includes: an infrastructure layer; a microservice runtime layer for running independent microservice instances; an intelligent scheduling and configuration layer for proactively discovering newly deployed microservice instances, parsing their interface metadata, and generating optimal configuration schemes based on the system operating environment; a global service registration layer for receiving and storing the optimal configuration schemes and microservice instance address information, and maintaining the dynamic topology and routing table of the entire network services in real time; and a business application gateway layer for monitoring routing table change events, routing external requests to the corresponding microservice instances, performing automated health probing before new instances are connected, and switching real business traffic to the microservice instance after the probing passes. This invention achieves a fully automated closed loop from service deployment to business availability.

Description

Technical Field

[0001] This invention relates to the fields of enterprise software integration, distributed systems, and intelligent operation and maintenance technology, and in particular to an intelligent service discovery and automated integration system and method based on microservice architecture. Background Technology

[0002] In today's era of rapid development in information technology and internet applications, the scale and complexity of enterprise applications and software systems are growing exponentially. To meet rapidly evolving business needs and a constantly changing market environment, internal enterprise systems require extremely frequent upgrades and refactoring. Simultaneously, enterprises are increasingly integrated with the external ecosystem, and systems typically need to integrate numerous internal sub-services as well as diverse third-party system services (such as third-party payment interfaces, logistics tracking services, and external data analytics platforms).

[0003] Traditional monolithic architectures and early service-oriented architectures (SOA) have gradually revealed serious limitations when faced with massive data, high concurrency requests, and the demands of agile development. These architectures often lead to high coupling between service modules, and any minor modification to a function can trigger a global system recompilation and downtime deployment. This not only makes independent expansion and scaling difficult but also significantly reduces the system's flexibility and maintainability.

[0004] Furthermore, in terms of system integration, especially for the integration of third-party system services, existing industry-standard solutions heavily rely on cumbersome manual configuration. Operations and maintenance personnel or developers need to manually obtain the interface documentation provided by the service provider, manually enter the service IP address, port number, and communication protocol in the system's API gateway or configuration center, and manually configure complex routing rules, load balancing strategies, timeout retry mechanisms, and security authentication information. This integration mechanism, heavily reliant on manual intervention, has many drawbacks: First, it significantly increases the complexity and time cost of system integration, leading to lengthy business deployment cycles; Second, when faced with frequent address changes or version updates of third-party services, manual configuration modifications are often delayed, easily causing service call interruptions; Third, due to the lack of automatic awareness of the current system context (such as network load, security level, and data flow), manual configuration is difficult to optimize, easily introducing human error or omissions, making it difficult to guarantee the accuracy of the service integration process and the overall system reliability.

[0005] Therefore, there is an urgent need in this field for a more flexible, intelligent and automated service architecture and integration mechanism to completely break the tight coupling between services and achieve "plug and play" and intelligent flow of services. Summary of the Invention

[0006] To address the shortcomings of the existing technologies, this invention proposes an intelligent service discovery and automated integration system and method based on microservice architecture, which is based on the automated configuration and scheduling of system architecture design and service integration. The aim is to solve the problems of high service integration coupling, cumbersome manual configuration, high time cost and low reliability in the existing technologies.

[0007] On the one hand, this invention proposes an intelligent service discovery and automated integration system based on a microservice architecture, the system comprising:

[0008] The infrastructure layer provides computing resources and a standardized microservice cluster container runtime environment.

[0009] The microservice runtime layer is deployed and runs on top of the infrastructure layer, and is used to run several independent microservice instances;

[0010] The intelligent scheduling and configuration layer is deployed and runs on top of the microservice runtime layer. It is used to proactively discover newly deployed microservice instances, parse the interface metadata of the microservice instance, and generate the optimal configuration scheme for the microservice instance based on the current system runtime environment.

[0011] The global service registration layer is connected to the intelligent scheduling and configuration layer and the microservice runtime layer, respectively. It is used to receive and store the optimal configuration scheme and the address information of each microservice instance, and maintain the dynamic topology and routing table between each microservice instance in real time.

[0012] The business application gateway layer communicates with the global service registration layer and the microservice runtime layer respectively. It is used to listen for changes in the routing table and route external requests to the corresponding microservice instance according to the changes. It performs automated health testing before the newly deployed microservice instance is connected, and switches real business traffic to the microservice instance after the testing is passed.

[0013] Furthermore, the infrastructure layer includes:

[0014] Multiple compute nodes are used to provide CPU, memory, and network resources for the operation of each microservice instance;

[0015] The container orchestration cluster, running on the multiple compute nodes, is used to manage the scheduling, dynamic scaling, and version update management of each microservice instance.

[0016] Furthermore, the microservice instance includes: a first type of instance and a second type of instance; wherein, the first type of instance is obtained by splitting each business application in the enterprise's internal business system into several microservices according to business boundaries, packaging each microservice with a standardized container and allocating independent running resources; the second type of instance is obtained by encapsulating the third-party system service to be connected to the enterprise's internal business system in a proxy container.

[0017] Furthermore, the intelligent scheduling and configuration layer includes:

[0018] The service probe detection module is used to deploy service probes on the network segment where each computing node is located. The service probes are used to discover newly deployed microservice instances running on each computing node and to confirm the activity status of the microservice instance through heartbeat detection. If the microservice instance is active, the interface metadata parser is triggered to intervene. If the microservice instance is inactive, the microservice instance is ignored and the processing flow is terminated.

[0019] An interface metadata parser, which communicates with the service probe detection module, is used to send requests to the standard health check interface or metadata interface exposed by the newly deployed microservice instance after confirming that the microservice instance is active, and automatically capture the interface metadata of the microservice instance. The captured interface metadata is abstracted into a service function signature; the service function signature is compared with the built-in business function feature library, and the business category that is successfully matched is used as the service feature of the microservice instance.

[0020] A context environment collector is used to collect the current system operating environment and generate the current context vector; wherein the system operating environment includes at least one of the following dimensions: operating environment dimension, network topology dimension, system load dimension, and security and compliance dimension; and the context vector is a structured data object containing information on at least one of the following dimensions: operating environment type, network topology status, system load indicators, and security and compliance requirements.

[0021] The intelligent decision-making and configuration recommendation engine is communicatively connected to the interface metadata parser and the context environment collector, respectively. It receives the service features and the context vector as input parameters, and uses a built-in rule engine or machine learning model to assign weights to various configuration combinations, and outputs one or more optimal configuration schemes suitable for the current context environment.

[0022] Furthermore, the interface metadata includes, but is not limited to: service name, version number, list of provided interfaces, input / output parameter formats, supported communication protocols, and authentication methods.

[0023] Furthermore, the specific method for abstracting the captured interface metadata into service function signatures, comparing them with the built-in business function feature library, and using the successfully matched business category as the service function feature of the microservice instance is as follows:

[0024] Extract the service name and interface list from the captured interface metadata, and convert the extracted service name and interface list into a unique identifier that represents the service characteristics of the microservice instance according to preset rules, which serves as the service function signature of the microservice instance.

[0025] The service function signature is compared with the built-in business function feature library; the business function feature library pre-stores several service function signatures and business category tags corresponding to each service function signature;

[0026] If the comparison is successful, the business category label corresponding to the service function signature is output and used as the service feature of the microservice instance; if the comparison fails, the microservice instance is marked as an unknown business category and a manual confirmation process is triggered.

[0027] Furthermore, the operating environment dimension includes: development environment, testing and debugging environment, or production environment;

[0028] The network topology dimension includes: the physical node where the newly deployed microservice instance is located, the subnet area, and the network latency and bandwidth status with the caller;

[0029] The system load dimension includes: the traffic saturation of the current business application gateway layer and the connection pool utilization rate of the backend database; wherein the backend database is independent of the intelligent service discovery and automated integration system and serves as the data storage resource for microservice instances;

[0030] The security and compliance dimensions include: the security encryption level, data anonymization rules, and access control policies required by the business line to which the currently running microservice instance belongs.

[0031] Furthermore, the specific method for receiving the service features and the context vector as input parameters, weighting and scoring multiple configuration combinations through a built-in rule engine or machine learning model, and outputting one or more optimal configuration schemes suitable for the current context environment is as follows:

[0032] Obtain the service features identified by the interface metadata parser and the context vector generated by the context environment collector;

[0033] Based on the service characteristics, candidate configuration items related to the service characteristics are extracted from a preset configuration item library, and multiple candidate configuration combinations are generated;

[0034] The configuration item library stores candidate configuration items corresponding to various service characteristics and their optional values. These candidate configuration items include, but are not limited to: load balancing strategies, timeout settings, circuit breaker degradation mechanisms, log tracing strategies, and long timeouts. Optional values ​​for load balancing strategies include, but are not limited to: round-robin, weighted, or minimum connection count. The optional values ​​for timeout settings are set according to the current operating environment. Optional values ​​for circuit breaker degradation mechanisms include: enabled or disabled. Optional values ​​for log tracing strategies include: enabled or disabled. The optional values ​​for long timeouts are set as a multiple of a preset standard timeout. Long timeouts are enabled in the test environment but disabled in the production environment.

[0035] The service features and the context vector are input into the built-in rule engine or a pre-trained machine learning model to assign weights to the multiple candidate configuration combinations.

[0036] Based on the weighted scoring results, select one or more candidate configuration combinations with the highest scores as the optimal configuration scheme suitable for the current context.

[0037] On the other hand, this invention proposes an intelligent service discovery and automated integration method based on a microservice architecture, which includes the following process:

[0038] Based on the microservice transformation and independent deployment mechanism, various business applications in the enterprise's internal business system or third-party system services that need to be connected to the enterprise's internal business system are encapsulated into microservices to obtain several microservice instances.

[0039] From all the obtained microservice instances, proactively discover newly deployed microservice instances, parse the interface metadata of the microservice instance, and identify the service characteristics of the microservice instance based on the parsing results;

[0040] Collect the current system operating environment, generate a context vector, and generate the optimal configuration scheme for the microservice instance based on the service characteristics and the context vector;

[0041] Obtain the address information of the microservice instance, and update the dynamic topology and routing table between all microservice instances in conjunction with the optimal configuration scheme;

[0042] During the update process, when a change event is detected in the routing table, external requests are routed to the corresponding microservice instance based on the change event.

[0043] Perform automated health checks before connecting to the newly deployed microservice instance, and then switch real business traffic to the microservice instance after the checks pass.

[0044] Furthermore, the specific method for encapsulating various business applications in the enterprise's internal business system or third-party system services to be integrated into the enterprise's internal business system into several microservice instances based on the microservice transformation and independent deployment mechanism is as follows:

[0045] For internal business systems, each business application in the internal business system is split into several microservices according to business boundaries, and packaged using standardized container technology to form several first-type microservice instances, and each first-type microservice instance is allocated independent running resources.

[0046] For third-party system services that need to be integrated into the enterprise's internal business system, the third-party system services are encapsulated in an independent proxy container to form a second type of microservice instance, and independent running resources are allocated to each second type of microservice instance.

[0047] Using the built-in performance monitoring component, when the network request QPS of any microservice instance exceeds the preset scaling threshold, the number of instances of that microservice instance is automatically increased; when the network request QPS is lower than the preset scaling threshold, the number of instances of that microservice instance is automatically reduced.

[0048] For microservice instances that require version updates, blue-green deployment or canary deployment is used for version updates. Blue-green deployment uses a one-time full switch to switch traffic from the old version to the new version. Canary deployment uses a proportional incremental switch to switch traffic from the old version to the new version.

[0049] The beneficial effects of adopting the above technical solution are as follows:

[0050] (1) Greatly improves the flexibility and maintainability of the system: The present invention adopts a thorough microservice architecture mechanism, which breaks down the large and complex monolithic application system into multiple fine-grained microservice units with single responsibilities, so that each service (including internal services and external access services) runs in an independent container or process and has an independent life cycle. The independent deployment, scaling and updating of each microservice unit do not interfere with each other, effectively breaking the tight coupling limitation of the traditional architecture, enabling the system of the present invention to cope with local traffic surges or rapid iteration of specific businesses.

[0051] (2) Significantly reduces the complexity and time cost of system integration: The method and system of this invention achieve "self-discovery and self-configuration" after service deployment through innovative intelligent service discovery and automated integration mechanisms. Specifically, for third-party system services, this invention introduces a context-aware intelligent discovery and self-configuration network. Once each microservice unit is deployed or connected to the network, the probe built into the system of this invention can automatically detect and identify its functional characteristics and interface metadata, and then automatically capture interface metadata and generate integration strategies, eliminating the complicated manual steps such as interface debugging and route entry, shortening the manual integration work that originally required several days to minutes, and greatly improving the efficiency of R&D and operation and maintenance.

[0052] (3) Comprehensive improvement in the accuracy and reliability of service integration: The system of this invention can automatically identify service functions from a global perspective and analyze them based on real-time context (including but not limited to network topology, resource load, security policies, and business dependencies, such as differences between test and production environments, and rate limiting requirements under high concurrency). It intelligently recommends the most reasonable configuration strategy and automatically completes the registration and business integration process of services in the global registry center. This automated registration and integration realizes a fully automated closed loop from service launch to business availability, eliminating the hidden dangers caused by manual copying and pasting or misunderstanding, and ensuring smooth network communication and the overall stability of system operation. Attached Figure Description

[0053] Figure 1 This is the overall architecture diagram of the intelligent service discovery and automated integration system based on microservice architecture in this embodiment;

[0054] Figure 2 This is a flowchart of the intelligent service discovery and automated integration method based on microservice architecture in this embodiment. Detailed Implementation

[0055] To facilitate understanding of this application, specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and embodiments. The following embodiments are used to illustrate the present invention, but are not intended to limit the scope of the invention. Rather, these embodiments are provided to enable a more thorough and comprehensive understanding of the disclosure of this application. It should be noted that the various modules, engines, and network architectures described in this embodiment can all be implemented using existing computer hardware and software technologies combined with the innovative logic described in this invention.

[0056] Example 1:

[0057] This embodiment presents an intelligent service discovery and automated integration system based on a microservice architecture, such as... Figure 1 As shown, the system includes:

[0058] The infrastructure layer provides computing resources and a standardized microservice cluster container runtime environment.

[0059] In this embodiment, the overall architecture of the intelligent service discovery and automated integration system can be divided from bottom to top into: an infrastructure layer, a microservice runtime layer, an intelligent scheduling and configuration layer, a global service registration layer, and a business application gateway layer. The system's underlying layer relies on standardized microservice cluster containers (such as Kubernetes or Docker Swarm clusters), and all internal business services and third-party access services run as independent microservice instances on various computing nodes.

[0060] The infrastructure layer includes:

[0061] Multiple compute nodes are used to provide CPU, memory, and network resources for the operation of each microservice instance.

[0062] The container orchestration cluster, running on the multiple compute nodes, is used to manage the scheduling, dynamic scaling, and version update management of each microservice instance.

[0063] The microservice runtime layer is deployed and runs on top of the infrastructure layer, and is used to run several independent microservice instances.

[0064] The microservice instances include: a first type of instance and a second type of instance; wherein, the first type of instance is obtained by splitting each business application in the enterprise's internal business system into several microservices according to business boundaries, packaging each microservice in a standardized container and allocating independent running resources; the second type of instance is obtained by encapsulating the third-party system services to be connected to the enterprise's internal business system in a proxy container.

[0065] For internal business systems of an enterprise, the system often contains complex business logic. For example, for an order fulfillment platform (monolithic application system) run by an e-commerce company, all functions are packaged in a large system, including: user management, product management, order management, payment processing, logistics tracking and notification push services. In actual application, if you want to modify the configuration of any module or call external data analysis, the entire system must be redeployed, which wastes resources.

[0066] To address the aforementioned issues, this embodiment utilizes a microservices architecture to decompose and containerize internal business systems. Specifically, based on the principle that "each service is responsible for a single business domain," complex business logic is broken down into multiple fine-grained services (i.e., microservices) according to business boundaries, such as user services, product services, order services, payment services, logistics services, and notification services. Each service is packaged using standardized container technology and allocated independent runtime resources (CPU, memory, and network space), resulting in several microservice instances.

[0067] For any third-party system service that needs to access the enterprise's internal business systems, to ensure that external code does not directly pollute the runtime memory of the enterprise's internal business systems, this embodiment encapsulates the third-party system service in a specific proxy container (Sidecar). This proxy container is then connected to the network of the enterprise's internal business systems. For example, to obtain information such as express tracking numbers and logistics trajectories, the enterprise's internal business systems need to access a third-party logistics API. Therefore, in this embodiment, all communication configurations of the logistics API are encapsulated in a Sidecar proxy container. When the order service needs to query logistics information, it only needs to send a request to the local Sidecar proxy container, which then handles the call and response encapsulation to the external logistics API. When the third-party logistics API is upgraded or changed, only the Sidecar proxy container needs to be updated; there is no need to modify the order service or other business code.

[0068] In this embodiment, the intelligent scheduling and configuration layer is the core of the invention. The intelligent scheduling and configuration layer is deployed and runs on top of the microservice runtime layer. It is used to actively discover newly deployed microservice instances, parse the interface metadata of the microservice instance, and generate the optimal configuration scheme for the microservice instance based on the current system operating environment.

[0069] The intelligent scheduling and configuration layer includes:

[0070] The service probe detection module is used to deploy service probes on the network segment where each computing node is located. The service probes are used to discover newly deployed microservice instances running on each computing node and to confirm the activity status of the microservice instance through heartbeat detection. If the microservice instance is active, the interface metadata parser is triggered to intervene. If the microservice instance is inactive, the microservice instance is ignored and the processing flow is terminated.

[0071] In this embodiment, for newly deployed internal services or newly integrated third-party system services, a service self-discovery and automatic identification method based on probe technology is adopted. This means the system initiates a proactive self-discovery and detection mechanism, completely replacing manual registration. The specific process is as follows: When a newly deployed microservice instance starts up and is assigned an IP address in the network segment, the service probes deployed in each network segment immediately capture this network event. Subsequently, the service probes initiate heartbeat detection to the newly deployed microservice instance via lightweight UDP multicast or TCP handshake to confirm its active state.

[0072] The interface metadata parser, which communicates with the service probe detection module, is used to send requests to the standard health check interface or metadata interface exposed by the newly deployed microservice instance after confirming that the microservice instance is active, and automatically capture the interface metadata of the microservice instance. The captured interface metadata is abstracted into a service function signature. The service function signature is compared with the built-in business function feature library, and the business category that is successfully matched is used as the service feature of the microservice instance.

[0073] The interface metadata includes, but is not limited to: service name, version number, list of provided interfaces, input and output parameter formats, supported communication protocols, and authentication methods.

[0074] The specific method for abstracting the captured interface metadata into a service function signature, comparing it with the built-in business function feature library, and using the successfully matched business category as the service function feature of the microservice instance is as follows:

[0075] Extract the service name and interface list from the captured interface metadata, and convert the extracted service name and interface list into a unique identifier that represents the service characteristics of the microservice instance according to preset rules, which serves as the service function signature of the microservice instance.

[0076] The service function signature is compared with the built-in business function feature library; the business function feature library pre-stores several service function signatures and business category tags corresponding to each service function signature.

[0077] If the comparison is successful, the business category label corresponding to the service function signature is output and used as the service feature of the microservice instance; if the comparison fails, the microservice instance is marked as an unknown business category and a manual confirmation process is triggered.

[0078] In this embodiment, after confirming activity, the "interface metadata parser" intervenes to capture and parse the interface metadata. Specifically, the system sends a request to the standard health check or metadata interface (e.g., / actuator / info or Swagger API docs endpoint) exposed by the newly deployed microservice instance to automatically capture the interface metadata of the microservice instance. The captured interface metadata includes, but is not limited to: service name, version number, list of provided Restful / gRPC interfaces, input / output parameter formats (JSON / XML and specific field definitions), supported communication protocols, and authentication methods. Subsequently, the system abstracts the captured interface metadata into service function signatures (in this embodiment, the service function signature is obtained by extracting strings or calculating hash values), and compares them with the system's built-in business function feature library. The business function feature library pre-stores multiple sets of service function signatures and their corresponding business category tags. For example, the service function signature corresponding to the "payment gateway" business category may contain interface paths such as / pay, / refund, and / callback in its interface list; the service function signature corresponding to the "notification push" business category may contain interface paths such as / send, / sms, and / email in its interface list; and the service function signature corresponding to the "data storage" business category may contain interface paths such as / query, / insert, / update, and / delete in its interface list. In this way, the system can automatically identify whether the service belongs to the business category of "payment gateway," "notification push," or "data storage," thus completing the accurate definition of the service function.

[0079] A context environment collector is used to collect the current system operating environment and generate the current context vector; wherein the system operating environment includes at least one of the following dimensions: operating environment dimension, network topology dimension, system load dimension, and security and compliance dimension; and the context vector is a structured data object containing information on at least one of the following dimensions: operating environment type, network topology status, system load indicators, and security and compliance requirements.

[0080] The operating environment dimension includes: development environment, testing and debugging environment, or production environment.

[0081] The network topology dimension includes: the physical node where the newly deployed microservice instance is located, the subnet area, and the network latency and bandwidth status with the caller.

[0082] The system load dimension includes: the traffic saturation of the current business application gateway layer and the connection pool utilization rate of the backend database; wherein the backend database is independent of the intelligent service discovery and automated integration system and serves as the data storage resource for microservice instances.

[0083] The security and compliance dimensions include: the security encryption level, data anonymization rules, and access control policies required by the business line to which the currently running microservice instance belongs.

[0084] In this embodiment, the context environment collector summarizes the status data of the current main system, namely the intelligent service discovery and automation integration system, in real time. These data constitute a multi-dimensional context vector, specifically including: (1) runtime environment dimension: whether it is currently a development environment, a test and debugging environment, or a production environment; (2) network topology dimension: the physical node where the new service is located, the subnet area, and the network latency and bandwidth status between it and the caller; (3) system load dimension: the traffic saturation of the current global API gateway (i.e., the business application gateway layer) and the connection pool utilization rate of the backend database; (4) security and compliance dimension: the security encryption level required by the business line (such as TLS version requirements), data anonymization rules, and access control policies (Role-Based Access Control, RBAC).

[0085] The intelligent decision-making and configuration recommendation engine is communicatively connected to the interface metadata parser and the context environment collector, respectively. It receives the service features and the context vector as input parameters, and uses a built-in rule engine or machine learning model to assign weights to various configuration combinations, and outputs one or more optimal configuration schemes suitable for the current context environment.

[0086] The specific method for receiving the service features and the context vector as input parameters, weighting and scoring multiple configuration combinations through a built-in rule engine or machine learning model, and outputting one or more optimal configuration schemes suitable for the current context environment is as follows:

[0087] Obtain the service features identified by the interface metadata parser and the context vector generated by the context environment collector.

[0088] Based on the service characteristics, candidate configuration items related to the service characteristics are extracted from a preset configuration item library, and multiple candidate configuration combinations are generated.

[0089] The configuration item library stores candidate configuration items corresponding to various service characteristics and the optional values ​​of each candidate configuration item; wherein, the candidate configuration items include, but are not limited to: load balancing strategy, timeout setting, circuit breaker degradation mechanism, log tracking strategy, and long timeout.

[0090] In this embodiment, the system activates its built-in intelligent decision-making and configuration recommendation engine. This engine receives identified service features and context vectors as input parameters. Based on the service features, it extracts candidate configuration items related to those service features from a preset configuration item library and generates multiple candidate configuration combinations. In this embodiment, the configuration item library stores candidate configuration items corresponding to various service features and their optional values, including but not limited to: load balancing strategies (such as aggressive or conservative), timeout settings (100ms, 500ms, 1000ms, etc.), circuit breaker degradation mechanisms (on / off), and log tracking strategies (on / off). The optional value for the timeout setting is set according to the operating environment type: a preset value within the range of 100ms to 1000ms in a production environment, and a preset value within the range of 1000ms to 10000ms in a test environment. The optional value for a long timeout is set according to a multiple of the preset standard timeout. Long timeouts are enabled in the test environment but not in the production environment.

[0091] It should be noted that in this embodiment, the aggressive load balancing strategy is defined as follows: with the goal of minimizing response time, requests are preferentially distributed to the microservice instance with the fewest current connections, and no maximum connection limit is set; the conservative load balancing strategy is defined as follows: with the goal of maximizing system stability, a maximum connection limit is set for a single service instance, and no new requests are distributed to it after the limit is exceeded.

[0092] The service features and the context vector are input into the built-in rule engine or a pre-trained machine learning model to assign weights to the multiple candidate configuration combinations.

[0093] Furthermore, through a built-in rule engine (or a trained machine learning model), the engine assigns weights to various possible candidate configuration combinations. In this embodiment, the rule engine is implemented using a rule engine based on the RETE algorithm (such as Drools). This engine has a series of predefined decision rules built-in, each consisting of a condition part and a conclusion part. The condition part is used to determine whether the input service features and context vector meet specific conditions. For example, the condition part of a rule can be described as: if the service features indicate that the microservice instance belongs to the payment gateway category, and the runtime environment dimension in the context vector is the production environment, and the gateway traffic saturation in the system load dimension exceeds 80%, then the rule is triggered. The conclusion part is used to assign weights to the candidate configuration combinations corresponding to the rule. For example, after the above rule is triggered, the engine will increase the weight score of the candidate configuration combination of "aggressive load balancing strategy", increase the weight score of "short timeout setting", and increase the weight score of "enabling circuit breaker degradation mechanism", the added weight score values ​​of which are defined by the user. The rule engine has dozens of similar rules pre-defined, covering different service categories, runtime environments, load conditions, and security requirements. When a candidate configuration combination is recommended by multiple rules simultaneously, its weight scores are accumulated; conversely, if some rules recommend the opposite configuration, corresponding points are deducted. Ultimately, the rule engine calculates a comprehensive weight score for all candidate configuration combinations; a higher score indicates that the configuration combination is more suitable for the current context. In this embodiment, the machine learning model is implemented using a gradient boosting decision tree (e.g., XGBoost or LightGBM). This model is trained offline, with the current service features and context vectors input into the trained model. The model outputs an applicability prediction score for each candidate configuration combination. This score is the weight score for that candidate configuration combination.

[0094] Based on the weighted scoring results, select one or more candidate configuration combinations with the highest scores as the optimal configuration scheme suitable for the current context.

[0095] In this embodiment, one or more optimal configuration schemes best suited to the current context are obtained through the built-in rule engine or pre-trained machine learning models. Taking third-party payment service access as an example, if the system is in a high-concurrency production environment, the engine will automatically recommend the following configurations: an aggressive load balancing strategy, a shorter timeout setting (e.g., 500ms), and enabling circuit breaker degradation mechanisms (e.g., Hystrix). If in a test environment, it may recommend enabling full-link log tracing and a longer timeout. These configuration strategies are all automatically generated by the system, eliminating the need for manual review.

[0096] The global service registration layer communicates with both the intelligent decision-making and configuration recommendation engine and the microservice runtime layer. It receives and stores the optimal configuration scheme and the address information of each microservice instance, and maintains the dynamic topology and routing table between each microservice instance in real time.

[0097] In this embodiment, after determining the optimal intelligent recommendation configuration parameters, the system executes the final automated integration loop, enabling the new service to be truly integrated into business operations. During the automated integration loop, the global service registration layer is responsible for maintaining the dynamic topology and routing table of all network services. The dynamic topology represents the call relationships between microservice instances, and the routing table stores the mapping relationship between storage service names and specific microservice instance addresses. When a new microservice instance is registered or an existing instance goes offline, the global service registration layer updates the dynamic topology and routing table in real time and pushes the change event to the business application gateway layer to achieve dynamic route refresh. In this embodiment, for newly deployed microservice instances, the automated integration module writes and persists the microservice instance's IP address, port, interface list, and configuration information including routing rules, rate limiting policies, and retry mechanisms from the optimal configuration scheme to a globally distributed service registry (such as Nacos or Consul). The service registry maintains the dynamic topology and routing tables among the microservice instances. This dynamic topology and routing tables are then synchronized to the API gateway (i.e., the business application gateway layer) and the unified configuration center for the microservice instances to retrieve. It should be noted that the unified configuration center is an independent component used to manage microservice configuration information (such as database connection strings and business parameters). In Nacos, it provides both service registration and discovery and configuration management functions; therefore, "synchronizing to the unified configuration center" refers to synchronizing the configuration information to Nacos's configuration management module.

[0098] The business application gateway layer communicates with the global service registration layer and the microservice runtime layer respectively. It is used to listen for changes in the routing table and route external requests to the corresponding microservice instance according to the changes. It performs automated health testing before the newly deployed microservice instance is connected, and switches real business traffic to the microservice instance after the testing is passed.

[0099] In this embodiment, after the API gateway (i.e., the business application gateway layer) detects a change event in the service registry, it dynamically refreshes the routing table in memory without restarting, directing external or internal network requests of a specific format to the newly deployed microservice instance. Simultaneously, the system automatically establishes a bidirectional encrypted communication link (mTLS) between the new service and existing dependent services at the underlying layer using service mesh technology. Before real business traffic is imported, the system automatically generates simulated business request packets to perform an automated health check on the newly deployed microservice instance. If the check results meet expectations (e.g., returning the correct HTTP status code and data format), the system officially grants business permissions and smoothly switches real business traffic to the service according to the load balancing strategy. Thus, the entire process from service deployment to business integration is automated by the system.

[0100] Example 2:

[0101] This embodiment presents an intelligent service discovery and automated integration method based on a microservice architecture, such as... Figure 2 As shown, the process and steps of implementing this invention will be described in detail from both microscopic and macroscopic perspectives. The method includes the following steps:

[0102] Based on the microservice transformation and independent deployment mechanism, various business applications in the enterprise's internal business system or third-party system services that need to be connected to the enterprise's internal business system are encapsulated into microservices to obtain several microservice instances.

[0103] The specific method for encapsulating various business applications in the enterprise's internal business system or third-party system services to be integrated into the enterprise's internal business system into microservices, based on the microservice transformation and independent deployment mechanism, to obtain several microservice instances is as follows:

[0104] For internal business systems, each business application within the system is split into several microservices according to business boundaries, and packaged using standardized container technology to form several first-type microservice instances, with each first-type microservice instance allocated independent runtime resources.

[0105] For third-party system services that need to be integrated into the enterprise's internal business systems, the third-party system services are encapsulated in an independent proxy container to form a second type of microservice instance, and independent running resources are allocated to each second type of microservice instance.

[0106] Using the built-in performance monitoring component, when the network request QPS of any microservice instance exceeds the preset scaling threshold, the number of instances of that microservice instance is automatically increased; when the network request QPS is lower than the preset scaling threshold, the number of instances of that microservice instance is automatically reduced.

[0107] For microservice instances requiring version updates, blue-green deployment or canary deployment is used. Blue-green deployment uses a one-time full switch to migrate traffic from the old version to the new version; canary deployment uses a proportional, incremental switch to migrate traffic from the old version to the new version.

[0108] In this embodiment, based on microservice transformation and independent deployment mechanisms, existing business modules or upcoming third-party system services within the enterprise's internal business systems are encapsulated into microservices. Complex business logic is broken down into multiple fine-grained services according to business boundaries, with each service responsible for a single business domain, and packaged using standardized container technology. Independent runtime resources (CPU, memory, and network space) are allocated to each microservice instance. Third-party system services are encapsulated in specific proxy containers (Sidecars) to access the system network described in Embodiment 1, ensuring that external code does not directly pollute the runtime memory of the internal main system. Utilizing a built-in performance monitoring component, when the network request QPS (queries per second) of a certain microservice instance (e.g., order processing service or third-party SMS sending service) exceeds a preset scaling threshold, the number of instances of that service is automatically horizontally scaled up in the cluster; when it falls below a preset scaling-down threshold, i.e., a request trough, it is automatically scaled down. Simultaneously, blue-green deployment and canary releases are supported to ensure a smooth transition when services are updated, without interrupting business operations. Specifically, when updating a microservice instance, both the new and old versions of the microservice instance are run simultaneously. Once the new version microservice instance passes a health check, business traffic is switched from the old version microservice instance to the new version microservice instance all at once. Alternatively, a certain percentage of the total business traffic is first allocated to the new version microservice instance. After confirming that the new version microservice instance is running normally, the proportion of business traffic allocated to the new version microservice instance is gradually increased until all traffic is switched to the new version microservice instance.

[0109] From all the obtained microservice instances, actively discover newly deployed microservice instances, parse the interface metadata of the microservice instance, and identify the service characteristics of the microservice instance based on the parsing results.

[0110] In this embodiment, for newly deployed internal services or newly integrated third-party system services, a service self-discovery and automatic identification method based on probe technology is adopted to completely replace manual registration. The specific process is as follows: When a newly deployed microservice instance starts up and is assigned an IP address in the network segment, the service probes deployed in each network segment will immediately capture the network event. The probes initiate a heartbeat probe to the microservice instance through lightweight UDP multicast or TCP handshake to confirm that it is active. After confirming its activity, a request is sent to the standard health check or metadata interface exposed by the microservice instance (such as the / actuator / info or Swagger API docs endpoint) to automatically capture the interface metadata of the microservice instance. By abstracting the captured interface metadata into a service function signature and comparing it with the built-in business function feature library, the business category to which the microservice instance belongs is automatically identified, thus completing the accurate definition of the service function.

[0111] Collect the current system operating environment, generate a context vector, and generate the optimal configuration scheme for the microservice instance based on the service characteristics and the context vector.

[0112] In this embodiment, after successfully identifying the service functions and interface characteristics, the system does not simply connect them directly, but enters a deep context environment awareness and intelligent configuration stage. This is a key step in reducing manual intervention and improving integration accuracy. By summarizing the current status data of the main system in real time, a multi-dimensional context vector is constructed, specifically including: runtime environment dimension, network topology dimension, system load dimension, and security and compliance dimension. Then, based on the identified service characteristics and context vector as input parameters, the built-in rule engine (or a trained machine learning model) assigns weights to various possible configuration combinations, ultimately outputting one or more configuration schemes most suitable for the current context environment.

[0113] Obtain the address information of the microservice instance, and update the dynamic topology and routing table between all microservice instances in conjunction with the optimal configuration scheme.

[0114] In this embodiment, after determining the optimal intelligent recommendation configuration parameters, a closed-loop, end-to-end automated registration, verification, and business integration are executed, enabling the newly deployed microservice instance to truly engage in business processes. The address information of the microservice instance, including its IP address, port, and interface list, as well as the routing rules, rate limiting policies, retry mechanisms, and other configuration information included in the optimal configuration scheme, are uniformly written to and persisted to a globally distributed service registry (such as Nacos or Consul), and synchronized to the API gateway and unified configuration center.

[0115] During the update process, when a change event is detected in the routing table, external requests are routed to the corresponding microservice instance based on the change event.

[0116] In this embodiment, the API gateway listens for change events in the registry center and, without restarting, dynamically refreshes the routing table in memory, directing external or internal network requests of a specific format to the new service. Simultaneously, through Service Mesh technology, it automatically establishes a bidirectional encrypted communication link (mTLS) between the new service and existing dependent services at the underlying layer.

[0117] Perform automated health checks before connecting to the newly deployed microservice instance, and then switch real business traffic to the microservice instance after the checks pass.

[0118] The specific method for performing automated health probing before connecting to the newly deployed microservice instance, and then switching real business traffic to the microservice instance after the probing passes, is as follows:

[0119] Before real business traffic is imported, one or more simulated business request packages are automatically generated based on the captured interface metadata. The simulated request packages are used to perform automated health probing to verify the readiness status of the newly deployed microservice instance.

[0120] Send the generated simulated business request packet to the newly deployed microservice instance and verify whether the response returned by the microservice instance meets expectations.

[0121] If the expected results are met, the microservice instance is determined to be ready, and real business traffic is routed to the microservice instance according to the load balancing strategy.

[0122] If the expected behavior is not met, the system will block the entry of real business traffic and trigger an alarm or retry mechanism.

[0123] In this embodiment, before importing real business traffic, the system automatically generates simulated business request packets to perform an automated health check on the new service. If the check result, i.e., the response returned by the microservice instance, meets expectations, such as returning the correct HTTP status code and data format, the system officially grants business permissions and smoothly switches the real business traffic to the service according to the load balancing strategy. Thus, the entire process from service deployment to business integration is completed automatically by the system.

[0124] In summary, this embodiment proposes an intelligent service discovery and automated integration method based on a microservice architecture. By deeply integrating microservice transformation, probe self-detection, context-aware analysis, and dynamic registration technology, it achieves a highly adaptive integrated network. This method significantly reduces system development and maintenance costs while endowing enterprise-level systems with powerful self-evolution and self-configuration capabilities under complex network environments and changing business requirements.

[0125] Example 3:

[0126] This embodiment proposes an electronic device, including: one or more processors, and a memory, wherein the memory is used to store instructions, and when the instructions are executed by the one or more processors, the one or more processors execute the intelligent service discovery and automated integration method based on microservice architecture.

[0127] The electronic device may be a mobile phone, computer, or tablet computer, etc., and includes a memory and a processor. The memory stores a computer program, which, when executed by the processor, implements the intelligent service discovery and automated integration method based on a microservice architecture as described in the embodiments. It is understood that the electronic device may also include input / output (I / O) interfaces and communication components.

[0128] The processor is used to execute all or part of the steps in the intelligent service discovery and automated integration method based on a microservice architecture as described in the above embodiments. The memory is used to store various types of data, which may include, for example, instructions for any application or method in the electronic device, as well as application-related data.

[0129] The processor can be implemented as an Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), controller, microcontroller, microprocessor, or other electronic components, and is used to execute the intelligent service discovery and automated integration method based on microservice architecture described in the above embodiments.

[0130] Example 4:

[0131] This embodiment proposes a computer-readable storage medium that stores executable instructions. When these instructions are executed, if they are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium.

[0132] The computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the intelligent service discovery and automated integration method based on microservice architecture described in the various embodiments of this application.

[0133] The aforementioned storage media include: flash memory, hard disks, multimedia cards, card-type memory (e.g., SD (Secure Digital Memory Card) or DX (Memory Data Register, MDR) memory), random access memory (RAM), static random-access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic storage, disks, optical discs, servers, APP (Application) application stores, and other media capable of storing program verification codes. These media store computer programs, which, when executed by a processor, can implement the various steps of the aforementioned intelligent service discovery and automated integration method based on a microservice architecture.

[0134] Example 5:

[0135] This embodiment proposes a computer program product, including a computer program or instructions, which, when executed by a processor, implements the aforementioned intelligent service discovery and automated integration method based on a microservice architecture.

[0136] Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a computer program product.

[0137] The various embodiments in this application are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0138] The scope of protection of this application is not limited to the embodiments described above. Obviously, those skilled in the art can make various modifications and variations to this disclosure without departing from the scope and spirit of this disclosure. If such modifications and variations fall within the scope of this disclosure and its equivalents, then the intent of this disclosure also includes these modifications and variations.

Claims

1. A microservice-based intelligent service discovery and automated integration system, characterized in that, The system includes: The infrastructure layer provides computing resources and a standardized microservice cluster container runtime environment. The microservice runtime layer is deployed and runs on top of the infrastructure layer, and is used to run several independent microservice instances; The intelligent scheduling and configuration layer is deployed and runs on top of the microservice runtime layer. It is used to proactively discover newly deployed microservice instances, parse the interface metadata of the microservice instance, and generate the optimal configuration scheme for the microservice instance based on the current system runtime environment. The global service registration layer is connected to the intelligent scheduling and configuration layer and the microservice runtime layer, respectively. It is used to receive and store the optimal configuration scheme and the address information of each microservice instance, and maintain the dynamic topology and routing table between each microservice instance in real time. The business application gateway layer communicates with the global service registration layer and the microservice runtime layer respectively. It is used to listen for changes in the routing table and route external requests to the corresponding microservice instance according to the changes. It performs automated health testing before the newly deployed microservice instance is connected, and switches real business traffic to the microservice instance after the testing is passed.

2. The intelligent service discovery and automated integration system based on microservice architecture according to claim 1, characterized in that, The infrastructure layer includes: Multiple compute nodes are used to provide CPU, memory, and network resources for the operation of each microservice instance; The container orchestration cluster, running on the multiple compute nodes, is used to manage the scheduling, dynamic scaling, and version update management of each microservice instance.

3. The intelligent service discovery and automated integration system based on microservice architecture according to claim 2, characterized in that, The microservice instances include: a first type of instance and a second type of instance; wherein, the first type of instance is obtained by splitting each business application in the enterprise's internal business system into several microservices according to business boundaries, packaging each microservice in a standardized container and allocating independent running resources; the second type of instance is obtained by encapsulating the third-party system services to be connected to the enterprise's internal business system in a proxy container.

4. The intelligent service discovery and automated integration system based on microservice architecture according to claim 3, characterized in that, The intelligent scheduling and configuration layer includes: The service probe detection module is used to deploy service probes on the network segment where each computing node is located. The service probes are used to discover newly deployed microservice instances running on each computing node and to confirm the activity status of the microservice instance through heartbeat detection. If the microservice instance is active, the interface metadata parser is triggered to intervene. If the microservice instance is inactive, the microservice instance is ignored and the processing flow is terminated. An interface metadata parser, which communicates with the service probe detection module, is used to send requests to the standard health check interface or metadata interface exposed by the newly deployed microservice instance after confirming that the microservice instance is active, and automatically capture the interface metadata of the microservice instance. The captured interface metadata is abstracted into a service function signature; the service function signature is compared with the built-in business function feature library, and the business category that is successfully matched is used as the service feature of the microservice instance. A context environment collector is used to collect the current system operating environment and generate the current context vector; wherein the system operating environment includes at least one of the following dimensions: operating environment dimension, network topology dimension, system load dimension, and security and compliance dimension; and the context vector is a structured data object containing information on at least one of the following dimensions: operating environment type, network topology status, system load indicators, and security and compliance requirements. The intelligent decision-making and configuration recommendation engine is communicatively connected to the interface metadata parser and the context environment collector, respectively. It receives the service features and the context vector as input parameters, and uses a built-in rule engine or machine learning model to assign weights to various configuration combinations, and outputs one or more optimal configuration schemes suitable for the current context environment.

5. The intelligent service discovery and automated integration system based on microservice architecture according to claim 4, characterized in that, The interface metadata includes, but is not limited to: service name, version number, list of provided interfaces, input and output parameter formats, supported communication protocols, and authentication methods.

6. The intelligent service discovery and automated integration system based on microservice architecture according to claim 5, characterized in that, The specific method for abstracting the captured interface metadata into a service function signature, comparing it with the built-in business function feature library, and using the successfully matched business category as the service function feature of the microservice instance is as follows: Extract the service name and interface list from the captured interface metadata, and convert the extracted service name and interface list into a unique identifier that represents the service characteristics of the microservice instance according to preset rules, which serves as the service function signature of the microservice instance. The service function signature is compared with the built-in business function feature library; the business function feature library pre-stores several service function signatures and business category tags corresponding to each service function signature; If the comparison is successful, the business category tag corresponding to the service function signature will be output and used as the service feature of the microservice instance. If the comparison fails, the microservice instance is marked as an unknown business category and a manual confirmation process is triggered.

7. The intelligent service discovery and automated integration system based on microservice architecture according to claim 6, characterized in that, The operating environment dimension includes: development environment, testing and debugging environment, or production environment; The network topology dimension includes: the physical node where the newly deployed microservice instance is located, the subnet area, and the network latency and bandwidth status with the caller; The system load dimension includes: the traffic saturation of the current business application gateway layer and the connection pool utilization rate of the backend database; wherein the backend database is independent of the intelligent service discovery and automated integration system and serves as the data storage resource for microservice instances; The security and compliance dimensions include: the security encryption level, data anonymization rules, and access control policies required by the business line to which the currently running microservice instance belongs.

8. The intelligent service discovery and automated integration system based on microservice architecture according to claim 7, characterized in that, The specific method for receiving the service features and the context vector as input parameters, weighting and scoring multiple configuration combinations through a built-in rule engine or machine learning model, and outputting one or more optimal configuration schemes suitable for the current context environment is as follows: Obtain the service features identified by the interface metadata parser and the context vector generated by the context environment collector; Based on the service characteristics, candidate configuration items related to the service characteristics are extracted from a preset configuration item library, and multiple candidate configuration combinations are generated; The configuration item library stores candidate configuration items corresponding to various service characteristics and their optional values. These candidate configuration items include, but are not limited to: load balancing strategies, timeout settings, circuit breaker degradation mechanisms, log tracing strategies, and long timeouts. Optional values ​​for load balancing strategies include, but are not limited to: round-robin, weighted, or minimum connection count. The optional values ​​for timeout settings are set according to the current operating environment. Optional values ​​for circuit breaker degradation mechanisms include: enabled or disabled. Optional values ​​for log tracing strategies include: enabled or disabled. The optional values ​​for long timeouts are set as a multiple of a preset standard timeout. Long timeouts are enabled in the test environment but disabled in the production environment. The service features and the context vector are input into the built-in rule engine or a pre-trained machine learning model to assign weights to the multiple candidate configuration combinations. Based on the weighted scoring results, select one or more candidate configuration combinations with the highest scores as the optimal configuration scheme suitable for the current context.

9. A method for intelligent service discovery and automated integration based on microservice architecture, implemented using the intelligent service discovery and automated integration system based on microservice architecture as described in any one of claims 1-8, characterized in that, This method includes the following steps: Based on the microservice transformation and independent deployment mechanism, various business applications in the enterprise's internal business system or third-party system services that need to be connected to the enterprise's internal business system are encapsulated into microservices to obtain several microservice instances. From all the obtained microservice instances, proactively discover newly deployed microservice instances, parse the interface metadata of the microservice instance, and identify the service characteristics of the microservice instance based on the parsing results; Collect the current system operating environment, generate a context vector, and generate the optimal configuration scheme for the microservice instance based on the service characteristics and the context vector; Obtain the address information of the microservice instance, and update the dynamic topology and routing table between all microservice instances in conjunction with the optimal configuration scheme; During the update process, when a change event is detected in the routing table, external requests are routed to the corresponding microservice instance based on the change event. Perform automated health checks before connecting to the newly deployed microservice instance, and then switch real business traffic to the microservice instance after the checks pass.

10. The intelligent service discovery and automated integration method based on microservice architecture as described in claim 9, characterized in that, The specific method for encapsulating various business applications in the enterprise's internal business system or third-party system services to be integrated into the enterprise's internal business system into microservices, based on the microservice transformation and independent deployment mechanism, to obtain several microservice instances is as follows: For internal business systems, each business application in the internal business system is split into several microservices according to business boundaries, and packaged using standardized container technology to form several first-type microservice instances, and each first-type microservice instance is allocated independent running resources. For third-party system services that need to be integrated into the enterprise's internal business system, the third-party system services are encapsulated in an independent proxy container to form a second type of microservice instance, and independent running resources are allocated to each second type of microservice instance. Using the built-in performance monitoring component, when the network request QPS of any microservice instance exceeds the preset scaling threshold, the number of instances of that microservice will be automatically increased. When the network request QPS is lower than the preset scaling-down threshold, the number of microservice instances will be automatically reduced. For microservice instances that require version updates, blue-green deployment or canary deployment is used for version updates. Blue-green deployment uses a one-time full switch to switch traffic from the old version to the new version. Canary deployment uses a proportional incremental switch to switch traffic from the old version to the new version.

Images