Micro-service anti-patterns and traps microservices antipatterns and pitfalls reading notes

This is a creation in Article, where the information may have evolved or changed.

Catalogue [−]

2. Data-driven migration anti-pattern
   1. Too many data migrations
   2. function segmentation first, data migration last
4. Timeout anti-pattern
   1. Use timeout
   2. Using fuse design mode
6. Share anti-pattern
   1. Too much Reliance
   2. Techniques for sharing Code
8. Arrival report Anti-pattern
   1. Micro-Service Reporting issues
   2. Asynchronous Event pushing
10. Sand traps
    1. Scope and functionality of the analysis service
    2. Analyzing Database transactions
    3. Analytics Service Orchestration
12. No-cause developer traps
14. The trap of the crowd
16. Other schema modes
18. Static contract Traps
20. Are we here, trap?
22. Rest traps

A few days ago I wrote a book Note: "Eight principles of product-level microservices," introducing Uber's SRE engineer Susan J. Fowler's free book: MicroServices in Production, the only criterion for a microservices success is usability, It's very practical. But this book favors microservices from the perspective of SRE (Site reliability engineer), and for Development engineers (SWE, software engineer), the focus is on how to properly refactor from monolithic programs to microservices architectures. or design a micro-service architecture from scratch, this reading note is mainly about the practice and experience.

OReilly's free Little book, microservices Antipatterns and Pitfalls, was written by the experienced Mark Richards. In the book, the Anti-pattern (antipattern) is defined as "a practice pattern that looks good at first, to the last trouble," and the Trap (pitfall) is defined as "not a good design at first", which lists several common anti-patterns and pitfalls in microservices development, These experiences are very grounded in gas. He also provides video tutorials.

In 2006, when SOA (service-oriented architecture) became popular, countless companies embraced SOA with technological trends, regardless of whether they had fully understood the strengths and weaknesses of this complex architectural style, which inevitably plunged into and served the granularity, performance, In the struggle for data migration and the transformation of SOA organizations, many companies have had to abandon SOA, or compromise to create a mixed architectural style.

The tragedy of history will be repeated again. Micro-service is the industry's current development trend. Today, microservices are a technology boom, just like SOA in the middle of the 2000. Many companies are changing their approach to microservices architectures in order to gain the benefits of microservices architectures such as ease of testing, rapid, easy deployment, granular scalability, modularity and agility. However, like SOA, these enterprises are caught up in the struggle for service granularity, data migration, organizational change, and distributed processing when they develop micro-services.

As with many new technologies, the deeper you know, the architectural style, the anti-patterns, the pitfalls, and the many lessons that are learned throughout the process. As said above, the anti-pattern is like going to the right way, walking for a long time to find the road is wrong, and the trap is not long before you will find the road is wrong.

This book introduces several common anti-patterns and traps, but it is clear that it is not possible to introduce all the anti-patterns and pitfalls of microservices in such a thin book. These commonly used anti-patterns and traps include service granularity (sand traps), data migration (migration anti-pattern with a drive), Remote access latency ("We're There" traps), reporting (Arrival report anti-pattern), contract ve Rsioning (Static contract trap), service responsiveness (timeout anti-pattern), and so on.

Data-driven migration anti-pattern

Data-driven Migration Antipattern

MicroServices Create a large number of small, distributed, single-purpose services, each with its own data. This service and data coupling supports a bounded context and a schema without shared data, where each service and its corresponding data are separate pieces, completely independent of all other services. The service exposes only a clear interface (service contract). Bounded contexts can allow developers to develop, test, and deploy quickly and easily with minimal reliance.

Most of the data-driven migration anti-patterns are when you migrate from a single (monolithic) application to a microservices architecture. The reason we call it anti-pattern is that it seems to be a good idea to start creating microservices, and that the service and the corresponding data are independent into a microservices, very nice, but as the book goes on, this could lead you to the wrong path, with high risk, excess costs, and additional migration work.

