Address information issuing system and method

Abstract

The invention provides an address information publishing system, which comprises an address information management module and a dynamic address publishing module, and is characterized in that the address information management module is used for configuring first address information declared by a first service; the dynamic address issuing module is coupled with the address information management module and used for inquiring the first address information from the address information management module and issuing the first address information to a client, the client and the first service are located in different virtual subnets, and the first address information is used for the client to access the first service. The invention further provides an address information publishing method, electronic equipment, a computer readable storage medium and a computer program product. According to the method and the device, the problems of excessive dependence on the proxy server, data forwarding delay and relatively low resource utilization rate of the server when the client accesses services such as Redis and the like through the proxy server in a cross-subnet manner in the related technology can be at least solved.

Description

Technical Field

[0001] This application relates to the field of network communication, and in particular to a system and method for publishing address information. Background Technology

[0002] As virtualization technology continues to optimize and enhance its ability to manage large-scale services, more and more cloud computing companies are choosing to deploy services like Redis as virtual machines or containers in virtualized environments. Virtualization platforms create independent virtual subnets on the host machine. Services within a subnet can communicate with each other, while services outside the subnet cannot directly access services within the subnet. Therefore, when deploying services like Redis in a virtualized environment, clients face the challenge of accessing these services across subnets.

[0003] In related technologies, to address the aforementioned issues, taking Redis as an example, a proxy server can be introduced between the client and the Redis service. The client can then access the Redis service across subnets through the proxy server. However, in practical applications, this approach of accessing the Redis service through a proxy server relies too heavily on the proxy server. Furthermore, due to the introduction of an additional proxy layer between the client and the Redis service, additional overhead and costs inevitably arise in terms of data forwarding latency and server resource utilization. Summary of the Invention

[0004] This application provides an address information publishing system and method to address the problems in related technologies where clients access services such as Redis across subnets via proxy servers, resulting in excessive reliance on proxy servers, data forwarding delays, and low server resource utilization.

[0005] To solve the above-mentioned technical problems, this application is implemented as follows:

[0006] Firstly, an address information publishing system is provided, including:

[0007] The address information management module is used to configure the first address information that the first service announces to the outside world.

[0008] A dynamic address publishing module, coupled to the address information management module, is used to query the first address information from the address information management module and publish the first address information to the client, wherein the client and the first service are located in different virtual subnets, and the first address information is used by the client to access the first service.

[0009] Secondly, a method for publishing address information is provided, including:

[0010] Configure the primary address information to be publicly announced by the primary service;

[0011] The first address information is published to the client, wherein the client and the first service are located in different virtual subnets, and the first address information is used by the client to access the first service.

[0012] Thirdly, an electronic device is provided, comprising:

[0013] processor;

[0014] Memory used to store the processor's executable instructions;

[0015] The processor is configured to execute the instructions to implement the method as described in the second aspect.

[0016] Fourthly, a computer-readable storage medium is provided, wherein when instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform the method described in the second aspect.

[0017] Fifthly, a computer program product is provided, the computer program product including a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of the method as described in the second aspect.

[0018] In this embodiment, by configuring the first address information declared by the first service and then publishing this first address information to the client, the client can directly access the first service through the first address information when accessing the first service across subnets, without needing to access the first service through a proxy server. This reduces invalid data forwarding and improves resource utilization. Furthermore, since the address information declared by the first service can be dynamically published to the client, i.e., the address information declared by the first service can be dynamically updated, in the event of a change in the service address of the first service, the client can quickly restore communication with the first service using the dynamically published address information. In the event of a migration or cross-platform reconstruction of the first service, the client can automatically and quickly access the new first service using the dynamically published address information, thereby improving the service's disaster recovery capabilities. Attached Figure Description

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

[0020] Figure 1 This is a schematic diagram of the structure of an address information publishing system according to an embodiment of this application;

[0021] Figure 2 This is a schematic diagram illustrating the publication and management of address information according to one embodiment of this application;

[0022] Figure 3 This is a schematic diagram illustrating the access address and port of the Redis service within an open virtualization platform, as per an embodiment of this application.

[0023] Figure 4 This is a schematic diagram illustrating an embodiment of this application configuring the access address of the Redis service that has been exposed to the outside world on the virtualization platform;

[0024] Figure 5 This is a schematic diagram illustrating client access to Redis service according to an embodiment of this application;

[0025] Figure 6 This is a schematic diagram illustrating an embodiment of this application that detects a Redis service anomaly and notifies the client to switch the access address;

[0026] Figure 7 This is a schematic diagram illustrating cross-platform Redis service reconstruction as an embodiment of this application;

[0027] Figure 8 This is a schematic diagram illustrating how to view system and Redis service monitoring information through a visual monitoring module, as an embodiment of this application.

[0028] Figure 9 This is a flowchart illustrating an embodiment of the address information publishing method of this application;

[0029] Figure 10 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0030] As virtualization technology continues to optimize and enhance its ability to manage large-scale services, more and more cloud computing companies are choosing to deploy services such as Redis, databases, and message queues as virtual machines or containers in virtualized environments. The virtualization platform establishes independent virtual subnets on the host machine. Services within the subnet can communicate with each other, but services outside the subnet cannot directly access services within the subnet. Therefore, when deploying these services to a virtualized environment, taking Redis as an example, at least the following issues need to be considered:

[0031] (1) How can a client access the Redis service across subnets?

[0032] (1) How to quickly restore communication between the client and Redis when a Redis service in a virtual environment is migrated or its access address is changed;

[0033] (3) When the entire virtualization platform fails and the Redis service needs to be rebuilt across platforms, how can we ensure that the client can automatically and quickly access the new Redis service?

[0034] (4) How to ensure that the performance of client access to Redis is not affected by solving the above problems.

[0035] (5) How to manage and monitor the above process through a simple and convenient interactive interface.

[0036] In related technologies, the client can change the Redis service's IP address to a domain name, and then use dynamic DNS to map the domain name to the data proxy server's IP address. Ultimately, the client's access traffic will be forwarded by the proxy server to the Redis service in the virtual environment. This allows the client to access the Redis service across subnets through the proxy server. Furthermore, if a Redis service in the virtual environment is migrated or its access address changes, the client can also restore communication with the Redis service through the proxy server.

[0037] Regarding the aforementioned solution of clients accessing Redis services through a proxy server, in practical applications, due to the significant delay in updating the domain name's IP address, when the entire virtualization platform fails and is rebuilt across data centers, the client cannot obtain the latest proxy service address and resume access to Redis immediately. Furthermore, the introduction of an additional proxy layer between the client and server inevitably incurs additional overhead and costs in terms of data forwarding latency and overall server resource utilization.

[0038] This application provides an address information publishing system and method. By configuring a first address information publicly announced by a first service and then publishing this first address information to clients, clients can directly access the first service through this first address information when accessing it across subnets, without needing to go through a proxy server. This reduces invalid data forwarding and improves resource utilization. Furthermore, since the address information publicly announced by the first service can be dynamically published to clients, meaning the publicly announced address information can be dynamically updated, in the event of a change in the service address of the first service, clients can quickly restore communication with the first service using the dynamically published address information. In the event of a migration or cross-platform reconstruction of the first service, clients can automatically and quickly access the new first service using the dynamically published address information, thereby improving the service's disaster recovery capabilities.

[0039] It should be noted that the technical solutions provided in this application are applicable to at least the following scenarios:

[0040] Scenario 1: Clients located in different private subnets need to access the primary service across subnets;

[0041] Scenario 2: The primary service needs to be rebuilt across availability zones, and the client is required to be able to quickly and automatically switch access addresses;

