Microservices

 Principles Used to Design Microservice Architecture

The principles used to design Microservices are as follows:

1. Independent & Autonomous Services
2. Scalability
3. Decentralization
4. Resilient Services
5. Real-Time Load Balancing
6. Availability
7. Continuous delivery through DevOps Integration
8. Seamless API Integration and Continuous Monitoring
9. Isolation from Failures
10. Auto -Provisioning

Design Patterns of Microservices

1. Aggregator
2. API Gateway
3. Chained or Chain of Responsibility
4. Asynchronous Messaging
5. Database or Shared Data
6. Event Sourcing
7. Branch
8. Command Query Responsibility Segregator
9. Circuit Breaker
10. Decomposition

API Gateway Design Pattern

Microservices are built in such a way that each service has its own functionality. But, when an application is broken down into small autonomous services, then there could be few problems that a developer might face. The problems could be as follows:

1. How can I request information from multiple microservices?
2. Different UI require different data to respond to the same backend database service
3. How to transform data according to the consumer requirement from reusable Microservices
4. How to handle multiple protocol requests?

Well, the solution to these kinds of problems could be the API Gateway Design Pattern.  

The API Gateway Design Pattern address not only the concerns mentioned above but it solves many other problems. 

This microservice design pattern can also be considered as the proxy service to route a request to the concerned microservice. 

Being a variation of the Aggregator service, it can send the request to multiple services and similarly aggregate the results back to the composite or the consumer service. 

API Gateway also acts as the entry point for all the microservices and creates fine-grained APIs’ for different types of clients.

With the help of the API Gateway design pattern, the API gateways can convert the protocol request from one type to other. Similarly, it can also offload the authentication/authorization responsibility of the microservice.

So, once the client sends a request, these requests are passed to the API Gateway which acts as an entry point to forward the clients’ requests to the appropriate microservices. 

Then, with the help of the load balancer, the load of the request is handled and the request is sent to the respective services. 

Microservices use Service Discovery which acts as a guide to find the route of communication between each of them. 

Microservices then communicate with each other via a stateless server i.e. either by HTTP Request/Message Bus.

@EnableEurekaServer

@EnableEurekaClient

                <dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>

</dependency>

server:

  port: 8081

spring:

  application:

    name: API-GATEWAY

  cloud:

    gateway:

      routes:

        - id: USER-SERVICE

          uri: lb://USER-SERVICE

          predicates:

            - Path=/**

          filters:

            - name: CircuitBreaker

              args:

                name: USER-SERVICE

                fallbackuri: forward:/userServiceFallBack

        - id: LOGIN-SERVICE

          uri: lb://LOGIN-SERVICE

          predicates:

            - Path=/api/auth/**

          filters:

            - name: CircuitBreaker

              args:

                name: LOGIN-SERVICE

                fallbackuri: forward:/loginServiceFallBack

hystrix:

  command:

    fallbackcmd:

      execution:

        isolation:

          thread:

            timeoutInMilliseconds: 4000

Asynchronous Messaging Design Pattern

From the above pattern, it is quite obvious that the client gets blocked or has to wait for a long time in synchronous messaging. But, if you do not want the consumer, to wait for a long time, then you can opt for the Asynchronous Messaging. 

In this type of microservices design pattern, all the services can communicate with each other, but they do not have to communicate with each other sequentially. 

So, if you consider 3 services: Service A, Service B, and Service C. The request from the client can be directly sent to the Service C and Service B simultaneously. These requests will be in a queue. Apart from this, the request can also be sent to Service A whose response need not have to be sent to the same service through which request has come.

Circuit Breaker Pattern

As the name suggests, the Circuit Breaker design pattern is used to stop the process of request and response if a service is not working. 

So, for example, let’s say a client is sending a request to retrieve data from multiple services. But, due to some issues, one of the services is down. 

Now, there are mainly two problems you will face: first, since the client will not have any knowledge about a particular service being down, the request will be continuously sent to that service. 

The second problem is that the network resources will be exhausted with low performance and bad user experience.

So, to avoid such problems, you can use the Circuit Breaker Design Pattern. With the help of this pattern, the client will invoke a remote service via a proxy. 

This proxy will basically behave as a circuit barrier. So, when the number of failures crosses the threshold number, the circuit breaker trips for a particular time period. 

Then, all the attempts to invoke the remote service will fail in this timeout period. Once that time period is finished, the circuit breaker will allow a limited number of tests to pass through and if those requests succeed, the circuit breaker resumes back to the normal operation. Else, if there is a failure, then the time out period begins again.