The migration of monomer applications to the MicroServices architecture has two main goals: the first goal is to split the functionality of the monomer application into small, single-purpose services. The second goal is to migrate the data of a single application to each service's own exclusive small database (or standalone service).

As shown, the ideal is plump, but the reality is very bony.

Too many data migrations

The main problem with this migration is that it is difficult for you to split the granularity of the database at once into separate data for each microservices exclusive.

Of course you can split into coarse-grained data and services, and then further split into smaller microservices and data, you might want to make frequent service adjustments: granularity is too small, merging microservices, and granularity is too large to split into smaller microservices. Data migrations are more complex and error-prone than source code migrations, and are ideally migrated only once for microservices. Understanding the risk of data migration is the first step in avoiding this anti-pattern.

function segmentation first, data migration last

The main technique to avoid this anti-pattern is to first migrate the functionality and then consider the bounded context that divides the microservices and its data.

Timeout anti-pattern

MicroServices are a distributed architecture in which all components (that is, services) are deployed as separate applications and communicated through some kind of remote access protocol. One of the challenges of distributed applications is how to manage the availability of remote services and their responsiveness. While service availability and service response are all related to service communication, they are two completely different things. Service availability is the ability of the service consumer to connect to the service and to send requests, and the service response concerns the response time of the service.

If the service is unavailable, the service consumer will be notified in milliseconds, which can return an error message or attempt to connect. But what if the service receives the request but does not respond, what should the service consumer do? You can wait indefinitely or set a time-out.

Timeouts also look pretty good, but they can also cause anti-patterns.

Use timeout

You may be confused, shouldn't you set a time-out? You understand it right, but in most cases the error setting of the time-out will cause problems. For example, when you buy something, you submit an order, the service has been processed without a return, you submit the order at the time of the timeout, and obviously the server needs more complex logic to handle the problem of repeating the order.

So you may not want to set the time-out to be too short, but how much is appropriate? A database-based timeout to calculate the service timeout, another more common, calculate the maximum processing time under high pressure, multiply it by 2 as the time-out. But this value may be very inappropriate, it is possible for users to think that waiting too long to turn off the page, so still looking for a better way.

Using fuse design mode

Circuit Breaker Pattern

This design pattern is like the home appliance fuse, when the load is too large, or the circuit fails or abnormal, the current will rise, in order to prevent the rise of the current may damage some important parts of the circuit or valuable devices, burn the circuit and even cause a fire. Fuse will be in the abnormal rise of the current to a certain height and heat, the self-fusing cut off the current, thereby playing a protective circuit safe operation of the role.

When a software fuse detects that the service is unresponsive, it fuses and rejects the request. Once the service is restored, the fuse is connected and the service is allowed to pass.

Fuse has a variety of ways to monitor the availability of services, the simplest way is the heartbeat check, can also be used to call the virtual service accurate monitoring, but also real-time monitoring of the status of service calls, once the threshold is reached, the fuse enters the state of the current limit.

Share anti-pattern

I was taught to Share "Antipattern

MicroServices are a non-shared architecture, and I prefer to call it "try not to share" mode (share-as-little-as-possible) because there is always some code that is shared between microservices. For example, instead of providing an authentication micro-service, the authentication code is packaged as a jar file: security.jar All other services can be used. If the security check is a service-level feature, each service receives a request to check for security, which can improve performance well.

But this is prone to "nightmare-dependent":

Too much Reliance

If you are using an object-oriented development language, you will certainly encounter the following inheritance, and hundreds of modules will be dependent on a lot of shared libraries when they are split into microservices.

One of the goals of MicroServices is to share as little as possible, which helps the microservices determine its bounded context and make the service easier to test and deploy. The more dependencies between services, the more difficult it is to isolate the service.

Techniques for sharing Code

It's easier said than done, and introduces four scenarios where code sharing poses problems.

The first three ways to share code are well understood, and the fourth Way is to split the logic of shared code into a single service, such as an authentication service.

For shared libraries, do not put all the shared code in one library, for example, common.jar instead of dividing it into smaller libraries based on their logic, for example security.jar , persistence.jar dateutils.jar .

Arrival report Anti-pattern

Reach-in Reporting Antipattern

There are four ways to work with reports in the MicroServices architecture.

• Database Pull Model
• HTTP Pull Model
• Batch Pull Model
• event-based Push model

The first three models pull data from the MicroServices ' own database, so this anti-pattern is called "rearch-in reporting". Now that the first three kinds of anti-patterns appear, let's see why they cause trouble.

Micro-Service Reporting issues

There are two sides to the problem:

1. How to get the data of the report regularly?
2. Still have a bounded context for microservices and data?

Is the database pull model, which accesses databases directly, which leads to the non-independence of the database.

is the HTTP pull model, microservices provide a data reporting interface, but it can affect the performance of microservices, especially complex report queries.

Is the batch pull model, which batches the data of the microservices into the reporting database, but as with the HTTP pull model, this results in a non-independent database, and changes in the MicroServices database format can also affect Reporting Services.

Asynchronous Event pushing

is event-based push model, also called data pump. Although relatively complex, it does not violate the two issues raised in this section.

Sand traps

Grains of Sand Pitfall

One of the biggest challenges for architects and developers in adopting microservices architectures is the problem of service granularity. How good is the granularity of microservices services? Service granularity is critical, impacting application performance, robustness, reliability, testability, and setting up the release model.

When the granularity of service is too small, you will encounter sand traps. Micro-service micro does not mean that the smaller the service, the better, but how small is small?

If you look at the projects implemented by MicroServices, you will find many microservices implemented by a class, in which case it is easy to encounter a sand trap.

Of course, the granularity of microservices is not determined by the number of classes that the service implements, some services are simple, only one simple class can be implemented, and some require more classes. Since the number of classes cannot be used to determine the granularity of microservices, what is the appropriate standard to measure the granularity of a micro-service? Main dependencies: Scope of service and functionality (functionality), requirements for database transactions, and level of service orchestration.

Scope and functionality of the analysis service

What does the service do? What's the operation?

Integrity (Cohesion) plays a very important role. A customer service, for example, has the following actions:

• Add_customer
• Update_customer
• Get_customer
• Notify_customer
• Record_customer_comments
• Get_customer_comments

The first three operations are relevant and they are used to manage and maintain customer information. However, the latter three are not related to basic crud operations. In analyzing the integrity of this service, we are more clear that the service can be divided into three services: Customer Information Services, customer Notification Services and customer review services.

Sam Newman provides a good, actionable way to start dividing services into coarse-grained services that are further subdivided into smaller-grained services as you learn more about services.

Analyzing Database transactions

Database transactions are more formally called ACID transactions (atomicity, consistency, isolation, and durability). The acid transaction encapsulates multiple databases to be updated to a single unit of work, or the unit of work is either completed or rolled back in case of an error.

Because services in a microservices architecture are distributed and stand-alone applications, it is extremely difficult to maintain ACID transactions between two or more services, so the microservices architecture often relies on BASE (Basic availability, soft state, and Eventual consistency). However, you still need to use ACID transactions in a specific service. When you need to make tough decisions in ACID vs. BASE transactions, your service may be broken down too thin.

When you find that you cannot use final consistency, you typically adjust the service from fine-grained to coarse-grained services.

Analytics Service Orchestration

A third measure is the analysis of service orchestration. Service orchestration refers to the communication between services, usually also refers to internal service communication.
It takes time to remotely invoke the service, which reduces the overall performance of the application. Moreover, it can also affect the robustness and reliability of the service.

If you find that you need to invoke too many services to complete a logical request, the partitioning of the service may be too small.

Consolidating services, merging to coarser granularity can improve the overall performance of your application, and improve the robustness and reliability of your application. You can also remove dependencies between services for better control, testing, and publishing.

Of course, you might say that invoking multiple services can be performed in parallel, referring to the application's response, such as the asynchronous programming of the reactive architecture, the key or the pros and cons, ensuring a timely response to the user and the overall reliability of the system.

No-cause developer traps

Developer without a cause pitfall

The name comes from James Dean's film "The Rebellion of No cause" (Rebel without a cause), a problem youth who made the wrong decision for the wrong reasons.

Many architects and developers weigh in on the development of microservices, such as service granularity and operations tools, but make wrong decisions based on the wrong reasons.

is a scene. Services are thought to be too granular to affect performance and reliability, so migrate to a single, coarser-grained service.

seemed reasonable, but did not consider tradeoff. Release, change control, testing are deeply affected.

In contrast, coarse-grained services are divided into fine-grained services.

If you don't consider the tradeoff that this change brings, it can be a big impact.

The authors point out a deep understanding of the business drivers behind the selection of microservices.

The trap of the crowd

Jump on the bandwagon pitfall

Because microservices are the current trend, so you choose MicroServices, not carefully analyze your business needs, business drivers, organizational structure and technical environment, this is the trap of the crowd.

MicroServices are not suitable for all scenarios.

Avoid this trap in a way that fully understands the benefits and weaknesses of microservices, as the saying goes, Baizhanbudai.

Benefits:

• Release: Easy to publish
• Testing: Easy to test
• Change control: More easily change the functionality of a service
• Module
• Scale Scalable

Weaknesses

• Team organization Change
• Performance
• Reduced reliability
• Operational difficulty increased

So understand the advantages and disadvantages of micro-services, combined with their own actual situation, to decide whether to use micro-services.

Other schema modes

MicroServices have a good architecture, but not the only architectural pattern, such as some other architectural patterns:

• Service-based Architecture
• Service-oriented Architecture
• Layered Architecture
• Microkernel Architecture
• Space-based Architecture
• Event-driven Architecture
• Pipeline Architecture

Of course you don't have to use only one architectural pattern, you might mix these schema patterns in your system.

Here are some references to the architecture:

• Software Architecture fundamentals:understanding the Basics
• Software Architecture Fundamentals:beyond the Basics
• Software Architecture fundamentals:service-based Architecture
• Software Architecture Patterns
• MicroServices vs. Service-oriented Architecture

Static contract Traps

The Static contract Pitfall

This section focuses on version control of the service. In the first place, the service did not consider version control, when the schema of the service changed, or when the internal implementation logic changed, the communication and business processing between the consumer and the server would be problematic.

So you have to design the version number for your service.

There are two implementations, adding a version number to the header, or adding a version number to the schema of the service.

Are we here, trap?

is We there yet pitfall

This trap occurs when you do not know how long the remote call will take. 50 seconds? How long is the average, long tail delay?

First you should measure the invocation time of the service and at least know the approximate time at which a service is called remotely.

You should then evaluate the performance of different service communication protocols, such as rest, JMS, AMQP, and so on.

Of course, performance is not the only factor that measures the remote communication protocol, as described in the following section.

Rest traps

Using restful style is very popular, most software frameworks also choose it as a means of communication, such as Dropwizard, Spring boot, etc., interested readers can read my written Java RESTful framework performance comparison.

Since everyone is using it, how can it be a trap?

If you use rest as the only means of communication, it is possible to fall into this trap. For example, how to handle asynchronous communication (HTTP 1.1 is blocking), how to manage multiple service invocations in one transaction? How do I support broadcasting?

You should consider two types of messaging standards as messaging in a microservices architecture: a standard and platform-agnostic standard for a particular platform.

Platform-specific standards such as JMS for Java, MSMQ for. Net. Platform-independent, such as AMQP.

The benefits of using the messaging system can be requested asynchronously, the broadcast can also be implemented, and transaction requests can be implemented.

The author is one of the authors of the second edition of the Java message Service, and therefore has its own insight into the messaging system.