[0042] Scenario 3: Full data proxy scenario compatible with cross-subnet, supporting cross-availability zone service disaster recovery and reconstruction capabilities for existing full data proxy modes;

[0043] Scenario 4: Due to business adjustments, it is necessary to quickly migrate or rebuild the primary service on different cloud service provider platforms.

[0044] The first service mentioned above can be a caching service, such as Redis, or other open-source or high-performance caching services, such as Garnet, etc. There are no specific limitations here.

[0045] When publishing and dynamically updating the address information publicly announced by the first service to clients, a specific communication protocol can be used. For example, if the first service is Redis, this specific communication protocol could be the Redis Serialization Protocol (RESP). Of course, in other possible implementations, this specific communication protocol could be other non-RESP protocols, which are not specifically limited here.

[0046] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in this application will be clearly and completely described below with reference to the accompanying drawings of one or more embodiments. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this application.

[0047] The terms "first," "second," etc., used in this application and the claims are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that this application can be implemented in orders other than those illustrated or described herein. Furthermore, in this application and the claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0048] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0049] Figure 1 This is a schematic diagram of the structure of an address information publishing system 10 according to an embodiment of this application.

[0050] Figure 1 The address information publishing system 10 shown includes an address information management module 11 and a dynamic address publishing module 12. The address information management module 11 is used to configure the first address information to be publicly announced by the first service. The dynamic address publishing module 12, coupled to the address information management module 11, is used to query the first address information from the address information management module and publish the first address information to clients. The client and the first service reside in different virtual subnets, and the first address information is used by the client to access the first service across subnets.

[0051] The first service can be a Redis service or other caching service; no specific restrictions are made here.

[0052] The first service can be deployed within a first virtualization platform (the first service can run within the first virtualization platform as a virtual machine or container). When the first service is deployed within the first virtualization platform, the address information management module 11 can configure the first address information publicly announced by the first service to the first virtualization platform. The first address information is used by clients to access the first service across subnets, and may include the port exposed by the first service and the IP address of the host machine where the first service resides. Optionally, when configuring the first address information publicly announced by the first service to the first virtualization platform, the address information management module 11 can configure it using the native configuration commands of the first service. For example, if the first service is a Redis service, the address information management module 11 can configure the publicly announced first address information for the Redis service using native Redis configuration commands.

[0053] After configuring the first address information to be publicly announced by the first service to the first virtualization platform, the address information management module 11 can synchronize or send the first address information to the first service, that is, specify the address information to be publicly announced by the first service as the first address information. In this way, after the dynamic address publishing module 12 publishes the first address information to the client, the client can access the first service based on the first address information.

[0054] When the address information management module 11 configures the first address information to be publicly announced by the first service to the first virtualization platform and synchronizes the first address information to the first service, the dynamic address publishing module 12 can query the first address information from the address information management module 11 and publish the first address information to the client. In this way, the client can directly access the first service across subnets through the first address information. Compared with accessing the first service through a proxy server, this can reduce invalid data forwarding and improve resource utilization.

[0055] Optionally, in some implementations, the address information management module 11 can provide an address query interface. When the dynamic address publishing module 12 queries the first address information from the address information management module 11, it can use this address query interface to query the first address information from the address information management module 11.

[0056] It should be noted that after configuring the first address information to be publicly announced by the first service, the address information management module 11 can also update this first address information periodically. When the first address information changes, the dynamic address publishing module 12 can query the updated address information from the address information management module 11 and publish the updated address information to the client, i.e., dynamically publishing the address information publicly announced by the first service to the client. In this way, by dynamically updating and publishing the address information publicly announced by the first service, in the event of a change in the service address of the first service, the client can quickly restore communication with the first service using the dynamically published address information. Furthermore, in the event of a migration or cross-platform reconstruction of the first service, the client can automatically and quickly access the new first service using the dynamically published address information, thereby improving the service's disaster recovery capabilities.

[0057] In some implementations, the address information publishing system may further include a status check module coupled to the dynamic address publishing module. This status check module can be used to check the status of the first service (e.g., periodically check the status of the first service) to determine whether the status of the first service is normal or abnormal. If the status check module determines that the status of the first service is abnormal, it can notify the dynamic address publishing module that the status of the first service is abnormal, so that the dynamic address publishing module can obtain new address information from the address information management module.

[0058] In some implementations, if the first service experiences an abnormal state, it can automatically recover. Upon automatic recovery, the address information management module can update the externally declared address information of the first service from the first address information to the second address information. For the dynamic address publishing module, upon receiving notification from the status check module and confirming that the first service is abnormal, it can query the address information management module for the new externally declared address information of the first service, i.e., the second address information, and publish the second address information to the client. This allows the client to access the first service based on the second address information, thereby restoring communication with the first service. The second address information may include the port exposed by the first service after recovery and the IP address of the host machine where the first service resides.

[0059] Specifically, when deploying the first service in the first virtualization platform, the first service can be deployed in sentinel mode or cluster mode. The first service deployed in sentinel mode or cluster mode inherently possesses the ability to automatically recover from anomalies. Thus, after the first service experiences an anomaly, based on its automatic recovery capability, it can automatically recover from an anomaly to normal operation. After the first service recovers, its address information will also change accordingly. At this point, clients will be unable to access the first service based on the previous address information, and communication between the client and the first service will be disconnected. Since the address information management module can periodically update the address information declared by the first service, after the address information changes, the address information management module can obtain the updated address information through periodic updates and update it to the new address information declared by the first service, i.e., the second address information. For the dynamic address publishing module, after receiving notification from the status check module and confirming that the first service is in an anomaly state, it can query the new address information declared by the first service from the address information management module. If the address information management module has already updated the first service's declared address information to the second address information, the dynamic address publishing module can query the second address information from the address information management module. After retrieving the second address information from the address information management module, the dynamic address publishing module can publish the second address information to the client. In this way, the client can re-access the first service through the second address information. Thus, communication with the first service can be quickly restored through automatic switching of address information.

[0060] In some scenarios, the first service may need to be rebuilt or migrated. For example, the first virtualization platform may become unavailable for some reason, causing the first service to fail to automatically recover in the event of an anomaly. Alternatively, based on business needs, the first service may need to be migrated from the first virtualization platform to another virtualization platform. In these scenarios, the embodiments of this application can rebuild the first service across platforms with a single click and update the address information of the first service to the client, enabling the client to automatically and quickly access the new first service.

[0061] Specifically, when the first service needs to be migrated or rebuilt, the address information management module can rebuild the first service in the second virtualization platform. Upon successful rebuilding, the address information management module can update the externally advertised address information of the first service to third address information. Subsequently, the dynamic address publishing module can query the third address information from the address information management module and publish the third address information to clients. In this way, clients can access the rebuilt first service through the third address information. Therefore, in scenarios requiring the rebuilding or migration of the first service, clients can automatically and quickly access the new first service. The third address information can include the port exposed by the rebuilt first service in the second virtualization platform and the IP address of the host machine where the first service resides.

[0062] Optionally, during the reconstruction of the first service, in order to avoid interference or impact on the normal operation of the client due to the original service status, the address information management module is also used for at least one of the following:

[0063] Remove the relevant configurations for the first service from the first virtualization platform;

[0064] Update the first address information of the first service in the first virtualization platform to the third address information.

[0065] It should be noted that, due to the possibility that the first virtualization platform cannot be accessed normally when the address information management module performs at least one of the above operations, the address information management module may fail to perform at least one of the above operations. Therefore, in practical applications, the address information management module can attempt to perform at least one of the above operations, and even if it fails, it will not interrupt the reconstruction process of the first service.

