Service registration center, service management method and electronic equipment

Abstract

The invention provides a service registration center, a service management method and electronic equipment, and the service registration center comprises a network agent module and a data fragmentation module. Wherein the network agent module is deployed in a network forwarding layer, and is used for receiving a service request sent by a service provider client and / or a service consumer client, determining a target data fragment based on the service request, and forwarding the service request to the target data fragment; the data fragmentation module is deployed on a data storage layer and is used for storing a mapping relation between the service information and the instance information; wherein the target data fragment is used for receiving the service request forwarded by the network agent module, and executing a corresponding operation based on the service request. According to the scheme, the network forwarding layer and the data storage layer are separately designed, so that resource allocation is more reasonable, the problem of resource competition possibly generated when a single module processes a storage task and a forwarding task at the same time is avoided, and the performance of the service registration center is improved.

Description

Technical Field

[0001] This application relates to the field of computer technologies, and in particular, to a service registration center, a service management method, and an electronic device. Background Art

[0002] Microservices is a software development architecture style that aims to improve the scalability, flexibility, and continuous delivery and deployment capabilities of a system by building an application as a series of small, autonomous services.

[0003] In scenarios such as system startup, large-scale deployment, or frequent updates of service instances, there will be a large number of registration, update, and other requirements for service instances in a short period of time. In related technologies, however, the network forwarding and data storage of the registration center are generally integrated in the same server, and the horizontal expansion of network forwarding and data storage is limited to the performance of a single server, resulting in poor performance of the registration center in the face of high-concurrency scenarios. Summary of the Invention

[0004] The purpose of the embodiments of this application is to provide a service registration center, a service management method, and an electronic device to solve the above problems.

[0005] In a first aspect, the embodiments of this application provide a service registration center, which includes: a network proxy module and a data sharding module; where:

[0006] The network proxy module is deployed in the network forwarding layer and is used to receive service requests sent by a service provider client and / or a service consumer client, determine a target data shard based on the service request, and forward the service request to the target data shard;

[0007] The data sharding module is deployed in the data storage layer and is used to store the mapping relationship between service information and instance information; where the target data shard is used to receive the service request forwarded by the network proxy module and perform corresponding operations based on the service request.

[0008] In the implementation process of the above solution, by separating the design of the network forwarding layer and the data storage layer, on the one hand, it can make the resource allocation more reasonable, avoid the resource competition problem that may occur when a single module processes storage tasks and forwarding tasks simultaneously, thereby improving the performance of the above service registry; on the other hand, the horizontal expansion of the network forwarding layer and the data storage layer is no longer limited to the performance of a single server. In the face of high-concurrency scenarios, the network forwarding layer and the data storage layer can each be horizontally expanded and optimized, which is conducive to improving the scalability of the above service registry; on the other hand, different business scenarios may have inconsistent requirements for forwarding tasks and storage tasks. With the separated design of the network forwarding layer and the data storage layer, the service registry can optimize and adjust the network forwarding layer and the data storage layer according to different business requirements, enabling the above service registry to better adapt to business changes and expansion needs, which is conducive to improving the adaptability of the above service registry.

[0009] In one implementation manner of the first aspect, the network proxy module is used for:

[0010] Receiving a service registration request sent by a service provider client; wherein, the service registration request carries service information and instance information of the service to be registered; determining a target data shard of the service to be registered based on the service information of the service to be registered; forwarding the service registration request to the target data shard;

[0011] The target data shard in the data shard module is used for:

[0012] After receiving the service registration request forwarded by the network proxy module, persistently storing the mapping relationship between the service information and the instance information of the service to be registered.

[0013] In the implementation process of the above solution, the network forwarding layer focuses on the forwarding of service requests, and can quickly and efficiently forward the service registration request to the target data shard, avoiding the overload of the data storage layer due to directly processing a large number of network requests, enabling the data storage layer to focus on data storage and management, giving full play to its storage performance advantages, and further improving the service request processing performance of the above service registry.

[0014] In one implementation manner of the first aspect, the network proxy module is used for:

[0015] Receiving a service query request sent by a service consumer client; wherein, the service query request carries service information of the service to be queried; determining a target data shard of the service to be queried based on the service information of the service to be queried; forwarding the service query request to the target data shard; and, after receiving the instance information returned by the target data shard, returning the instance information to the service consumer client;

[0016] The target data shard in the data shard module is used for:

[0017] After receiving the service query request forwarded by the network proxy module, query the instance information corresponding to the service query request and return the instance information to the network proxy module.

[0018] In the implementation process of the above solution, in the service discovery scenario, the network forwarding layer and the data storage layer focus on request forwarding and data storage management respectively. On the one hand, in the face of high-concurrency scenarios, the above solution can quickly respond to the service query requests of service consumers, which is beneficial to improving the query response efficiency of the above service registry; on the other hand, the target data shards of the data storage layer can quickly respond to service query requests and return the corresponding instance information in a timely manner, which is beneficial to improving the request processing performance of the above service registry.

[0019] In one implementation manner of the first aspect, the network proxy module is used to:

[0020] Receive the service deregistration request sent by the service provider client; wherein, the service deregistration request carries the service information and instance information of the service to be deregistered; based on the service information of the service to be deregistered, determine the target data shard of the service to be deregistered; forward the service deregistration request to the target data shard;

[0021] The target data shard in the data shard module is used to:

[0022] After receiving the service deregistration request forwarded by the network proxy module, delete the service information and instance information of the service to be deregistered stored.

[0023] In the implementation process of the above solution, the service registry supports the deregistration function, can realize the timely update of service information, avoid request failures or resource waste caused by calling unavailable services, and is beneficial to improving the applicability of the above service registry.

[0024] In one implementation manner of the first aspect, the network proxy module is further used to:

[0025] Receive the service heartbeat signal sent by the service provider client at a fixed period; wherein, the service heartbeat signal carries the service information and instance information; based on the service information carried by the service heartbeat signal, determine the target data shard corresponding to the service heartbeat signal; forward the service heartbeat signal to the target data shard;

