Reading notes of microservice architecture design pattern Chapter 1 escape from monomer hell




This is a book about microservice architecture design. This is my study note. First, some symbols are explained:

() for supplement, it is generally the content in the book;
[] is the author’s note;

1. The long journey to single hell

In the book, the author analyzes the advantages and disadvantages of individual applications with food to go (hereinafter referred to as ftgo).

1.1 ftgo application monomer architecture


1.2 benefits of single architecture

  • Simple application development;
  • Easy to make large-scale modifications to the application;
  • The test is relatively simple and intuitive;
  • Simple and clear deployment;
  • Horizontal expansion is effortless;

1.3 ftgo application unit


1.4 what is monomer hell

  • Excessive complexity can scare off developers;
  • Slow development speed;
  • The period from code submission to actual deployment is very long, which is prone to problems;
  • Difficult to expand;
  • Delivering reliable single application is a challenge;
  • Need to rely on a technology stack that may be outdated for a long time;

2. Why is this book about you

Who is suitable for reading: software developer, architect, CTO or vice president of engineering research and development; Or the responsible application is beyond the scope that the single architecture can support.

2.1 reading threshold

  • Three tier architecture;
  • Web application design;
  • Use object-oriented design to develop business logic;
  • Relational database: the concept of SQL and acid transactions;
  • Inter process communication using message broker and rest API;
  • Security, including authentication and access authorization;
  • Spring framework;

3. What will you learn from this book

The knowledge and technical points that can be understood and mastered after reading this book.

3.1 key knowledge

  • The basic characteristics of microservice architecture, its advantages and disadvantages, and when to use microservice architecture;
  • Architecture mode of distributed data management;
  • Effective testing strategies for microservice architecture applications;
  • Deployment mode of microservice architecture application;
  • The strategy of reconstructing a single application into a micro service architecture;

3.2 other technologies

  • Using the architecture pattern of microservices to design the architecture of applications;
  • Develop business logic for services;
  • Using saga to maintain data consistency between processes;
  • Realize cross service data query;
  • Test service architecture applications more efficiently;
  • Develop application programs ready for production environment to realize security, configurability and observability;
  • Reconstruct the existing single application into service;

4. The way to save: Micro service architecture

This paper mainly introduces some definitions and basic characteristics of human microservice architecture.

4.1 three dimensions of extension application (extension cube) [definition of microservice]


  • X-axis expansion: load balancing of requests among multiple instances, [simply Ctrl CV];
  • Z-axis extension: route the request according to the attribute of the request (when the application needs to handle the increased transaction and data volume), [traffic partition expansion];
  • Y-axis extension: split the application into services according to the function (also known as functional decomposition), [generally expand the Y axis first, and then expand the X and Z axes];

4.2 basic characteristics of microservices

  • Extended cube;
  • Modularity, [which means that developers cannot access internal components without bypassing the API of the service];
  • Each service has its own database;

4.3 micro service architecture of ftgo

Applying Y-axis decomposition to ftgo application will get the following figure:

It can be seen that the characteristics of the model are:

  • Each service API is clearly defined;
  • Each service can be developed, tested, deployed and expanded independently;
  • modularization;

4.4 similarities and differences between microservice architecture and SOA


  • Are specific style architecture;
  • All organize the system in a series of service ways;


  • Completely different technology stacks (micro service architecture adopts lightweight, open source technology and dumb pipeline communication);
  • Different data processing methods (micro service architecture has its own database);
  • Different service sizes and scales (the services in the microservice architecture are relatively small);

5. Advantages and disadvantages of microservice architecture

5.1 benefits of microservice architecture

  • Enable continuous delivery and deployment of large and complex applications, [support automated testing, independent deployment, independent and loosely coupled development teams];
  • Each service is relatively small and easy to maintain;
  • Services can be deployed independently;
  • Services can be expanded independently;
  • Microservice architecture can realize team autonomy;
  • Easier to experiment and adopt new technologies;
  • Better fault tolerance;

5.2 disadvantages of microservice architecture

  • Splitting and defining services is a challenge;
  • Distributed system brings all kinds of complexity, which makes it difficult to develop, test and deploy;
  • When deploying functions that span multiple services, more development teams need to be carefully coordinated;
  • Developers need to think about what stage of the application should use microservice architecture;

6. Schema language of microservice architecture

One way to express multiple architectural design options and improve decision-making is to use pattern language. The pattern of microservice architecture is not only the key and difficult point of microservice architecture design, but also the key and difficult point of subsequent chapters.

6.1 some concepts (pattern, pattern language, etc.)

  • pattern: Reusable solutions to problems occurring in a specific context;
  • Pattern language: a collection of relevant patterns for solving problems in a specific field;
  • Software mode: solve software architecture or design problems by defining a set of collaborative software elements;

6.2 the common pattern structure includes three important parts

  • Requirements (forces): problems that must be solved;
  • Result context: possible consequences after adopting the mode (including benefits, disadvantages and problems);
  • Related patterns: 5 different types of relationships (leading, following, substitution, generalization and specialization);


6.3 microservice architecture pattern language

The picture above showsFour mode groups

  • Application schema group: on the far left, it is divided into single architecture mode and micro service architecture mode;
  • Apply related mode group: solve the specific technical and architectural problems faced by developers;
  • Application infrastructure related pattern group: solve infrastructure related problems at the application level;
  • Infrastructure related model group: solve the problems related to infrastructure in the development process;

6.4 main modes of microservices [key points]

Service splitting related modes:

[Chapter 2 highlights] splitting the system is essentially an art, but there can be some strategies, as shown in the figure below:


Communication related modes:

[introduction to chapters 3 and 8] interprocess communication (IPC) is an important part of distributed system, which includes:

  • Communication style: what kind of interprocess communication mechanism is used;
  • Service discovery: how the client obtains the IP address of the specific service instance;
  • reliability: how to ensure reliable communication between services when services are unavailable;
  • Transactional messages: how to integrate actions such as message sending and event publishing with database transactions of updated business data;
  • External API: how the client of the application communicates with the service;

Data consistency related modes for transaction management:

[introduction to Chapter 4 ~ 6] saga mode is used to ensure data consistency, rather than two-step submission (2pc). The following figure shows data consistency related patterns:


Related modes of querying data in the microservice architecture:

[Chapter 7 introduction] you can use the API composition mode to call the service APIs one by one, and then aggregate all returns together, as shown in the following figure:


Service deployment related modes:

[Chapter 12 introduction] a highly automated deployment infrastructure and a deployment platform (UI, graphical interface, command line, etc.) are often required, as shown in the following figure:


Observability correlation mode:

[introduction in Chapter 11] it refers to clarifying some behaviors of the application during operation, and diagnosing and troubleshooting according to faults such as wrong request or high delay. The following patterns can be used to design observable services:

  • Health check API: API that can return service health status;
  • Log aggregation: write the logs generated by the service to a centralized log server, which can provide log search and trigger alarms according to log conditions;
  • Distributed tracking: assign a unique ID to each external request for tracking external requests among services;
  • Exception tracking: send program exceptions to the exception tracking service, which will eliminate duplicate exceptions, send alarms to developers and track the resolution of each exception;
  • Application index: indicators for maintenance, such as counters, are exported to the indicator server;
  • Audit log: record the user’s behavior;

Relevant modes to realize service automation test:

[Chapter 9 ~ 10 introduction] it is necessary to test whether different services work together. The following modes simplify testing through separate testing services:

  • Consumer driven contract testing: verify that the service meets the functions expected by the client;
  • Consumer contract test: verify that the client of the service can communicate with the service normally;
  • Service component testing: test the service in an isolated environment;

Relevant models for solving infrastructure and boundary problems:

[Chapter 11 introduction] each service must implement many infrastructure related functions. In addition, it must implement the external configuration mode. When developing new services, you can use the micro service base pattern to solve some infrastructure related problems.

Safety related modes:

[Chapter 11 introduction] the access token mode is commonly used in user authentication. The service after user information transmission can verify the token and obtain user information.

7. Above microservices: process and organization

Architecture is not the only area that needs attention. It is also necessary to think about processes and organizations.

7.1 relationship between structure, process and organization


8. Summary of this chapter

  • The single architecture mode builds the application into a single deployable unit;
  • The microservice architecture pattern decomposes the system into a group of independently deployable services, and each service has its own database;
  • Monomer architecture is a good choice for simple applications, and microservice architecture is usually a better choice for large and complex applications;
  • Microservice architecture enables small autonomous teams to work in parallel, so as to speed up software development;
  • Microservice architecture is not a silver bullet: it has many disadvantages, including complexity;
  • Microservice architecture pattern language is a set of patterns that can help you build applications using microservice architecture. It can help you decide whether to use microservice architecture. If you choose microservice architecture, pattern language can help you apply it effectively;
  • You need more than just a microservice architecture to accelerate software delivery. Successful software development also requires Devops and small and autonomous teams;
  • Don’t forget to adopt the human dimension of micro services. You need to consider the employee’s emotions in order to successfully transition to the micro service architecture.


Newcomer production, if there are mistakes, welcome to point out, thank you very much!Welcome to the official account and share some more everyday things.If you need to reprint, please mark the source!
Reading notes of microservice architecture design pattern Chapter 1 escape from monomer hell