[0066] In this embodiment, when the dynamic address publishing module publishes the address information (i.e., the first address information, second address information, or third address information) announced by the first service to the client, it can publish it in various ways. In some implementations, the dynamic address publishing module can be used for:

[0067] The address information announced by the first service is proactively pushed to the client.

[0068] In other words, after retrieving the address information publicly announced by the first service from the address information management module, the dynamic address publishing module can proactively push this address information to the client. When the address information publicly announced by the first service changes, the dynamic address publishing module can proactively push the new address information to the client after obtaining the latest address information from the address information management module.

[0069] In some implementations, the dynamic address publishing module can be used for:

[0070] Upon receiving a query request from a client, the address information publicly announced by the first service is sent to the client.

[0071] In other words, the dynamic address publishing module only queries the address information declared by the first service from the address information management module and sends the declared address information to the client upon receiving a query request from the client. Alternatively, the dynamic address publishing module can first query the address information declared by the first service from the address information management module, then cache the address information locally, and send the address information to the client upon receiving a query request from the client.

[0072] For different types of clients, there are at least two different ways to obtain the address information publicly announced by the first service from the dynamic address publishing module. The first way is subscription, where the dynamic address publishing module proactively pushes new address information to the client when the publicly announced address information changes. The second way is polling, where the client queries the dynamic address publishing module for the publicly announced address information periodically. For the first method, after retrieving the publicly announced address information from the address information management module, the dynamic address publishing module can proactively push this information to the client. For the second method, when the dynamic address publishing module receives a query request from the client, it can retrieve the publicly announced address information from the address information management module based on the query request and send it to the client. Alternatively, the dynamic address publishing module can first retrieve the publicly announced address information from the address information management module, cache this information locally, and then send it to the client upon receiving a query request from the client.

[0073] When the dynamic address publishing module actively pushes or sends the address information announced by the first service to the client, it can do so through the first communication protocol. Specifically, the first communication protocol can include, but is not limited to, the RESP protocol, and the first service can include, but is not limited to, the Redis service.

[0074] For cases where the client obtains the address information announced by the first service from the dynamic address publishing module through polling, optionally, corresponding parameters can be pre-configured for the client. These parameters include, but are not limited to, the IP address and port of the dynamic address publishing module (used by the client to connect to the dynamic address publishing module and send query requests to it), the access password (or service password) of the first service, and the access mode. The address information publishing system of this embodiment can manage multiple access points for the first service simultaneously. To distinguish different first services, optionally, a globally unique service name can be used to uniquely identify a first service. Furthermore, for communication protocol compatibility, the access password for the first service can be constructed or generated using the service name and a randomly generated salt. The access mode of the first service can be used by the client to obtain the address information announced by the first service. In this embodiment, the access mode of the first service can include sentinel mode and cluster mode, meaning the client supports obtaining the address information announced by the first service through sentinel mode or cluster mode. However, it should be noted that when the client obtains the address information announced by the first service in sentinel mode, it can obtain address information in either single-instance mode or master-slave mode, meaning sentinel mode is compatible with both single-instance and master-slave modes.

