Shulou(Shulou.com)06/02 Report--

This article focuses on "what is service discovery and the introduction of Redis as a service intermediary". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "what is service discovery and the introduction of Redis as a service intermediary"!

What is service discovery?

Service discovery is not so unfathomable, and its principle is simple.

What a service provider is, to put it simply, is a HTTP server that provides API services with an IP port as the service address. What a service consumer is, it is a simple process that wants to access the services provided by the service provider to do something. A HTTP server can be a service provider that provides services to the outside world, or a service that consumers need other service providers to provide. This is service dependence. Without you, I would not be myself. Complex services even have multiple service dependencies.

Service discovery has three roles, service provider, service consumer and service intermediary. Service intermediary is a bridge between service providers and service consumers. The service provider registers the service address they provide with the service intermediary, and the service consumers find the address of the service they want from the service intermediary, and then enjoy the service. Service mediations provide multiple services, and each service corresponds to multiple service providers.

Image

A service mediation is a dictionary with many key/value key-value pairs, key is the service name, and value is the address list of the service provider. Service registration is to call the dictionary's Put method to plug things, and service lookup is to call the dictionary's Get method to get things.

When the service provider node dies, the service is required to cancel the registration in time, and then inform the consumer to re-obtain the service address in time.

When the service provider joins, the service intermediary is required to inform the service consumer in time whether you want to try the new service or not.

Redis as a service intermediary

Redis has a wealth of data structures that make it more appropriate to store service dictionaries. For each service name, we use a set structure to store the service's IP:Port string. If the service provider joins, call the sadd command to add the service address, and if the service dies, call the srem command to remove the service address. Use the smembers instruction to get all the service addresses to the service consumer and pick one at random in the consumption process, or use the srandmemember instruction to obtain the random service address directly.

At this time, you may wonder, is service discovery really that simple? The answer is that there are a few questions about the above solution.

The first problem is what if the service provider process is brutally killed by kill-9 and cannot actively invoke the srem command?

At this time, there is a black address in the service list that points to a service that does not exist and the consumer has no idea. At this time, the service intermediary becomes a black intermediary. What are we going to do?

We introduce service preservation and inspection mechanisms, and replace the data structure. The service provider needs to report survival to the service intermediary every 5 seconds or so, and the service intermediary records the service address and reporting time in the value and score of the zset data structure. The service intermediary needs to check the zset data structure every 10 seconds or so to kick out the service address entry that is seriously behind reporting time. In this way, the validity of the service address in the service list can be guaranteed in quasi-real time.

The second question is how to notify consumers when the list of services changes. There are two solutions.

The first is polling, where consumers need to check every few seconds to see if the list of services has changed. If there are many services, a large list of services, and a large number of consumers, redis will be under some pressure. So at this time, we can introduce the version number mechanism of the service list, and provide each service with a version number of the key/value setting service, that is, increment this version number when the service list changes. Consumers only need to poll for changes in the version number to know if the list of services has changed. Because the list of services is stable and changes frequently only in cases of severe network jitter, there is little pressure on redis.

The second is to use pubsub. The timeliness of this method is obviously better than polling. The downside is that each pubsub consumes a consumer thread and an additional redis connection. To reduce the waste of threads and connections, we use a single pubsub to broadcast changes in the global version number. The so-called global version number is that any list of services has changed, and this version number will be incremented. Consumers who receive a version change check to see if the version number of their list of dependent services has changed. This global version number can also be used for the first polling scheme.

The third problem is that redis is a single point, what if I hang up?

This is a big problem. Because of this problem, popular service discovery systems all use distributed database zookeeper/etcd/consul as service intermediary, they are distributed multi-node, it doesn't matter if a node is lost, the system can still work normally.

Image

What happens if the entire zk cluster dies? In fact, every service consumer keeps a current service list in local memory, and even if the service mediation cluster dies, it can use the current service list to work properly.

Is it really unreliable for redis to be a service intermediary? In fact, there is another redis-sentinel that can eliminate the single point problem of redis. Redis-sentinel can automatically upgrade the slave node to the master node when the master node dies. So it's okay to do this with redis. It's really easy to do service discovery with redis, although this approach is very unpopular.

Service providers are not just HTTP services

The above mentioned service provider is simply a HTTP server, but there are a variety of services. It can be a database service, a RPC service, a UDP service, and so on.

If it is a MySQL database, how do you register the MySQL service with the service mediation? Native MySQL does not provide this functionality. The general practice is to provide an Agent agent to register. In addition to registering the service address with the service intermediary, this agent also needs to monitor the health of the MySQL so that it can switch to the new MySQL service address in time if the MySQL goes down. Generally, this Agent monitors more than one database in order to save resources. It can monitor multiple databases, even multiple databases at the same time.

Service configuration reload

Service discovery is generally only used to register and find the list of services as a relatively simple function. However, modern service discovery systems also integrate service configuration management functions. This enables real-time reloading of the service configuration. The principle is also simple: for each service item, the service mediation also stores a separate key/value to store the configuration information for the service. When this configuration item is modified in the background, the service intermediary notifies the relevant server to change the configuration information in real time. Such as database address change, business parameter modification and so on.

Service management backend

In order to facilitate service management, general service discovery also provides a service management background for managers to check the status of the service cluster. If redundant configuration information is provided during service registration and reporting, the service management background can present more detailed service information. The service management background can also organize all service dependencies to present a beautiful service dependency tree.

A simple implementation of Service Discovery

In his spare time, the editor implements a simple service discovery system Captain based on Redis. Readers can go to github to download this project to learn. In addition to writing the server for service discovery, the client sdk has also been developed together, which may be unstable. I hope readers will understand and not be used in online business systems.

In the Captain project, my service discovery server encapsulates the services provided by Redis, provides HTTP API for service registration and search, and does not use the pubsub function mentioned above.

At this point, I believe you have a deeper understanding of "what is service discovery and the introduction of Redis as a service intermediary". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.