Table of content

When we learn something ,we should ask ourselves some questions,such as what is it ? why should we use it ?how to use it? when to use it and where to use it ?

Now,in this article we have three questions:

The first —— why should we use Services Discovery?

The second ——why do we choose zookeeper to do this kind of things?

The third ——what are the challenges o discovery services?

So，it’s time to give the answers!

why should we use Services Discovery

In our old ITOO project(a distributed system), if we want to invoke other services ,we should now what is the service’s name ,where is it ? we should know the exactly position of the service,you should know the service’s url then use the JNDI technology to find it.You know in this way,if we change the service’s url,we should change every services that invoke this service,it’s difficult to maintence.So we should use a concentrated position to manage all services,make it easy to pulish and discovery.

why do we choose zookeeper to do this kind of things?

You know there are many services discovery service,which should I choose? The services that we can use are DNS,Zookeeper,etcd,doorerd ,Consul,Eureka and forth on !

Oh, my God,there are so many,what is the right one to our project?maybe we should check each of that services and compare the differents to find the most suitable one.

As mentioned DNS has been used for a long time and is probably the largest Service Discovery system out there. For small-scale setups start with DNS but once you start provisioning nodes more dynamically, DNS starts becoming problematic due to the propagation time.

Arguably, Zookeeper is the most mature of the config stores used for discovery since it has been around for quite some time and is a comprehensive solution including configuration management, leader election, distributed locking etc. This makes it a very compelling general-purpose solution although it’s often more complex than it could be.

etcd & doozerd are the new age cousins of Zookeeper, built with similar architectures and features sets and hence can be used interchangeably in place of Zookeeper

Consul is a newer solution in this space that provides configuration management and a generic key-value store apart from Service Discovery. It also has killer features of health checking of nodes and supporting DNS SRV for improved interop with other systems. A big differentiator from Zookeeper is the HTTP & DNS APIs that can be used to interact with consul vis-à-vis a Zookeeper client.

If you lean more towards AP systems Eureka is a great choice and is battle tested in Netflix and it prefers Availability over Consistency in the wake of network partitions.

So,maybe zookeeper is the most suitable one for our project.

what are the challenges o discovery services?

It’s more complicated than you realize: it’s an extension of the distributed systems problem.

You might roll out configuration files with service names, IPs and ports but when the system becomes very dynamic you need to migrate to a “real” Service Discovery solution and that migration is usually not as easy as you think. One of the biggest challenges is the inability to understand how intrusive the choice of a Service Discovery system is: once chosen it is very difficult to change it and hence it is critical to do it right.

Most systems implement some form of distributed consensus algorithms, designed to be resilient in the face of node outages, but these algorithms are notoriously hard to get right and understanding failure modes is both key and difficult and failing to analyse them correctly usually takes you to make the wrong choices.

All the questions are answered,here is my summary about the Services Discovery

Summary

In this article,some ideas come from other people,some of come from mine,but it doesn’t matter,just do it,then do it better!