Module 11 / Microservices

Module 11 · lesson 5 of 7 · Read 7 min

Service discovery

Finding a service whose address keeps changing.

Orders needs to call Payments. In the old days you'd write Payments' address into a config file: PAYMENTS_URL=http://10.0.4.17:8080. That worked when Payments ran on one long-lived server that nobody touched.

At Tiffin today, Payments runs as 6 instances at lunch and 20 at dinner. Instances are replaced on every deploy, several times a day. When a machine dies, its instances start somewhere else with new addresses. The list of "where is Payments right now?" changes every few minutes. Hard-coding it is not an option.

The problem

Service discovery is how a service finds the current network addresses of the healthy instances of another service.

It has three parts:

  1. Registration. When an instance starts, something records "Payments instance at 10.0.7.31:8080 is up".
  2. Health. When an instance dies or gets sick, it's removed from the list, quickly.
  3. Lookup. When Orders wants Payments, it gets the current list of healthy addresses and picks one.

You've met a version of this already: a load balancer from Module 4 keeps a list of healthy servers and sends traffic to them. Service discovery is the same idea, applied to every service calling every other service, with a list that changes constantly.