This article takes you to understand the microservice architecture and design (multiple pictures)

In recent years, microservices have been very popular. Everyone is building microservices. If you don’t understand a little bit of microservice-related technologies, you are embarrassed to say hello to your peers. I have seen many people around me stepped on a lot of pits in microservices. I started to contact microservices in the year. I have experience in the architecture of microservice distributed systems of many large enterprises, so I plan to share with you a period of microservices. However, microservices and the distributed computing involved are very complicated. It can be explained clearly in one article. This article only introduces you to the basic use of the simplest concepts. If you are interested in the follow-up, you can consult related literature and technical books to learn more.

The microservices in this article share the following three parts, and the overall outline is as follows:

• Concepts and principles of microservices (theory)
• How Spring Cloud implements microservices at low cost (implementation)
• Architecture scheme of Spring Cloud large-scale project (real case)

Concepts and principles of microservices

What is a microservice?

A simple example: students who read military news should know that although an aircraft carrier has a strong combat capability, its weaknesses are too obvious, that is, its defensive capabilities are too poor. A single aircraft carrier rarely acts alone. Usually the aircraft carrier battle group is the main military force. , You can understand a single aircraft carrier as a single application (poor defense, poor maneuverability), and an aircraft carrier battle group (complex scheduling and high maintenance cost) as a microservice.

Simply speaking, the characteristics are:

• Monolithic application: simple, fragile (a certain module has a problem, the entire system is unavailable), weak combat effectiveness, low maintenance cost
• Microservice architecture: complex and robust (a problem with a certain module will not affect the overall availability of the system), strong combat effectiveness, and high maintenance costs

 

Most developers have experienced and developed monolithic applications. Whether it is traditional SSM or current SpringBoot/Rails, they are monolithic applications. So what are the disadvantages of monolithic applications that have accompanied us for a long time? What problems are we facing that leads us to abandon monolithic applications and switch to microservice architecture? Personal summary of the main issues are as follows:

• High deployment cost (whether it is to modify 1 line of code or 10 lines of code, all must be deployed and replaced)
• Changes have a large impact, high risks, and high testing costs (no matter how small the code changes, the cost is the same)
• Because of the high cost and high risk, the deployment frequency is low (cannot meet the needs of fast delivery customers)

Of course, there are problems such as inability to meet rapid expansion, elastic expansion, and inability to adapt to the characteristics of the cloud environment.

But we will not go into details one by one. The above problems are all problems to be solved by the microservice architecture. As for how to solve the specific problems, let's talk about it later.

Changes in the architecture of historical applications (Figure)

What problem was solved and what problem was introduced?

Let's first look at what microservices can bring us? Features of microservice architecture:

• Release for specific services, with low impact, low risk and low cost
• Frequent release of versions, fast delivery of requirements
• Low-cost expansion, elastic expansion, adapt to the cloud environment

We know a simple concept. Nothing is perfect. Everything has two sides. There are gains and losses.

So while choosing a microservice to solve the problem of rapid response and elastic scaling, what problems does it bring to us? Personal summary is as follows:

• Complexity of distributed systems
• Cost of deployment, testing and monitoring
• Distributed transactions and CAP related issues

The system application has changed from a single unit to dozens to hundreds of different projects. For example, problems such as dependencies between services, how to unpack services, internal interface specifications, data transmission, etc. will arise, especially service splitting. The team is familiar with business processes and knows how to make choices. It is necessary to ensure that the split granular service not only conforms to the basic principle of "high cohesion, low coupling", but also takes into account the development of the business and the company's vision, and it must persuade team members to work hard. And actively invest to strike a balance among multiple parties.

For distributed systems, deployment, testing, and monitoring all require a large amount of middleware to support, and the middleware itself also needs to be maintained. The original simple transaction problem of a single application becomes very complicated when it is transferred to a distributed environment. Whether the transaction uses a simple retry + compensation mechanism or a strong consistency method such as the two-phase commit protocol depends on familiarity with the business scenario plus repeated trade-offs. The same problem also includes the trade-off of the CAP model. In short, microservices have higher overall requirements for the overall technical stack level of the team

What principles should microservices follow?

The ancients said: Before the soldiers and horses move, the food and grass go first. Building microservices requires establishing a long-term plan. It is not like building a database table like writing a CMS and then starting to work. This way, it will fail in all likelihood. Before we carry out the transformation of microservices, the architects must plan ahead. We divide this into three steps, the pre-stage, the design stage, and the technical stage.