[0075] After pre-configuring the IP address and port of the dynamic address publishing module, the access password and access mode of the first service to the client, when the client obtains the address information announced by the first service from the dynamic address publishing module through polling, it can send a query request to the dynamic address publishing module based on the dynamic address publishing module's IP address and port. This query request can carry the access password of the first service. When the dynamic address publishing module receives the client's query request, it can authenticate the client based on the access password. If the client is successfully authenticated and the service accessed by the client is determined to be the first service, it can query the address information announced by the first service from the address information management module and send this address information to the client (or, the dynamic address publishing module can first obtain the address information announced by the first service from the address information management module, cache this address information locally, and send it to the client when it receives the client's query request). For the client, when the dynamic address publishing module sends the address information announced by the first service to the client, the client can obtain this address information through the access mode of the first service.

[0076] The address information publishing system provided in this application is compatible with related technologies where clients access the first service through a proxy server. In other words, this application can be applied to scenarios where the address information of the first service, accessible to external clients, already exists within the virtualization platform. For example, if the virtualization platform has a proxy server (or border gateway), and clients outside the virtualization platform need a specific IP address and port to access the first service within the virtualization platform, then, based on the address information publishing system provided in this application, clients can access the first service through the proxy server.

[0077] Specifically, when a proxy server is set up in the first virtualization platform, the address information management module can obtain the address information of the proxy server and use this address information as the address information publicly announced by the first service. For ease of distinction, this can be referred to as the fourth address information. The fourth address information may include the IP address and port of the proxy server, which is used by the client to access the first service through the proxy server. When the address information management module obtains the fourth address information, the dynamic address publishing module can obtain the fourth address information from the address information management module and publish the fourth address information to the client (actively pushing the fourth address information to the client or sending the fourth address information to the client according to the client's query request). In this way, when a proxy server is set up in the first virtualization platform, by obtaining the address information of the proxy server and exposing this address information to the client, the client can access the first service through the fourth address information. Thus, a smooth transition can be achieved from the scheme of accessing the first service through a proxy server in related technologies to the address information publishing system provided in this application embodiment.

[0078] It should be noted that in the scenario where the first virtualization platform is equipped with a proxy server, the status of the first service does not need to be monitored and checked (for example, if the address information publishing system includes a status check module, the status check module does not need to monitor the status of the first service). Instead, the first virtualization platform ensures the normal operation of the proxy server (or border gateway) and the first service, while ensuring that the client can access the first service through the fourth address information. In this embodiment, it is only necessary to obtain the fourth address information from the proxy server and expose it to the client.

[0079] In some implementations, the address information publishing system may further include a visual monitoring module, which may be coupled to at least one of the address information management module, the dynamic address publishing module, and the status check module, and may provide a visual interface, specifically for at least one of the following (1) to (6):

[0080] (1) Receive the association relationships between different virtualization platforms and different services configured through the visual interface, and store the association relationships in the address information management module.

[0081] There can be multiple virtualization platforms, and different services can be deployed on different virtualization platforms. To facilitate monitoring and management of services deployed on different virtualization platforms, the relationships between different virtualization platforms and different services can be configured. These relationships can indicate which virtualization platform a particular service is deployed on. Optionally, the relationships between different virtualization platforms and different services can be configured by the administrator through a visual interface provided by the visual monitoring module, and then the visual monitoring module receives these relationships.

[0082] After receiving the relationships between different virtualization platforms and services, the visualization monitoring module can store these relationships in the address information management module. This allows the address information management module to manage the address information of different services deployed on different virtualization platforms based on these relationships. When the dynamic address publishing module queries the address information management module for the publicly declared address information of a service, the address information management module can return the corresponding address information to the dynamic address publishing module based on the stored relationships.

[0083] (2) Store the client's configuration parameters. The configuration parameters are used by the client to establish a connection with the dynamic address publishing module and query the address information announced by the first service.

[0084] The client's configuration parameters include, but are not limited to, the IP address and port of the dynamic address publishing module, and the access password and access mode of the first service. The IP address and port of the dynamic address publishing module are used by the client to establish a connection with the module, while the access password and access mode of the first service are used by the client to obtain the address information publicly announced by the first service. In some implementations, if the client obtains the address information publicly announced by the first service through polling, the client can first establish a connection with the dynamic address publishing module using the IP address and port specified in the configuration parameters, and then send a query request to the module, which carries the access password for the first service.

[0085] (3) If the first virtualization platform is unavailable, causing the first service to be unable to recover normally or requiring the migration of the first service, receive the service reconstruction instruction and forward the service reconstruction instruction to the address information management module.

[0086] Service reconstruction commands can be sent by the administrator to the visual monitoring module via a visual interface. Upon receiving the command, the visual monitoring module forwards it to the address information management module. The address information management module then reconstructs the first service in the second virtualization platform based on the command and updates the publicly declared address information of the first service after successful reconstruction. The dynamic address publishing module can then query the updated address information from the address information management module and publish it to clients, enabling them to access the reconstructed first service using the updated address information.

[0087] (4) Query and display the address information announced by the first service.

[0088] For example, after the address information management module configures the address information publicly announced by the first service to the first virtualization platform, the visualization monitoring module can query this address information from the address information management module and display it in the visualization interface. As another example, after the address information management module updates the address information publicly announced by the first service, the visualization monitoring module can query the updated address information from the address information management module and display it in the visualization interface. After the visualization monitoring module queries and displays the address information publicly announced by the first service, the administrator can view this address information through the visualization interface.

[0089] (5) Query and display the business data flow of the client accessing the first service.

[0090] When a client accesses the first service based on the address information publicly announced by the first service, the visualization monitoring module can query the flow of business data related to the client's access to the first service and display this flow in the visualization interface. This allows administrators to understand the client's access behavior to the first service through the visualization interface.

[0091] (6) Query and display the status of the first service.

[0092] The status of the primary service could be, for example, "The primary service is running abnormally" or "The primary service is running normally." Optionally, the visual monitoring module can query the status of the primary service from the status check module and display the queried status on the visual interface. This allows administrators to view the status of the primary service through the visual interface for monitoring and management. For example, if an administrator finds that the primary service is abnormal and unrecoverable through the visual interface, they can send a service reconstruction command to the visual monitoring module, which will then forward the command to the address information management module to rebuild the primary service.

[0093] In some implementations, taking Redis as an example, the visualization interface provided by the visualization monitoring module may include a system environment configuration and management page, a Redis service basic information management page, and a Redis service monitoring page. The system environment configuration and management page is responsible for registering and managing virtualization platform management services, and administrators can add different virtualization platform management services on this interface. The address information publishing system provided in this application embodiment utilizes the managed virtualization platform management service information to migrate and rebuild Redis services across platforms, and can also manage multiple Redis services simultaneously on different virtualization platforms. The Redis service basic information management page allows viewing the basic information of all Redis services currently managed by the system, as well as information such as the environment (virtualization platform) and cloud vendor where the current Redis service resides. On this page, administrators can not only select Redis services in batches and rebuild Redis services across platforms with a single click using the master-slave switch button, but also create new Redis services or bind existing Redis services on different virtualization platforms. On the Redis service basic information management page, administrators can view more detailed Redis service information such as the current service's access address, and can also obtain the key parameters required by the client. On the Redis service monitoring page, you can view the performance metrics for different Redis services.

[0094] It should be noted that the specific page layouts of the above-mentioned system environment configuration and management page, Redis service basic information management page, and Redis service monitoring page can be set according to actual needs. No specific restrictions are placed on the detailed layout of these pages here.

[0095] The address information publishing system provided in this application, by configuring the first service to publicly announce its first address information and publishing this first address information to clients, enables clients to directly access the first service through this first address information when accessing the first service across subnets, without needing to access the first service through a proxy server. This reduces invalid data forwarding and improves resource utilization. Furthermore, since the address information publicly announced by the first service can be dynamically published to clients, i.e., the address information publicly announced by the first service can be dynamically updated, in the event of a change in the service address of the first service, clients can quickly restore previous communication with the first service through the dynamically published address information. In the event of a migration or cross-platform reconstruction of the first service, clients can automatically and quickly access the new first service through the dynamically published address information, thereby improving the service's disaster recovery capabilities.

[0096] To facilitate understanding of the address information publishing system provided in this application's embodiments, the following description will use Redis service as an example for the first service. Please refer to [link to relevant documentation] for details. Figures 2 to 8 .

[0097] Figure 2 This is a schematic diagram illustrating the publication and management of address information according to an embodiment of this application.

[0098] Figure 2 The diagram illustrates a virtualization platform and a container platform. The virtualization platform includes a virtualization platform management service and multiple host machines. Each host machine can deploy multiple Redis services. The virtualization platform management service can schedule Redis services and interact with the address information management module. Similarly, the container platform includes a container platform management service and multiple host machines. Each host machine can deploy multiple Redis services. The container platform management service can schedule Redis services and interact with the address information management module.

[0099] Figure 2 The address information publishing system includes an address information management module, a dynamic address publishing module, a status check module, and a visual monitoring module. Among them:

[0100] The address information management module is used to adapt to different types of virtualization platforms and configure the network forwarding address or port of the Redis service to the virtualization platform (i.e., the address information announced by the Redis service, hereinafter referred to as address information), and provide a Redis service address query interface for the dynamic address publishing module.

[0101] The dynamic address publishing module is used to implement the Redis communication protocol and publish the address information of the Redis service to the client in real time. When the client queries the address information of the Redis service or when the Redis service undergoes node migration, it queries the address information management module for the latest Redis address information and notifies the client.

[0102] The status check module is used to monitor the status of all Redis service instances. When a cluster instance cannot be accessed normally, it notifies the dynamic address publishing module to check whether the cluster's address information has changed.

[0103] The visualization monitoring module provides a system configuration interface (i.e., a visual interface) and forwards key configurations to the address information management module. It also displays the address information of the Redis cluster in real time, shows the flow of business data when clients access the Redis cluster, and the health status of the Redis cluster.

[0104] It should be noted that the address information management module, dynamic address publishing module, status check module, and visual monitoring module can be deployed independently outside the virtualization platform, or across multiple virtualization platforms, to ensure that the failure of a single virtualization platform will not affect the normal operation of the entire system.

[0105] Figure 3 This is a schematic diagram illustrating the access address and port of the Redis service within an open virtualization platform, as per an embodiment of this application.

[0106] Figure 3 The illustrated example is applicable to situations where the Redis client can directly access the host machine where the Redis service resides. Figure 3 The Redis service mentioned is the open-source Redis application, which supports specifying an IP address and port. If the system specifies a publicly declared IP address and port, when a Redis client queries the Redis service for service address information, the Redis service will return the specified IP address and port to the client.

[0107] In related technologies, when the Redis service runs as a virtual machine or container within a virtualization platform, the platform cannot perceive the Redis access port or host IP address exposed externally. This application embodiment allows setting the externally exposed port and host IP address information for the Redis service using native Redis configuration commands, thus preventing Redis clients from obtaining incorrect IP addresses and ports.

[0108] Figure 3 The illustrated embodiments may include the following steps:

[0109] Step 1: The administrator configures the association between the virtualization platform and the Redis service in the visual monitoring module.

[0110] This association can indicate which virtualization platform a Redis service runs on.

[0111] Step 2: The visual monitoring module stores the association relationship in the address information management module.

[0112] Step 3: In the address information management module, set the port exposed by the Redis service and the IP address of the host machine where the Redis service is located.

[0113] Step 4: The address information management module periodically synchronizes the ports exposed by the Redis service and the IP address of the host machine where the Redis service is located.

[0114] For example, you can set up a scheduled synchronization task to synchronize the ports exposed by the Redis service and the IP address of the host machine where the Redis service is located every 30 seconds.

[0115] Step 5: The address information management module specifies that the address information announced by the Redis service is the port exposed by the Redis service and the IP address of the host machine where the Redis service is located.

[0116] After specifying the address information to be publicly announced by the Redis service, that is, after synchronizing the address information to the Redis service, the client can access the Redis service through the address information.

[0117] Step 6: The address information management module notifies the status check module to periodically check the status of the Redis service.

[0118] Step 7: The status check module accesses the Redis service periodically via the host machine IP address and the port exposed by the Redis service to check the monitoring status of the Redis service.

[0119] Steps 1 and 2 above are the basic information configuration steps. Steps 3 to 5 are the steps for the address information publishing system to keep the information synchronized with the virtualization platform and to synchronize the platform information to the Redis service. Steps 6 and 7 are the steps for starting the Redis service health check.

[0120] Figure 4 This is a schematic diagram illustrating an embodiment of the present application, showing the configuration of the Redis service access address that the virtualization platform has already made publicly available. Figure 4 The illustrated embodiment applies to virtualization platforms where the address information for a Redis service already exists and is accessible to external clients. Clients can access the Redis service through this address information. For example, if the virtualization platform has a border gateway or proxy server configured, external clients need to access the services within the virtualization platform through a specific IP address and port. Figure 4 The illustrated embodiment includes the following steps:

[0121] Step 1: The administrator configures the association between the virtualization platform and the Redis service in the visual monitoring module.

[0122] This association can indicate which virtualization platform a Redis service runs on.

[0123] Step 2: The visual monitoring module stores the association relationship in the address information management module.

[0124] Step 3: The address information management module obtains the IP address and port from the proxy server.

[0125] Step 4: The address information management module sets the IP address and port to the address information that the Redis service announces to the outside world.

[0126] It should be noted that, in Figure 4 In the scenario shown, monitoring and checking of the Redis service is not required. The virtualization platform needs to ensure the normal operation of the border gateway, proxy server, and Redis service, and at the same time, it needs to ensure that the specific Redis service can be accessed through the IP address and port of the specified border gateway or proxy server.

[0127] Figure 4 The illustrated embodiment is compatible with related technologies where clients access Redis services through a proxy server, i.e., based on... Figure 4 The embodiments shown enable a smooth transition from the related technologies of accessing Redis services through a proxy server to the address information publishing system provided in this application embodiment.

[0128] Figure 5 This is a schematic diagram illustrating a client accessing a Redis service according to an embodiment of this application.

[0129] The client communicates with the address information publishing system provided in this application embodiment via the open-source RESP protocol and obtains the address information of the Redis service from the system. Before obtaining the Redis service address information from the address information publishing system provided in this application embodiment, the Redis client needs to be configured by the administrator with the IP address, port, Redis service access password, and access mode for connecting to the system.

[0130] The address information publishing system provided in this application embodiment can manage access points for multiple Redis services simultaneously. Optionally, to distinguish different Redis services, a globally unique service name can be used to uniquely identify a Redis service. To ensure compatibility with the Redis RESP protocol, an access password or Redis service password can be constructed using the service name and a randomly generated salt. When a client submits an authentication password to the address information publishing system provided in this application embodiment, the system can identify which Redis cluster the client needs to access.

[0131] Furthermore, Redis clients can be configured with access modes including single-instance mode, master-slave mode, sentinel mode, and cluster mode. However, this embodiment only supports clients using sentinel mode or cluster mode to obtain Redis service address information. This is because Redis sentinel mode is compatible with both single-instance and master-slave modes. In other words, for Redis services running within a virtualization platform in single-instance, master-slave, or sentinel modes, Redis clients can obtain the Redis access address through sentinel mode. Detailed information regarding Redis service deployment modes can be found in related technical documentation and will not be described in detail here.

[0132] Figure 5 The illustrated embodiment includes the following steps:

[0133] Step 1: The administrator obtains the client's configuration parameters.

[0134] The configuration parameters include the IP address and port of the address information publishing system provided in this application embodiment (specifically, the IP address and port of the dynamic address publishing module), the access password and access mode of the Redis service to be accessed, and the access modes include sentinel mode and cluster mode.

[0135] Step 2: The administrator configures the relevant parameters for the client.

[0136] Here, the configuration parameters obtained in step 1 can be configured for the client.

[0137] Step 3: The client sends a query request to the dynamic address publishing module, which includes the access password for the Redis service.

[0138] In step 3, the client can access the dynamic address publishing module based on the IP address and port in the configuration parameters, and submit the authentication key to the dynamic address publishing module, that is, send a query request to the dynamic address publishing module, carrying the access password of the Redis service in the query request so that the dynamic address publishing module can authenticate.

[0139] Step 4: The dynamic address publishing module authenticates the client and determines the name of the Redis service to be accessed.

[0140] In step 4, the dynamic address publishing module can decrypt the access password in the query request and determine the name of the Redis service that the client needs to access based on the access password.

[0141] Step 5: The dynamic address publishing module queries the address information of the Redis service from the address information management module.

[0142] The dynamic address publishing module can query the address information announced by the Redis service from the address information management module based on the name of the Redis service determined in step 4.

[0143] Step 6: The address information management module returns the address information of the Redis service to the dynamic address publishing module.

[0144] Step 7: The dynamic address publishing module sends the Redis service address information to the client.

[0145] In step 7, the dynamic address publishing module can return the address information of the Redis service in RESP protocol format.

[0146] Step 8: The client accesses the Redis service based on the Redis service's address information.

[0147] It should be noted that, Figure 5 The described embodiment is a specific implementation process for the client to obtain the address information of the Redis service through polling. In practical applications, the client can also obtain the address information of the Redis service through subscription. In this case, after the dynamic address publishing module queries the address information of the Redis service from the address information management module, it can actively push the address information to the client.

[0148] Figure 6 This is a schematic diagram illustrating an embodiment of this application that detects an abnormality in the Redis service and notifies the client to switch the access address.

[0149] Redis services deployed in Sentinel or Cluster mode inherently possess the ability to automatically recover from anomalies. However, when the Redis service access address automatically switches, clients located outside the virtualization platform cannot directly switch their access address. In this embodiment, when the Redis service malfunctions, new Redis address information can be automatically detected, and Redis clients can be notified to switch addresses.

[0150] Specifically, when the Redis service encounters an anomaly, the status check module immediately detects the change in service status and notifies the dynamic address publishing module to promptly publish the change in the Redis service access address. Upon receiving the message from the status check module, the dynamic address publishing module queries the address information management module for the latest externally exposed address information of the Redis service. The address information management module, from the outset, periodically updates the externally exposed address of the Redis service (see [link to detailed process]). Figure 3(As shown in the embodiment), in this way, when the Redis service automatically recovers, the address information management module can obtain the latest address information exposed by the Redis service. After retrieving the new address information from the address information management module, the dynamic address publishing module can publish the address information to the client, and the client can resume communication with the Redis service through the new address information.

[0151] Different types of clients can obtain the latest Redis service address information in two different ways. The first way is subscription, where the dynamic address publishing module actively pushes the new address information when the Redis service address information changes. The second way is polling, where the client queries the dynamic address publishing module for the Redis service address information at regular intervals. For details on the implementation process, please refer to [link to relevant documentation]. Figure 5 The example shown.

[0152] Figure 6 The illustrated embodiment includes the following steps:

[0153] Step 1: The status check module periodically checks and finds that the Redis service is abnormal.

[0154] Step 2: The status check module notifies the dynamic address publishing module that the Redis service status is abnormal.

[0155] Step 3: The dynamic address publishing module queries the address information management module for the latest address information of the Redis service.

[0156] Step 4: The dynamic address publishing module notifies the client of the latest address information of the Redis service.

[0157] In step 4, the dynamic address publishing module can notify the client of the latest address information of the Redis service through the RESP protocol. Specifically, it can actively push the latest address information of the Redis service to the client, or send the latest address information of the Redis service to the client according to the client's query request.

[0158] Step 5: The client closes the old connection with the faulty Redis service.

[0159] Step 6: The client uses the new address information to access the Redis service.

[0160] Figure 7 This is a schematic diagram illustrating cross-platform Redis service reconstruction as an embodiment of this application.

[0161] When a virtualization platform becomes completely unavailable, causing the original Redis service to fail to recover automatically, or when business adjustments require migrating the existing Redis service to another virtualization platform, the Redis service can be rebuilt across platforms with a single click using the embodiments of this application.

[0162] During the rebuilding of the Redis service, in order to avoid the original service state from interfering with or affecting the normal operation of the client, you can try to delete the Redis service on the original platform and change the configuration of the Redis service on the original platform. However, even if this step fails, it will not interrupt the Redis service rebuilding process.

[0163] For clients using a subscription method to obtain the latest Redis service address information, the dynamic address publishing module will proactively push the rebuilt Redis service address information after the Redis service is rebuilt. For clients using a polling method to obtain the latest Redis service address information, the dynamic address publishing module can... Figure 5 The example shown sends the address information of the rebuilt Redis service to the client.

[0164] Figure 7 The illustrated embodiment includes the following steps:

[0165] Step 1: The administrator issues a cross-platform rebuild command.

[0166] The cross-platform rebuild command here instructs the Redis service to be rebuilt across platforms, specifically rebuilding the Redis service on virtual platform B and migrating the Redis service from virtual platform A to virtual platform B. Administrators can issue cross-platform rebuild commands through the visual monitoring module.

[0167] Step 2: The visual monitoring module forwards the cross-platform reconstruction instruction to the address information management module.

[0168] Step 3: The address information management module attempts to delete the relevant configurations of the original Redis service.

[0169] This involves attempting to delete the relevant configurations for the Redis service in virtualization platform A.

[0170] Step 4: The address information management module rebuilds the Redis service on the new virtualization platform using the same configuration, and periodically synchronizes the ports exposed by the Redis service and the IP address of the host machine.

[0171] This means rebuilding the Redis service in virtualization platform B, and the Redis service rebuilt in virtualization platform B is the new Redis service.

[0172] Step 5: The address information management module configures the address information that the Redis service will announce to the outside world on the new virtualization platform.

[0173] Step 6: The address information management module attempts to configure the address information declared by the original Redis service to the address information declared by the new Redis service.

[0174] Step 7: The address information management module notifies the status check module to monitor the status of the new Redis service.

[0175] Step 8: The status check module periodically checks the status of the new Redis service.

[0176] Step 9: The address information management module notifies the dynamic address publishing module Redis service that the address information has changed.

[0177] Step 10: The dynamic address publishing module queries the address information of the new Redis service from the address information management module.

[0178] Step 11: The dynamic address publishing module notifies the client of the new Redis service address information.

[0179] In step 11, the dynamic address publishing module can notify the client of the new Redis service address information through the RESP protocol. Specifically, it can actively push the new Redis service address information to the client, or send the new Redis service address information to the client based on the client's query request.

[0180] Step 12: The client establishes a connection with the new Redis service based on the new Redis service's address information.

[0181] Figure 8 This is a schematic diagram illustrating how system and Redis service monitoring information is viewed through a visual monitoring module, as per an embodiment of this application. Figures 3 to 7 In the illustrated embodiment, the visual monitoring module provides administrators with a visual interactive interface for system configuration, parameter querying, and command issuance. However, in addition, the visual monitoring module periodically queries and records management information from each module and presents the administrator with monitoring information for the entire system and the Redis service. For example... Figure 8 As shown, Figure 8 The illustrated embodiment includes the following steps:

[0182] Step 1: The visual monitoring module periodically queries the monitoring data of client subscriptions or polling Redis address information.

[0183] Step 2: The visual monitoring module periodically queries the address information of different Redis services.

[0184] Step 3: The visualization monitoring module periodically queries the running status and monitoring data of different Redis services.

[0185] Step 4: The administrator views the monitoring data of the system operation and the monitoring data of the Redis service.

[0186] The visualization monitoring module provides a visual interface, allowing administrators to view monitoring data for system operation and the Redis service.

[0187] based on Figures 2 to 8 The address information publishing system provided in this application, as shown in the embodiments, can achieve at least the following technical effects:

[0188] (1) Client access addresses can be controlled as needed. In conjunction with the service port mapping function in the existing cloud service environment, clients can access cache services across private subnets. Clients and cache servers can belong to different availability zones or cloud service providers.

[0189] (2) It can monitor the health status of the cache service in real time and support automatic failover of the cache service in the availability zone or data center.

[0190] (3) Compared with the full data proxy solution in related technologies, it can effectively reduce the business data transfer process and maximize the performance of client access to cache services.

[0191] (4) It is compatible with the full data proxy scheme in related technologies. The caching service using the full data proxy can be smoothly upgraded to the scheme provided in the embodiments of this application.

[0192] (5) Supports rapid reconstruction of cache services across availability zones, cloud services, and availability zones. Clients can automatically access the reconstructed cache services without modifying the configuration.

[0193] (6) Supports the visual caching service across availability zones, cloud services, and availability zones for disaster recovery and reconstruction.

[0194] This application also provides a method for publishing address information. This method can be executed by the address information publishing system provided in this application, or it can be executed by other devices, apparatuses or systems, without specific limitations.

[0195] Figure 9 This is a flowchart illustrating an embodiment of the address information publishing method of this application. Figure 9 The method for publishing the address information shown includes the following steps.

[0196] S902: Configure the first address information to be publicly announced by the first service.

[0197] The first service can be a Redis service or other caching service; no specific restrictions are made here.

[0198] The first service can be deployed within the first virtualization platform (the first service can run within the first virtualization platform as a virtual machine or container). When the first service is deployed within the first virtualization platform, the first address information publicly advertised by the first service can be configured on the first virtualization platform. This first address information is used by clients to access the first service across subnets, and may include the port exposed by the first service and the IP address of the host machine where the first service resides.

[0199] Optionally, when configuring the first address information to be publicly announced by the first service on the first virtualization platform, the configuration can be done using the native configuration commands of the first service. For example, if the first service is a Redis service, the native configuration commands of Redis can be used to configure the first address information to be publicly announced by the Redis service.

[0200] In some implementations, after configuring the first address information to be publicly announced by the first service on the first virtualization platform, this first address information can be synchronized or sent to the first service, that is, the address information publicly announced by the first service can be designated as this first address information. Thus, after the first address information is subsequently published to the client, the client can access the first service based on this first address information.

[0201] S904: Publish the first address information to the client. The client and the first service are located in different virtual subnets. The first address information is used by the client to access the first service.

[0202] After synchronizing the first address information to the first service, the first address information can be published to clients. Clients can then access the first service based on this first address information. Compared to accessing the first service through a proxy server, this reduces invalid data forwarding and improves resource utilization.

[0203] It should be noted that in S902 above, after configuring the first address information to be publicly announced by the first service, this first address information can also be updated periodically. If the first address information changes, the updated address information can be published to the client, i.e., the address information publicly announced by the first service is dynamically published to the client. In this way, by dynamically updating and publishing the address information publicly announced by the first service, it is possible to ensure that clients can quickly restore previous communication with the first service through the dynamically published address information when the service address of the first service changes. Furthermore, in the event of a migration or cross-platform reconstruction of the first service, it is guaranteed that clients can automatically and quickly access the new first service through the dynamically published address information, thereby improving the service's disaster recovery capabilities.

[0204] In some implementations, after publishing the first address information to the client, the following steps may be included:

[0205] Check the status of the first service;

[0206] If the status of the first service is determined to be abnormal and it automatically recovers to normal, the first address information will be updated to the second address information;

[0207] The client receives a second address, which is used by the client to access the first service after normal access is restored.

[0208] When checking the status of the first service, it can be checked periodically, for example, every 30 seconds. In this embodiment, the first service can be deployed in sentinel mode or cluster mode. The first service deployed in sentinel mode or cluster mode inherently possesses the ability to automatically recover from anomalies. After the first service becomes abnormal, based on its automatic recovery capability, it can automatically recover to normal operation. After the first service recovers to normal, its address information will also change accordingly. At this time, the client will be unable to access the first service based on the previous address information, and communication between the client and the first service will be disconnected. In this situation, the changed address information of the first service can be obtained and updated to the address information publicly announced by the first service, i.e., the second address information. Then, the second address information is published to the client, allowing the client to re-access the first service through this second address information. Thus, communication with the first service can be quickly restored through automatic address information switching. The second address information may include the port exposed by the first service after recovery and the IP address of the host machine where the first service resides.

[0209] In some scenarios, the first service may need to be rebuilt or migrated. For example, the first virtualization platform may become unavailable for some reason, causing the first service to fail to automatically recover in the event of an anomaly. Alternatively, based on business needs, the first service may need to be migrated from the first virtualization platform to another virtualization platform. In these scenarios, the embodiments of this application can rebuild the first service across platforms with a single click and update the address information of the first service to the client, enabling the client to automatically and quickly access the new first service.

[0210] Specifically, in cases where it is necessary to migrate or rebuild the primary service, the following steps may be included:

[0211] Rebuild the first service in the second virtualization platform;

[0212] Update the address information publicly announced by the first service to the third address information;

[0213] The third address information is published to the client, which is used by the client to access the first service rebuilt in the second virtualization platform.

[0214] The third address information may include the port exposed by the first service rebuilt in the second virtualization platform and the IP address of the host machine where the first service resides. After rebuilding the first service in the second virtualization platform, the port exposed by the first service and the IP address of the host machine can be obtained, i.e., the third address information. The address information announced by the first service can be updated to the third address information, and then the third address information is published to the client. The client can restore communication with the first service through the third address information. Thus, in scenarios where the first service needs to be rebuilt or migrated, the client can automatically and quickly access the new first service.

[0215] Optionally, during the reconstruction of the first service, to avoid interference or impact on the normal operation of the client due to the original service status, at least one of the following steps may be included:

[0216] Remove the relevant configurations for the first service from the first virtualization platform;

[0217] Update the first address information of the first service in the first virtualization platform to the third address information.

[0218] It should be noted that, since the first virtualization platform may be inaccessible when performing at least one of the above operations, the above operations may not be successfully performed. Therefore, in practical applications, it is possible to try to perform at least one of the above operations, and even if it fails, the reconstruction process of the first service will not be interrupted.

[0219] In this embodiment of the application, when publishing the address information publicly announced by the first service (i.e., the aforementioned first address information, second address information, or third address information) to the client, it can be done in various ways. In some implementations, publishing the address information publicly announced by the first service to the client may include:

[0220] The address information announced by the first service is proactively pushed to the client.

[0221] In other words, after configuring the address information to be publicly announced by the first service, this publicly announced address information can be proactively pushed to the client. When the address information to be publicly announced by the first service changes, the updated address information can be proactively pushed to the client.

[0222] In some implementations, publishing the address information publicly announced by the first service to the client may include:

[0223] Upon receiving a query request from a client, the address information publicly announced by the first service is sent to the client.

[0224] In other words, after the address information publicly announced by the first service is configured, it will only be sent to the client upon receiving a query request from the client. Furthermore, when the address information publicly announced by the first service changes, the updated address information will only be sent to the client upon receiving a query request from the client.

[0225] For different types of clients, there are at least two different ways to obtain the address information publicly announced by the first service: subscription and polling. For the first method, the address information publicly announced by the first service can be proactively pushed to the client. For the second method, the address information publicly announced by the first service can be sent to the client based on a query request.

[0226] When a client obtains the address information publicly announced by the first service through polling, the client's query request may include the access password for the first service. Therefore, sending the publicly announced address information of the first service to the client upon receiving the client's query request can include the following steps:

[0227] Upon receiving a query request from a client, the client is authenticated based on the access password;

[0228] Once the client is successfully authenticated, the address information publicly announced by the first service will be sent to the client.

[0229] Specifically, for cases where the client obtains the address information publicly announced by the first service through polling, corresponding parameters can be pre-configured for the client. These parameters include, but are not limited to, the access password (or service password) and access mode of the first service. In this embodiment, multiple access points to the first service can be managed simultaneously. To distinguish different first services, a globally unique service name can be used to uniquely identify each first service. Furthermore, for communication protocol compatibility, the access password for the first service can be constructed or generated using the service name and a randomly generated salt. The access mode of the first service can be used by the client to obtain the address information publicly announced by the first service. In this embodiment, the access mode of the first service can include sentinel mode and cluster mode, meaning the client supports obtaining the address information publicly announced by the first service through either sentinel mode or cluster mode. However, it should be noted that when the client obtains the address information publicly announced by the first service in sentinel mode, it can obtain address information in either single-instance mode or master-slave mode, meaning sentinel mode is compatible with both single-instance and master-slave modes.

[0230] When a client obtains the address information publicly announced by the first service through polling, it can send a query request, which may include the access password for the first service. Upon receiving the client's query request, the server can authenticate the client based on the access password. If the client is successfully authenticated and the server confirms that the service accessed by the client is the first service, the server can send the publicly announced address information of the first service to the client.

[0231] In some implementations, when publishing the address information (the aforementioned first address information, second address information, or third address information) announced by the first service to the client (actively pushing the address information to the client or sending it to the client according to a query request), the following steps may be included:

[0232] The address information announced by the first service is published to the client through the first communication protocol, which includes the Redis serialization protocol RESP.

[0233] In other words, when actively pushing or sending the address information announced by the first service to the client, this can be achieved through the first communication protocol. Specifically, the first communication protocol can be used to actively push or send the address information announced by the first service to the client. This first communication protocol may include, but is not limited to, the RESP protocol, and correspondingly, the first service may include, but is not limited to, the Redis service.

[0234] The address information publishing method provided in this application is compatible with related technologies where clients access the first service through a proxy server. In other words, this application can be applied to scenarios where the address information of the first service, accessible to external clients, already exists within the virtualization platform. For example, if the virtualization platform has a proxy server (or border gateway), and clients outside the virtualization platform need a specific IP address and port to access the first service within the virtualization platform, then based on the address information publishing method provided in this application, clients can access the first service through the proxy server.

[0235] Specifically, if a proxy server is set up on the first virtualization platform, the following steps may be included:

[0236] Obtain the fourth address information of the proxy server;

[0237] The client receives a fourth address, which is used by the client to access the first service through the proxy server.

[0238] The fourth address information may include the IP address and port of the proxy server, which is used by the client to access the first service through the proxy server. When a proxy server is set up in the first virtualization platform, by obtaining the address information of the proxy server and exposing this address information to the client (actively pushing the fourth address information to the client or sending the fourth address information to the client according to the client's query request), the client can access the first service through the fourth address information. Thus, a smooth transition can be achieved from the related technology's scheme of accessing the first service through a proxy server to the address information publishing method provided in this application embodiment.

[0239] It should be noted that in the scenario where the first virtualization platform is configured with a proxy server, the status of the first service does not need to be monitored and checked. Instead, the first virtualization platform ensures the normal operation of the proxy server (or border gateway) and the first service, while ensuring that the client can access the first service through the fourth address information. In this embodiment, it is only necessary to obtain the fourth address information from the proxy server and expose it to the client.

[0240] Optionally, in some implementations, the address information publicly announced by the first service, the flow of business data from client access to the first service, and the status of the first service can be displayed through a visual interface for administrator viewing. Furthermore, administrators can also use the visual interface to configure the relationships between different virtualization platforms and services, store client configuration parameters, and issue service rebuild commands.

[0241] The address information publishing method provided in this application, by configuring the first address information publicly announced by the first service and publishing this first address information to the client, enables the client to directly access the first service through the first address information when accessing the first service across subnets, without needing to access the first service through a proxy server. This reduces invalid data forwarding and improves resource utilization. Furthermore, since the address information publicly announced by the first service can be dynamically published to the client, i.e., the address information publicly announced by the first service can be dynamically updated, in the event of a change in the service address of the first service, the client can quickly restore communication with the first service using the dynamically published address information. In the event of a migration or cross-platform reconstruction of the first service, the client can automatically and quickly access the new first service using the dynamically published address information, thereby improving the service's disaster recovery capabilities.

[0242] The foregoing has described specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0243] Figure 10 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Please refer to it. Figure 10 At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and memory. The memory may include main memory, such as high-speed random-access memory (RAM), or non-volatile memory, such as at least one disk drive. Of course, the electronic device may also include other hardware required for other business operations.

[0244] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 10The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0245] Memory is used to store programs. Specifically, programs may include program code, which includes computer operation instructions. Memory may include main memory and non-volatile memory, and provides instructions and data to the processor.

[0246] The processor reads the corresponding computer program from non-volatile memory into main memory and then runs it, forming a mechanism for distributing address information at the logical level. The processor executes the program stored in memory and specifically performs the following operations:

[0247] Configure the primary address information to be publicly announced by the primary service;

[0248] The first address information is published to the client, wherein the client and the first service are located in different virtual subnets, and the first address information is used by the client to access the first service.

[0249] The above is as stated in this application. Figure 10 The method executed by the address information publishing device disclosed in the illustrated embodiment can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0250] The electronic device can also perform Figure 9 The method, and the device for publishing address information in Figure 9 The functions described in the illustrated embodiments will not be repeated here.

[0251] Of course, in addition to software implementation, the electronic device of this application does not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. In other words, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0252] This application also discloses a computer-readable storage medium that stores one or more programs, the programs including instructions that, when executed by a portable electronic device including multiple applications, enable the portable electronic device to perform... Figure 9 The method of the illustrated embodiment is specifically used to perform the following operations:

[0253] Configure the primary address information to be publicly announced by the primary service;

[0254] The first address information is published to the client, wherein the client and the first service are located in different virtual subnets, and the first address information is used by the client to access the first service.

[0255] This application also proposes a computer program product comprising a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps in the above-described method embodiments for publishing address information.

[0256] In summary, the above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

[0257] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0258] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0259] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0260] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

Claims

1. A system for publishing address information, comprising: an address information management module configured to configure first address information announced by a first service; a dynamic address publishing module coupled to the address information management module, configured to query the first address information from the address information management module, and publish the first address information to a client, wherein the client and the first service are located in different virtual subnets, and the first address information is used for the client to access the first service. 2.The system of claim 1, further comprising: a state checking module coupled to the dynamic address publishing module, configured to check a state of the first service, and notify the dynamic address publishing module that the state of the first service is abnormal in a case that the state of the first service is determined to be abnormal. 3.The system of claim 2, wherein: the address information management module is further configured to update the first address information to second address information in a case that the first service is restored to normal; the dynamic address publishing module is further configured to query the second address information from the address information management module in a case that the state of the first service is determined to be abnormal, and publish the second address information to the client, wherein the second address information is used for the client to access the first service restored to normal. 4.The system of claim 1, wherein the first service is deployed in a first virtualization platform, and wherein: the address information management module is further configured to rebuild the first service in a second virtualization platform, and update address information announced by the first service to third address information; the dynamic address publishing module is further configured to query the third address information from the address information management module, and publish the third address information to the client, wherein the third address information is used for the client to access the first service rebuilt in the second virtualization platform. 5.The system of any one of claims 1 to 4, wherein the dynamic address publishing module is configured to at least one of: actively push address information announced by the first service to the client; send address information announced by the first service to the client in a case that a query request of the client is received; wherein the address information announced by the first service comprises the first address information, second address information, or third address information. 6.The system of claim 5, wherein the query request comprises an access password of the first service; the dynamic address publishing module is configured to authenticate the client according to the access password, and send address information announced by the first service to the client in a case that the client is authenticated successfully. 7.The system of claim 1, wherein a first virtualization platform where the first service is located is provided with a proxy server, and wherein: the address information management module is further configured to obtain fourth address information of the proxy server. The dynamic address publishing module is configured to obtain the fourth address information from the address information management module, and publish the fourth address information to the client, wherein the fourth address information is used by the client to access the first service through the proxy server.

