table of Contents
A business presentation scene
Two, Spring Cloud core components: Eureka
Three, Spring Cloud core components: Feign
Four, Spring Cloud core components: Ribbon
Five, Spring Cloud core components: Hystrix
Six, Spring Cloud core components: Zuul
Seven summary
Outline
There is no doubt, Spring Cloud is currently the leader in the field of micro-service architecture, in numerous books blog to explain this technology. But most still remain at the level of explanation for Spring Cloud function to use, many of the principles underlying, many people may not be aware of. Therefore, this paper through a lot of hand drawing, talk to you about the underlying principles of the Spring Cloud micro-services architecture.
In fact, Spring Cloud is a family bucket technology stack, contains a lot of components. This paper begins with its core of several components start to analyze what works its underlying. That is Eureka, Ribbon, Feign, Hystrix, Zuul these components.
First, the business scenarios introduced
first to tell you that a business scenario, we assume that electricity suppliers are now developing a Web site, to realize the function of the pay orders, process is as follows:
After you create an order, if the user is immediately paid for this order, we need to update the order status to "paid"
Deduction of the corresponding commodity stocks
Notice warehousing center, shipping
To the user's current shopping a corresponding increase in integration
In response to these processes, we need to have service orders, inventory services, warehousing services, integration services. The general idea of the whole process as follows:
After the user completes the payment for an order, the order will go to service, order status update
Orders Inventory service call service, complete the corresponding function
Orders service calls warehousing services, complete the corresponding function
Orders integral service call service, complete the corresponding function
At this point, the entire payment orders end business processes
The figure below this figure, clearly shows that the calling process between the various services:
it is good! Once you have the business scenario, let's take a look at Spring Cloud micro-service architecture, and how these components work together, as well as the respective roles of the principles behind it.
Two, Spring Cloud core components: Eureka
Let's consider the first question: you want to call order service inventory services, warehousing services, or integration service, how to call?
Order Services Inventory Service simply did not know the people on which machine ah! He even wants to initiate a request, do not know to whom to send, powerless!
At this time, the turn of Spring Cloud Eureka played. Eureka is a micro-service architecture in the registry, responsible for registration and discovery services.
Let's look at this chart below, with plans to carefully analyze what the entire process:
As shown above, inventory services, warehousing services, integration services have a Eureka Client component, the component responsible for the registration of the information service in the Eureka Server. To put it plainly, it is to tell Eureka Server, which on its own machine, listening on which port. The Eureka Server is a registration center, which has a registry, save the machine where each service and port number
Order service also has a Eureka Client component, the Eureka Client Components will find Eureka Server ask: Inventory Service which machine ah? Listening on which port ah? Warehousing services? Integration services? Then you can put these information pulled from the registry Eureka Server's up to your local cache.
Then if you want to call to order service inventory service, you can not find your own local Eureka Client Inventory Service to ask which machine? Which port to monitor it? After receiving the response, you can immediately send a request in the past, call the service inventory deductions that interface stock! Similarly, if you want to call to order service warehousing services, integration services, also followed suit.
in conclusion:
Eureka Client: This information service is responsible for the registration to Eureka Server
Eureka Server: registration center, which has a registry, save the machine where each service and port number
Three, Spring Cloud core components: Feign
now order service do know that inventory services, integration services, warehousing services where we are, but also listening on which port number. But the new question again: Do you want to write your own order service a lot of code, establishing a network connection with other services, and then construct a complex request, then sends a request in the past, the final response to the results returned to write a lot of code deal with it?
This is the code snippet above-mentioned process of translation, let's take a look, understand what this hopeless and helpless feeling! ! !
Tips, high-energy front:
After reading the above that a large section of code, there did not feel back cold, a cold sweat? When you actually inter-service call, if every handwritten code, the code to be more than the above period of at least several times, so this thing simply will not the people on earth capable.
That being the case, how to do it? Do not worry, Feign has already provided us with a good elegant solution. If Feign take a look at it, your order service invocation code inventory services become Chengshayang?
After reading the above code does it feel? I am not feeling the whole world clean, and to find the courage to live! Did not establish the underlying connection configuration request, the response parsing code, is directly defined by a FeignClient annotation interfaces, that interface and then calls it. People Feign Client according to your notes, you specify the services with the establishment of the underlying connection configuration requests, seeking to initiate Zhen, get a response, parse the response, and so on. This series of dirty work, people Feign give you all did.
So the question is, how do Feign is so magical it? Very simple, a key mechanism Feign is the use of dynamic proxy. Let's take a look at the following chart, with plans to analyze:
First of all, if you define @FeignClient comment on an interface, Feign for this interface will create a dynamic proxy
Then if you call that interface, essentially calls the dynamic proxy Feign created, which is the core of the core
Feign dynamic proxy based on your @RequestMapping and other notes on the interface, to dynamically construct a service you requested address
Finally this address initiates a request, parse the response
Four, Spring Cloud core components: Ribbon
finished Feign, not finished. New problem now again, if the people on the inventory service deployment in five machines, as follows:
192.168.169:9000
192.168.170:9000
192.168.171:9000
192.168.172:9000
192.168.173:9000
This time trouble! Feign how people know which machine is which request it?
Then Spring Cloud Ribbon comes in handy. Ribbon is specifically designed to solve this problem. Its role is to load balancing, it will help you choose a machine on every request, even to distribute requests to each machine
Ribbon load balancing using the default classic Round Robin polling algorithm. what is this? Simply put, if the order of service inventory service launched 10 requests, then let you ask first machine, then the first two machines, 3 machines, 4 machines, 5 machines, then again - cycles, the first machine, the second machine. . . And so on.
In addition, Ribbon and Feign and Eureka is close cooperation to complete the work, as follows:
First Ribbon will get from Eureka Client in the corresponding service registry, will know all the services which are deployed on the machines, which in the listening port number.
Then you can use the default Ribbon Round Robin algorithm, choose a machine
Feign would be focused on this machine, constructed and initiated the request.
The whole process above, again a map to help people more profound understanding:
Five, Spring Cloud core components: Hystrix
In the micro-services architecture, the system will have a lot of services. In a business scenario in this article as an example: In order service need to call a business process in three services. Now suppose order service only own up to 100 threads to handle requests, then, unfortunately, I hung up integration services, each service order when calling integration services, will be stuck for a few seconds, then throws - a timeout exception.
Let's work together to analyze, this will cause any problems?
If the system is under high concurrency scenarios, Chung large number of requests over time, the order of service card will be 100 threads in this request integration services. Service orders led to a thread can not process the request
Then it will lead to others when requesting service orders, service orders found to have hung up, does not respond to any requests
Above this, the service is terrible avalanche problems micro services architecture, as shown below:
As shown above, so many service calls each other, if without any protection, then hung up a certain service, it will cause a chain reaction, leading to other services are also linked. For example, integration services hung up, causes the thread all the cards in the order of service request integration services here, a thread can not work, resulting in an instant order service also hung up, all others requesting service orders will be stuck, unable to respond.
But we think about, even if the integral service hung up, service orders can not hang ah! why?
We combine business point of view: when the payment order, as long as the stock deduction, and then warehouse delivery notification on OK
If the integral service hung up, big deal, etc. After he recovered, human flesh slowly by hand to recover data! Why must as a service integrator hung up on the direct order service also lead to hang out? Unacceptable!
Analysis done now, how to solve?
That's where Hystrix the debut. Hystrix is isolated, and a frame fuse degraded. What does it mean? To put it plainly, Hystrix will engage in a number of small thread pool, such as order service is a service request thread pool inventory, warehousing service request is a thread pool, integral service request is a thread pool. Each thread pool thread on request only for that service.
Analogy: Now, unfortunately, integral service hung up, will Zeyang?
Of course, the order will result in the service that used to call integration service threads are stuck not work ah! However, due to orders for service calls inventory services, warehousing services both thread pools are working properly, so the two services will not be affected in any way.
This time if someone else order service requests, service orders or service can be called normal inventory deduction of inventory, warehousing services call notification delivery. Just call the integral service when every time an error. But if integration services are linked to each call have to go to get stuck doing it for a few seconds? Make sense? of course not! Therefore, we direct integration services to the fuse does not have, such as requesting service points in 5 minutes directly on the return, not to take the network requests stuck for a few seconds, this process is called fuse!
That people said, brother, you just hang integral service fuse, whatever the outcome, something you do ah! Do consequently quit to return directly ah? No problem, we come to a downgrade: each call integration services, you record a message in the database, he said to a certain number of users increased integration, because integration service hung up, did not lead to increased success! Such integration and other services restored, you can add about integrating these records by hand. This process is called the downgrade.
To help you more intuitive understanding, followed by a map, comb Hystrix isolation, fuse, and the whole process of degradation:
Six, Spring Cloud core components: Zuul
finished Hystrix, and then everyone to talk about the last component: Zuul, which is micro-services gateway. This component is responsible for network routing. Understand network routing? OK, I'll give you talk about, if not daily work Zuul what would happen?
Suppose you backstage deployed hundreds of services, now there is a front-end sibling, people request is sent directly from the browser over there. Analogy: people want to look at inventory service request, do you still let people remember this service name is inventory-service? Deployed on five machines? Even if people are willing to remember this one, you can have hundreds of backstage name and address of the service it? Implying a family request, you have to remember one? You want to play like this, then it is the friendship of the boat, said turn on the turn!
Above this situation, simply did not realistic. Therefore, the general micro-service architecture are bound to design a gateway on the inside, like android, ios, pc front-end, small micro-channel program, H5, etc., do not have to care about the back end there are hundreds of service, we know there is a gateway to all requests will go to the gateway, the gateway at the request of some of the features, the request is forwarded to the back-end service.
And there is a behind the gateway, there are many benefits, such as unified downgrade can do, limiting, authentication and authorization, security, and so on.
VII Summary:
Finally, to sum up, the role of the above several Spring Cloud core components, micro-service architecture, were played:
Eureka: When each service starts, Eureka Client service will be registered with the Eureka Server, and Eureka Client can also turn to take the registry from Eureka Server pull, so they know where other services
Ribbon: the time between services initiated the request, based on the Ribbon to do load balancing, multiple machines from a service, select a
Feign: Based on the dynamic proxy mechanism Feign, according to the notes and selected machine, stitching request URL address and send a request
Hystrix: request is initiated by Hystrix thread pool to go, different services take a different thread pool to achieve the isolation of different service calls, to avoid the avalanche of service issues
Zuul: If the front end, back-end system to call the mobile terminal, the gateway into the Unified from Zuul, the gateway forwards the request to the corresponding Zuul service
These are our electricity business through a business scenario to explain the underlying principles of the Spring Cloud micro Services Architecture few core components.
Text summary also intuitive enough? no problem!
We'll Spring Cloud's five core components through a picture together, and come to an intuitive feel for the underlying principles of architecture:
