Microservices
Last updated
SC - Software Architecture
Last updated
A software design choice, that breaks a single application design choice (Monolith) into several pieces (Services).
Each of these services are:
One of it's major advantages is the possibility to scale each service independently.
Each service can be developed by it's own separate team, and this:
This makes teams more autonomous.
Accelerates development and deployment.
Having a Microservice Architecture with:
Scalability, Service independence, Fail tolerance and Resilience.
Requires:
Good Strategic Modeling.
Async communication between services.
Event-Driven Architecture.
CQRS.
Dont't have your services depend on each other.
Having dependency between services is the worst case scenario.
When you have to scale your teams, or the application independently.
When you have well defined contexts/business areas.
When you have maturity in deployment processes. (Like CI/CD)
In this way, a microservice makes a HTTP request directly to another microservice to do something.
Mainly used for communication for operations that require an immediate response, like data query or actions that need an immediate confirmation.
Major downside that one service is tightly coupled to the other.
In this way, microservices communicate over asynchronous messages that are place over queues or topics.
Mainly used for events and background processes, where an immediate response is not required.
Increases microservice independence.
It is a decentralized way of setting up communication between services, where the own services knows what other services they depend on.
Mini API GatewayYou add API Gateways in front of a group of Services. (That usually are in the same Context)
It is also possible to add rules, like Limits, Transformations, and other resources available by an API Gateway.
It is a centralized way of setting up communication between services, where a Mediator is used to handle which service should be called after another.
And if something goes bad between a transaction, the Mediator can undo all in the correct order.
At some point every system will fail, so how can I mitigate these risks of data and transactions loss.
A system in a distributed architecture should adopt auto-preservation mechanisms to garantee its operation.
Also a system should not be selfish in doing non-stop requests to another failing system.
Indepotence is the ability to detect and deal with duplicity. (Ex.: Duplicated requests sent to Queues)
Fallback policies to define what should happen or what should be done when something is unavailable.
Help alot with APM (Application Performance Monitoring).
Allows easy tracing of errors with Distributed Tracing.
Personalized metrics.
A mechanim to check the health of systems.
An unhealth system have a chance to recover, if traffic can be redirected out of it.
In active mode, the system itself will self ping and check its health.
In passive mode, the system will only know its health after someone else checked for him.
Can protect a sytem based on the limits it was supposed/build to handle.
It protects a system, making all requests to it to be blocked.
Policies for retrying to reach services if they fail.
Retries are done within a contant time between tries.
The time between tries increase exponentialy.
Again the time between tries grows, but an additional mount of time (Jitter/Noise) is added.
Choose this policy, since it decreases the probability of different requests, retry at the same time.
It is a single point of entry for a group of services.
It can garantee that inappropriate requests don't hit internal services. (Like unauthenticated users)
It also help us to organize our microservices in contexts.
API Gateways can be stateless or stateful.
It can control and monitor the entire network, by using Proxies in front of the services.
The Service Mesh handles, Rate limiting, Healthchecks, Circuit Breakers, Retries, etc..
This is a Pattern of Event Driven Architecture, .
In some extreme cases, where you have thousands of microservices you may end up with a topology like .
This is a Pattern of Event Driven Architecture, .
Independent from each other:
Will have their own databases.
Will have it's own scalability parameters.
You should be able to completly shutdown a microservice and this should not bring down any other microservice.
Will communicate with each other by an Event Bus (API's, Queues, Streams, etc.)
Meaning that they also won't directly access other services databases.
Will have eventual consistency, because of this async communication.
Closed Circuit
Requests arrive normally.
Opened Circuit
Requests are blocked.
Semi Opened Circuit
Allows limited amount of requests, for system check reasons.
