Hello there. In this video, we will talk about the Registration and Discovery Services. So, if you're ready, let's start with Discovery Services. So, what is Service Discovery?

Let's imagine several microservices that make up a more or less complex application. These will communicate with each other somehow. A microservices-based application typically runs in virtualized or containerized environments. The number of instances of a service and its locations change dynamically. We need to know where these instances are and their names to allow requests to arrive at the target microservice. This is where tactics such as Service Discovery come into play. The Service Discovery mechanism helps us know where each instance is located. In this way, a Service Discovery component acts as a registry in which the addresses of all instances are tracked. The instances have dynamically assigned network paths. Consequently, if a client wants to make a request for a service, it must use a Service Discovery mechanism.

A microservice needs to know the location, IP address and port of every service that it communicates with. If we don't employ a Service Discovery mechanism, service locations become coupled leading to a system that's difficult to maintain. We could wire the locations or inject them via configuration in a traditional application but it isn't recommended in a modern cloud-based application of this kind. Dynamically determining the location of an application service isn't a trivial matter. Things become more complicated when we consider an environment where we're constantly destroying and disturbing new instances of services. This may well be the case for a cloud-based application that's continuously changing due to horizontal auto-scaling to meet peak loads or the release of a new version. Hence, the need for a Service Discovery mechanism. Service Discovery handles things in two parts. First, it provides a mechanism for an instance to register and say, "I'm here."

Second, it provides a way to find the service once it has been registered. Let's clarify the concept we've discussed so far with an example. A service consumer and a service provider, a service exposing REST API. The service consumer needs the service provider to read and write data. The diagram on this slide shows the communication flow. Now, let's describe the steps illustrated in the diagram. Number 1 describes the location of the service provider sent to their service registry, a database containing the locations of all available service instances. Number 2 describes the service consumer asking the service discovery server for the location of the service provider. Number 3 describes the location of the service provider searched by the service registry in its internal database and returned to the service consumer. And number 4 describes how the service consumer can now make direct requests to the service provider. There are two main patterns for Service Discovery: client-Side Discovery and Server-Side Discovery, let's clarify them.

When using Client-Side Discovery, the service consumer is responsible for determining the network locations of available service instances and load balancing requests between them. The client queries the service register, then the client uses a load balancing algorithm to choose one of the available service instances and performs a request. The alternate approach to Service Discovery is the Server-Side Discovery model which uses an intermediary that acts as a load balancer. The client makes a request for a service via load balancer that acts as an orchestrator. The load balancer queries the service registry and routes each request to an available service instance. Now let's talk about Service Registration. So far, we've assumed that the service registry already knew the locations of each microservice, but how do these registration and de-registration operations take place? The Service Register is a crucial part of service identification. It's a database containing the network locations of service instances. A Service Registry must be highly available and up-to-date. Clients can cache the network paths obtained from the Service Registry. However, this information eventually becomes obsolete and clients won't reach the service instances.

Consequently, a Service Registry consists of a cluster of servers that use a replication protocol to maintain consistency. There are two service registration options. The first one is self-registration. When using the self-registration model, a service instance is responsible for registering and de-registering itself in the Service Registry. In addition, if necessary, a service instance sends heartbeat requests to keep its registration alive. The self-registration model has several pros and cons. One advantage is that it's relatively simple and doesn't require other system components as intermediaries. However, a significant disadvantage is that a couple service instances to the Service Registry, which means we must implement the registration code in each language and framework used. And the other service registration option is third-party registration. When using the third-party registration model, the service instances aren't responsible for registration in the Service Registry. Instead, another system component known as the Service Register is responsible for registration.

The Service Register keeps track of changes to running instances by pulling the deployment environment or subscribing to events. When it detects a newly available service instance, it records it in its database. The service registry also de-registers terminated service instances. Like self-registration, the third-party registration scheme also has various pros and cons. One of the main advantages is that services are decoupled from the Service Registry. There's no need to implement service registration logic for each programming language and framework. Instead, the registration of service instances is managed centrally within a dedicated service. One disadvantage of this model is that unless it's embedded in the deployment environment, it's yet another highly available system component that needs to be set up and managed. All right, so that's talking about Service Discovery and Service Registration. Let's take a short break here, see you in the next video.