8. An address information publishing method, comprising: configuring first address information announced by a first service to the outside; publishing the first address information to a client, wherein the client and the first service are located in different virtual subnets, and the first address information is used by the client to access the first service.

9. The method of claim 8, further comprising: checking a state of the first service; in a case where it is determined that the state of the first service is abnormal and automatically recovers to normal, updating the first address information to second address information; publishing the second address information to the client, wherein the second address information is used by the client to access the first service that recovers to normal.

10. The method of claim 8, the first service deployed in a first virtualization platform; The method further comprises: rebuilding the first service in a second virtualization platform; updating address information announced by the first service to the outside to third address information; publishing the third address information to the client, wherein the third address information is used by the client to access the first service rebuilt in the second virtualization platform.

11. The method of claim 10, further comprising at least one of: deleting related configurations of the first service in the first virtualization platform; updating the first address information of the first service in the first virtualization platform to the third address information.

12. The method of any one of claims 8 to 11, further comprising: actively pushing address information announced by the first service to the outside to the client, wherein the address information announced by the first service to the outside comprises the first address information, second address information, or third address information.

13. The method of any one of claims 8 to 11, further comprising: in a case where a query request of the client is received, sending address information announced by the first service to the outside to the client, wherein the address information announced by the first service to the outside comprises the first address information, second address information, or third address information.