[0026] The target data shard in the data shard module is further used to:

[0027] After receiving the service heartbeat signal forwarded by the network proxy module, update the last survival time of the instance corresponding to the instance information.

[0028] In the implementation process of the above solution, on the one hand, the service registry in the above solution can timely detect faulty instances through service heartbeat signals, avoiding routing traffic to unavailable instances, thereby achieving high availability of the service; on the other hand, by updating the latest survival time of the service in the target data shard, the dynamic update of the service status is realized, so that the service registry can make more reasonable traffic distribution decisions based on the service status, thereby optimizing the performance and response speed of the service registry.

[0029] In an implementation manner of the first aspect, the service registry further includes: a configuration data module;

[0030] The data shard module is further configured to report metadata information and data shard topology structure information to the configuration data module;

[0031] The configuration data module is deployed in the control and operation and maintenance layer, and is configured to obtain the metadata information and data shard topology structure information reported by the data shard module, and forward the metadata information and data shard topology structure information to the network proxy module.

[0032] In the implementation process of the above solution, the service registry can realize the state awareness of data shards through the configuration data module. On the one hand, the data shard state perceived by the service registry can be transmitted to the network proxy module, so that the network proxy module can make reasonable traffic routing decisions based on the data shard state, which is beneficial to improving the performance and response speed of the service registry; on the other hand, the operation and maintenance personnel can also obtain the state information of the data shard through the configuration data module, so as to perform corresponding operation and maintenance operations in a timely manner, which is beneficial to improving the operation and maintenance efficiency of the above service registry.

[0033] In an implementation manner of the first aspect, the service registry further includes: a fault detection module;

[0034] The fault detection module is deployed in the control and operation and maintenance layer, and is configured to periodically check the availability of each data shard in the data shard module. If a data shard fails, a fault instruction is sent to the configuration data module;

[0035] The configuration data module is further configured to:

[0036] After receiving the fault instruction sent by the fault detection module, perform isolation operation or hemostasis operation on the faulty shard.

[0037] In the implementation process of the above solution, the service registry performs fault detection on data shards through the fault detection module. On the one hand, it can timely detect faulty instances, thus avoiding misrouting traffic to faulty instances and reducing the impact of service unavailability on user experience, which is beneficial to improving the real-time availability of services in the above service registry. On the other hand, performing isolation operations or hemostasis operations in a timely manner after a fault is detected is beneficial to improving the reliability and fault tolerance of the service registry.

[0038] In one implementation manner of the first aspect, the service registry further includes: a control and management module; the control and management module is deployed in the control and operation and maintenance layer and provides an operation and maintenance control plane service for the operation and maintenance client.

[0039] The control and management module is used for:

[0040] Receiving an operation and maintenance instruction sent by the operation and maintenance client; where the operation and maintenance instruction includes at least one of a traffic removal instruction, a traffic diversion instruction, a traffic limiting instruction, and an operation and maintenance query instruction.

[0041] Issuing an operation and maintenance task to the data shard module and / or the configuration data module according to the operation and maintenance instruction.

[0042] In the implementation process of the above solution, operation and maintenance personnel can centrally manage each module in the service registry through the operation and maintenance control plane service, realizing the centralized management of the service registry, which is beneficial to simplifying the operation and maintenance operations of the above service registry. On the other hand, operation and maintenance personnel can quickly obtain the running status and performance metrics of the service registry through the control plane service, timely discover and solve problems, which is beneficial to improving the operation and maintenance efficiency of the above service registry.

[0043] In one implementation manner of the first aspect, the network proxy module is further used for:

[0044] Converting the write mode from the shard write mode to the broadcast write mode after receiving a shard migration request; where the shard migration request carries the shard information of the shard to be migrated.

[0045] Taking the shard to be migrated offline after the data shards in the data shard module converge.

[0046] Converting the write mode from the broadcast write mode to the shard write mode.

[0047] In the implementation process of the above solution, after receiving a shard migration request, the network proxy module converts the write mode from the shard write mode to the broadcast write mode, enabling smooth traffic switching without large-scale restarts or service interruptions, which is beneficial to improving the service continuity of the above service registry.

[0048] In an implementation of the first aspect, multiple replicas are respectively set for each data shard in the data sharding module; data consistency is achieved among the multiple replicas of each data shard by means of a consistency algorithm.

[0049] In the implementation process of the above solution, by setting replicas for data shards, when a data shard node fails, the replica node can continue to provide services, which is beneficial to improving the disaster tolerance ability of the above service registry; on the other hand, by distributing data shard replicas on multiple nodes, read and write operations can be shared among different nodes, which is beneficial to improving the load balancing of the above service registry and improving the performance of the service registry.

[0050] In a second aspect, an embodiment of the present application provides a service management method, which is applied to a network proxy module of a service registry. The method includes: receiving a service registration request sent by a service provider client; wherein the service registration request carries service information and instance information of the service to be registered; determining a target data shard of the service to be registered based on the service information of the service to be registered; forwarding the service registration request to the target data shard so that the target data shard persistently stores the mapping relationship between the service information and the instance information of the service to be registered.

[0051] In an implementation of the second aspect, the method further includes: receiving a service query request sent by a service consumer client; wherein the service query request carries service information of the service to be queried; determining a target data shard of the service to be queried based on the service information of the service to be queried; forwarding the service query request to the target data shard so that the target data shard queries and returns the instance information corresponding to the service query request; after receiving the instance information returned by the target data shard, returning the instance information to the service consumer client.

[0052] In a third aspect, an embodiment of the present application provides an electronic device, including: a processor, a memory, and a communication bus, wherein the processor and the memory complete communication with each other through the communication bus; computer program instructions executable by the processor are stored in the memory, and when the computer program instructions are read and run by the processor, the method provided by the second aspect or any possible implementation of the second aspect is executed.

[0053] Other features and advantages of the present application will be described in the subsequent specification, and part of them will become obvious from the specification, or can be understood by implementing the embodiments of the present application. The objectives and other advantages of the present application can be achieved and obtained through the structures specifically pointed out in the written specification, claims, and drawings. Description of the Drawings

[0054] To more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings required to be used in the embodiments of the present application. It should be understood that the following drawings only show some embodiments of the present application, and therefore should not be regarded as limiting the scope. For those of ordinary skill in the art, without creative efforts, other related drawings can also be obtained based on these drawings.

[0055] Figure 1 Schematic diagram of the architecture of the service registration center provided by the embodiments of the present application;

[0056] Figure 2 Schematic diagram of the interaction process when the service registration center provided by the embodiments of the present application implements the service registration function;

[0057] Figure 3 Schematic diagram of the interaction process when the service registration center provided by the embodiments of the present application implements the service discovery function;

[0058] Figure 4 Schematic diagram of the interaction process when the service registration center provided by the embodiments of the present application implements the service deregistration function;

[0059] Figure 5 Schematic diagram of the interaction process when the service registration center provided by the embodiments of the present application implements the heartbeat detection function;

[0060] Figure 6 Another schematic diagram of the architecture of the service registration center provided by the embodiments of the present application;

[0061] Figure 7 Schematic diagram of the interaction process when the service registration center provided by the embodiments of the present application implements the data shard status awareness function;

[0062] Figure 8 Schematic diagram of the interaction process when the service registration center provided by the embodiments of the present application implements the fault detection function;

[0063] Fig. 9 Schematic diagram of the process of the service management method provided by the embodiments of the present application;

[0064] Fig.10 Another schematic diagram of the process of the service management method provided by the embodiments of the present application;

[0065] Fig.11 Schematic diagram of the structure of the electronic device provided by the embodiments of the present application. Detailed implementation manners

[0066] The following will describe the technical solutions in the embodiments of the present application in conjunction with the accompanying drawings in the embodiments of the present application. The following embodiments are only used to more clearly illustrate the technical solutions of the present application, so they are only examples and cannot be used to limit the protection scope of the present application.

[0067] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the technical field to which this application belongs; the terms used herein are only for the purpose of describing specific embodiments and are not intended to limit this application; the terms "including" and "having" and any variations thereof in the specification and claims of this application and the above drawings are intended to cover non-exclusive inclusion. In the description of the embodiments of this application, the meaning of "a plurality" is more than two, unless otherwise specifically defined.

[0068] Referring to "embodiments" herein means that the specific features, structures or characteristics described in connection with the embodiments can be included in at least one embodiment of this application. The phrase appears in various places in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will explicitly and implicitly understand that the embodiments described herein can be combined with other embodiments.

[0069] In the description of the embodiments of this application, the term "and / or" is only a relationship describing the associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " herein generally represents an "or" relationship between the associated objects before and after.

[0070] The embodiments of this application provide a service registration center. By separating the design of the network forwarding layer and the data storage layer, on the one hand, it can make the resource allocation more reasonable, avoid the resource competition problem that may occur when a single module processes storage tasks and forwarding tasks simultaneously, thereby improving the performance of the above service registration center; on the other hand, the horizontal expansion of the network forwarding layer and the data storage layer is no longer limited to the performance of a single server. In the face of high-concurrency scenarios, the network forwarding layer and the data storage layer can be horizontally expanded and optimized respectively, which is beneficial to improving the scalability of the above service registration center; on the other hand, the requirements for forwarding tasks and storage tasks in different business scenarios may be inconsistent. With the separate design of the network forwarding layer and the data storage layer, the service registration center can optimize and adjust the network forwarding layer and the data storage layer according to different business needs, so that the above service registration center can better adapt to business changes and expansion requirements, which is beneficial to improving the adaptability of the above service registration center.

[0071] Please refer to Figure 1Schematic diagram of the architecture of the shown service registry. The service registry 100 provided by the embodiments of the present application may include:

[0072] A network proxy module 110, deployed in the network forwarding layer, for receiving service requests sent by service provider clients and / or service consumer clients, determining a target data shard based on the service requests, and forwarding the service requests to the target data shard in the data shard module 120;

[0073] A data shard module 120, deployed in the data storage layer, for storing the mapping relationship between service information and instance information; wherein, the target data shard is used to receive the service requests forwarded by the network proxy module 110 and perform corresponding operations based on the service requests.

[0074] The above service registry 100 can be used as one of the core components in the microservices architecture for managing services in the microservices architecture. The management content of services includes but is not limited to: service registration, service discovery, service deregistration, storage status awareness, service heartbeat awareness, fault detection, service migration, cluster operation and maintenance, etc.

[0075] The above service provider refers to a microservice that provides a certain function or data. The service provider exposes one or more API interfaces for other services to call. The service provider is usually responsible for executing specific business logics, processing data, and returning the results to the caller. The above service consumer refers to a microservice that calls the API interfaces provided by other microservices to implement its own functions. The service consumer usually does not directly process business logics, but obtains the required data or services by calling the service provider. In the microservices architecture, the service consumer and the service provider usually interact through lightweight communication mechanisms (such as HTTP, gRPC), and this interaction method enables decoupling between services to improve scalability and maintainability.

[0076] The above network forwarding layer and data storage layer adopt a separated design, and they can be deployed in the same device (such as a server) or in different devices.

[0077] The above network proxy module 110 can provide rich protocol API support, can adapt to multiple currently popular service discovery client protocols, such as Nacos standard API and some Consul standard APIs, etc., and can also support the private GRPC long connection protocol, making the network forwarding layer have good compatibility and facilitating access by various other cloud native facilities and clients.

[0078] In addition, the above-mentioned network proxy module 110 can implement the traffic management function for services. Based on the traffic management function, advanced strategies such as gray release and blue-green release can be implemented, and the call path between services can be controlled through routing rules.

[0079] It can be understood that the storage function of the above-mentioned service registry 100 is mainly used to store the mapping relationship between service information and instance information, and a key-value storage method can be adopted. Among them, the key is service information, and the value is instance information.

[0080] The above-mentioned service information refers to the information used to identify and describe services, which can include the name, type, version, description, tags, etc. of the service. Instance information refers to the detailed information of the specific running instances of the service, which can include the IP address, port number, status, health status, metadata information, etc. of the instance. It can be understood that service information is abstract, which mainly describes the overall characteristics and functions of the service and is the main basis for service consumers to select services. Instance information is specific, which mainly describes the detailed information of the specific running instances of the service and is the information required for service consumers to communicate with service providers actually. Taking service discovery as an example, service consumers usually first query the service registry according to service information to obtain all instance information related to the service, and then communicate with the service instance according to the instance information.

[0081] The above-mentioned data sharding module 120 stores the mapping relationship between service information and instance information in a data sharding manner. Data sharding refers to dividing a large database or data set into multiple data shards according to specific rules, and then storing these data shards in different storage nodes respectively to improve the performance of the entire system and enhance the scalability and fault tolerance of the system at the same time. The above-mentioned storage nodes are, for example, physical servers, virtual machines or cloud storage instances, etc.

[0082] The above-mentioned network proxy module 110 determines the scheme for the target data shard based on the service request, for example:

[0083] Calculate the hash value according to the data sharding algorithm and the service information carried in the service request; the data sharding algorithm is, for example, the consistent hashing algorithm;

[0084] Determine the starting position of the hash value on the preset hash ring; among them, multiple virtual nodes corresponding to the data shards are set on the preset hash ring;

[0085] Starting from the starting position on the preset hash ring, query the first virtual node in the clockwise direction, and determine the data shard corresponding to the virtual node as the target data shard.

[0086] It can be understood that, since the above-mentioned network forwarding layer and data storage layer adopt a separated design, the above-mentioned service registration center 100 can increase the number of service instances that the entire service registration center 100 can carry by adding data shards.

[0087] The following introduces the solution for the above-mentioned service registration center 100 to implement the service registration function:

[0088] Optionally, please refer to Figure 2 , the main steps for the above-mentioned service registration center 100 to implement the service registration function include:

[0089] The network proxy module 110 receives a service registration request sent by a service provider client; among them, the service registration request carries service information and instance information of the service to be registered;

[0090] The network proxy module 110 determines the target data shard of the service to be registered based on the service information of the service to be registered;

[0091] The network proxy module 110 forwards the service registration request to the target data shard;

[0092] After receiving the service registration request forwarded by the network proxy module 110, the target data shard in the data shard module 120 persistently stores the mapping relationship between the service information and instance information of the service to be registered.

[0093] The above-mentioned persistent storage means that the data is saved in a non-volatile manner to ensure that it can still maintain its original state after the system is shut down, crashes or restarts. In persistent storage, the data is written to a non-volatile storage medium, such as a hard disk, a solid-state drive (SSD) or other types of persistent storage devices.

[0094] The network forwarding layer in the above solution focuses on the forwarding of service registration requests, and can quickly and efficiently forward service registration requests to the target data shard, avoiding the overload of the data storage layer due to directly processing a large number of network requests, enabling the data storage layer to focus on data storage and management, giving full play to its storage performance advantages, and thus improving the service request processing performance of the above-mentioned service registration center 100.

[0095] The following introduces the solution for the above-mentioned service registration center 100 to implement the service discovery function:

[0096] Optionally, please refer to Figure 3 , the main steps for the above-mentioned service registration center 100 to implement the service discovery function include:

[0097] The network proxy module 110 receives a service query request sent by a service consumer client; among them, the service query request carries service information of the service to be queried;

[0098] The network proxy module 110 determines the target data shard of the service to be queried based on the service information of the service to be queried;

[0099] The network proxy module 110 forwards the service query request to the target data shard;

[0100] After receiving the service query request forwarded by the network proxy module 110, the target data shard in the data shard module 120 queries the instance information corresponding to the service query request and returns the instance information to the network proxy module 110;

[0101] After receiving the instance information returned by the target data shard, the network proxy module 110 returns the instance information to the service consumer client.

[0102] The above service discovery refers to the process in which a service consumer obtains the service instance information of a service provider by querying the service registry when it needs to call a service. The service consumer selects a suitable service instance for invocation according to the obtained service instance information.

[0103] It can be understood that after the network proxy module 110 returns the instance information to the service consumer client, the service consumer can establish communication with the service provider client corresponding to the instance information according to the requirements, so as to obtain the corresponding service.

[0104] In the service discovery scenario, the network forwarding layer and the data storage layer focus on request forwarding and data storage management respectively. On the one hand, in the face of a high-concurrency scenario, the above solution can quickly respond to the service query requests of service consumers, which is beneficial to improving the query response efficiency of the above service registry 100; on the other hand, the target data shard of the data storage layer can quickly respond to service query requests and return the corresponding instance information in a timely manner, which is beneficial to improving the request processing performance of the above service registry 100.

[0105] The following introduces the solution for the service registry 100 to implement the service deregistration function:

[0106] Optionally, please refer to Figure 4 , the main steps for the above service registry 100 to implement the service discovery function include:

[0107] The network proxy module 110 receives a service deregistration request sent by the service provider client; the service deregistration request carries the service information and instance information of the service to be deregistered;

[0108] The network proxy module 110 determines the target data shard of the service to be deregistered based on the service information of the service to be deregistered;

[0109] The network proxy module 110 forwards the service deregistration request to the target data shard;

[0110] After receiving the service deregistration request forwarded by the network proxy module 110, the target data shard in the data shard module 120 deletes the service information and instance information of the service to be deregistered stored therein.

[0111] The above service deregistration means that in a microservices architecture, when the service provider client goes offline or the process exits, the service registry 100 can actively delete the relevant instance information.

[0112] The service registry 100 in the above solution supports the deregistration function, can realize the timely update of service information, avoid request failures or resource waste caused by calling unavailable services, and is conducive to improving the applicability of the above service registry 100.

[0113] The following introduces the solution for the service registry 100 to implement the heartbeat detection function:

[0114] Optionally, please refer to Figure 5 , the main steps for the service registry 100 to implement the heartbeat detection function include:

[0115] The network proxy module 110 receives the service heartbeat signal sent by the service provider client at a fixed period; among them, the service heartbeat signal carries service information and instance information;

[0116] The network proxy module 110 determines the target data shard corresponding to the service heartbeat signal based on the service information carried by the service heartbeat signal;

[0117] The network proxy module 110 forwards the service heartbeat signal to the target data shard;

[0118] After receiving the service heartbeat signal forwarded by the network proxy module 110, the target data shard in the data shard module 120 updates the last survival time of the instance corresponding to the instance information.

[0119] The above service heartbeat detection function means that the microservice instance periodically sends a heartbeat signal to the service registry 100 to indicate that the service is still active and available. The service registry 100 is responsible for receiving the heartbeat signal and updating the health status of the service instance accordingly.

[0120] The above data shard module 120 can update the last survival time of the instance in the metadata of the instance information, so that the relevant modules deployed in the control and operation and maintenance layers can timely perceive the latest status of the instance.

[0121] On the one hand, the service registry 100 in the above solution can timely detect faulty instances through service heartbeat signals, avoiding routing traffic to unavailable instances, thus achieving high availability of the service. On the other hand, by updating the latest survival time of the service in the target data shard, the dynamic update of the service status is realized, so that the service registry 100 can make more reasonable traffic distribution decisions based on the service status, thereby optimizing the performance and response speed of the service registry 100.

[0122] Please refer to Figure 6 , the above service registry 100 can also set up a control and operation and maintenance layer, in which a configuration data module for realizing data shard status awareness, a fault detection module for realizing instance fault detection, and a control management module for operation and maintenance personnel can be deployed.

[0123] The following introduces the solution for the service registry 100 to realize the data shard status awareness function:

[0124] Optionally, the above service registry 100 may further include: a configuration data module 130.

[0125] Please refer to Figure 7 , the main steps for the above service registry 100 to realize the data shard status awareness function through the configuration data module 130 include:

[0126] The data shard module 120 reports metadata information and data shard topology structure information to the configuration data module 130;

[0127] The configuration data module 130 obtains the metadata information and data shard topology structure information reported by the data shard module 120, and forwards the metadata information and data shard topology structure information to the network proxy module 110, so that the network proxy module 110 realizes the awareness of the data shard status.

[0128] The above data shard topology structure information refers to the distribution and interconnection relationship of data shards on physical nodes, and the data shard topology structure information can affect the storage and access performance of data.

[0129] The above metadata may include information such as the cluster id, IP address, port number, whether it is the Raft cluster leader, the current version number, service tags, and weights of the data shard. The data shard module 120 will report the metadata to the configuration data module 130 in real time.

[0130] In the above solution, the service registry 100 can realize the status awareness of data sharding through the configuration data module 130. On the one hand, the data sharding status perceived by the service registry 100 can be transmitted to the network proxy module 110, so that the network proxy module 110 can make reasonable traffic routing decisions based on the data sharding status, which is beneficial to improving the performance and response speed of the service registry 100; on the other hand, the operation and maintenance personnel can also obtain the status information of the data sharding through the configuration data module 130, so as to perform corresponding operation and maintenance operations in a timely manner, which is beneficial to improving the operation and maintenance efficiency of the above service registry 100.

[0131] Next, a solution for the service registry 100 to implement the fault detection function will be introduced:

[0132] Optionally, the above service registry 100 may further include: a fault detection module 140.

[0133] Please refer to Figure 8 , the main steps for the service registry 100 to implement the fault detection function through the fault detection module 140 include:

[0134] The fault detection module 140 periodically checks the availability of each data shard in the data sharding module. If a data shard fails, a fault instruction is sent to the configuration data module 130;

[0135] The configuration data module 130, after receiving the fault instruction sent by the fault detection module 140, performs isolation operations or hemostasis operations on the faulty shard.

[0136] Taking the detection of heartbeat signals to determine whether a service is available as an example, if a service instance does not send heartbeat signals for a continuous period of time, the fault detection module 140 can determine that the service instance is unhealthy (or has failed), and trigger the corresponding fault handling mechanism.

[0137] The above isolation operation refers to fault isolation, which is a fault tolerance mechanism designed to isolate the faulty shard from the normal shards, so that the normal functions and fault handling functions of the above service registry 100 can be independent of each other, thus ensuring the normal operation of the service registry 100. The above hemostasis operation can be understood as a defensive operation. When a data shard of the service registry 100 fails, through a series of measures, such as flow limiting, disabling non-critical functions, automatic rollback, etc., to reduce the impact of the fault, so as to prevent the service registry from crashing.

[0138] In the above solution, the service registry 100 detects faults in data shards through the fault detection module 140. On the one hand, it can timely detect faulty instances, thus avoiding misrouting traffic to faulty instances and reducing the impact of service unavailability on user experience, which is beneficial to improving the real-time availability of services in the above service registry 100. On the other hand, performing isolation operations or hemostasis operations in a timely manner after detecting faults is beneficial to improving the reliability and fault tolerance of the service registry 100.

[0139] The following introduces the solution for the service registry 100 to implement operation and maintenance functions:

[0140] Optionally, the above service registry 100 further includes: a control and management module 150, which is deployed in the control and operation and maintenance layer and provides an operation and maintenance control plane service for operation and maintenance clients;

[0141] The control and management module 150 is used to: receive operation and maintenance instructions sent by operation and maintenance clients; where the operation and maintenance instructions include at least one of a traffic removal instruction, a traffic diversion instruction, a traffic limiting instruction, and an operation and maintenance query instruction; and issue operation and maintenance tasks to the data shard module and / or the configuration data module according to the operation and maintenance instructions.

[0142] It can be understood that, in order to distinguish client behavior from operation and maintenance personnel behavior, the above control and management module 150 provides a set of control plane APIs dedicated to operation and maintenance personnel, and the control plane service forwards the operation and maintenance instructions of operation and maintenance personnel to the data shard module 120 and / or the configuration data module 130.

[0143] The above control and management module 150 can be responsible for starting and stopping the release of other modules in the service registry 100, removing and diverting traffic, and providing functions for retrieving and querying business data.

[0144] The above operation and maintenance instructions may include:

[0145] Traffic removal instruction: When a data shard node fails or needs to be upgraded offline, a traffic removal instruction is issued to the network proxy module 110. After traffic removal, the network proxy module 110 blocks the traffic sent to the corresponding data shard node;

[0146] Traffic diversion instruction: It can be understood as the reverse process of traffic removal. A traffic diversion instruction for the target data shard node is issued to the network proxy module 110. After traffic diversion, the traffic will be normally sent to the target data shard node;

[0147] Flow limiting instruction: When the traffic exceeds the cluster's carrying capacity or there is abnormal client traffic, flow limiting can be performed on the specified client ID or the executed API. The flow limiting configuration will be stored in the configuration data module 130 and sent to the network proxy module 110. After receiving the flow limiting configuration, the network proxy module 110 will take effect dynamically to defend against client traffic.

[0148] Operation and maintenance query instruction: Operation and maintenance personnel can directly query the data in the data shards through this command via the configuration data module. They can not only query all instances under the specified service space but also send SQL statements for conditional queries.

[0149] In the above solution, operation and maintenance personnel can centrally manage each module in the service registry 100 through the operation and maintenance control plane service, achieving centralized management of the service registry 100, which is conducive to simplifying the operation and maintenance operations of the above service registry. On the other hand, operation and maintenance personnel can quickly obtain the running status and performance metrics of the service registry 100 through the control plane service, discover and solve problems in a timely manner, which is conducive to improving the operation and maintenance efficiency of the above service registry 100.

[0150] The following introduces the shard migration solution of the above service registry 100:

[0151] Optionally, the above network proxy module 110 is also used for:

[0152] After receiving the shard migration request, convert the write mode from the shard write mode to the broadcast write mode; among them, the shard migration request carries the shard information of the shard to be migrated;

[0153] After the data shards in the data shard module 120 converge, take the shard to be migrated offline;

[0154] Convert the write mode from the broadcast write mode to the shard write mode.

[0155] The above shard migration refers to the process of moving a service instance from one shard to another. Shard migration usually occurs in the following scenarios:

[0156] (1) Load balancing: To better utilize system resources, move service instances from shards with high load to shards with low load to relieve the load pressure on the shards;

[0157] (2) Fault recovery: When a certain shard fails (such as a node crashing or a network partition), move the affected service instances to other healthy shards to ensure service continuity and high availability;

[0158] (3) System expansion: To support business growth, the system capacity is expanded by adding new shards, and some service instances are migrated to the new shards to achieve capacity expansion.

[0159] (4) Maintenance and upgrade: When maintaining or upgrading a certain shard, service instances can be migrated to other shards to ensure that the service is not affected or is affected to a lesser extent.

[0160] The sources of the above shard migration requests can include:

[0161] (1) Manually triggered by operation and maintenance personnel: Operation and maintenance personnel can manually issue shard migration requests based on the real-time status of the service registry 100 and business requirements. For example, when the load of a certain shard is too high, resulting in a decline in system performance, operation and maintenance personnel can manually select some service instances to migrate from this shard to other shards with lower load to achieve load balancing.

[0162] (2) Scheduled operation and maintenance plan: Operation and maintenance personnel can formulate a shard migration plan in advance according to the system maintenance or upgrade plan. For example, during the planned system upgrade, to ensure service continuity, operation and maintenance personnel will issue instructions in advance through the control plane API to migrate service instances from the shard to be upgraded to other shards, and then migrate the service instances back after the upgrade is completed.

[0163] (3) Automatic monitoring: The service registry 100 can collect and analyze the performance metrics of each shard in real time (such as CPU usage, memory usage, network bandwidth, etc.). When it detects that the performance metrics of a certain shard exceed the preset threshold, it can automatically trigger a shard migration request. For example, if the CPU usage of a certain shard continuously exceeds 90%, the monitoring system will notify the load balancing service, and the load balancing service will automatically issue instructions to migrate some service instances from this shard to other shards with good performance.

[0164] (4) Automatically triggered by elastic scaling architecture: In some microservice architectures that support automatic elastic scaling, when the business load increases or decreases, the elastic scaling system will automatically adjust the number and capacity of shards according to the preset rules. For example, during the business peak period, the elastic scaling architecture will automatically create new shards and issue instructions to migrate some service instances to the newly created shards to handle the increased traffic.

[0165] (5) Fault trigger: When the fault detection module 140 detects that a certain shard has a fault (such as a node outage, network partition, etc.), it can automatically issue a shard migration request. For example, if a node of a certain shard suddenly goes down, the fault detection module 140 will immediately mark this shard as unavailable and notify the configuration data module 130, and the configuration data module 130 will issue instructions to migrate service instances from the faulty shard to other healthy shards.

[0166] (6) Fault recovery: When performing data backup and recovery operations on a data shard, a shard migration request may be triggered. For example, when the data of a shard needs to be restored from a backup, a shard migration request will be generated to temporarily migrate the service instance on the shard to another shard. After the data recovery is completed, the service instance will be migrated back.

[0167] (7) New business launch: When new business functions need to be launched, existing shards may be adjusted and migrated to ensure service stability and performance.

[0168] (8) Business offline: When certain business functions need to be offline or stop service, the shards also need to be adjusted accordingly.

[0169] (9) Upgrade and maintenance: When the software of the service registration center 100 is upgraded or the hardware is maintained, a shard migration request may be triggered.

[0170] The above-mentioned sharding write mode and broadcast write mode are two different input write strategies, where:

[0171] Shard write mode: refers to writing data to a specific shard. In this mode, data writing operations are only targeted at one or more specific shards, not all shards. Each shard is responsible for storing and managing a portion of the data, and write operations are only performed on the relevant shards.