In the early stage, roughly do the following things:

• Fully communicate with multiple parties to ensure that it meets the needs of customers and organizations and is recognized
• Communicate with the team so that teammates (development/testing/operation and maintenance) understand and actively invest
• Communicate with the business department, specify the version plan and launch time

In the design phase, referring to Sam Newman's "Microservice Design" , a single microservice must meet the following conditions to meet the basic requirements of microservices:

• Standard REST style interface (based on HTTP and JSON format)
• Independent deployment, avoid sharing the database (avoid affecting the entire distributed system because of the database)
• High business cohesion, reduce dependence (design to avoid too large or too small services)

A huge distributed system needs a strong infrastructure to support it. What infrastructure is involved in microservices?

• CI/CD and automation (distributed systems are almost impossible to release manually)
• Virtualization technology (to ensure the isolation of the microservice operating environment, the current industry mainstream is to use Docker containers)
• Log aggregation, full link monitoring (highly observable, analyze and diagnose problems)

Having said so much, under what circumstances is your team not suitable for building microservices? (Please do not check in)

1. The development team does not have autonomy, and the organization has a lot of restrictions on the development team (for details, please refer to  Conway's Law )
2. The team is not familiar with the business, cannot identify the boundary of the service, and make a reasonable split (please refer to DDD  domain-driven design )

Microservice design is actually a very early design idea, because with the rise of virtualization technology, microservices can be realized at low cost, so it has also become popular and rising.

The connotation of microservices is very deep, including automation, decentralization, independence, etc. The details cannot be summarized clearly in an article. When we are making technology selection or solutions, we should learn as much as possible about the technology. Combine the characteristics of our business with itself and origin to make better choices.

How to implement microservices at low cost?

Why is Spring Cloud the most popular microservice framework in China, and what components does it provide out of the box? The overview is as follows:

• Srping Boot service application
• Spring Cloud Config Configuration Center
• Spring Cloud Eureka service discovery
• Spring Cloud Hystrix fuse protection
• Spring Cloud Zuul Service Gateway
• Spring Cloud OAuth 2 service protection
• Spring Cloud Stream message driver
• Distributed full link tracking
• Deploy microservices

Suggested reference materials: microservice architecture integration, cloud computing best practices

The cornerstone of Spring Boot microservices

SpringBoot is an ideal framework for building microservices. It is mainly due to the fact that SpringBoot can be packaged into a single executable JAR file to deliver services. Spring Actuator's public service health information is the cornerstone of microservices. Why do you say that?

Let's first look at the 4 important principles for building microservices

• Services should be independent and independently deployable
• The configuration should be read from the central (configuration center)
• Transparent to the client
• Convey health information

Microservices have advantages and disadvantages. Not all applications are suitable for microservice architecture. Architects need to be able to meet the following requirements:

• Break down business problems: describe business problems, pay attention to verbs, and look for data cohesion
• Establish service granularity: restructure large services into smaller services, focusing on how services interact with each other, and service responsibilities change over time
• Define service interface: Embrace the concept of REST, use URI to convey intent, and use HTTP status code to convey results

What are the characteristics of bad microservices?

• Too coarse-grained: the service takes on too many responsibilities, the service manages data across a large number of tables, and there are too many test cases
• Too fine-grained: services are heavily dependent on each other, and there is no logic inside the service

When should you not use microservices?

• Unwilling to invest (requires highly mature operation and maintenance, scalability, and complexity issues)
• Management/monitoring of scattered servers also requires high costs
• Not suitable for small applications, too expensive
• Data transaction (distributed system processing transaction is very difficult)

Spring Cloud Config configuration service

Spring Config is a lightweight implementation of the configuration center provided by Spring, based on Git storage,

Most domestic users recommend using Alibaba's open source  Nacos  (integrated configuration center and registration center), which is a very good implementation of the configuration center

Several management principles of the microservice program for the configuration center:

• The actual code separation of application configuration and deployment (separation of configuration center and application)
• Centralized (centralize the configuration center in a small number of repositories)
• Stable (the configuration center must ensure high availability)

The core functions provided by the Spring Config configuration center:

• Configure the server to allow environment specific values
• Use Spring Profile to distinguish environmental values
• You can use file-based or Git-based storage properties
• Allow symmetric encryption and asymmetric encryption

Spring Cloud Eureka service discovery

Service discovery is a very important concept in the microservice architecture. It is also called the registration center . It is similar to the role of real estate intermediaries in our lives. Buying and selling houses must pass through it , so it is the only way for all microservices to go online/offline. To master the power of life and death of microservices, the registry will perform operations such as excluding, offline, and reinstatement of specific services based on the CAP strategy and the health check of microservices. The main functions include the following core functions:

• Quickly scale the number of services in the environment (functions and k8s overlap, but you can also set the number of runtimes for specific services)
• Abstract the physical location of the service (microservices usually run in Docker containers, there is no fixed IP, it can only be found through the registry)
• Improve program flexibility and auto-scaling
• Information sharing, health check

What are the basic requirements to achieve a registry in the microservice architecture?

• High availability, registration information sharing (registry center cluster deployment), it is impossible to cause all clusters to be unavailable because the registry is down
• Load balancing (load balancing of dynamic requests between services), reasonable distribution of traffic between services
• Resilient (client caching service information)
• Fault tolerance, health check (detected broken services are automatically removed without manual intervention)

What are the characteristics of the service discovery implementation provided by Spring Eureka?

• The physical location of the service discovery abstract service
• Add and remove services without perception
• Provide load balancing for calls between services
• Use 3 different mechanisms to call services: DiscoveryClient, RestTemplate that supports Ribbon, FeignClient of Netflix

Spring Cloud Hystrix fuse protection

The concept of fuse is very easy to understand. For example, when the power consumption load in our home is too high and reaches the set threshold, the circuit system will start the fuse mechanism, also called overload protection, to protect it by tripping and forcibly cutting off the power. The stability of the overall circuit is the same as the concept of fuse in microservices. It is to protect the firewall that is the stability of microservices, and to avoid the collapse of a single service or abnormalities that cause avalanches and chain reactions of the entire cluster system.

Why are microservices fusing? When a service has a problem:

• Usually start from a small part, until the exhaustion thread completely crashes
• Calls between services will block for a long time
• The service will always be called if it is not closed, leading to a chain effect
• A poorly performing service can quickly bring down the entire application

Why is fusing important?

• Each node (calling service and database) implements a circuit breaker, which can avoid the chain effect of service crash
• Realize that only the service that has problems is affected, and the rest of the service functions are complete (the scope of impact is minimized)
• Fuse is the flexible foundation of the server

Key capabilities provided by circuit breakers

• Fail fast
• Functional degradation (alternative plan)
• Seamless recovery (regular inspection of circuit breakers, automatic recovery of service)

The Hystrix implementation developed and produced by Netflix is ​​a mature and stable fuse implementation. It has been in production practice and operation at Netflix for many years and is very reliable. Later, it joined the Spring Cloud system and became a member of the Spring Cloud microservice ecological chain. It is also very easy to use. Simple and convenient

Hystrix supports 4 break modes:

• Client load balancing mode (detect service error, remove service)
• Circuit breaker mode (when a timeout occurs, an exception is thrown to force a failure, and all calls are forced to fail if the threshold is exceeded)
• Back-up mode (not throw an exception but perform alternatives, such as queuing, try again later, etc.)
• Bulkhead mode (allocate resources for remote calls to an independent thread pool, the only problem with the call is that the thread pool is saturated and the request is stopped)

Three kinds of results can be caused by a trip:

• Service B immediately knows that there is a problem with service C, without waiting, it fails immediately
• Service B executes the alternative code of service C to take action (backup mode)
• After service C can be tripped again, check the problem and recover quickly

Several treatment principles of fusing:

• Designing distributed applications must consider flexibility
• Complete failure of the service is easy to detect and deal with, but it takes time, and the circuit breaker gives this time window
• Poor performance of a service may cause the cluster to crash, because mutual calls will block threads and exhaust resources
• Hystrix supports two isolation models, namely THREAD and SEMAPHORE

Spring Cloud Zuul Gateway

The gateway is the entrance to the entire microservices distributed cluster. For users, users do not need to know the address of each of your services, but only need to remember the gateway address. This understanding may be more abstract. Take a life example, microservices The cluster is a large company. There are many different functional departments (corresponding to each microservice) within the company, but if you want to access a specific functional department, you must first register at the front desk, and then the front desk will take you to the one you want to visit Specific functional departments handle actual business (intelligent routing)

Microservices implementation specifications for gateways:

• A service independently responsible for all service call filtering and routing
• The middleman between service and client, simplifying client development

What does the gateway usually do:

• Static routing to obtain the specific location of each microservice from the registry
• Dynamic routing (according to the characteristics of parameters, call specific services, a small number of users experience new functions, usually used for gray release)
• Verification and authorization: verify the identity of the visitor (unified verification, the service only needs to focus on business logic)
• Data collection and logs (collection calls and response time, etc.)

The specific operation reference diagram of Zuul gateway:

Spring Cloud Zuul is an early version of the API gateway implementation, providing the following functions:

• Combine with Spring Cloud Eureka to add the registered address of service discovery to Zuul routing
• Zuul can easily add prefix routing addresses such as /api to all services
• Customize the timeout of Zuul's Spring Cloud Hystrix and Spring Cloud Ribbon (scheduling strategy) globally
• Realize dynamic routing, A/B test for different versions
• Check the validity of parameters, such as JWT, timestamp, etc.

Spring Cloud OAuth 2 service protection

Oauth 2 is used to ensure the legitimacy and correctness of the request. In order to make the microservice itself more focused on the business , the OAuth 2 similar configuration center is separately extracted and used as the unified authentication center of the basic component. The role of OAuth 2 is similar to ours The role of the Public Security Bureau in life . When we need to go to a formal organization to handle business, we need to provide a valid ID card (legal identification mark). If you don’t have one, you need to go to the Public Security Bureau (OAuth) to apply for one. The ID card (Token) inside, and then with this ID card we can go to buy air tickets, hotels and other social services (microservices), social service agencies will also give you the ID card (Token) you provide The Public Security Bureau (OAuth) sends information online to verify the legitimacy of your ID card (Token legitimacy verification). If the identity verification fails, the service will be denied. Only legitimate identities can handle business. About the OAuth workflow , Can be understood with the following figure:

Microservices authorize the four types of OAuth2 specifications: password/client credentials/authorization code/implicit

What convenience does Spring Cloud OAuth 2 provide us?

• Security framework, providing logic such as token generation and verification
• Out of the box, seamless integration with other services
• Industry standards, easy integration with cloud service providers

OAuth 2: /auth/oauth/token return information

• access_token (OAuth2 token, presented for each call)
• token_type (token type, commonly used bearer token)
• refresh_token (renewal token)
• expires_in (expiration description, default 12H)
• scope (token valid scope)

OAuth 2 supports the specification of JWT (JSON Web Token). The principle of JWT is not explained in particular. Simple JWT has the following characteristics

• Small (Base64 encoding)
• Password signature (tamper proof)
• Self-contained (no need to call the verification service to confirm the content, symmetric decryption through the same key)
• Scalable (additional information can be included in the token)

A brief summary of OAuth 2:

• OAuth2 is a token verification framework
• To use OAuth2, OAuth2 authentication service needs to be established
• All calls to protected resources must pass OAuth2 verification

Spring Cloud Stream message driver

Our interaction with the world is not synchronous. In many cases, it is based on the asynchronous message-driven model, such as mail, ordering, ticket booking, etc. To understand Spring Cloud Stream, you must first understand the event-based (MQ) programming model, based on Message-driven is conducive to the development and construction of highly decoupled systems, because Spring Cloud Stream does not implement message middleware by itself, but does a layer of encapsulation and abstraction for the mainstream MQ products on the market (such as RabbitMQ, KafKa), Spring Cloud What Stream does is nothing new, very similar to what ORM does. Students who understand the ORM framework should be familiar with how important abstraction is for multiple database products (MySQL, Oracle, SQL Server), and database-oriented ORM Access allows you to get rid of the deep dependence and binding of specific database products, and you don’t have to learn the localization features and dialects of different databases, reducing the cost of learning. If you want to migrate from Oracle to MySQL, it is almost unnecessary To change a line of code, you only need to change the ORM configuration to achieve it. Refer to the following figure to briefly understand the ORM:

Spring Cloud Stream is similar to ORM. You only need to program based on the message model provided by Spring Cloud Stream. It does not matter whether the underlying message component uses RabbitMQ, kafka, or other message middleware products. It does not even matter if the underlying message component is replaced. It will have any impact on your application. This is the benefit of standardization. For a better understanding of the Spring Cloud Stream working model, you can simply refer to the following figure:

Comparison of two service communication methods used in microservices:

1. Synchronization: request through REST endpoint interface: tight coupling between services (strong dependence), fragility between services (chain effect), and inflexibility in adding new consumers

2. Asynchronous: Message-based middleware communication: loose coupling (reliance on direct calls without interfaces), durability (historical messages can be consumed after the service restarts), scalability (too many messages can start multiple services to process messages), flexibility ( Easily add new consumers)

Disadvantages of messaging architecture:

1. Message processing semantics: message sequence processing, message exception processing
2. Message visibility: the message will not be processed immediately, the transaction correlation ID is transmitted in the message

What data is placed in the message?

1. The message body should be as small as possible to reduce transmission costs: usually only the action type and id are returned, and then the id is used to obtain the latest data
2. Only use message delivery status: include the version number and time stamp in the message, and the data processing service can check the version number of the data

The message model and concepts of Spring Cloud Stream:

• Transmitter (Source): Receive the object (the object represents the message to be published), serialize the object, and publish the message to the channel
• Channel: The abstraction of the queue, the channel is written in the configuration file, and the configuration is changed to switch the channel (read and write queue)
• Binder: Spring code that talks to the messaging platform, without relying on specific APIs to publish and consume messages
• Sink: Receive messages from the queue and deserialize the messages into POJO

A brief summary of Spring Cloud Stream:

• Asynchronous communication using message passing is a key part of the microservice architecture
• Using messaging can make services scalable and more fault-tolerant
• Spring Cloud Stream abstracts the details of the underlying messaging platform through simple annotations

Sleuth and Zipkin distributed tracking

The distributed architecture of microservices brings complexity. The highest cost is tracking inspection and operation and maintenance. Distributed means tracking a transaction in multiple services and machines. Both Sleuth and Zipkin are used for distributed tracking of the Spring Cloud service system. Technology, let’s look at the final result directly. The following figure is a simple visual link tracking call. ZipKin can clearly see the consumption of a client request to process each service. Click to see the specific transaction execution Content for easy troubleshooting

The workflow of Spring Cloud Sleuth:

1. Transparently create and inject an associated ID into the service call
2. Manage the propagation of the associated ID to outbound service calls
3. Add associated information to Spring's MDC log records (application/tracking ID/span ID/data sending)
4. Publish the tracking information in the service call to the Zipkin tracking platform

A brief overview of Open Zipkin:

1. The call chain uses a clean and concise picture, which is much better than a million logs
2. Distributed tracking platform, used to track transactions of multiple service calls
3. Graphically view the amount of time spent by transactions and break down the time spent by each service
4. 4 different data storage: memory data/MySQL/Cassandra/Elasticsearch

Summary of full link tracking of microservices:

• SpringCloudSleuth can seamlessly add associated IDs to microservices
• You can use the associated ID to view all service behaviors involved in the transaction
• Correlation ID needs to be used in conjunction with log aggregation
• Logging platform is very important, but visually tracking transactions is also a valuable tool

Deploy microservices

The construction and deployment pipeline is the most important part of the microservice architecture. The main feature of the microservice is rapid construction, modification, and release

The deployment that meets the characteristics of microservices must meet the following requirements:

1. Automatic (automatically build and deploy code
2. Complete (the finished software is a mirror image), immutable (no human intervention in the release process)
3. A good microservice deployment pipeline should allow the deployment of new features and bug fixes in a few minutes

Architecture scheme of Spring Cloud large-scale project

Real case explanation

This is a micro-service architecture system that is actually used by a large domestic enterprise to support a project with an average of one million orders per day. Since the two-year confidentiality period has passed, it can be shared

Just to combine the previous messy knowledge points to see how Spring Cloud is built. The whole set of microservices is the following architecture diagram:

The specific role of each component is not explained in detail here, in this set of architecture solutions

We did not completely copy the formation of the Spring Cloud family bucket, but replaced the components according to our own needs. For example:

• The configuration center is changed from Spring Cloud Config to Apollo. In addition to better performance, there is also a more simplified operation page and millisecond response to modification of configuration files
• The service found that Eureka's official website has ceased maintenance. We later replaced it with Alibaba Nacos. Service registration and heartbeat detection have been upgraded to milliseconds. Eureka uses 90-second polling.
• Distributed task scheduling introduces XXL-JOB, which is the mainstream distributed task scheduling platform in China, and there is no special need to explain it.
• Log aggregation also uses the mainstream ELK technology solution to collect and retrieve logs

PS: In addition, it is worth adding that at the time of writing this article, Spring Cloud Zuul has not been officially recommended for use. The alternative is Spring Cloud Gateway  with better performance  . You can pay attention to it when you understand

Final summary:

Microservices are the only way for large-scale enterprises in the future. Although the cost is high, it can improve the robustness of IT systems and increase the breadth and depth of technical personnel.