| Table of Contents |
|---|
...
| Reference_description_with_linked_URLs_______________________ | Notes_________________________________________________________________ |
|---|---|
| Ward Cunningham - Portland Pattern Repository | |
| Gang of Four Design Patterns | |
| https://www.tutorialspoint.com/design_pattern/factory_pattern.htm | G4 Pattern summary tutorials point |
| https://springframework.guru/gang-of-four-design-patterns/ | G4 Pattern summary Spring - 1 page |
| JEE Enterprise Services Patterns | |
| Enterprise Integration Patterns | |
| https://microservices.io/patterns/index.html | Microservices Design Patterns |
| https://microservices.io/patterns/monolithic.html | Monolithic Architecture pattern |
| https://microservices.io/patterns/microservices.html | Microservices Architecture pattern |
| Microservices orchestration vs | |
Key Concepts
Declarative vs Imperative Coding
...
Microservices Application Pattern
Please see the example applications developed by Chris Richardson. These examples on Github illustrate various aspects of the microservice architecture.
Resulting Context
Benefits
...
- Decomposition patterns
- The Database per Service pattern describes how each service has its own database in order to ensure loose coupling.
- The API Gateway pattern defines how clients access the services in a microservice architecture.
- The Client-side Discovery and Server-side Discovery patterns are used to route requests for a client to an available service instance in a microservice architecture.
- The Messaging and Remote Procedure Invocation patterns are two different ways that services can communicate.
- The Single Service per Host and Multiple Services per Host patterns are two different deployment strategies.
- Cross-cutting concerns patterns: Microservice chassis pattern and Externalized configuration
- Testing patterns: Service Component Test and Service Integration Contract Test
- Circuit Breaker
- Access Token
- Observability patterns:
- UI patterns:
Microservice Orchestration vs Choreography
https://www.softobiz.com/microservice-orchestration-vs-choreography/
Microservice Orchestration Vs Choreography-softobiz.com.pdf
How to stitch these service modules together?
Orchestration = central controller
In an orchestra, we have a central man called the “orchestrator”. Therefore, he is responsible for invoking all the sounds.
Similarly, in the microservice orchestration, the orchestrator (central controller) handles all the microservice interactions. It transmits the events and responds to it.
The microservice Orchestration is more like a centralized service. It calls one service and waits for the response before calling the next service. This follows a request/response type paradigm.
Orchestration Benefits
Easy to maintain and manage as we unify the business process at the center.
In synchronous processing, the flow of the application coordinates efficiently.
Limitations
Creating dependency due to coupled services. For example, if service A is down, service B will never be called.
The orchestrator has the sole responsibility. If it goes down, the processing stops and the application fails.
We lose visibility since we are not tracking business process.
Microservice Choreography
It is the other way to achieve microservice interaction.
We want to avoid dependencies in a microservice architecture. So, that each service can work independently. Choreography solves this issue which was the main challenge in orchestration approach.
You can imagine Microservice Choreography as a belle dance (as shown in the above picture). In it, every individual performs steps independently.
Similarly, in microservice Choreography, every microservice performs their actions independently. It does not require any instructions. It is like the decentralized way of broadcasting data known as events. The services which are interested in those events, will use it and perform actions. This is also known as reactive architecture. The services know what to react to, and how-to, which is more like an asynchronous approach.
Benefits
Enables fast processing. As no dependency on the central controller.
Easy to add and update. The services can be removed or added anytime from the event stream.
As the control is distributed, there is no single point failure.
Works well with the agile delivery model, as teams work on certain services rather than on entire application.
Several patterns can be used. For example, Event sourcing, where events are stored, and it enables event replay. Command-query responsibility segregation (CQRS) can separate read and write activities.
Limitations
Complexity is the concerning issue. Each service is independent to identify the logic and react based on the logic provided from the event stream.
The Business process is spread out, making it difficult to maintain and manage the overall process.
Mindset change is a must in the asynchronous approach.
Most of the times, these approaches don’t work well in architecture. So, what is the solution in these use cases?
Hybrid
That is to say, the hybrid approach can solve the problem. For example, if we have a mix of synchronous and asynchronous blocks of activity. So consequently, one or more hybrid pattern can add value to the projects.
Hybrid is the combination of the orchestration approach and choreography. In this approach, we use orchestration within the services whereas we use choreography in between the services.
A Hybrid approach like others is two-edged. Let’s discuss:
Benefits
- The Overall flow is distributed. Each service contains its flow logic.
- Services are decoupled (but to an extent).
Limitations
- The coordinator is coupled with the services.
- If the coordinator goes down, it impacts the entire system.
Interoperable Blockchain ACID transaction pattern
...