Shulou(Shulou.com)06/03 Report--

This article mainly introduces "what are the most important design patterns of micro-service architecture". In daily operation, I believe many people have doubts about the most important design patterns of micro-service architecture. I have consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the questions about "what are the most important design patterns of micro-service architecture"! Next, please follow the editor to study!

Micro-service architecture

In my previous blog post, I have covered in detail the microservice architecture: a brief overview of why it is used in the next project and is the modular monolithic software architecture really dead? If you are interested, you can read them to learn more about them.

What is the micro-service architecture? There are many definitions of microservice architecture. This is my definition:

The microservice architecture aims to divide large, complex systems vertically (by functional or business requirements) into smaller subsystems that belong to processes (and therefore can be deployed independently) and communicate with each other through lightweight language-independent network communications (such as REST,gRPC) or asynchronously (through messaging).

This is the component view of a business Web application with a micro-service architecture:

> Microservice Architecture by Md Kamaruzzaman

Key features of the microservice architecture:

The entire application is divided into multiple separate processes, each of which can contain multiple internal modules.

In contrast to modular Monoliths or SOA, microservice applications are split vertically (based on business capability or domain)

The microservice boundary is external. As a result, microservices communicate with each other through network calls (RPC or messages).

Because microservices are independent processes, they can be deployed independently.

They communicate in a lightweight way and do not need any intelligent communication channels.

Advantages of microservice architecture:

Better development scale.

A higher speed of development.

Support iterative or incremental modernization.

Take full advantage of modern software development ecosystem (cloud, container, DevOps, serverless).

Horizontal scaling and granularity scaling are supported.

Because of its small size, it reduces the cognitive complexity of developers.

Disadvantages of microservice architecture:

A large number of active parts (services, databases, processes, containers, frameworks).

Complexity shifts from code to infrastructure.

The surge in RPC calls and network traffic.

Managing the security of the entire system is challenging.

It is difficult to design the whole system.

Introduces the complexity of distributed systems.

When to use the microservice architecture:

Web scale application development.

Enterprise application development is performed when multiple teams are working on the application.

Long-term gains take precedence over short-term gains.

The team has software architects or senior engineers who can design micro-service architectures.

Design pattern of micro-service architecture

Each microservice monopolizes the database

Once the company replaces large monolithic systems with many smaller microservices, the most important decision it faces is about databases. In the overall architecture, a large central database is used. Many architects like to leave the database as it is, even if they switch to a micro-service architecture. Although it provides some short-term benefits, it is an anti-pattern, especially in large-scale systems, because micro-services are tightly coupled in the database layer. The entire goal of moving to microservices will fail (for example, team authorization, independent development).

A better approach is to provide each microservice with its own data store so that there is no strong coupling between services in the database layer. Here, I use the word database to represent the logical separation of data, that is, microservices can share the same physical database, but they should use separate schemas / collections / tables. It will also ensure that microservices are properly isolated according to domain-driven design.

> Database per Microservice by Md Kamaruzzaman

Advantages:

Full ownership of the data to the service.

Loose coupling between teams that develop services.

Disadvantages:

Sharing data between services becomes challenging.

It becomes more difficult to provide application-wide ACID transaction guarantees.

Breaking down the Monolith database into smaller parts requires careful design, which is a daunting task.

When does each microservice use the database:

Application in large enterprises.

When the team needs full ownership of its micro services to expand and speed up development.

When not to use the database of each microservice:

In small applications.

If a team develops all the microservices.

Enable Technology example:

All SQL and NoSQL databases provide logical data separation (for example, separated tables, collections, schemas, databases).

Event source Event Sourcing

In a micro-service architecture, especially when each micro-service uses a database, micro-services need to exchange data. For resilient, highly scalable and fault-tolerant systems, they should communicate asynchronously by exchanging events. In this case, you may need to perform atomic operations, such as updating the database and sending messages. If you have a SQL database and want to allocate distributed transactions for large amounts of data, you cannot use two-phase locking (2PL) because it cannot be extended. If you use a NoSQL database and want to have distributed transactions, you cannot use 2PL because many NoSQL databases do not support two-phase locking.

