Microservices Design principle & Design patterns
Vivek Yadav
Arth3.0 Learner|| MERN || Docker || Linux || AWS || python || ML || JS || Kubernetes || Jenkins || Ansible
What is Microservice Architecture?
The microservice architecture is structured on the business domain and it's a collection of small autonomous services. In a microservice architecture, all the components are self-contained and wrap up around a single business capability.
Why do we need to consider the microservice architecture instead of using monolithic architecture? Below mentioned four main concepts that described the importance of microservice architecture over monolithic architecture.
1. Visibility is high - MSA provides better visibility to your services.
2. Improves resilience - Improves the resilience of our service network
3. Production time reduced - Reduce the delivery time from idea to final product.
4. Reduced cost - Reduce the overall cost of designing, implementing, and maintaining IT services.
Essential Microservice Design Patterns and Principles
Now that you know what is Microservice architecture and why you need to consider Microservice architecture to build applications that can stand the test of time and are scalable enough to handle real-world traffic, let's now go through the fundamental principle of Microservices and?design pattern?which you can use to solve common problem associate with microservice architecture.?
Let's look at the principles in which the microservice architecture has been built.
?1. Scalability
?2. Flexibility
3. Independent and autonomous
4. Decentralized governance
5. Resiliency
6. Failure isolation.
7. Continuous delivery through the DevOps
In this article, we are going to discuss design patterns which are mentioned below.
??????1. Database per Microservice
??????2. Event Sourcing
??????3. CQRS
??????4. Saga
??????5. BFF
??????6. API Gateway
??
So first start with the Database per Microservice design pattern.
1. Database per Microservice Pattern
Database design is rapidly evolving, and there are numerous hurdles to overcome while developing a microservices-based solution. Database architecture is one of the most important aspects of microservices.?
What is the best way to store data and where should it be stored?
There should are two main options for organizing the databases when using the microservice architecture.?
1.1 Database per service.
The concept is straightforward. There is a data store for each microservice (whole schema or a table). Other services are unable to access data repositories that they do not control. A solution like this has a lot of advantages.
Individual data storage, on the other hand, is easy to scale. Furthermore, the microservice encapsulates the domain's data. As a result, understanding the service and its data as a whole is much easier. It's especially crucial for new development team members.?
It will take them less time and effort to properly comprehend the area for which they are responsible. The main drawback of this database service is that there is a need for a failure protection mechanism in case the communication fails.?
1.2 Shared Database
The use of a shared database is an anti-pattern. It is, however, questionable. The issue is that when microservices use a shared database, they lose their key features of scalability, robustness, and independence. As a result, Microservices rarely employ a shared?database.
When a common database appears to be the best solution for a microservices project, we should reconsider if microservices are truly necessary. Perhaps the monolith is the better option. Let's have a look at how a shared database works.
Using a shared database with microservices isn't a frequent scenario. A temporary state could be created while moving a monolith to microservices. Transaction management is the fundamental advantage of a shared database versus a per-service database. There's no need to spread transactions out across services.
2. Event Sourcing Pattern
The event sourcing is responsible for giving a new ordered sequence of events. The application state can be reconstructed using querying the data and in order to do this, we need to reimage every change to the state of the application.?Event Sourcing?is based on the idea that any change in an entity's state should be captured by the system.?
The persistence of a business item is accomplished by storing a series of state-changing events. A new event is added to the sequence of events every time an object's state changes. It's essentially atomic because it's one action. By replaying the occurrences of an entity, its current state can be reconstructed.
An event store is used to keep track of all of your events. The event store serves as a message broker as well as a database of events. It gives services the ability to subscribe to events via an API. The event store sends all interested subscribers information about each event that is saved in the database. In an event-driven microservices architecture, the event store is the foundation.
This pattern can be used in the following scenarios,
So as from the above discussion, it is clearly indicated that the event sourcing addresses a challenge of implementing an event-driven architecture. Microservices with shared databases can't easily scale.?The database will also be a single point of failure. Changes to the database could have an influence on a number of services.
领英推荐
3. Command Query Segmentation (CQRS)?Pattern
In the above, we have discussed what is event sourcing. In this topic, we are going to discuss what is CQRS? We can divide the topic into two parts with commands and queries.
?Commands - Change the state of the object or entity.
?Queries -?Return the state of the entity and will not change anything.
In traditional data management systems, there are some issues,
??1. RisK of data contention
??2. Managing performance and security is complex as objects are exposed to both reading and writing applications.?
So in order to solve these problems, the CQRS comes to the big picture. The CQRS is responsible for either change the state of the entity or return the result.?
benefits of using the CQRS are discussed below.
??1. The complexity of the system is reduced as the query models and commands are separated.
??2. Can provide multiple views for query purposes.
??3. Can optimize the read side of the system separately from the write side.?
The write side of the model handles the event's persistence and acting as a source of information to the read side.?The system's read model generates materialized views of the data, which are often highly denormalized views.
4. SAGA
SAGA is one of the best solutions to keep consistency with data in distributed architecture without having the ACID principles. SAGA is responsible for committing multiple commentary transactions by giving rollback opportunities.
There are two ways to achieve the saga's
1. Choreography
2. Orchestration.
In this choreography saga, there is no central orchestration.?Each service in the Saga carries out its transaction and publishes events. The other services respond to those occurrences and carry out their tasks. In addition, depending on the scenario, they may or may not publish additional events.
In the Orchestration saga, each service participating in the saga performs their transactions and publish events.?The other services respond to those events and complete their tasks.
Advantage of using SAGA?
1. Can be used to maintain the data consistency across multiple services without tight coupling.
The disadvantage of using SAGA
1. Complexity of the SAGA design pattern is high from the programmer's point of view and developers are not well accustomed to writing sagas as traditional transactions.
5. Backend For Frontend (BFF)
This pattern is used to identify how the data is fetched between the server and clients. Ideally, the frontend team will be responsible for managing the BFF.
A single BFF is responsible for handling the single UI and it will help us to keep the frontend simple and see a unified view data through the backend.
Why BFF needs in our microservice application?
The goal of this architecture is to decouple the front-end apps from the backend architecture.
As a scenario, think about you have an application that consists of the mobile app, web app and needs to communicate with the backend services in a microservices architecture.?
This can be done successfully but if you want to make a change to one of the frontend services, you need to deploy a new version instead of stick to updating the one service.
So here comes the?microservice architecture?and this is able to understand what our apps need and how to handle the services.
This is a big improvement in microservice architecture as this allows to isolate the backend of the application from the frontend. One other advantage that we can get from this BFF is that we can reuse the code as this allows all clients to use the code from the backend.?
Between the client and other external APIs, services, and so on, BFF functions similarly to a proxy server. If the request must pass through another component, the latency will undoubtedly increase.
6. API Gateway
This microservice architecture pattern is really good for large applications with multiple client apps and it is responsible for giving a single entry point for a certain group of microservices.?
API gateway sits between the client apps and the microservices and it serves as a reverse proxy, forwarding client requests to services.?Authentication, SSL termination, and caching are some of the other cross-cutting services it can provide.
Why do we consider the API Gateway architecture instead of using direct client-to-microservice communication? We will discuss this with the following examples,
1. Security issues?-?All microservices must be exposed to the "external world" without a gateway, increasing the attack surface compared to hiding internal microservices that aren't directly accessed by client apps.
2. Cross-cutting concerns?- Authorization and SSL must be handled by each publicly published microservice. Those problems might be addressed in a single tier in many cases, reducing the number of internal microservices.
3. Coupling?-?Client apps are tied to internal microservices without the API Gateway pattern. Client apps must understand how microservices decompose the application's various sections.
Last but not least, the microservices API gateway must be capable of handling partial failures. The failure of a single unresponsive microservice should not result in the failure of the entire request.
A microservices API gateway can deal with partial failures in a variety of ways, including: