So in this lesson, we're going to talk about service discovery. We're going to register a service with the Eureka running instance that has what we call a Ribbon Client for load balanced communication with other services. We're going to configure that service for inter service communication using client-side load balancing via Ribbon. And we're also going to see how Hystrix can implement the circuit breaker problem. A fundamental part of microservice architecture is that we want to maximize availability of our services. The access to a distributed service can be controlled by a load balancing as a means to optimize the distribution of workloads across multiple services or multiple instances of the same services to maximize availability. If one goes down, there's still another one up. Clients-side load balancing delivers a list of server IP addresses to a client. That client can randomly select or use some other load balancing algorithm, like round robin, to make a call to one of those entries in that list. Netflix OSS has a project called Ribbon that provides client-side load balancers. With Ribbon attached to your service, the service will select from the local registry the Eureka registered services and create a subset of the service that you want. So if I wanted service one, it will look in the local registry and say, well, how many instances of service one do I have? I have three, let's create a subset of those three. And what will happen, in due course, is that the load balancer will use some sort of algorithm to select one of those three instances to delegate to when it needs to courtesy of a request. We have a round robin algorithm built into Ribbon. And so the round robin just means I will oscillate from one service to the next in the list as each request comes in. So we know that Eureka provides a service registry for all Netflix services. Ribbon clients are typically created configured for each of the registered services within that registry. When Eureka is used in conjunction with Ribbon, that is, they are both on the class path, the subset list of potential services from the local registry is called the Ribbon server list. As an extension of DiscoveryEnabledNIWSServerList, which is basically a class that's being used under the hood. Ribbon will use the local Eureka Service service registry to identify the service that it wants and leverage the extracted subset of service in a load balanced manner. It actually uses a dynamic server list load balancer under the hood to delegate to one of the selected services within this list. Each service instance is identified by a service ID or the metadata, as we talked about earlier, to make sure they're unique within the registry. And they are put into a Ribbon server list. Ribbon then delegates in a round robin fashion to each service in the Ribbon Service list for each request that comes in. So we're registered, we have a local registry, we create a subset, the Ribbon Service list. The Ribbon Client takes that subset and for request one, it'll go to service one. Request two, service two, request three, service three, request four, back to service one, and so on, and so on. Since most of the code has provided us by Spring Cloud, we've already seen EnableDiscoveryClient that registers this service with a running instance of Eureka when it's deployed. You now see a few more new annotations. I'm actually going to mention first that the REST template we'll be using is annotated with LoadBalanced. That means that Spring Cloud will know that this REST template will be used in a load balanced manner with Ribbon. And then we also see the @RibbonClient annotation with a name, capitalServ. That seems to imply that we will be calling something called capitalServ. So we have a capital client service that will be calling something called capitalServ, maybe. What that capitalServ actually refers to is a piece of YAML configuration, the Ribbon configuration. You can see that it's got capitalServ. But the Ribbon configuration, through the load balancer, is actually going to be calling a service called capital-service, the real service in our Ribbon server list. So the capitalServ nothing more than a label to connect to us to some YAML configuration that will then pick up the new service that we want to delegate time to. This is called service discovery, as we will see, as nowhere in the code will there be a physical IP, DNS entry, or host name. It's just going to be looking for something called capitalServ, which will be matched to capital-service. And the last bit to notice is that, as we're constantly doing heartbeats with Eureka server and getting new services down, if any of those four within the extracted subset for Ribbon, they'll be added to that subset, that Ribbon server list. And conversely, if we don't hear from a service as we pull them down, they will be removed from that subset. The actual service discovery becomes clearer here within the implementation of our capital service client calling our capital service. You will see we're using our load balance REST template to do getForObject, but look at the URL, the URL just says capitalServ. It does not mention hostname, it does not mention IP address, it does not mention port, it does not mention anything. And capitalServ, through YAML, is talking to the real server that it wants off the Ribbon Server list and to make the remote call. In addition, as we hit this end point again and again, because we're using a load balanced REST template, the first request may get the first entry in that Ribbon Server list. The second request will get the second entry in that Ribbon Server list, and so on.