[0172] Broadcast write mode: refers to writing data to all data shards. In this mode, data writing operations are performed on all data shards at the same time, ensuring that each shard has a complete copy of the data.

[0173] During the implementation of the above solution, after receiving the shard migration request, the network proxy module 110 converts the write mode from the shard write mode to the broadcast write mode, so that the traffic can be switched smoothly without large-scale restart or service interruption, which is conducive to improving the service continuity of the above-mentioned service registration center 100.

[0174] Optionally, each data shard in the above-mentioned data sharding module 120 is respectively provided with multiple copies; a consistency algorithm is used between the multiple copies of each data shard to achieve data consistency.

[0175] The above-mentioned data shard replicas are data that are copied to the data shards and stored on multiple nodes. Each data shard replica contains the same data but is stored on a different node.

[0176] The above consistency algorithms, such as the Raft algorithm or the Paxos algorithm, can coordinate data writing and synchronization by electing a Leader and Followers, where:

[0177] Raft protocol: Coordinate data writing and synchronization by electing a leader. The leader receives all write requests and broadcasts these requests to all followers in the form of logs. Only when the majority of followers successfully receive and persist the log entries will the leader apply the log entries to the local state machine and notify the client that the data writing is successful. The Raft protocol ensures that the shard availability is not affected when less than half of the nodes in the cluster are down, and can ensure the stability of the above service registry 100. In addition, requests or instructions related to data sharding will initiate a data modification proposal through the Leader of the data shard, and the proposal will spread through the Raft protocol to reach consensus across the entire data shard.

[0178] Paxos protocol: Achieve consensus through a series of proposal and acceptance processes to ensure data consistency across all replicas.

[0179] The above solution sets replicas for data shards. When a data shard node fails, the replica node can continue to provide services, which is beneficial to improving the disaster tolerance ability of the above service registry 100; on the other hand, by distributing data shard replicas on multiple nodes, read and write operations can be shared among different nodes, which is beneficial to improving the load balancing of the above service registry 100 and improving the performance of the service registry 100.

[0180] Please refer to Fig. 9 , based on the same inventive concept, an embodiment of the present application also provides a service management method, which is applied to the network proxy module 110 of the service registry 100. The method includes:

[0181] Step S210: Receive a service registration request sent by a service provider client; wherein, the service registration request carries service information and instance information of the service to be registered;

[0182] Step S220: Determine the target data shard of the service to be registered based on the service information of the service to be registered;

[0183] Step S230: Forward the service registration request to the target data shard so that the target data shard persistently stores the mapping relationship between the service information and the instance information of the service to be registered.

[0184] Please refer to Fig.10 , optionally, the above service management method further includes:

[0185] Step S310: Receive a service query request sent by a service consumer client; among them, the service query request carries service information of the service to be queried.

[0186] Step S320: Based on the service information of the service to be queried, determine the target data shard of the service to be queried.

[0187] Step S330: Forward the service query request to the target data shard so that the target data shard queries and returns instance information corresponding to the service query request.

[0188] Step S340: After receiving the instance information returned by the target data shard, return the instance information to the service consumer client.

[0189] It can be understood that the above steps S210 to S230 and steps S310 to S340 respectively introduce the solutions for the network proxy module 110 to implement the service registration function and the service discovery function. For the solutions for the network proxy module 110 to implement other functions, please refer to the introduction of the network proxy module 110 in the above content, and the embodiments of the present application will not be elaborated herein.

[0190] Fig.11 It is a schematic diagram of an electronic device provided by an embodiment of the present application. Referring to Fig.11 , the electronic device 400 includes: a processor 410, a memory 420, and a communication interface 430. These components are interconnected and communicate with each other through a communication bus 440 and / or other forms of connection mechanisms (not shown).

[0191] Among them, the memory 420 includes one or more (only one is shown in the figure), which may be, but is not limited to, a random access memory (Random Access Memory, abbreviated as RAM), a read-only memory (Read Only Memory, abbreviated as ROM), a programmable read-only memory (Programmable Read-Only Memory, abbreviated as PROM), an erasable programmable read-only memory (Erasable Programmable Read-Only Memory, abbreviated as EPROM), an electrically erasable programmable read-only memory (Electric Erasable Programmable Read-Only Memory, abbreviated as EEPROM), etc. The processor 410 and other possible components can access the memory 420, read and / or write data therein.

[0192] The processor 410 includes one or more (only one is shown in the figure), which can be an integrated circuit chip with signal processing capabilities. The above-mentioned processor 410 can be a general-purpose processor, including a Central Processing Unit (CPU), a Micro Controller Unit (MCU), a Network Processor (NP), or other conventional processors; it can also be a dedicated processor, including a Digital Signal Processor (DSP), an Application Specific Integrated Circuits (ASIC), a Field Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0193] The communication interface 430 includes one or more (only one is shown in the figure), which can be used to communicate directly or indirectly with other devices for data interaction. For example, the communication interface 430 can be an Ethernet interface; it can be a mobile communication network interface, such as an interface for 3G, 4G, or 5G networks; it can also be other types of interfaces with data sending and receiving functions.

[0194] One or more computer program instructions can be stored in the memory 420, and the processor 410 can read and run these computer program instructions to implement the service management method provided in the embodiments of the present application and other desired functions.

[0195] It can be understood that Fig.11 The structure shown is only schematic, and the electronic device 400 can also include more or fewer components than Fig.11 shown in the figure, or have a different configuration from Fig.11 shown in the figure. Fig.11 Each component shown in the figure can be implemented using hardware, software, or a combination thereof. For example, the electronic device 400 can be a single server (or other device with computing and processing capabilities), a combination of multiple servers, a cluster of a large number of servers, etc., and can be either a physical device or a virtual device.

[0196] The embodiments of the present application also provide a computer-readable storage medium, on which computer program instructions are stored. When the computer program instructions are read and run by the processor of the computer, the service management method provided in the embodiments of the present application is executed. For example, the computer-readable storage medium can be implemented as Fig.11 the memory 420 in the electronic device 400 shown in the figure.

