Microservices need interprocess communication so that services can communicate with each other. Spring Cloud uses Netflix Ribbon, a client-side load balancer that plays this critical role and can handle both HTTP and TCP. Ribbon is cloud-enabled and provides built-in failure resiliency. Ribbon also allows you to use multiple and pluggable load balancing rules. It integrates clients with load balancers.

In the last chapter, we added Eureka Server. Ribbon is integrated with Eureka Server in Spring Cloud by default. This integration provides the following features:

There are different clients available in Spring Cloud that use Ribbon, such as RestTemplate or FeignClient. These clients allow microservices to communicate with each other. Clients use instance IDs in place of hostnames and ports for making an HTTP call to service instances when Eureka Server is used. The client passes the service ID to Ribbon, Ribbon then uses the load balancer to pick the instance from the Eureka Server.

If there are multiple instances of services available in Eureka, as shown in the following screenshot, Ribbon picks only one for the request, based on load balancing algorithms:

Multiple service registration – Restaurant service

We can use DiscoveryClient to find all the available service instances in Eureka Server, as shown in the following code. Method getLocalServiceInstance() of class DiscoveryClientSample returns the all local service instances available in Eureka Server.

DiscoveryClient sample:

@Component
class DiscoveryClientSample implements CommandLineRunner {

    @Autowired
    private DiscoveryClient;

    @Override
    public void run(String... strings) throws Exception {
   //print the Discovery Client Description
        System.out.println(discoveryClient.description());
   // Get restaurant-service instances and prints its info
        discoveryClient.getInstances("restaurant-service").forEach((ServiceInstance serviceInstance) -> {
            System.out.println(new StringBuilder("Instance --> ").append(serviceInstance.getServiceId())
                    .append("
Server: ").append(serviceInstance.getHost()).append(":").append(serviceInstance.getPort())
                    .append("
URI: ").append(serviceInstance.getUri()).append("


"));
        });
    }
}

When executed, this code prints the following information. It shows two instances of the Restaurant service:

Spring Cloud Eureka Discovery Client
Instance: RESTAURANT-SERVICE
Server: SOUSHARM-IN:3402
URI: http://SOUSHARM-IN:3402
Instance --> RESTAURANT-SERVICE
Server: SOUSHARM-IN:3368
URI: http://SOUSHARM-IN:3368

The following samples showcase how these clients can be used. You can see that in both clients, the service name restaurant-service is used in place of a service hostname and port. These clients call /v1/restaurants to get a list of restaurants containing the name given in the name query parameter:

Rest Template sample:

@Override
public void run(String... strings) throws Exception {
ResponseEntity<Collection<Restaurant>> exchange
= this.restTemplate.exchange(
"http://restaurant-service/v1/restaurants?name=o",
                   HttpMethod.GET,
                   null,
                   new ParameterizedTypeReference<Collection<Restaurant>>() {
                  },
                   ( "restaurants");
exchange.getBody().forEach((Restaurant restaurant) -> {
System.out.println(new StringBuilder("


[ ").append(restaurant.getId()).append(" ").append(restaurant.getName()).append("]"));
});
}

FeignClient sample:

@Component
class FeignSample implements CommandLineRunner {

    @Autowired
    private RestaurantClient restaurantClient;

    @Override
    public void run(String... strings) throws Exception {
        this.restaurantClient.getRestaurants("o").forEach((Restaurant restaurant) -> {
            System.out.println(restaurant);
        });
    }
}

@FeignClient("restaurant-service")
interface RestaurantClient {

    @RequestMapping(method = RequestMethod.GET, value = "/v1/restaurants")
    Collection<Restaurant> getRestaurants(@RequestParam("name") String name);
}

All preceding examples will print the following output:

[ 1 Big-O Restaurant]
[ 2 O Restaurant]

After client-side load balancing, it is important for us to define server-side load balancing. In addition, from the microservice architecture's point of view, it is important to define the routing mechanism for our OTRS app. For example, / may be mapped to our UI application, /restaurantapi is mapped to restaurant service, and /userapi is mapped to user service.

We'll use the Netflix Zuul Server as our Edge Server. Zuul is a JVM-based router and server-side load balancer. Zuul supports any JVM language for writing rules and filters and having the in-built support for Java and Groovy.

The external world (the UI and other clients) calls the Edge server, which uses the routes defined in application.yml to call internal services and provide the response. Your guess is right if you think it acts as a proxy server, carries gateway responsibility for internal networks, and calls internal services for defined and configured routes.

Normally, it is recommended to have a single Edge Server for all requests. However, few companies use a single Edge Server per client to scale. For example, Netflix uses a dedicated Edge Server for each device type.

An Edge Server will also be used in the next chapter, when we configure and implement microservice security.

Configuring and using the Edge Server is pretty simple in Spring Cloud. You need to use the following steps:

Let's see a working Edge Server. First, we'll call the restaurant service deployed on port 3402, shown as follows:

Direct Restaurant service call

Then, we'll call the same service using the Edge Server that is deployed on port 8765. You can see that the /restaurantapi prefix is used for calling /v1/restaurants?name=o, and it gives the same result:

Restaurant Service call using Edge Server