In this blog first am going to describes some of the recommended design patterns on whom microservices is implemented along with that monolithic architecture and what are the advantages and disadvantages of it , along with that microservice architecture and its advantages.
what is microservices?
The microservices architectural style is an approach of developing a single application split into set of smaller, interconnected services, distributed instead of building single monolithic application. And each split will be developed individually, packaged individually and deploy individually.
Introducing to Microservice:
How to design a microservices using micro service architecture.
Here we are going to see one of the use case that is Uber architecture.
There are lots of use case those are implemented based on microservice architecture. For example, Uber, OLA cab, any e-commerce site like flip kart, amazon etc. These organization internal architecture are completely implemented on Microservice architecture.
Lets guys discuss one of the real-time implementation who migrate their architecture from monolithic design pattern to Microservice architecture
Uber architecture before it is going to convert to microservice architecture, basically it is a monolithic architecture. One of the best example is
Uber architecture which completely implemented based on microservice architecture design pattern.
So before going to discuss microservice architecture lets just overlook what is monolithic architecture? And what reason or pitfall behind the monolithic architecture that make to force Uber people to migrate from monolithic architecture to microservice architecture.
In monolithic architecture after developing every services at the end we packaging all the services in a single war file and deploy in the server.
WHAT IS MONOLITHIC ARCHITECTURE:
Stripe adopter used for billing, there are multiple api which are available inside the stripe.Stripe adopter will give some billing application.
SENDGRID is for sending the mail. So, if we want send automatically mail two different mail host with secured stuff we can use SENDGRID api.
Twilio adopter is for sending sms. Whenever we are getting any cab book message that will be run by Twilio adopter.
Finally MySQL adopter where data is stored in database.
This is the monolithic architecture which was implemented by Uber when it is initially launched.
This application has internally the passenger management, billing, notification, payments, trip management and driver management all these are composed in single application so basically this is running in single monolithic application. This is kind of distributed monolithic architecture because everything will connect to a single server.
So if I need to do some modification in the billing I have to change the whole application, means I need to create a new release or version of the application. Which is a great disadvantage of monolithic architecture.
Disadvantages in Monolithic architecture:
1. Continuous deployment integration will suffer a lot.
means a small modification in one component force to us to redeploy the entire application again with a new release.
2. Monolithic application has a barrier for adapting new technology.
Since changes in framework will affect the entire application, thatís why it is extremely expensive in both development time and development cost.
3. Exception propagation not proper.
For example letís consider if my payments service go down then it impacts to my Entire application.
4. Code Readability is not there.
5. As we deployed entire service as WAR, the performance of the application goes down because of huge amount of data present in the war.
6. The size of the application can slow down the startup time.
7. We must and should redeploy the entire application for each update.
8. It also difficult to scale up when different modules have conflicting resource requirement.
Microservice Design Patterns
Letís discuss some design pattern upon which microservices is implemented.
1)Aggregator Microservice Design Pattern:
The most commonly used design pattern is aggregator microservice design pattern.
Aggregator is a simple web page that invokes multiple services to achieve the functionality required by the application.
Letís consider Service A, Service B, and Service C are exposed using a lightweight REST mechanism, the web page can retrieve the data and process/display it accordingly.
If there are multiple services that need to access Service A, B, and C, then its recommended to abstract that logic into a composite microservice and aggregate that logic into one service.
each individual microservice has its own caching and database. If Aggregator is a composite microservice, then it may have its own caching and database layer.
It can be scale up based on our requirement.
It is a variation of Aggregator. In this case, the aggregation need not to be required on the client but a different microservice may be invoked based upon the business need.
It can be scale up based on our requirement as like aggregator microservice design pattern.
We need to go for this where each individual service need not be exposed to the consumer and should go through an interface.
3)Chained Microservice Design Pattern:
Chained microservice design pattern produce a single or unified response to the request.
In this situation, the request from the client is received by Service A, which is then communicating with Service B, which in turn may be communicating with Service C. All the services are likely using a synchronous HTTP request/response messaging
The major disadvantage is that the client is blocked until the complete chain of request/response.
That means the client should wait until Service A and Service B along with that the Service B Service C, till completed their request.
The request from Service B to Service C may be look completely different from the request from Service A to Service B.
Similarly, response from Service B to Service A may look completely different from Service C to Service B. And this is the whole point where different services are adding their business value.
4)Branch Microservice Design Pattern:
Branch microservice design pattern extends Aggregator design pattern.
It allows simultaneous response processing from two chains of microservices.
Letís Service A is either a web page or a composite microservice, it can invoke two different chains simultaneously. It seems to be similar with the Aggregator design pattern.
5)Asynchronous Messaging Microservice Design Pattern:
As The REST design pattern is quite widespread, and well understandable but it have some limitation like being synchronous as a result it also quite blocking in nature.
Even though we can achieve Asynchronous but that is done based on an application specific way.
Some microservice architectures use message queues instead of REST request/response for achieving Asynchronous Messaging supports.
In this pictorial diagram, the Service A may call Service C synchronously which is then communicating with Service B and D asynchronously using a shared message queue.
The main base concept of microservices architecture is split your application into set of smaller, interconnected services instead of building single monolithic application.
Its an architectural way of designing or building the application with several small modules which is developed individually, packaged individually and deploy individually
Each microservices is a small application with hexagonal architecture along with plugins of various adapter like STRIPE adapter and TWILIO adapter.
So Uber people refactor the whole application and comes up with new architecture i.e microservice architecture.
From API gateway all internal rest architecture are connected. The API gateway acts as a common gateway to my application.
So literally any one can connect api gateway and after that he will connect to any microservices.
All these are individually deployable unit, thatís why these are called microservices, we can individually deploy them without deploying all the application. If we want to change anything within trip management we can separately do that instead of disturbing other units. That means it completely follows clean and cut separation of concern.
See as per diagram, each service are interlink with each other but all modules are separate here means independent war.
First of all just think as per above pictorial diagram we developed 8 micro services, as we are not going to deploy all the microservices as a single war, then how these all means 8 microservices are communicating with each other. Thatís why lot of third party vendors comes into picture and give their hand support for Micro services architecture. Netflix is one of them who provide support for to register N number of micro services. So the Netflix community provided one embedded server which is Eureka where we can register our micro services to communicate with each other.
What is API Gateway?
The API gateway is a service that provides each client with unified interface to services.
The API-Gateway is nothing but it can be any Cloud environment or Eureka or Zuul proxy server. So from User Interface we are not going to communicate directly to our micro services.
First of all when we send the Request it will comes to API-Gateway, the based on incoming URL pattern it will find mapping controller from Service Registry after that it will delegate the Request to corresponding Controller and execute the business logic.
That is how Uber has splits their microservices.
1) CDI development will not suffer a lot.
Means it enable each service to be developed independently by team which is focused on that particular service. Along with that each service can be scale up independently.
2)Exception propagation is very proper and high extensive.
if any service goes down then it donít impact the Entire application we can propagate it by using Hystrix.
3)Code Readable is very clear and high extensive.
4)As we deployed each service individually in different container and register them in Eureka Service Registry the performance performance of the application is very high.