Spring Cloud - Part 2

Clients are such an important part of any business architecture, because it is for them all the services are meant and we remain always committed in fulfilling their ends, and if they provide an easy interface to interact with them, then sure I cannot ask for more.

To access the microservices, we either use:

1. Restemplate based client
2. Feign Based client.
We will discuss both of them here.

I have uploaded my code base at GITHUB

When talking about clients that can access the services rather microservices registered in Eureka, the first approach we have taken is with “RESTTemplate”.

The RESTTemplate that we have used (rather injected) in Spring-Cloud-Client is auto configured by Spring Cloud and uses Netflix Ribbon to do the micro-service lookup.

Ribbon is the software based load balancer implemented at the client side helps to pick a microservice based on service-name (as registered with the Eureka) specified with the property:

spring:
 
  application:
 
       name: client-service
 

in the properties file and transforms it into actual chosen service with host and port name.
[Note: Remember for each and every service that we will be registering in Eureka, we ensure that the port is dynamic with :

# HTTP Server
server:
 
   port: 0   # HTTP (Tomcat) port
 
    contextPath: /clientservice
 
 

configuration, we will see its Utility when we will be encountering Zuul, The GateKeeper]

Spring-Cloud-Client2: We can access Micro Services with another Client Technology Named “Feign”.

Feign is a declarative Web Service Client. Just like Spring JPA we need to define the interface and rest will be taken care by Spring Cloud. Let’s figure out how can we configure Feign Client.

Here is the starter Class:

@SpringBootApplication
@EnableEurekaClient
@EnableFeignClients
public class ClientStarter2 {
 
 public static void main(String[] args)
 {
  SpringApplication.run(ClientStarter2.class, args);
 }

}

The annotation @EnableFeignClients looks for the classes annotated with @FeignClient and creates and registers the bean of those classes in the ApplicationContext for we can use or in other words Autowire them, much on the same line as Spring Data JPA.

The client Class or Bean looks like:

@FeignClient("AUTH-SERVICE")
public interface FeignClientService2 {
 
 @RequestMapping(value = "/authservice/login", method = RequestMethod.GET)
 public String getFeignAuthInfo();
 
 @RequestMapping(value = "/authservice/loginUser", method = RequestMethod.GET)
 public String getFeignAuthInfoUser(String user);

}

@FeignClient takes the service id of the MicroService as the parameter and it signifies that this is the client for the corresponding MicroService, and the rest of the annotations are very much similar to Spring MVC. One this I would like to mention, is that the parameter to the method getFeignAuthInfoUser() i.e. user actually forms the request body of the actual service method of AUTH-SERVICE which somehow looks like:

@RequestMapping("/loginUser")
@ResponseBody
 public String loginUser(@RequestBody String user)
 {
  System.out.println("USERNAME:"+dbUser+"\n\n PASSWORD:"+dbPwd);
  return "Hurrahh!!! "+user+" Logged In....";
 }

There is nothing different in the property configuration, so not bringing them here.

Spring-Cloud-Zuul: Zuul the mighty “GATEKEEPER”. It may be defines as the starting point from where the calls will be traversing to various endpoints i.e. various services. It basically a Router.

Apart from Routing it provides the following services:

1) Security
2) Authentication etc.

Though we will be mainly see Routing here.
The Starter class looks like:

@EnableZuulProxy
@Controller
public class ZuulApplication {

 public static void main(String[] args) {
  // TODO Auto-generated method stub
  SpringApplication.run(ZuulApplication.class, args);
  //new SpringApplicationBuilder(ZuulApplication.class).web(true).run(args);

 }

}

We have made the Zuul Proxy to listen to particular port 8765, instead of dynamic one as we have done in all the previous services as we need to make calls to all other micro services through Zuul, we must have the host and port for the same.

So call would be like:
Zuul Proxy --------------> Client Service --------------> Actual Service (Here AUTH-SERVICE)

And this will be done with the following configuration:

zuul: 
 
   ignoredServices: "*" 
 
   routes: 
 
       CLIENT-SERVICE2: 
 
           path: /details/**
 
 

This configuration depicts that all service calls will be ignored except those with /details/** and when it is found it calls and finds the CLIENT-SERVICE2 and then the rest of the URL goes for the required service.

The URL I am using is:
http://localhost:8765/gatekeeper/details/clientservice2/feignauthDetails2

So, with http://localhost:8765/gatekeeper/details Zuul finds the service with ID CLIENT-SERVICE2 from the Eureka instance and then with the help of /clientservice2/feignauthDetails2 it invokes the required service.

My code base can be accessed at GITHUB

Interesting isn’t it.