In this case, use a combination of event-based architecture and event sources. In traditional databases, business entities with current "state" are stored directly. In the event source, any state change event or other important event is stored, not the entity. This means that changes to the business entity will be saved as a series of immutable events. By reprocessing all events of the business entity at a given time, the status of the business entity can be deducted. Because data is stored as a series of events rather than by updating the data store directly, various services can replay events from the event store to calculate the appropriate state of their respective data stores.

> Event Sourcing by Md Kamaruzzaman

Advantages:

Provides atomicity for highly scalable systems.

Automatic history of entities, including time travel functions.

Loosely coupled and event-driven microservices.

Disadvantages:

Reading entities from the event store becomes challenging, often requiring additional data stores (CQRS mode)

The overall complexity of the system increases, and domain-driven design is usually required.

The system needs to handle repetitive events (idempotents) or missing events.

Migrating event patterns becomes challenging.

When to use event sources:

A highly scalable transaction system with an SQL database.

Transaction system with NoSQL database.

Highly scalable and resilient micro-service architecture.

Typical message-driven or event-driven systems (e-commerce, reservation and reservation systems).

When not to use event sources:

Low scalability transaction system with SQL database.

In a simple microservice architecture, microservices can exchange data synchronously (for example, through API).

Enable Technology example:

Event storage: EventStoreDB,Apache Kafka,Confluent Cloud,AWS Kinesis,Azure event Center, GCP publish / subscribe, Azure Cosmos DB,MongoDB,Cassandra. Amazon DynamoDB

Frame: Lagom,Akka,Spring,akkatecture,Axon,Eventuate

Command query responsibility isolation (CQRS)

If we use event sources, it becomes challenging to read data from the event store. To get entities from the data store, we need to handle all entity events. In addition, sometimes we have different consistency and throughput requirements for read and write operations.

In this use case, we can use the CQRS pattern. In CQRS mode, the data modification part (command) of the system is separated from the data reading (query) part. The CQRS pattern comes in two forms: simple and advanced, which leads to some confusion among software engineers.

In a simple form, different entities or ORM models are used for reading and writing, as follows:

CQRS (simple) by Md Kamaruzzaman

It helps to implement the "single responsibility principle" and "separation of concerns", thus making the design more concise.

In its advanced form, different datastores are used for read and write operations. Advanced CQRS is used in conjunction with the event source. Different types of write data stores and read data stores are used, depending on usage. Writing to the datastore is the "recording system", the gold source of the entire system.

CQRS (advanced) by Md Kamaruzzaman

For reread applications or micro-service architectures, use the OLTP database (any SQL or NoSQL database that provides ACID transaction assurance) or a distributed messaging platform as write storage. For heavy writing programs (high write scalability and throughput), a horizontally writable scalable database (public cloud global database) is used. Normalized data is stored in the write data store.

A NoSQL database optimized for searching (for example, Apache Solr,Elasticsearch) or reading (key data store, document data store) is used as read storage. In many cases, scalable SQL databases are used where SQL queries are needed. Normalized and optimized data is saved in read storage.

Data is copied asynchronously from write storage to read storage. As a result, the read store lags behind the write store and eventually remains consistent.

Advantages:

Read data faster in event-driven microservices.

High availability of data.

The read-write system can be expanded independently.

Disadvantages:

Read data store weak consistency (final consistency)

The overall complexity of the system increases. Freight training CQRS may seriously endanger the entire project.

When to use CQRS:

In a highly scalable microservice architecture that uses event sources.

In a complex domain model where reading data requires querying to multiple datastores.

In systems where read and write operations have different loads.

When not to use CQRS:

In a micro-service architecture with a negligible number of micro-events, it is a better choice to use event storage snapshots to calculate entity state.

In systems where read and write operations have a similar load.

Enable Technology example:

Write storage: EventStoreDB,Apache Kafka,Confluent Cloud,AWS Kinesis,Azure Event Hub,GCP publish / subscribe, Azure Cosmos DB,MongoDB,Cassandra. Amazon DynamoDB

Read the store: Elastic Search,Solr,Cloud Spanner,Amazon Aurora,Azure Cosmos DB,Neo4j

Frame: Lagom,Akka,Spring,akkatecture,Axon,Eventuate

SAGA

If you use the micro-service architecture with the database of each micro-service, managing consistency through distributed transactions can be challenging. You cannot use the traditional two-phase commit protocol because it cannot be extended (SQL databases) or is not supported (many NoSQL databases).

You can use the Saga pattern for distributed transactions in Microservice Architecture. Saga is an old schema that was developed in 1987 as a conceptual alternative to long-running database transactions in SQL databases. However, modern variants of this pattern are also very effective for distributed transactions. The Saga pattern is a sequence of local transactions in which each transaction updates data in the data store and publishes events or messages in a single microservice. The first transaction in the legend is initiated by an external request (event or action). Once the local transaction is completed (the data is stored in the data store and the message or event is published), the published message / event triggers the next local transaction in the Saga.

> Saga by Md Kamaruzzaman

If the local transaction fails, Saga performs a series of compensating transactions to undo changes from the previous local transaction.

There are two main variants of Saga deal coordination:

Decentralized coordination in which each microservice generates and listens to events / messages from other microservices and decides whether action should be taken.

As a whole, the coordinator tells the coordinated micro-service which local transactions need to be performed.

Advantages:

Provide consistency through transactions in a highly scalable or loosely coupled, event-driven microservice architecture.

Consistency is provided by using transactions in a microservice architecture that does not have 2PC support for NoSQL databases.

Disadvantages:

Short-term failures need to be handled and idempotent should be provided.

It is difficult to debug, and as the number of microservices increases, so does the complexity.

When to use Saga:

In a highly scalable, loosely coupled microservice architecture that uses event sources.

In systems that use distributed NoSQL databases.

When not to use saga:

Low scalability transaction system with SQL database.

In systems where there are circular dependencies between services.

Enable Technology example:

Axon,Eventuate,Narayana

The back end of the front end (BFF)

In modern business application development, especially in micro-service architecture, front-end and back-end applications are separate and independent services. They are connected through API or GraphQL. If the application also has Mobile App clients, it becomes a problem to use the same back-end microservices for both Web and Mobile clients. API requirements for mobile clients are usually different from those for Web clients because they have different screen sizes, display, performance, energy, and network bandwidth.

The back-end pattern can be used in scenarios where each UI has a separate back-end customized for a particular UI. It also provides other advantages, such as acting as a facade for downstream micro-services, thereby reducing chat communication between UI and downstream micro-services. Similarly, in highly secure situations, downstream microservices are deployed in DMZ networks, and BFF is used to provide higher security.

> Backends for Frontends by Md Kamaruzzaman

Advantages:

Separation of concerns between BFF. We can optimize them for a specific UI.

Provide higher security.

Reduce communication between UI and downstream microservices.

Disadvantages:

Code duplication between BFF.

If you use many other UI (for example, smart TV, Web, mobile devices, desktops), the number of BFF will also surge.

BFF should not contain any business logic, but should contain only customer-specific logic and behavior, so it needs to be carefully designed and implemented.

When to use the back end for the front end:

If the application has multiple UI with different API requirements.

If an extra layer is needed between UI and downstream microservices for security reasons.

If you use a micro-front end in UI development.

When not to use the back end as the front end:

If the application has multiple UI, but they use the same API.

If the core microservice is not deployed in DMZ.

Enable Technology example:

Any back-end framework (Node.js,Spring,Django,Laravel,Flask,Play, etc.) supports it.

