What are Microservices?
Microservice, a.k.a, microservice architecture is an architectural style with an approach for developing a single application as a suite of small services, each running in its own process and communicating with a lightweight resource API that has the following characteristics:
- Loosely coupled
- Highly maintainable
- Easily testable
- Independently deployable
- Built around business capabilities or single responsibilities
- Fault isolation
- Resilient
- Scalable
- Easy to integrate with third party APIs
- Small and smart end-point
Microservices vs Monolithic Applications
Microservice is a separate, with single responsibility, easily deployable, loosely coupled, independent as opposed to monolithic app.
In monolithic app database is common, entire app is built and if anything goes wrong the whole app goes down. So monolithic architectural style is built as a single, autonomous unit. So let’s say an web application with client-server model, where the server-side application is a monolith application that handles request/response, executes business logic and work with the data in the underlying database. Any modification made to a small part of a monolithic application requires deploying entirely the new version.
Each microservice has separate database. In microservices if anything goes wrong then the particular microservice will go down. Independent development is possible in microservices.
How to break a Monolith web service into Microservices?
You have a legacy monolithic web service. You want to break into multiple loosely coupled microservices. Here are few steps you can consider while breaking into microservices architecture.
Overall approach would look like following:
- Design: Figuring out what are separate “byte sized” microservices?
- Getting started: Start deploying micro services, as well as a single API Gateway to consolidate all micro services under one gateway for ease of communication from client.
- Testing the overall solutions.
- Migration strategy
- Performance testing; comparing data with older runs.
Why eureka server is used in microservices?
It’s a Spring cloud. Used for registering and discovering the services. We need to define for each service with the URL. each service will have service name. It is not good idea to hard-code the URLs of the services.
To understand why the Eureka server is needed in microservice architecture, let’s understand how one service calls another service REST endpoint for communication. Say we need to call the employee payroll service to get payroll information for an employee. The payroll service is deployed on the localhost 8080 port (we got that information by passing the employee primary key) so we just call the following: http://localhost:8080/payroll/1 or http://127.0.0.1/payroll/1 Where localhost/127.0.0.1 is the hostname/IP address and payroll is the payroll service context, 1 is the employee primary key. But this is only possible when you know the hostname/IP addresses beforehand, then you can configure your URL. So here the hostname or IP address is a constraint or a pain point. If the IP address of a server/container is fixed, then you can use that approach, but what happens when your IP addresses and hostname are unpredictable? Nowadays, on a cloud platform, it is obvious that all the servers or containers use dynamic IPs for auto scaling. And the interesting thing is that in microservice architecture, the key principle is that your service can auto-scaled as per load, so cloud platforms are ideal for microservices. What I am trying to say here is that we can not predict the IP addresses of the container/server beforehand, so putting dependent services IP addresses in the config file is not a solution. We need a more sophisticated technique to identify the service, and Eureka server steps in here.
What are different ways to manage transactions in microservices architecture?
Over a period of time Microservices community devised different ways of handling transactions across Microservices. Some of the approaches address transaction management at the design level and others at design and coding level. The good part is that we can use one or all of these below approaches in a given Microservices environment. In a given environment, two Microservices can use one approach and other can follow the different approach for transaction management. Avoiding transactions across Microservices Two-Phase Commit Protocol XA Standard REST-AT Standard Draft Eventual Consistency and Compensation.
What is the use of Container in Microservices?
Containers are a good way to manage microservice based application to develop and deploy them individually. You can encapsulate your microservice in a container image along with its dependencies, which then can be used to roll on-demand instances of microservice without any additional efforts required.
API Gateway
API Gateway is a special class of microservices that meets the need of a single client application (such as android app, web app, angular JS app, iPhone app, etc) and provide it with single entry point to the backend resources (microservices), providing cross-cutting concerns to them such as security, monitoring/metrics & resiliency.
Client Application can access tens or hundreds of microservices concurrently with each request, aggregating the response and transforming them to meet the client application’s needs. Api Gateway can use a client-side load balancer library (Ribbon) to distribute load across instances based on round-robin fashion. It can also do protocol translation i.e. HTTP to AMQP if necessary. It can handle security for protected resources as well.
Features of API Gateway
Spring Cloud Discovery Client integration, Request Rate Limiting (available in Spring Boot 2.x), Path Rewriting, Hystrix Circuit Breaker integration for resiliency
What are the differences between Monolithic, SOA and Microservices Architecture?
Monolithic Architecture is similar to a big container wherein all the software components of an application are assembled together and tightly packaged.
A Service-Oriented Architecture is a collection of services which communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity.
Microservice Architecture is an architectural style that structures an application as a collection of small autonomous services, modeled around a business domain.
What is orchestration and Choreography approach in micro services ?
In Orchestration, we rely on a central system to control and call other Microservices in a certain fashion to complete a given task. The central system maintains the state of each step and sequence of the overall workflow.
Let’s say we want to develop a microservice that will send product recommendation email in a fictitious e-shop. In order to send Recommendations, we need to have access to user’s order history which lies in a different microservices.
In Orchestration approach, this new microservice for recommendations will make synchronous calls to order service and fetch the relevant data, then based on his past purchases we will calculate the recommendations. Doing this for a million users will become cumbersome and will tightly couple the two microservices.
In Choreography approach, we will use event-based Asynchronous communication where whenever a user makes a purchase, an event will be published by order service. Recommendation service will listen to this event and start building user recommendation. This is a loosely coupled approach and highly scalable. The event, in this case, does not tell about the action, but just the data.
How to avoid transactions for Microservices?
Avoiding transactions across Microservices:
Let’s take the example of twitter application
Assume that If Twitter maintains two different Microservices for user profile information and tweets information then want to show the last tweet date time of User on User profile screen, so storing/updating tweet’s date, time everytime whenever Users tweets any new tweet in Users table, so we need to maintain distributed transaction across tweets and users information Microservices.
Another way is to get the last tweet’s date, time of users while showing user’s profile information by making a separate request to tweets microservice to get the latest tweet’s date time and show it dynamically, this way we can stop avoiding the distributed transactions across multiple services without storing tweet’s date time in the User table.
This approach addresses the transaction management challenge primarily at the design level.
What are Reactive Extensions in Microservices?
Reactive Extensions also are known as Rx. It is a design approach in which we collect results by calling multiple services and then compile a combined response. These calls can be synchronous or asynchronous, blocking or non-blocking. Rx is a very popular tool in distributed systems which works opposite to legacy flows.
What are different ways to manage transactions in microservices architecture?
Over a period of time Microservices community deviced different ways of handling transactions across Microservices. Some of the approaches address transaction management at the design level and others at design and coding level.
Following are the list of different approaches which we can use in managing transactions. The good part is that we can use one or all of these below approaches in a given Microservices environment. In a given environment, two Microservices can use one approach and other can follow the different approach for transaction management.
- Avoiding transactions across Microservices
- Two-Phase Commit Protocol
- XA Standard
- REST-AT Standard Draft
- Eventual Consistency and Compensation
What do you understand by Distributed Transaction?
Distributed Transaction is any situation where a single event results in the mutation of two or more separate sources of data which cannot be committed atomically. In the world of microservices, it becomes even more complex as each service is a unit of work and most of the time multiple services have to work together to make a business successful.
For example: Checking out an online shopping cart. It would involve potentially a third party payment gateway service, inventory service, and more.