CODEWITHSUNDEEP
microservices
Zeina
Zeina

Reputation: 257

The Registration process in microservices architecture

Chris Richardson mentioned in his article "3rd-party-registration":

"The 3rd party registrar might only have superficial knowledge of the state of the service instance, e.g. RUNNING or NOT RUNNING and so might not know whether it can handle requests."

But what this really means? What information does a microservice send to the registrar when it starts? Why is the registrar not able to know information about the service and its location?

Upvotes: 0

Views: 143

Answers (1)

Oswin Noetzelmann
Oswin Noetzelmann

Reputation: 9555

"The 3rd party registrar might only have superficial knowledge of the state of the service instance, e.g. RUNNING or NOT RUNNING and so might not know whether it can handle requests."

What information does a micro service send to the registrar when it starts? Why the registrar is not able to know information about the service and its location ?

The service will typically not contact the registry by itself. The pattern that has emerged is rather that an orchestration system starts up the service and makes sure the service is registered and its status is checked. This is helpful so you don't have to worry about these things when you design your service - The service should have a pure business focus and not have any knowledge about service discovery mechanisms. And the registry will of course need to know about the service and its location(s). Because it's part of the orchestration system it provides this information to the rest of the service cluster.

Then about the quote: It refers to the fact that the registrar is a separate entity and there is a need for communication between the registry and the service. The scope of communication is usually confined to the purpose of service readiness and availability (e.g. through a health probe). However it is not uncommon that systems with a service registry allow custom health probes for your own service types. Since those are in your control, you can define the exact communication and what APIs and return values make your service healthy or not.

Why is this very basic information about the service status sufficient?

The status information is what is required to divert traffic to healthy services when a service fails and / or automatically replace unhealthy service containers. These are the typical use cases and thus supported out of the box by a typical registration or orchestration system.

Upvotes: 1

Related Questions