[0197] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For another example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection between each other can be through some communication interfaces. The indirect coupling or communication connection of the devices or units can be in electrical, mechanical or other forms.

[0198] In addition, the units described as separate components may or may not be physically separated. The components displayed as units may or may not be physical units, that is, they can be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0199] Furthermore, in each embodiment of the present application, the functional modules can be integrated together to form an independent part, or each module can exist alone, or two or more modules can be integrated to form an independent part.

[0200] The above are only the embodiments of the present application and are not used to limit the protection scope of the present application. For those skilled in the art, the present application can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A service registration center, characterized in that: The service registration center includes: a network proxy module and a data sharding module; wherein: The network proxy module is deployed in the network forwarding layer, and is used to receive a service request sent by a service provider client and / or a service consumer client, determine a target data slice based on the service request, and forward the service request to the target data slice; The data sharding module is deployed in the data storage layer and is used to store the mapping relationship between service information and instance information; wherein the target data shard is used to receive the service request forwarded by the network proxy module and perform corresponding operations based on the service request.

2. The service registration center according to claim 1, characterized in that: The network proxy module is used to: Receive a service registration request sent by the service provider client; wherein the service registration request carries service information and instance information of the service to be registered; determine a target data slice of the service to be registered based on the service information of the service to be registered; forward the service registration request to the target data slice; The target data slice in the data slice module is used to: After receiving the service registration request forwarded by the network proxy module, the mapping relationship between the service information and the instance information of the service to be registered is persistently stored.

3. The service registration center according to claim 1, characterized in that: The network proxy module is used to: Receiving a service query request sent by the service consumer client; wherein the service query request carries service information of the service to be queried; determining a target data shard of the service to be queried based on the service information of the service to be queried; forwarding the service query request to the target data shard; and after receiving instance information returned by the target data shard, returning the instance information to the service consumer client; The target data slice in the data slice module is used to: After receiving the service query request forwarded by the network proxy module, query the instance information corresponding to the service query request, and return the instance information to the network proxy module.

4. The service registration center according to claim 1, characterized in that: The network proxy module is used to: Receive a service deregistration request sent by the service provider client; wherein the service deregistration request carries service information and instance information of the service to be deregistered; determine a target data slice of the service to be deregistered based on the service information of the service to be deregistered; forward the service deregistration request to the target data slice; The target data slice in the data slice module is used to: After receiving the service deregistration request forwarded by the network proxy module, the stored service information and instance information of the service to be deregistered are deleted.

5. The service registration center according to claim 1, characterized in that: The network proxy module is also used for: Receiving a service heartbeat signal sent by the service provider client at a fixed period; wherein the service heartbeat signal carries service information and instance information; determining a target data shard corresponding to the service heartbeat signal based on the service information carried by the service heartbeat signal; and forwarding the service heartbeat signal to the target data shard; The target data shard in the data shard module is further used for: After receiving the service heartbeat signal forwarded by the network proxy module, the last survival time of the instance corresponding to the instance information is updated.

6. The service registration center according to any one of claims 1 to 5, characterized in that: The service registration center also includes: a configuration data module; The data slicing module is further used to report metadata information and data slicing topology information to the configuration data module; The configuration data module is deployed in the control and operation layer, and is used to obtain the metadata information and the data sharding topology information reported by the data sharding module, and forward the metadata information and the data sharding topology information to the network proxy module.

7. The service registration center according to claim 6, characterized in that: The service registration center also includes: a fault detection module; The fault detection module is deployed in the control and operation layer and is used to regularly check the availability of each data shard in the data shard module. If a fault occurs in the data shard, a fault instruction is sent to the configuration data module. The configuration data module is also used for: After receiving the fault instruction sent by the fault detection module, an isolation operation or a hemostasis operation is performed on the faulty slice where the fault occurs.

8. The service registration center according to claim 6, characterized in that: The service registration center also includes: a control management module; the control management module is deployed in the control and operation and maintenance layer, and provides operation and maintenance control plane services to the operation and maintenance client; The control management module is used to: Receive an operation and maintenance instruction sent by the operation and maintenance client; wherein the operation and maintenance instruction includes at least one of a flow removal instruction, a flow diversion instruction, a flow limiting instruction, and an operation and maintenance query instruction; According to the operation and maintenance instruction, an operation and maintenance job is issued to the data sharding module and / or the configuration data module.

9. The service registration center according to any one of claims 1 to 5, characterized in that: The network proxy module is also used for: After receiving a shard migration request, converting the write mode from the shard write mode to the broadcast write mode; wherein the shard migration request carries shard information of the shard to be migrated; After all data shards in the data sharding module converge to be consistent, the shard to be migrated is offline; The write mode is converted from the broadcast write mode to the shard write mode.

10. The service registration center according to any one of claims 1 to 5, characterized in that: Each data shard in the data sharding module is respectively provided with multiple copies; a consistency algorithm is used between the multiple copies of each data shard to achieve data consistency.

11. A service management method, characterized in that: A network proxy module applied to a service registration center, the method comprising: Receive a service registration request sent by a service provider client; wherein the service registration request carries service information and instance information of the service to be registered; Determine a target data slice of the service to be registered based on the service information of the service to be registered; The service registration request is forwarded to the target data slice, so that the target data slice persistently stores the mapping relationship between the service information and the instance information of the service to be registered.

12. The service management method according to claim 11, characterized in that: The method further comprises: Receiving a service query request sent by a service consumer client; wherein the service query request carries service information of a service to be queried; Based on the service information of the service to be queried, determining a target data shard of the service to be queried; Forwarding the service query request to the target data shard, so that the target data shard queries and returns the instance information corresponding to the service query request; After receiving the instance information returned by the target data slice, the instance information is returned to the service consumer client.

13. An electronic device, characterized in that: include: A processor, a memory and a communication bus, wherein the processor and the memory communicate with each other via the communication bus; The memory stores program instructions that can be executed by the processor, and the processor calls the program instructions to execute the method according to claim 11 or 12.

Images