Introduction
Recently I've been digging deep into microservices and distributed systems in order to get a better understanding of how bigger companies make applications and products that can scale almost infinitely. I've taken Netflix as a great example of microservice implementation in a product used by millions of people. They use microservices for literally EVERYTHING, and it's fully cloud-based (AWS).
But I see a lot of people (including me once) wondering how they keep track of their service instances when they autoscale. It's not like you have a set amount of service instances and you know their credentials (host and port). When you are autoscaling, you might have n amount of instances for a single service and not know their credentials.
For example, let's say you have 2 services: Service A and Service B. Service A depends on Service B for some kind of functionality. If you have one instance of Service B, you can just hardcode that instance's (Service B) credentials in Service A's configuration and use it. But what will you do when you have multiple instances of Service B and cant keep track of them?
How do you solve it?
That's where a Service Registry (also known as Service Discovery) comes into play. A Service Registry is basically a server itself, but it keeps track of all the other running service instances along with their credentials (host and port). The idea here is that whenever a new service instance starts, it will "register" itself on the registry by connecting to it and sending it's credentials as payload. Then it will just keep heartbeating (sending periodic packets) to let the registry know that it's "alive". If a service instance does not send a heartbeat for a long time, it will be considered as "dead" and removed from the registry.
Just in case you are confused, let me specify the abstractions here. The registry will have multiple "services". Here, a service can be some kind of application or server that is required in your application's architecture. Each "service" can have multiple "instances" because you might have to scale.
We got a registry, how do we access the instances?
We now know how we can register services, but how do we get an instance's credentials so that we can actually use it? One might say that we can just randomly select an instance from the registry. But that is not optimal since it's not 100% "random" and might return the same instance's credentials multiple times. The best option here would be to use some sort of load balancing algorithm. Most service registry systems come with a "round-robin" load balancing implementation which works best if you have servers with same specs/configuration. And when you are autoscaling, that would usually be the case. I can write a whole article on load balancing algorithms so I won't babble about it here.
Anyways, a load balancing algorithm will simply give you an instance's credentials by load-balancing all of the "alive" instances registered under that specific "service". Once you get the credentials of an instance, you can just use it in your application. BOOM!
I'm sold, but which service registry software should I use?
There are MANY good service registry software available, including one that I made (which is fairly new, but you can give it a try). I will list a few good ones here that I recommend for starters and production.
Conclusion
Well that is it for this post, I hope you enjoyed learning about Service Registries. It's been a while since I've written an article, so it might not be the best thing I've written. Regardless, I hope this new knowledge about Service Registries help you in the long run and make your backend easier to scale.
Happy Coding :D
Top comments (0)