Transfer from: Please! Please don't ask me about the underlying principles of Spring Cloud in the interview!
Business scenario introduction
To develop an e-commerce website, to realize the function of paying orders, the process is as follows:
- After creating an order, if the user pays the order immediately, we need to update the order status to "paid"
- Deduct the corresponding product inventory
- Notify the warehousing center for delivery
- Add corresponding points to the user for this purchase
For the above process, we need order service, inventory service, warehousing service, and point service.
Spring Cloud core components:
Eureka
In the architecture 注册中心, it is responsible for service registration and discovery.
Eureka Client:
1. Responsible for registering the information of this service to Eureka Server (tell Eureka Server which machine you are on and which port it is listening on).
2. In turn, pull the registry from Eureka Server and cache it locally (thereby knowing where other services are)
Eureka Server: registry, there is a registry, which saves the machine and port number of each service
Feign
(Establish a connection configuration request, it sends a request resolution response)
based on the Feign 动态代理mechanism, and annotated according to the selected machine, splicing request URL address, initiation request
- First, if you define the @FeignClient annotation for 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
Ribbon
(If other people's inventory service is deployed on 5 machines, how does Feign know which machine to request?) When
a request is made between services, it is based on Ribbon 负载均衡and one service is selected from multiple machines.
The most classic Round Robin used by default 轮询算法.
Ribbon works closely with Feign and Eureka to complete the work:
- First of all, Ribbon will get 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.
Hystrix
Requests are initiated through the Hystrix thread pool. Different services use different thread pools, which realizes the isolation of different service calls and avoids the problem of service avalanche.
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 process 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.
- If the system is in a high-concurrency scenario, when a large number of requests flow in, 100 threads of the order service will be stuck in requesting the point service. As a result, the order service does not have a thread that can process the request
- Then it will cause others to request the order service, and find that the order service is also hung up, and will not respond to any requests.
But let's think about it, even if the points service is down, the order service can be left out! why?
Let’s look at the business: when paying for the order, just deduct the inventory, and then notify the warehouse to ship it.
If the points service is down, it is a big deal to wait for him to recover, slowly recover the data manually! Why must the order service be suspended because a credit service is suspended? Not acceptable!
（Hystrix是隔离、熔断以及降级的一个框架，Hystrix搞很多个小小的线程池，每个线程池里的线程就仅仅用于请求那个服务。）
But if the credit service is all hung up, why do you have to get stuck for a few seconds every time you call it? Does it make sense? of course not! Therefore, we just need to fuse the points service directly. For example, if you request the point service within 5 minutes, you will return directly. Don't go to the network and request to be stuck for a few seconds. This process is so-called 熔断!
If the integral service is down, you will fuse it. What are you doing! Don't just return without doing anything? No problem, let's downgrade: every time you call the points 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, and 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 降级.
Zuul
Microservices 网关(this component is responsible for network routing)
If the front-end and mobile end want to call the back-end system, they don’t have to worry about hundreds of services in the back-end. They enter from the Zuul gateway. The gateway will request according to some characteristics in the request. Forward to the corresponding service.
Can do unified downgrade, current limit, authentication and authorization, security, etc.
Integration:
The underlying architecture principle