API Gateway

In a micro-service architecture, UI is usually connected to multiple micro-services. If microservices are FaaS, clients may need to connect to many microservices, which becomes tedious and challenging. Moreover, services, including their API, can evolve. Large enterprises also want to have other cross-cutting issues (SSL termination, authentication, authorization, restrictions, logging, etc.).

One possible way to solve these problems is to use an API gateway. The API gateway sits between the client APP and the back-end microservice and acts as a facade. It can be used as a reverse proxy to route client requests to the appropriate back-end microservice. It can also support extending the fan-out requested by the client to multiple microservices and then returning the summarized response to the client. It also supports basic cross-domain concerns.

> API Gateway by Md Kamaruzzaman

Advantages:

Provides loose coupling between front-end and back-end microservices.

Reduce the number of round-trip calls between the client and the microservice.

High security is achieved through SSL termination, authentication and authorization.

Centrally managed cross-domain issues, such as logging and monitoring, throttling, load balancing.

Disadvantages:

May cause a single point of failure in the microservice architecture.

The delay has increased due to additional network calls.

Without expansion, they can easily become a bottleneck for the entire enterprise.

Additional maintenance and development costs.

When to use an API gateway:

In a complex micro-service architecture, this is almost mandatory.

In large companies, API gateways must be used to centralize security and cross-domain issues.

When not to use API gateways:

In private projects or small companies where security and central management are not the highest priority.

If the number of microservices is very small.

Enable Technology example:

Amazon API Gateway,Azure API Management, Apigee,Kong,WSO2 API Manager

Strangler

If you want to use the micro-service architecture in the brownfield project, you need to migrate older or existing Monolithic applications to micro-services. Migrating existing large production monolithic applications to microservices is challenging because it can undermine the availability of the application.

One solution is to use the Strangler mode. The Strangler pattern means gradually migrating Monolithic applications to a micro-service architecture by gradually replacing specific functions with new micro-services. In addition, the new features are only added to microservices, bypassing traditional Monolithic applications. The Facade (API Gateway) is then configured to route requests between the older Monolith and the microservice. Once the functionality is migrated from the Monolith to the microservice, Facade intercepts the client request and routes to the new microservice. Once all the old Monolithic features have been migrated, the old Monolithic application will be "strangled", that is, retired.

> Strangler by Md Kamaruzzaman

Advantages:

Securely migrate Monolithic applications to microservices.

Migration and new feature development can be carried out in parallel.

The migration process can be at its own pace.

Disadvantages:

Sharing data storage between existing Monolith and new microservices becomes challenging.

Adding a facade (API gateway) will increase system latency.

End-to-end testing becomes difficult.

When to use Strangler:

Incrementally migrate large back-end monolithic applications to microservices.

When not to use Strangler:

If the overall backend components are small, batch replacement is a better choice.

If the client's request for an older Monolithic application cannot be intercepted.

Drive technology:

A back-end application framework with an API gateway.

Circuit breaker

In the micro-service architecture, micro-services communicate synchronously, and micro-services usually invoke other services to meet business requirements. Due to a transient failure (slow network connection, timeout, or unavailable time), a call to another service may fail. In this case, retry the call can resolve the problem. However, if there is a serious problem (the microservice fails completely), the microservice will be unavailable for a long time. In this case, there is no point in retrying and a waste of valuable resources (threads are blocked, wasting CPU cycles). Similarly, a failure of one service can lead to a cascading failure of the entire application. In this case, immediate failure is a better approach.

For such use cases, the circuit breaker mode can be used. A microservice should request another microservice through an agent that works like a circuit breaker. The agent should calculate the number of recent failures and use it to decide whether to allow the operation to continue or to return an exception directly.

> Circuit Breaker by Md Kamaruzzaman

Circuit breakers can have the following three states:

