Service invocation apparatus and method for a distributed system

Abstract

The embodiment of the application provides a service calling device and method of a distributed system, the device comprises a plurality of data centers, each data center comprises a plurality of registration centers, a plurality of microservices and a plurality of gateways, wherein the registration center is used for registering service information of the corresponding data center; the gateway communicates with each application system of the distributed system, and calls between microservices according to a service list of the registration center; the gateway and the microservice are provided with a multi-center monitoring module and a service list multi-level cache module, wherein the multi-center monitoring module is used for monitoring the state of the service information of the plurality of data centers; and the service list multi-level cache module caches the service list of the registration center. Through the application, the problems of independent centers, poor availability and incomplete emergency mechanism of the distributed system in the related art are solved, the coordination and availability of the multiple registration centers are improved, and the effect of solving the emergency condition is achieved.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of distributed system architecture, and more specifically, to a service invocation device and method for a distributed system. Background Technology

[0002] With the development of Internet technology, application systems are gradually adopting distributed architecture. In distributed architecture, the registration and discovery component plays a core role in distributed microservice architecture, such as service registration, service discovery, service invocation, and configuration center. The high availability of the registration and discovery component is of great significance to the stability of distributed systems.

[0003] Existing distributed systems based on registry centers like Zookeeper and Eureka register services on their respective registry centers. The entire service call chain, from start to finish, occurs within the current data center, meaning each center is a relatively independent environment. If a service in a center fails, the entire center becomes unavailable, and its transactions are switched to a backup or other center, leading to resource waste and unreasonable load balancing. While Consul-based distributed systems natively support multi-center mode, this support is limited, only at the deployment level. Microservices still access their own center's service list and configurations, and there's no cross-center access strategy, failing to fully leverage the advantages of multi-center systems.

[0004] In existing Spring Cloud microservice architectures, the service list cache based on LoadBalancer uses an expiration mechanism, remaining valid only for a specified period. When a service is called, it first retrieves this LoadBalancer cache; if the cache expires, it accesses the service registry. A longer expiration time for the LoadBalancer cache can lead to delayed updates and calls to unavailable services. A shorter expiration time results in frequent interactions with the registry. Most importantly, if the registry fails, there is no fallback service list cache available for service calls, meaning services cannot communicate with each other when the registry is down. Furthermore, in existing distributed systems, when the registry fails, the service list stops updating, leading to instances of unavailable services being called repeatedly, resulting in call failures.

[0005] In summary, existing distributed systems suffer from problems such as independent centers, poor availability, and incomplete emergency response mechanisms. Summary of the Invention

[0006] This invention provides a service invocation device and method for a distributed system, which at least solves the problems in related technologies such as the existence of independent centers, poor availability, and incomplete emergency mechanisms in distributed systems.

[0007] According to an embodiment of the present invention, a service invocation apparatus for a distributed system is provided, comprising multiple data centers, each data center including multiple registry centers, multiple microservices, and multiple gateways. The registry centers are used to register service information corresponding to their respective data centers. The gateways communicate with various application systems of the distributed system and invoke the microservices according to the service lists of the registry centers. The gateways and microservices are equipped with a multi-center module and a multi-level service list caching module. The multi-center module is used to monitor the status of the multiple registry centers in the multiple data centers. The multi-level service list caching module caches the service lists of the registry centers.

[0008] According to another embodiment of the present invention, a service invocation method for a distributed system is provided, implemented using the above-described service invocation device, comprising: a client obtaining a list of names of multiple data centers; obtaining a service list from the registry of the corresponding data center according to a preset priority order of the registry centers based on the microservice name to be invoked by the client; and invoking the microservice according to the service list, wherein, when obtaining the service list, the service list is obtained from a multi-level service list caching module according to a preset priority order.

[0009] According to yet another embodiment of the present invention, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed.

[0010] According to yet another embodiment of the present invention, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0011] This invention provides a service invocation device for a distributed system, comprising multiple data centers, each data center including multiple registry centers, multiple microservices, and multiple gateways. The registry centers register service information for their respective data centers. The gateways communicate with various application systems within the distributed system, invoking between microservices based on the service lists of the registry centers. Each gateway includes a multi-center module and a multi-level service list caching module. The multi-center module monitors the status of multiple registry centers across the multiple data centers. The multi-level service list caching module caches the service lists of registry centers in different statuses. This invention solves the problems of independent registry centers, poor availability, and incomplete contingency mechanisms in related distributed systems, improving the coordination and availability of multiple registry centers and enabling emergency response. Attached Figure Description

[0012] Figure 1 This is a deployment architecture diagram based on Zookeeper or Eureka;

[0013] Figure 2 This is a diagram of a multi-center deployment architecture based on Consul.

[0014] Figure 3 This is a service call principle diagram of a distributed system according to an embodiment of the present invention;

[0015] Figure 4 This is a schematic diagram of the structure of a service invocation device for a distributed system according to an embodiment of the present invention;

[0016] Figure 5 This is a flowchart of a microservice call according to an embodiment of the present invention;

[0017] Figure 6 This is a schematic diagram of the initialization process of the service list when the registration center crashes according to a scenario embodiment of the present invention.

[0018] Figure 7 This is a schematic diagram of the structural principle of the emergency escape module according to a scenario embodiment of the present invention;

[0019] Figure 8 This is a schematic diagram of the communication principle of the emergency escape module according to a scenario embodiment of the present invention;

[0020] Figure 9 This is a schematic diagram of the emergency address invocation principle according to a scenario embodiment of the present invention. Detailed Implementation

[0021] The embodiments of the present invention will be described in detail below with reference to the accompanying drawings and examples.

[0022] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0023] Figure 1 This is a deployment architecture diagram based on Zookeeper or Eureka. The system contains two independent centers, Center 1 and Center 2. Services under each center are registered under the corresponding center. When a service in Center 1, such as service1, fails, Center 1 will be made unavailable, which will increase the traffic and access pressure on Center 2.

[0024] When Zookeeper or Eureka is used as the registry center, services are registered in the registry center cluster of their respective centers. Transaction calls occur entirely within the current center, meaning each center is a relatively independent environment. If all instances of a service within a center fail, the entire center becomes unavailable, and transactions from that center are moved to a backup or other center. This leads to resource waste and unreasonable load balancing, causing a significant increase in traffic and access pressure on other centers, and posing risks of service failures and congestion. While Zookeeper, with its native event listening mechanism, allows for the retrieval and updating of the service list, updates cease when the registry center fails. Furthermore, this approach heavily relies on Zookeeper's event listening mechanism, making it unavailable for systems that cannot use Zookeeper as their registry center.

[0025] Figure 2 This is a multi-center deployment architecture diagram based on Consul. The system contains two centers, Center 1 and Center 2. At the network layer, Consul in each center communicates based on the LAN Gossip Pool (LGP), and Consul in each center communicates based on the WAN Gossip Pool (WGP). However, for the services of each center, it still obtains the service list and configuration of its own center, and cross-center support and design are not implemented.

[0026] While native Consul supports a multi-center model, its support is limited, existing only at the deployment level. Each microservice still accesses its own local registry, including its service list and configurations. There's no cross-center access strategy or high-availability design based on cross-center access. When Consul is the registry, the service list is retrieved via a Consul API call. In existing Spring Cloud microservice architectures, the service list cache is based on a load-balanced cache with an expiration mechanism, valid only within its expiration period. When a service makes a call, it prioritizes retrieving the load-balanced cache; if the load-balanced cache expires, it accesses the registry to obtain the service list. Therefore, if the registry fails, there's no fallback service list cache for service calls, meaning services cannot communicate when the registry (Consul) is down. Furthermore, when the registry fails, the service list stops updating, leading to service unavailability and repeated calls to the same service, resulting in call failures.

[0027] In distributed systems based on registry centers such as Zookeeper and Eureka, services are registered on the registry center of their respective centers. The entire service call chain, from start to finish, takes place within the current data center, meaning each center is a relatively independent environment. If a service in a center fails, the entire center becomes unavailable, and its transactions are switched to a backup center or another center. This leads to resource waste and unreasonable load balancing.

[0028] In Consul-based distributed systems, Consul natively supports multi-center mode, but its support for multi-center is limited, only at the deployment level. Microservices still obtain the service list and configuration of their own center, and there is no cross-center access strategy, thus failing to fully leverage the advantages of multi-center.

[0029] In existing Spring Cloud microservice architectures, load balancing based on LoadBalancer uses a service list cache with an expiration mechanism. The cache is only valid for a specified expiration period. When a service is called, it first retrieves the service list from the load balancer cache; if the load balancer cache expires, it accesses the service registry. When the load balancer cache expiration time is configured to be long, there is a risk of delayed updates and calls to unavailable services. When the load balancer cache expiration time is configured to be short, there is a problem of frequent interactions with the registry. The most critical issue is that if the registry fails, there is no fallback service list cache available for service calls; that is, if the registry fails, services cannot communicate with each other.

[0030] In existing technologies, when the registry center crashes, the service list stops updating, leading to the problem that even when a service is unavailable, multiple calls to that service may still fail.

[0031] To address the aforementioned issues, this invention provides a service invocation device for a distributed system, comprising multiple data centers. Each data center includes multiple registration centers, multiple microservices, and multiple gateways. The registration centers register service information for their respective data centers. The gateways communicate with various application systems within the distributed system and invoke microservices based on the service lists of the registration centers. Each gateway and microservice is equipped with a multi-center module and a multi-level service list caching module. The multi-center module monitors the status of service information from multiple registration centers across the multiple data centers. The multi-level service list caching module caches the service lists of the registration centers under different statuses.

[0032] In one exemplary embodiment, the registry center can be a Consul registry center; the microservices can be Spring Cloud microservices. In actual implementation, the types of registry center and microservices can be determined according to the actual situation, and no restrictions are imposed here.

[0033] In one exemplary embodiment, the multi-center module further includes: a listener for monitoring the status of service lists of multiple registries, a connector for connecting multiple registries with clients, and a filter for filtering service lists obtained from multiple registries according to access rules.

[0034] In an exemplary embodiment, the service list multi-level caching module includes: a load balancing caching unit, a local service list caching unit, and a local file caching unit, wherein the load balancing caching unit has a higher priority than the local service list caching unit; the load balancing caching unit is used to cache the service list of a normally available registry center, and the effective time of the load balancing cache is controlled by configuring the Time To Live (TTL); the local service list caching unit is used to retrieve the service list from the local cache for the data center when the registry center connection is abnormal; the local file caching unit is used to perform initialization operations on the local service list caching unit after the registry center connection is abnormal and the distributed system restarts.

[0035] In one exemplary embodiment, the gateway is further provided with an emergency escape module, which is used to provide a proxy address and an emergency address for the distributed system, and to directly notify the data center to activate the emergency address for service invocation in the event of an anomaly in the proxy address.

[0036] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0037] In another embodiment of the present invention, a service invocation method for a distributed system is also provided, implemented using the above-described service invocation apparatus, comprising:

[0038] The client obtains a list of data center names, retrieves a service list from the corresponding data center's registry according to a preset priority order based on the client's call address, and makes microservice calls based on the service list. In the process of retrieving the service list, the service list is retrieved from the multi-level service list cache module according to a preset priority order.

[0039] In one exemplary embodiment, the system further includes: monitoring the status of the data center and the registration center through a multi-center monitoring module; and obtaining an emergency address through an emergency escape module in the event of an anomaly in the current system's proxy service, and using the emergency address to replace the current proxy address for communication and microservice data transmission.

[0040] In one exemplary embodiment, the method further includes: monitoring the service list of the registry center through a multi-center monitoring module; removing microservices with abnormal call results from the service list when the registry center is normally available; wherein, if the cause of the abnormal call result is an abnormal communication network connection, monitoring continues until the communication network connection is restored, and the removed microservices are then restored; and if the registry center connection is abnormal, a preset number of access failures is set for the corresponding microservice in each service list; when the actual number of failed accesses exceeds the preset number of failed accesses, the corresponding microservice is removed or the call is suspended.

[0041] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0042] Embodiments of the present invention also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed.

[0043] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0044] Embodiments of the present invention also provide an electronic device including a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the steps in any of the above method embodiments.

[0045] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0046] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0047] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0048] To enable those skilled in the art to better understand the technical solution of the present invention, specific scenario embodiments are described below.

[0049] Scenario Example 1

[0050] Figure 3 This is a service call principle diagram of a distributed system according to an embodiment of the present invention, such as... Figure 3 As shown, the system consists of multiple centers, each comprising a Consul registry, Spring Cloud-based microservices, and a gateway. Each service registers its service information with the registry. The registry checks the health of the services registered therein through health checks, and services retrieve the service list from the registry to make calls between services.

[0051] In actual implementation, microservices and gateways also include multi-center modules, multi-level caching modules for service lists, and emergency escape modules. Figure 4 This is a schematic diagram of the structure of a service invocation device for a distributed system according to an embodiment of the present invention, such as... Figure 4 As shown, the multi-center module includes a multi-center list retrieval listener and a multi-center access client connector (i.e., Figure 4 Multi-center access client connector), multi-center access rule filter (i.e. Figure 4 (Service list priority filter).

[0052] The multi-center list retrieval listener supports configuration loading of multiple center names and dynamic listening for multiple center online / offline status; the multi-center access client connector is initialized based on the multi-center list and is used to communicate with the registry center; the multi-center access rule filter returns the service list of the highest priority center according to the configured priority of each center in the retrieved service list.

[0053] Multi-center monitoring module:

[0054] Multi-center list retrieval listener: Enhances the Consul multi-center functionality by loading a list of multi-center names based on configuration and retrieving the service list for each center based on its name. It monitors changes to the multi-centers in real time, adding or removing services from the corresponding center's list as centers are added or removed, enabling dynamic online / offline functionality for multi-centers.

[0055] Multi-center access client connector: Based on the multi-center list, initialize the multi-center access client to communicate with the registry center and obtain the service list, configuration, etc. of the multi-center.

[0056] Service list multi-center priority filter: When services call each other, the default strategy is to access services from the nearest center, prioritizing services within the current center. However, the priority of multiple centers can be customized to filter the service list according to priority. Even if a service in the current center is unavailable, the transaction chain can still be maintained by accessing services from other centers.

[0057] like Figure 4 As shown, the service list multi-level caching module consists of a load-balanced cache L1 and a local service list cache L2 (i.e., ... Figure 4 The service list memory cache L2) and local file cache L3 (i.e. Figure 4The service list cache (L3) consists of multiple levels, including a load balancer cache (L1) for caching the service list when Consul is available, with configurable expiration times. The service list memory cache (L2) is used for service list degradation strategies after Consul crashes, and the service list file cache (L3) initializes the service list upon service restart when Consul is unavailable. A failure removal strategy marks failed service calls and supports modifying the service status in the load balancer cache (L1), service list memory cache (L2), and service list file cache (L3) according to the configured failure policy. Specifically, for microservices and gateways based on Spring Cloud, the service list cache is a multi-level cache, including load balancer cache (L1), service list memory cache (L2), and service list file cache (L3), with multi-level caching supporting on / off configuration and combination.

[0058] Load Balancing Cache L1: Supported in native mode, the validity period of the Load Balancing Cache L1 is controlled by configuring the TTL expiration time. Within the cache validity period, the cached list data is retrieved first. The Load Balancing Cache can be turned on and off. When enabled, the service list of the Load Balancing Cache L1 is retrieved first. If the Load Balancing Cache L1 does not have the list of a service, the list of that service is obtained from the registry center through the multi-center client and written to the Load Balancing Cache L1. When disabled, the list of that service is directly obtained from the registry center through the multi-center client, and the cache is updated simultaneously.

[0059] Service list memory cache L2:

[0060] Initialization: When a service is called, the service name is added to the listening list set. At the same time, a service list update schedule is started, which periodically retrieves the latest service list from the registry center and updates the service list memory cache L2.

[0061] Usage: When calling a service to retrieve the service list, if the connection with the registry center Consul fails, the L2 data is retrieved using the service list memory cache as a fallback logic in case of registry center failure.

[0062] Service list file cache L3: Maintains synchronization asynchronously with service list memory cache L2, ensuring no data loss upon service restart. It is primarily used when the registry center Consul is unavailable and a service restart is necessary. At startup, the contents of service list file cache L3 are loaded into the local service list cache L2 as the initial service list memory cache.

[0063] like Figure 4As shown, an emergency escape module is also included for system integration. It communicates via a proxy, uses configuration monitoring in the registry center and multi-center configuration synchronization to receive and distribute emergency notifications, ensuring both network isolation and normal inter-system transactions in emergencies. The emergency escape mechanism employs a multi-level service list cache compatible with microservices and gateways, collectively forming a multi-center high-availability system. When systems integrate, a proxy is used for communication to achieve cross-system service integration. To mitigate the impact of proxy failures on inter-system calls, an emergency escape switching mechanism is proposed. The caller configures the address of the called party (proxy address), the emergency address (caller service address), and its status in its configuration center. In an emergency, the emergency switching notification includes two pieces of information: service name and service status. Upon receiving the notification, each system updates its system status configuration based on the system name. During a call, if the caller's proxy fails, the outgoing address of the relevant transaction uses the emergency address. If the current service's proxy fails, all outgoing transactions of the current service use the emergency address.

[0064] like Figure 4 As shown, an access failure removal strategy is also set: the service list cache at each level is not strongly consistent with the actual service list data in real time. It's possible that a service may be offline but still in the service list cache. Calling this service according to the load balancing strategy can lead to timeouts or even connection exhaustion. Based on the load balancing lifecycle, an access failure exception strategy is proposed, supporting policy-based suspension of access to services with access failures when the registry center is normal or down. When the registry center is available, services with non-business-related exceptions are removed from the multi-level service list cache. Due to health checks, if the exception is a temporary network problem, the service will recover and resume normal service after the next health check, avoiding service congestion caused by continuous access failures. When the registry center is down, it supports configuring access failure strategies (strategy) and access failure counts (counts). Failure strategies include direct removal (remove) and suspension (suspend) strategies. The suspension strategy can be configured with the number of suspensions (suspendCounts). Specifically, the removal strategy: when the number of failed calls to an instance of a service list exceeds (counts), the instance is removed from the service list cache at each level. Suspension call strategy: When the number of failed calls to an instance of a certain service list exceeds (counts), the status of that service instance is set to suspend calls to that service for a period of time (suspendCounts).

[0065] The service invocation device of the above-mentioned distributed system is used to perform multi-center listening, which includes the following process: Multi-center module: including multi-center list acquisition listener, multi-center connection client connector, and multi-center access rule filter.

[0066] The multi-center list retrieval listener supports configuration loading of multi-center names and dynamic listening for multi-center online / offline status; the multi-center access client connector initializes the multi-center access client based on the multi-center list for communication with the registry center; the multi-center access rule filter returns the service list of the highest priority center according to the configured priority of each center in the retrieved service list.

[0067] (1) Multi-center list acquisition: The multi-center name list can be explicitly specified in the configuration. When the service starts, it first obtains the configured data center name list. If not configured, it obtains the multi-center name of the registration center through the registration center client.

[0068] (2) Multi-center list monitoring: Initialize the center list scheduler, periodically pull the center list, compare it with the current center list, and if they are inconsistent, trigger a multi-center change event; after receiving the event, update the center list.

[0069] (3) Multi-center access client connector: Modify the registry access client. Based on the multi-center list name obtained in (1) and (2), initialize the multi-center access client when it starts loading, and use it to obtain the service list.

[0070] (4) Multi-center access rule filter: Based on (3), the multi-center access client obtains the service list from the registration center, filters the obtained service list according to the multi-center priority, and returns available services.

[0071] Figure 5 This is a flowchart of a microservice call according to an embodiment of the present invention, such as... Figure 5 As shown, the process of microservice invocation based on a multi-level caching module mainly includes:

[0072] (1) When the @EnableFeignClients switch is enabled, it will scan the @FeignClient annotation and encapsulate it into BeanDefinition, generating a factory instance FeignClientFactoryBean.

[0073] (2) Based on Spring's initialization of FactoryBean, a dynamic proxy class FeignInvocationHandler will be constructed.

[0074] (3) When a service call is initiated, the invoke method of the generated proxy class is executed.

[0075] (4) Construct request parameters, generate the calling client FeignBlockingLoadBalancerClient, and launch the calling client.

[0076] (5) Obtain the load balancing strategy from the load balancing factory. The default is the round-robin strategy.

[0077] (6) Obtain the service list from the service list provider. The service list provider relies on the MultiConsulClient multi-center access client connector and multi-center access rule filter built by the multi-center listening module. The service list is a multi-level cache, consisting of load balancing cache L1 (optional), service list memory cache L2, and service list file cache L3 (optional). The multi-level cache supports on / off configuration and combination, and the service list provider is assembled according to the configuration.

[0078] Load balancing cache L1: When load balancing caching is enabled, the service list is first retrieved from the load balancing cache. If the retrieval is successful, the service list is used directly. If the retrieval fails, the multi-center access client calls the registry center to retrieve the service list, updates the load balancing cache L1 and the local service list cache L2, and asynchronously updates the service list file cache L3. When load balancing caching is disabled, the multi-center access client directly calls the registry center to retrieve the service list, updates the local service list cache L2, and asynchronously updates the file cache L3.

[0079] (7) Service list multi-center priority filter: filters the obtained service list, and returns the service list under the local center by default based on the nearest access principle; when the service list of the local center is empty, it returns the service list of the center with the highest priority according to the configured access priority order of each center.

[0080] (8) Select one service from the service list returned by (7) according to the load balancing strategy, and use it as the request address of the callee.

[0081] (9) Request the server address via HTTP and obtain the access result.

[0082] (10) Based on the LoadBalancerLifeCycle, a strategy for removing services with access anomalies is proposed, which supports suspending access to services with access anomalies when the registry center is normal or down.

[0083] When the registry center is available, services with non-business-related errors are marked and removed from the multi-level cache of the service list. Due to the existence of health checks, if the error is a temporary one caused by network problems, the service will recover and resume normal service during the next health check. This avoids service congestion caused by continuous access failures.

[0084] When the registry center crashes, the call completion strategy is modified according to the configured call failure strategy. When a call to a service fails, the number of failures and the service instance are recorded. Access failure strategy includes a direct removal strategy and a suspend strategy. The suspend strategy can be configured with a suspend count (suspendCounts). Access failure counts are recorded; the strategy is activated when the number of failures reaches counts. Removal strategy: When the number of failed calls to an instance in a service list exceeds counts, the instance is removed from the service list cache at all levels. Suspension strategy: When the number of failed calls to an instance in a service list exceeds counts, the status of that service instance is set to zero, and calls to that service are stopped for suspendCounts.

[0085] Figure 6 This is a schematic diagram illustrating the initialization process of the service list when the registration center crashes according to an embodiment of the present invention. Figure 6 As shown, the initialization of the service list based on the local service list cache L2 and the service list file cache L3 mainly includes the following processes:

[0086] 1. When a microservice starts, listen for the application startup success event and initialize the service list from the service list file cache L3 to the service list memory cache L2.

[0087] 2. When a service is invoked, the caller's service name is added to the local service list monitoring set. Simultaneously, scheduling is enabled to monitor changes in the service list for that service name. When the service list changes, the local service list cache (L2) is updated, and the file cache (L3) is updated asynchronously.

[0088] Figure 7 This is a schematic diagram of the structural principle of the emergency escape module according to an embodiment of the present invention, as shown below. Figure 7 As shown, a microservice architecture system is composed of microservices, a gateway, and a registry center. Communication with other systems is uniformly managed by the management platform. Communication between systems is based on a proxy, ensuring no intrusion into the system.

[0089] Figure 8 This is a schematic diagram of the communication principle of the emergency escape module according to an embodiment of the present invention, such as... Figure 8As shown, to improve the availability of inter-system calls, an emergency switchover mechanism is implemented based on configuration monitoring in the registry center, multi-center configuration synchronization, and the receipt and distribution of emergency notifications. This ensures that in the event of a large-scale failure of the distributed proxy, emergency addresses are used for inter-system communication, guaranteeing both network isolation and normal inter-system transactions during emergencies. The caller configures the address (proxy address), emergency address (domain name), and status of the called party in its database. The management platform performs health checks, and when an anomaly is detected, it issues an emergency switchover notification containing two pieces of information: service name and service status. Upon receiving the notification, each system updates its database with the relevant configurations for the emergency switchover. The multi-center daemon periodically synchronizes database data to the Consul configuration in the registry center, and subsequently to the environment variables of the service instances in each center.

[0090] Figure 9 This is a schematic diagram of the emergency address invocation principle according to an embodiment of the present invention, such as... Figure 9 As shown, during a call, if the current service is in a normal state and the called service is in an emergency state, then the transaction of the called service will use the emergency address; if the current service is in an emergency state, then all transactions of the current service calling other systems will use the emergency address. This achieves high availability for inter-system calls.

[0091] In summary, the above embodiments of the present invention provide a service invocation device and method for a distributed system. By supporting multi-center list acquisition and monitoring, multi-level caching of service lists, and an emergency escape mechanism, it implements a multi-center registration and discovery high-availability technology and its system implementation under a financial distributed microservice architecture. Specifically: 1. It implements a Consul-based multi-center high-availability distributed system design, realizing the acquisition and priority configuration of multi-center service lists. When all instances under a certain service in a local center are unavailable, it seamlessly calls services from other centers, ensuring proximity access to reduce network latency and improving transaction success rates. 2. The system's key design element, the service list caching section, consists of multi-level caching and supports on / off configuration and combination, as well as configuration of access failure strategies. When the registration center is available, it improves the consistency between the cache and the service list in the registration center; when the registration center is down, inter-system calls are unaffected; the failure strategy modifies the state of an instance when a call to that instance fails, mitigating the impact of unavailable services on the system's links. 3. When communicating between systems, an emergency switchover and escape mechanism based on a proxy is implemented. Based on configuration monitoring of the registry center and configuration synchronization of multiple centers, an emergency switchover and escape mechanism is implemented, which enables fault transfer without the system's awareness. This ensures both network isolation and normal inter-system transactions in emergency situations, thereby improving the high availability between systems.

[0092] Compared to existing technologies, current technologies lack in-depth research on multi-center architecture and cannot provide a multi-center mode. Each center's services are registered separately with its own registry, and the entire service call chain occurs within the current data center, meaning each center operates in a relatively independent environment. When all services in a center fail, the entire center's operations become unavailable, and transactions are redirected to a backup or other center, resulting in resource waste and unreasonable load balancing. This invention proposes a Consul-based multi-center implementation that supports multi-center list retrieval and monitoring, multi-center configuration, and dynamic online / offline status. When all service instances in a center become unavailable, services in other centers are seamlessly invoked, ensuring proximity access to reduce latency and improving transaction response and success rates. Existing technologies based on Spring Cloud and LoadBalancer load balancing do not provide a local service list, leading to service call failures when the registry fails. While Duboo-based distributed architectures provide a local service list, it cannot be updated when the registry fails. This invention proposes a multi-level cached service list, supporting on / off configuration and combination, and supports configuration failure strategies. When the registry center is available, the consistency between the cache and the registry center's service list is improved; in the event of a registry center downtime, inter-system calls remain unaffected; the service call failure strategy modifies the state of an instance when a call to that instance fails, mitigating the impact of unavailable services on the system call chain. Existing technologies often employ either no isolation or absolute isolation for inter-system calls, resulting in inadequate emergency response mechanisms.

[0093] This invention proposes an emergency switching mechanism with inter-system connectivity. Based on configuration monitoring in the registry center and configuration synchronization in multiple centers, it enables fault transfer without the system's awareness, ensuring both network isolation and normal inter-system transactions in emergency situations, thereby improving the high availability between systems.

[0094] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A service invocation device for a distributed system, characterized in that, It includes multiple data centers, and each data center includes multiple registry centers, multiple microservices, and multiple gateways, wherein, The registration center is used to register service information under the corresponding data center; the gateway communicates with various application systems of the distributed system and makes calls between the microservices according to the service list of the registration center. The gateway and the microservice are configured with a multi-center module and a multi-level service list caching module. The multi-center module is used to monitor the status of the multiple registration centers in the multiple data centers. The multi-level service list caching module caches the service list of the registration centers. The service list multi-level caching module includes: a load balancing caching unit, a local service list caching unit, and a local file caching unit. The load balancing caching unit has a higher priority than the local service list caching unit. The load balancing caching unit is used to cache the service list of the normally available registry center, and the effective time of the load balancing cache is controlled by configuring the Time-to-Live (TTL). The local service list caching unit is used to retrieve the service list from the local cache for the data center when the registry center connection is abnormal. The local file caching unit is used to perform initialization operations on the local service list caching unit after the registry center connection is abnormal and the distributed system restarts.

2. The apparatus according to claim 1, characterized in that, in, The registry center is Consul; the microservice is a Spring Cloud microservice.

3. The apparatus according to claim 1, characterized in that, The multi-center module further includes: a listener for monitoring the service status of the multiple registration centers, a connector for connecting the multiple registration centers with the client, and a filter for filtering the service list obtained by the multiple registration centers according to access rules.

4. The apparatus according to claim 1, characterized in that, The gateway is also equipped with an emergency escape module, which provides a proxy address and an emergency address for the distributed system. In the event of an anomaly in the proxy address, the module directly notifies the data center to activate the emergency address for service invocation.

5. A service invocation method for a distributed system, characterized in that, Implemented using the service invocation apparatus according to any one of claims 1-4, comprising: The client obtains a list of names of multiple data centers, and retrieves a service list from the registry of the corresponding data center according to the priority order of the registry according to the name of the microservice to be called by the client. The client then makes a microservice call based on the service list. In the process of retrieving the service list, the service list is retrieved from the multi-level cache module of the service list according to the preset priority order. The service list multi-level caching module includes: a load balancing caching unit, a local service list caching unit, and a local file caching unit, wherein the load balancing caching unit has a higher priority than the local service list caching unit. The method further includes: The load balancing cache unit caches the list of services of the registry that are normally available, and controls the effective time of the load balancing cache by configuring the time-to-live (TTL). When the registration center connection fails, the local service list caching unit retrieves the service list from the local cache for the data center. After the registry center connection fails and the distributed system restarts, the local service list cache unit is initialized through the local file cache unit.

6. The method according to claim 5, characterized in that, Also includes: The multi-center monitoring module monitors the status of the data center and the registration center. In the event of an abnormal status of the current system's proxy service, the emergency escape module obtains an emergency address and uses the emergency address to replace the current proxy address for communication and microservice data transmission.

7. The method according to claim 5, characterized in that, Also includes: The multi-center monitoring module listens for call feedback on the service list of the registry center. If the registry center is normally available, microservices with abnormal call results are removed from the service list. If the abnormal call result is caused by a communication network connection problem, monitoring continues until the communication network connection is restored, at which point the removed microservice is reinstated. If the registry center connection is abnormal, a preset number of failed access attempts is set for each microservice in the service list. When the actual number of failed access attempts exceeds the preset number, the corresponding microservice is removed or its access is suspended.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program is configured to perform the method described in any one of claims 5 to 7 when executed.

9. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method as described in any one of claims 5 to 7.

Images