14. The method of claim 13, the query request including an access password for the first service. The sending, in a case where the query request of the client is received, the address information announced by the first service to the outside to the client, comprises: in a case where the query request of the client is received, authenticating the client according to the access password; in a case where the client is authenticated successfully, sending the address information announced by the first service to the outside to the client.

15. The method of any one of claims 8 to 11, wherein the first service comprises a Redis service; and the method further comprises: publishing, to the client, address information announced by the first service to the outside through a first communication protocol, wherein the first communication protocol comprises a Redis serialization protocol RESP, and the address information announced by the first service to the outside comprises the first address information, second address information, or third address information. 16.The method of claim 15, wherein the address information announced by the first service comprises a port exposed by the first service and an IP address of a host where the first service is located. 17.The method of claim 8, wherein a first virtualization platform where the first service is located is provided with a proxy server, and the method further comprises: obtaining fourth address information of the proxy server; and publishing the fourth address information to the client, wherein the fourth address information is used by the client to access the first service through the proxy server. 18.An electronic device comprising: a processor; a memory for storing instructions executable by the processor; wherein the processor is configured to execute the instructions to implement the method of any one of claims 8-17. 19.A computer-readable storage medium storing instructions which, when executed by a processor of an electronic device, cause the electronic device to perform the method of any one of claims 8-17. 20.A computer program product comprising a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of the method of any one of claims 8-17. ​ ​ ​ ​ ​

Images