Closed: the circuit breaker sends the request to the microservice and calculates the number of failures in a given period of time. If the number of failures exceeds the threshold within a certain period of time, it will trip and enter the "open state".

Open: the request from the microservice immediately fails and an exception is returned. After the timeout, the circuit breaker enters the half-open state.

Semi-open: only a limited number of requests from the microservice are allowed to pass and invoke the operation. If these requests are successful, the circuit breaker will enter a closed state. If any request fails, the circuit breaker enters the "open" state.

Advantages:

Improve the fault tolerance and resilience of the micro-service architecture.

Stop cascading failures to other microservices.

Disadvantages:

Complex exception handling is required.

Recording and monitoring.

Manual reset should be supported.

When to use a circuit breaker:

In the tightly coupled micro-service architecture, micro-services communicate synchronously.

Whether a microservice depends on multiple other microservices.

When not to use circuit breakers:

Loosely coupled, event-driven micro-service architecture.

Whether microservices do not depend on other microservices.

Drive technology:

API gateway, service grid, various circuit breaker libraries (Hystrix,Reselience4J,Polly.

Externalized configuration

Each business application has many configuration parameters for various infrastructure (for example, database, network, connected service address, credentials, certificate path). Similarly, in an enterprise environment, applications are typically deployed in a variety of runtimes (local, development, production). One way to achieve this is through internal configuration, which is a fatal bad practice. Because it is easy to break production credentials, it can lead to serious security risks. In addition, any changes to the configuration parameters require the application to be rebuilt. This is particularly important in the microservices architecture because we may have hundreds of services.

A better approach is to externalize all configurations. As a result, the build process is separated from the runtime environment. In addition, security risks are minimized because production profiles are used only at run time or through environment variables.

Advantages:

Production configuration is not part of the code base, so security vulnerabilities can be minimized.

Configuration parameters can be changed without rebuilding.

Disadvantages:

We need to choose a framework that supports externalized configuration.

When to use externalized configuration:

Any important production application must use an external configuration.

When not to use externalized configuration:

Proof of the development of the concept.

Enabling technology: almost all modern enterprise-level frameworks support externalized configuration.

Consumer-driven contract testing

In the micro-service architecture, many micro-services are usually developed by independent teams. These microservices work together to meet business needs (for example, customer requests) and communicate with each other synchronously or asynchronously. Integration testing of consumer microservices is challenging. In general, faster and cheaper tests can be done with TestDouble in this case. But TestDouble usually does not represent a true provider micro-service. In addition, if the provider microservice changes its API or message, TestDouble cannot confirm this. Another option is to conduct end-to-end testing. Although end-to-end testing must be done before production, it is fragile, slow, expensive, and cannot replace integration testing (test pyramid).

Consumer-driven contract testing can help us in this regard. Here, the consumer microservice owner team writes a test suite that contains requests and expected responses for specific provider microservices (for synchronous communication) or expected messages (for asynchronous communication). These test suites are called explicit contracts. For the provider micro service, all contractual test suites of its users are added to the automated test. When performing automated tests for specific provider microservices, it runs its own tests, contracts, and validates contracts. In this way, contract testing can help maintain the integrity of microservice communications in an automated way.

Advantages:

If the provider accidentally changes the API or message, it will automatically find it in a very short time.

Fewer surprises and higher robustness, especially for enterprise applications that contain a large number of micro-services.

Improve team autonomy.

Disadvantages:

Because contract testing may use a completely different testing tool, additional work is required to develop and integrate contract testing in the contractor's micro service.

If the contract test does not match the actual service consumption, it may lead to production failure.

When to use consumer-driven contract testing:

In large enterprise business applications, usually, different teams develop different services.

When not to use consumer-led contract testing:

A team develops relatively simple, smaller applications for all microservices.

Whether the provider micro-service is relatively stable and not under active development.

Drive technology:

Contract, postman, Spring Cloud contract

At this point, the study on "what are the most important design patterns of micro-service architecture" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.