The above are the masters of Spring-Cloud's microservice architecture and the best business practices of cloud computing.
There is a male hormonal impulse to come into contact with spring-cloud, and I especially want to conquer it. I think she likes me. It reminds me of Xin Qiji's poem: I see the green hills are more charming, and the green hills see me should be like this.
Now that the two love each other, let us have a deeper understanding, how to go deep here... (what do you want), then teach you a PUA-style tutorial, let’s
stop here, if you are particularly interested in the above, you can feel free Exchange, return to the topic.
1. The past and present of Spring-Cloud
1. First of all, do we want to go to Spring-Cloud?
这篇文章针对没有接触过spring-cloud，或者有经验的可以更加巩固一下，Spring Cloud 是一系列框架的有
序集合，它利用 Spring Boot 的开发便利性简化了分布式系统的开发，比如服务发现、服务网关、服务路
由、链路追踪等。Spring Cloud 并不重复造轮子，而是将市面上开发得比较好的模块集成进去，进行封装，
从而减少了各模块的开发成本。换句话说：Spring Cloud 提供了构建分布式系统所需的“全家桶”。
2. Current status of spring-cloud?
目前，国内使用 Spring Cloud 技术的公司并不多见，不是因为 Spring Cloud 不好，主要原因有以下几点：
Spring Cloud 中文文档较少，出现问题网上没有太多的解决方案。国内创业型公司技术老大大多是阿里系员
工，而阿里系多采用 Dubbo 来构建微服务架构。大型公司基本都有自己的分布式解决方案，而中小型公司
的架构很多用不上微服务，所以没有采用 Spring Cloud 的必要性。但是，微服务架构是一个趋势，而 Spring Cloud 是微服务解决方案的佼佼者，这也是作者写本系列课程的意义所在。
3. Advantages and disadvantages of spring-cloud?
其主要优点有：集大成者，Spring Cloud 包含了微服务架构的方方面面。
约定优于配置，基于注解，没有配置文件。
轻量级组件，Spring Cloud 整合的组件大多比较轻量级，且都是各自领域的佼佼者。
开发简便，Spring Cloud 对各个组件进行了大量的封装，从而简化了开发。
开发灵活，Spring Cloud 的组件都是解耦的，开发人员可以灵活按需选择组件。
接下来，我们看下它的缺点：
项目结构复杂，每一个组件或者每一个服务都需要创建一个项目。
部署门槛高，项目部署需要配合 Docker 等容器技术进行集群部署，而要想深入了解 Docker，学习成本高。
Spring Cloud 的优势是显而易见的。因此对于想研究微服务架构的同学来说，学习 Spring Cloud 是一个不错的选择。
2. Spring-Cloud usage and business scenarios
In fact, I am just new to spring-cloud, and I feel a little in love at first sight, so take the opportunity, miss it and meet again.
Business scenario introduction: Suppose we are now developing an online video learning project to realize the function of paying orders.
The process is as follows:
- After creating an order, the user pays for the order immediately, and needs to update the order status to "paid"
- Deduct the corresponding commodity inventory
- Notify the warehouse storage center for delivery
- Increase the corresponding points
- Or deduct the corresponding coupon
In response to the above, there are order services, inventory services, warehouse services, integral services, and coupon services.
The general idea:
- After the user completes the payment for an order, he will go to the order service to update the order status
- Order service calls inventory service to complete corresponding functions
- The order service calls the warehouse service to complete the corresponding function
- The order service calls the integral service to complete the corresponding function
The entire payment order business process ends, as shown in Figure 1 clearly showing the calling process between services:
Then let us explore which components in the Spring Cloud microservice architecture, how to interact with each other and the leading brother behind it?
Spring Cloud consists of many sub-projects, such as Spring Cloud Config, Spring Cloud Netflix, Spring Cloud Consul, etc. It provides tools commonly used to build distributed systems and microservices, such as configuration management, service discovery, circuit breakers, intelligent routing, and microagents , Control bus, one-time token, global lock, master selection, distributed session and cluster state, etc., meet all the solutions required to build microservices.
服务发现——Netflix Eureka
客服端负载均衡——Netflix Ribbon
断路器——Netflix Hystrix
服务网关——Netflix Zuul
分布式配置——Spring Cloud Config
Let's get her
one by one. One of the core components of Spring Cloud: Eureka [jʊ'ri:kə]
Then the question is, how does the order service want to call the inventory service, warehouse service, and point service?
The order service simply doesn't know which machine the inventory service is on! Even if it wants to initiate a request, it doesn't know who to send it to.
It's powerless! At this time, it's Spring Cloud Eureka's turn. Eureka is the registry in the microservice architecture, which is responsible for service registration and discovery.
Let's take a look at the following picture, and analyze the whole process carefully in combination with the picture:
As shown in the above picture, there is an Eureka Client component in inventory service, warehousing service, and point service. This component is responsible for registering the information of this service. To Eureka Server.
To put it bluntly, it is to tell Eureka Server which machine you are on and which port you are listening on.
The Eureka Server is a registry with a registry that stores the machine and port number of each service.
There is also an Eureka Client component in the order service. This Eureka Client component will ask Eureka Server: Which machine is the inventory service? Which port is listening? What about the warehousing service? What about the point service?
Then you can pull the relevant information from the Eureka Server's registry to your local cache.
At this time, if the order service wants to call the inventory service, you can find your local Eureka Client and ask which machine the inventory service is on? Which port is it listening on?
After receiving the response, you can immediately send a request to call the interface of the inventory service to deduct the inventory! Similarly, if the order service needs to call the warehousing service and the point service, the same is true.
in conclusion:
Eureka Client: Responsible for registering the information of this service to Eureka Server.
Eureka Server: The registry, which contains a registry that stores the machine and port number of each service.
The second core component of Spring Cloud: Feign's
order service now knows where the inventory service, point service, and warehouse service are, and which port numbers are also monitored.
But there is a new question again: Does the order service have to write a lot of code by itself, establish a network connection with other services, then construct a complex request, then send the request in the past, and finally write a lot of code for the response result returned? Handle it?
This is the code snippet translated by the above process. Let's take a look together to experience this feeling of despair and helplessness!!!
Friendly reminder, high-energy warning ahead: After
reading the large piece of code above, do you feel a cold back or a cold sweat? In fact, when you make a call between services, if you write the code every time, the amount of code is more than the above paragraph At least several times more, so this thing is simply not capable of the earth.
In that case, what should we do? Don't worry, Feign has already provided us with an elegant solution. Let's see if you use Feign, what will your order service call inventory service code look like?
What do you feel after reading the above code? Do you feel that the whole world is clean, and you have found the courage to live!
There is no underlying code for establishing a connection, constructing a request, and parsing a response, just define a Feign Client interface with annotations, and then call that interface.
The Feign Client will establish a connection with the service you specify, construct a request, initiate a request, get a response, parse the response, etc. at the bottom according to your annotations. Feign did all this dirty work for you.
So the question is, how does Feign do such a magical thing? Very simple, a key mechanism of Feign is to use dynamic proxy.
Let's take a look at the above picture and analyze it in combination with the picture:
First, if you define the @FeignClient annotation on an interface, Feign will create a dynamic proxy for this interface.
Then if you call that interface, you will essentially call the dynamic proxy created by Feign, which is the core of the core.
Feign's dynamic proxy will dynamically construct the address of the service you want to request based on your @RequestMapping and other annotations on the interface.
Finally, for this address, initiate a request and parse the response.
Spring Cloud core component three: Ribbon
Finished talking about Feign, not finished yet. Now the new problem comes again, if the inventory service is deployed on 5 machines.
As follows:
192.168.169:9000
192.168.170:9000
192.168.171:9000
192.168.172:9000
192.168.173:9000
This is troublesome! How does Feign know which machine to request? Then Spring Cloud Ribbon comes in handy Up.
Ribbon specifically solves this problem. Its role is load balancing, it will help you select a machine for each request, and evenly distribute the request to each machine.
The most classic Round Robin polling algorithm used by Ribbon's load balancing by default. what is this?
To put it simply, if the order service initiates 10 requests for the inventory service, then first ask you to request the first machine, then the second machine, the third machine, the fourth machine, the fifth machine, and then Come again-a cycle, the first machine, the second machine. . . And so on.
In addition, Ribbon worked closely with Feign and Eureka to complete the work, as follows:
First of all, Ribbon will obtain the corresponding service registry from Eureka Client, which also knows which machines all services are deployed on and which port numbers are being monitored.
Then Ribbon can use the default Round Robin algorithm to select a machine from it.
Feign will construct and initiate a request for this machine.
For the whole process mentioned above, here is another picture to help you understand more deeply:
Spring Cloud core component four: Hystrix
In the microservice architecture, a system has many services. Take the business scenario of this article as an example: the order service needs to call three services in a business process.
Now suppose that the order service itself has at most 100 threads that can handle requests. Then, the credit service unfortunately hangs. Every time the order service calls the credit service, it will be stuck for a few seconds and then throw a timeout exception.
Let’s analyze together, what kind of problems will this cause? If the system is in a high concurrency scenario, when a large number of requests come in, 100 threads of the order service will be stuck in requesting the point service, resulting in no thread in the order service. Process the request.
Then, when others request the order service, they find that the order service is also down and no longer responds to any requests.
The above is the horrible service avalanche problem in the microservice architecture, as shown in the following figure:
As shown in the figure above, if so many services call each other, if no protection is done, a certain service hangs, it will cause a chain reaction and cause other services to hang.
For example, if the credit service is down, all the threads of the order service will be stuck in requesting the credit service, and none of the threads can work, and the order service will also be suspended in an instant. All other people requesting the order service will be stuck and cannot respond.
But let’s think about it, even if the point service is suspended, the order service can be suspended! Why?
Let’s take a business perspective: when paying for an order, just deduct the inventory and notify the warehouse to ship it.
If the point service is down, it’s a big deal to wait for it to recover, and then slowly restore the data manually! Why must the order service be hung up directly because a point service is down? It is not acceptable!
Now that the problem is analyzed, how to solve it? Now it's Hystrix's turn to debut. Hystrix is a framework for isolation, fusing and degradation. What do you mean?
To put it bluntly, Hystrix will engage in many small thread pools. For example, order service request inventory service is a thread pool, request storage service is a thread pool, and request credit service is a thread pool. Each thread in the thread pool is only used to request that service.
Let’s make an analogy: unfortunately now, the credit service is down. What will happen? Of course, the thread used to call the credit service in the order service is stuck and cannot work!
However, since the two thread pools of the order service calling the inventory service and the warehousing service are working normally, these two services will not be affected in any way.
At this time, if someone requests order service, the order service can still call the inventory service to deduct the inventory, and call the warehousing service to notify the delivery.
It's just that when calling the credit service, an error will be reported every time. But if the points service is all hung up, what does it mean to get stuck for a few seconds every time you call it? Does it make sense? Of course not!
So we just need to fuse the point service directly. For example, if the point service is requested within 5 minutes, it will be returned directly. Don't go to the network and the request is stuck for a few seconds. This process is the so-called fuse!
Then they said, brother, if the point service is down, you will fuse it. Anyway, what are you doing! Don't just return without doing anything?
No problem, let's downgrade: every time you call the point service, you will record a message in the database, saying how many points have been added to a certain user, because the point service is down, so the increase is not successful!
After the point service is restored, you can manually add points based on these records. This process is the so-called downgrade.
In order to help everyone understand more intuitively, let's use a picture to sort out the entire process of Hystrix isolation, fusing and downgrading:
Spring Cloud core component five: Zuul
After talking about Hystrix, let's talk about the last component: Zuul, which is the microservice gateway. This component is responsible for network routing.
Don't understand network routing? Okay, then let me tell you what would happen without Zuul's daily work?
Suppose you have deployed hundreds of services in the background, and now there is a front-end brother, and the request is sent directly from the browser.
For example, if someone wants to request an inventory service, do you remember that the name of this service is inventory-service? It is deployed on 5 machines?
Even if people are willing to remember this one, you have hundreds of service names and addresses in the backend? Is it true that if an adult asks for one, you have to remember one? If you want to play like this, it is really a boat of friendship. turn!
The above situation is simply unrealistic. Therefore, a gateway must be designed in the general microservice architecture.
Like Android, iOS, PC front-end, WeChat applet, H5, etc., you don’t need to worry about hundreds of services in the back-end. You know that there is a gateway. All requests go to the gateway. The gateway will The request is forwarded to the various back-end services.
And after having a gateway, there are many benefits, such as unified downgrade, current limit, authentication and authorization, security, etc.
to sum up
Finally, let's summarize the roles of the above-mentioned Spring Cloud core components in the microservice architecture:
Eureka: When each service starts, Eureka Client will register the service with Eureka Server, and Eureka Client can also pull the registry from Eureka Server in turn, so as to know where other services are.
Ribbon: When a request is initiated between services, load balancing is performed based on Ribbon, and one of the multiple machines of a service is selected.
Feign: Based on Feign's dynamic proxy mechanism, according to the annotations and the selected machine, the request URL address is spliced to initiate the request.
Hystrix: Requests are initiated through Hystrix's thread pool. Different services use different thread pools, which realizes the isolation of different service calls and avoids the problem of service avalanche.
Zuul: If the front-end and mobile end want to call the back-end system, they enter the Zuul gateway uniformly, and the Zuul gateway forwards the request to the corresponding service.
The above is an e-commerce business scenario that explained the underlying principles of several core components of the Spring Cloud microservice architecture.
The text summary is not intuitive enough? No problem! We connect the 5 core components of Spring Cloud through a picture, and then intuitively feel the underlying architecture principle:
