Мікросервісна архітектура для початківців. Частина ІІ

We continue to understand the microservice architecture! In the previous article, we considered the terms without which it is impossible to take the first steps in this field.

In general, the architecture of microservices is quite simple. It is just a pattern that guides us through the process of applying other architectural patterns according to best practices and principles. However, the implementation itself requires knowledge of some topics that should be kept in mind before starting development. We will not delve into the details because these topics require a deep dive and cannot be covered in one article. Instead, you can learn more about them on your own if you know what and where to look.

Interservice communication

Strategy

Communication and networking aspects are the first thing we should think about when we get into the field of distributed systems development. In particular, we will talk about interdepartmental communication, which differs from interprocessor communication.

Basic communication strategies

There are various high-level and low-level network protocols that can be used together or separately. However, first of all, a general communication strategy should be defined. The main communication strategies are divided into four types, shown in the diagram above.

It:

• Blocking and synchronous
• Blocking and asynchronous
• Non-blocking and synchronous
• Non-blocking and asynchronous

If we take all the available technologies and put them on the diagram above, we will get a visual tool that will tell us which technologies are suitable for us and which are not. It is enough to remove from the scheme all the technologies that do not suit us.

API

As part of choosing a communication strategy, REST/HTTP and GraphQL are the basic protocols commonly used to provide high-level web APIs. In any case, the design of high-level APIs requires a clear understanding of API Management best practices.

For beginners, it is important to understand the concepts of API Gateway and API versioning. Understanding the API-Led Connectivity pattern is the starting point for a deep dive into the organization of low-level APIs and subsystems.

Fault tolerance

In a microservices architecture, fault tolerance is not very different from common practices of distributed systems. However, I think it’s worth starting with latency tracking and error and exception handling.

Here you should think about:

• Timeout – to guarantee a response time
• Retry – to automate retries in case of network degradation
• Circuit Breaker – for control in case of cascading errors
• Deadline – for controlling long requests that depend on many services
• Rate Limiter – for load control according to SLA (Service Layer Agreement)

Data consistency

Unlike a monolith, we also don’t have a single database. Working with multiple data sources requires a distributed transaction management mechanism. But usually distributed transactions are not used in microservices architecture. The reason is that

a) the use of existing solutions limits us in terms of supported technologies;
b) building your own distributed transaction processing system can be very complex, and again will be limited in technology support and may require significant maintenance efforts.

Instead, microservices use an event-driven approach available for implementation in two models: orchestration and/or choreography.

Transactions

First of all, stop thinking about transactions in databases. Think about a business transaction. In economic organizations, business process transactions are performed in an event-oriented manner. Example.

When you buy a cup of coffee, there are no database transactions involved in this process. You pay money and wait in line until you get a notification that your coffee is ready. If something goes wrong, you ask for compensation and either get your coffee or your money back. In other words, it is an event-driven architecture.

Events

There are two logical entities: events and messages. They differ logically in the same way as an event bus from a message queue. It is necessary to distinguish the logical difference between these terms.

A message is a part of systems based on message brokers, where a message is sent to a queue/topic, given that a consumer will receive it and do something about it. This model is called “fire and forget”.

Events are slightly different from messages. The message can be anything (number, text, JSON, etc.). Events, in turn, are logically complete contextual information and must have a well-defined structure (for example, JSON). Events can also be stored in the system until a specific time for repeated use (event replay) or audit.

Event buses are usually responsible for storing/streaming/processing events, which is how they differ from message brokers. For example, Kafka vs. RabbitMQ.

Patterns

There are commonly used patterns that are used to implement event-oriented microservice systems.

For example:

• Event Sourcing – for saving the state of the program in a series of events
• CQRS – to take advantage of the separation of read and write models
• SAGA – to ensure global data consistency using a sequence of local transactions
• Event Streaming – for applying the principles of stream processing to events

Infrastructure

A microservices architecture can become very complex, so infrastructure management and DevOps best practices are important at all stages of development.

Developing a scalable and high -available microservice solution can take a lot of effort. Including, it is difficult to maintain a system where there are hundreds of microservices.

One of the ways to overcome such a situation is the use of domain-oriented decoupling, which is based on the grouping of microservices by business domain (context). Such systems are divided into smaller business domains (contexts) that interact through the event bus. Within each domain (context), services can interact with each other either through an API or through an event bus. However, services do not have direct access to APIs of other domains’ services, they can only communicate with them through the event bus. As a result, the subsystems built are smaller in size and more manageable in terms of support and maintenance.

In any case (multi-domain or not), in a microservices architecture you will have to deal with topics such as:

• Code Repositories – mono-repo vs. multi-repo
• Deployment Strategies — including environment topology (dev, qa , uat, prod) and deployment strategies (blue-green, canary, etc.).
• Automation – including cluster orchestration, Service Mesh, CI/CD .
• Common Concerns – containerization, orchestration, configuration, security, monitoring, logging, tracing, caching, communications, etc.
• Testing – e2e, integration, contract-driven, etc.

Conclusion

As you can see, the concept of microservice architecture has many topics to explore. We saw only the tip of the iceberg. Depending on the type of your application, you may also find it useful to learn about:

• best practices of refactoring monoliths to microservices
• data processing platforms (Data Platform, Data Lake)
• various event-driven architectures

So feel free to ask questions, collaborate and stay in touch! Where and how? To your attention – the professional communities of GlobalLogic operating on Facebook :