[Microservices] Understanding Microservices

Before we learn microservices, we need to understand the concepts of monomer, cluster, and distributed, which will help us learn the following courses more easily .

monomer

When the business volume of a system is small, all the codes should be placed in one project, and then the project should be deployed on one server. All services of the entire project are provided by this server. This is the stand-alone structure.

Monolithic application development is simple , and deployment and testing are simple . However, there are some problems , such as : single-point problems , and the processing capacity of a single machine is limited . When your business grows to a certain extent, the hardware resources of a single machine will not be able to Meet your business needs.

distributed

Since the entire system needs to use Tomcat and MySQL , the processing capacity of a single server is limited , and 2G of memory needs to be allocated to

Tomcat and MySQL are used. As the business becomes more and more complex, more and more requests are made . The memory becomes less and less enough, so we need distributed deployment at this time

We make a request for comments. This request can only be completed by relying on the components [Tomat and MySQL] distributed on two different servers . So it is called a distributed system .

cluster

In the above illustration, there are actually problems. For example, Tomcat has a single point of failure problem. Once the server where Tomcat is located is down and unavailable, we will not be able to provide services . Therefore, for the single point of failure problem, we Will use the cluster to solve . So what is the cluster mode ?

When the stand-alone processing reaches the bottleneck, you copy several copies of the stand-alone, thus forming a " cluster " . Each server in the cluster is called a " node " of the cluster , and all nodes form a cluster. Each node provides the same service, so the processing capacity is equivalent to being increased several times (having several nodes is equivalent to increasing so many times).

But the question is which node will handle the user's request? It is best to let the nodes with less load at this moment handle it, so that the pressure on each node is relatively average. To realize this function, it is necessary to add a " scheduler " role in front of all nodes. All user requests are handed over to it first, and then it decides which one to hand over the request to according to the current load conditions of all nodes. Node processing. This " scheduler " has a compelling name-load balancing server.

We only show the Tomcat cluster in the above figure. If the pressure on MySQL is relatively high, we can also cluster MySQL .

1.2 System Architecture Evolution

With the development of the Internet, the scale of website applications has also continued to expand, resulting in continuous changes in the system architecture.

From the early days of the Internet to the present, the system architecture has generally gone through the following processes : single application architecture ---> vertical application architecture ---> distribution

Architecture --->SOA Architecture ---> Microservice Architecture.

Next, let's take a look at what each system architecture looks like, and what are the advantages and disadvantages of each.

1.2.1 Monolithic application architecture

In the early days of the Internet, the traffic of general website applications was small, and only one application was needed to deploy all the functional codes together.

This can reduce development, deployment and maintenance costs.

For example, an e-commerce system will contain many modules such as user management, product management, order management, logistics management, etc. We will make them into a web project and deploy them to a tomcat server superior.

advantage:

The project structure is simple, and for small projects, the development cost is low

The project is deployed on one node, which is easy to maintain

shortcoming:

All functions are integrated in one project, which is not easy to develop and maintain for large projects

Tight coupling between project modules, low single-point fault tolerance

Unable to perform targeted optimization and horizontal expansion for different modules

1.2.2 Vertical Application Architecture

As the number of visits gradually increases, a single application can only rely on adding nodes to deal with it, but at this time it will be found that not all modules will have a relatively large number of visits . Let’s take the above e-commerce as an example, The increase in user visits may only affect the user and order modules, but the impact on the message module is relatively small . Then at this time we hope to only add a few more order modules without increasing the message module . At this time, the single The application is impossible , and the vertical application comes into being .

The so-called vertical application architecture is to split an original application into several independent applications to improve efficiency. For example, we can split the e-commerce single application above into :

E-commerce system ( user management product management order management )

Background system ( user management order management customer management )

CMS system ( advertising management marketing management )

After the split is completed, once the number of user visits increases, it is only necessary to increase the nodes of the e-commerce system without increasing the background

and CMS nodes.

advantage:

System splitting realizes traffic sharing, solves concurrency problems, and can be optimized and horizontally expanded for different modules

Problems in one system will not affect other systems, improving fault tolerance

shortcoming:

The systems are independent of each other and cannot call each other

The systems are independent of each other, and there will be repeated development tasks

1.2.3 Distributed architecture

When there are more and more vertical applications, there will be more and more duplicate business codes. At this time, we thought about whether it is possible to extract and make a unified business layer as an independent service, and then the front-end control layer calls different business layer services? This leads to new distributed system architectures. It will split the project into two parts, the presentation layer and the service layer, and the service layer contains business logic . The presentation layer only needs to process the interaction with the page, and the business logic is realized by calling the services of the service layer.

Advantages :

Extract common functions as service layer to improve code reusability

Disadvantages :

The degree of coupling between systems becomes high, the calling relationship is intricate and difficult to maintain

1.2.4 SOA architecture

Under the distributed architecture, when there are more and more services, problems such as capacity evaluation and waste of small service resources gradually appear. At this time, it is necessary to add a scheduling center to manage the cluster in real time. At this time, the resource scheduling and governance center (SOA Service Oriented Architecture , service-oriented architecture ) is the key.

Advantages :

Use the registration center to solve the automatic adjustment of the calling relationship between services

Disadvantages :

There will be dependencies between services. Once a certain link goes wrong, it will have a greater impact ( service avalanche )

The service relationship is complex, and O&M, testing and deployment are difficult

1.2.5 Microservice architecture

To some extent, the microservice architecture is the next step in the continued development of the service-oriented architecture SOA , which places more emphasis on the " complete splitting " of services .

Advantages :

Atomic splitting of services, independent packaging, deployment, and upgrades ensure clear task division of each microservice, facilitating expansion

Microservices use RESTful and other lightweight Http protocols to call each other

Disadvantages :

High technical cost of distributed system development (fault tolerance, distributed transactions, etc.)

1.3 Microservice Architecture Introduction

The microservice architecture, simply put, is to further split the monolithic application into smaller services, and each service is a project that can run independently.

Frequently Asked Questions about Microservice Architecture

Once the microservice system architecture is adopted, the following problems are bound to be encountered:

So many small services, how to manage them?

With so many small services, how do they communicate with each other?

With so many small services, how do clients access them?

With so many small services, once there is a problem, how should we deal with it?

With so many small services, once a problem occurs, how should we troubleshoot it ?

For the above problems, no microservice designer can bypass them, so most microservice products are aimed at each

Each problem provides corresponding components to solve them .

1.4 Introduction to Spring Cloud

Spring Cloud is a collection of frameworks. It uses the development convenience of Spring Boot to subtly simplify the development of distributed system infrastructure, such as service discovery registration, configuration center, message bus, load balancing, circuit breaker, data monitoring, etc., all of which can be developed with Spring Boot The style achieves one-click startup and deployment.

Spring Cloud does not repeat manufacturing wheels, it just combines the relatively mature and practical service frameworks through Spring Boot style to shield complex configuration And the principle of implementation, finally leaving a set of distributed system development toolkit that is easy to understand, easy to deploy and easy to maintain for developers.

1.4.1 What is the relationship between SpringBoot and SpringCloud ?

SpringBoot focuses on the rapid and convenient development of individual microservices.

SpringCloud is a microservice coordination and governance framework that focuses on the overall situation. It integrates and manages individual microservices developed by SpringBoot , and provides configuration management, service discovery, circuit breakers, routing, and event buses for each microservice. , Distributed transactions , etc. integration services.

Summary : SpringBoot focuses on the rapid and convenient development of individual microservices, while SpringCloud focuses on the collection of global service governance components

combine.

1.4.2 Spring Cloud version name ?

Because Spring Cloud is different from other independent projects, it is a large project with many sub-projects. So the version it is is the version name + version number (such as Greenwich.SR6 ).

Version name: is the name of the London Underground

Version number: SR ( Service Releases ) is fixed , which roughly means a stable version. It will be followed by an incrementing number.

So Greenwich.SR6 is the sixth Release version of Greenwich .

1.4.3 Why choose SpringCloud Alibaba ?

Why we choose SpringCloud Alibaba here is mainly because the components of SpringCloud Netflix : Eureka for service registration and discovery , Hystrix for service flow limit and downgrade , and gateway Zuul have all stopped updating. If there is a problem , the official does not maintain it and needs to solve it by itself .

1 Ease of use

2 Is the official still maintaining

3 Is the community active?