In this recipe, we have used DNS as our service discovery mechanism. We did this specifically to align our development environment with our expected production environment under Kubernetes. There are of course many ways to deploy a microservice system and also many other service discovery mechanisms that we could have used.
Some other options for consideration are:
- Consul.io by HashiCorp (https://www.consul.io/), provides a robust service discovery mechanism providing both HTTP and DNS based registration and lookup.
- etcd (https://github.com/coreos/etcd) distributed key value store. This is used internally by Kubernetes.
- Zookeeper, distributed key value store from the Apache project (https://zookeeper.apache.org/).
- Peer to peer based service discovery protocols such as the Raft Consensus Algorithm (https://raft.github.io/raft.pdf), the SWIM protocolb (http://www.cs.cornell.edu/~asdas/research/dsn02-SWIM.pdf), or the Dat protocol (https://github.com/datproject/docs/blob/master/papers/dat-paper.pdf).
- We will be covering service discovery further and in more detail in Chapter 11, Deploying Systems.