In previous articles, we introduced Eureka, Ribbon and Feign, using Eureka cluster to ensure the high availability of the registry, using the Ribbon in Eureka for load balancing, using FeIGN interface to replace the code of manually coded request interface, and the whole microservice seems to be almost complete Is there anything worth optimizing? The answer is certainly there, and is the most important part of the whole micro service, that is, the thermal circuit breaker and downgrade of service, why is the service circuit breaker and downgrade the most important part? Let’s start with the concept of service avalanche.
Service avalanche
So-called service avalanche, is peculiar to micro service system concept, don’t understand the concept of service avalanche of children’s shoes, listen to the service at the beginning of an avalanche, will associate to cache the avalanche, the so-called cache avalanche, namely a large number of cached in the same time expired, resulting in a large number of requests not to walk the cache and database access, database, instantaneous pressure lead to database downtime. In general, our solutions are as follows: 1. Set different expiration times for different caches. 2. 3. Cache preheating. The reason we want to prevent cache avalanche, from five aspects: system architecture (high performance/high availability, scalability/scalability/security), is to ensure that the performance of the system and protect the database, and we said to preventive services avalanche, in order to guarantee the availability of the micro service system, let us use a diagram for details:
Suppose in a micro electric business service system, the user service, orders for services, products and services, logistics services and other services, user service calls to order, order service invocation products and services, product service call logistics service, if not considering the service of fusing with relegation, if at the time of product service call logistics service, logistics service itself is something wrong with returned an error Swings in request timeout or network, the products and services will be an error, which affects the order service follow error, layer upon layer back, until the top service, thus resulted in a micro service problems influence the whole of the micro system level error, this is known as avalanche of services, in extreme cases, can lead to a few or even the whole service system outage, this right It is intolerable for modern microservice systems, so we need to fuse and degrade the service. It is important to note that the service characteristics and degradation are two concepts, in general, the so-called service fusing, is for the service provider, when the service provider cannot call need to be fusing, and degradation is for service consumer, when the service provider to provide services, consumer need down-cycled. Spring Circuit-breakers and downgrades of services in the Cloud use Hystrix, so let’s take a closer look at Hystrix.
Service fuse with downgrading hystrix
Hystrix, which translates to porcupine in Chinese, is an open source Netflix framework for fusing and degrading services for distributed systems. So how do we use it? Dhp-micro-service-producer-hystrix = dhP-micro-service-producer-hystrix = dhP-micro-service-producer-hystrix
Maven dependencies are added in three steps:
Then modify the code:
The @hystrixCommand is used to specify a fuse method. When the annotated method throws an exception, the method specified by fallbackMethod will be called. This method needs to be done according to the business needs. Note that both the input and return values of the eureka method must be the same as the original method.
Finally modify the startup class to add support for Hystrix:
If the eureka-server fails to start, this does not affect our test because we mock the database using code as the product information in the Producer project:
Select * from product where ID>6; select * from product where ID>6;
Illustrate our service providers in the service of abnormal fusing method has been successfully used, but it is not enough, in some cases, the service provider and there is no problem, but may be due to network reasons lead to consumer is not a successful call to the interface, the disclosing party as the provider of any processing is meaningless, so we need at the consumer end Since we used Feign for interface proxy, and FeIGN already integrated Hystrix, we need to modify the consumer side code: First, add fallbackFactory to the Feign proxy interface to specify the degraded service class:
We then implement the class, which implements the create method of the FallbackFactory interface, returns a generic specified service, and implements the degradation of all methods in the specified interface:
Then we can verify that: first start eureka-server, then start producer, and register producer with Eureka:
After successful startup, visit to try it out:
If id=1, we can get the result successfully, try again if id >6:
We can see from the description that this is implementing the producer[DHP-micro-service-producer-hystrix] circuit breaker. How can we verify the consumer degradation method? First of all, the self-protection function of Eureka-Server should be disabled, and the self-check should be set once every 10 seconds to eliminate invalid services:
So what is invalid? This requires the service provider to set the time when producer[DHP-micro-service-producer-hystrix] sends heartbeat beats and the service expiration time so that Eureka-server can eliminate producer as soon as possible.
In order to quickly make Eureka-server eliminate producer, we set the eureka-server to send a heartbeat every 5 seconds (the default value is 30 seconds) and tell eureka-server that if no heartbeat is sent within 15 seconds (the default value is 90 seconds, which is generally 3 times of the heartbeat interval), eureka-SE will send a heartbeat When rver removes producer, the active failure detection time of Eureka-server is 10 seconds. When we stop producer, Eureka-server removes producer at most 25 seconds, and then visits consumer:
As you can see, this is our demotion method for consumer, and from there hystrix is configured on both the service provider and consumer side. Isn’t that easy? Next, take a look at Hystrix’s dashboard.
HystrixDashboard
Dashboard is a service monitoring function provided by Hystrix, which can be used to monitor a micro-service. Let’s try it. First create a module[DHP-micro-service-Hystrix-Dashboard]:
Next, add maven dependencies:
Then the configuration file modifies the service port number:
Then launch the class to add dashboard support:
Start up and take a look:
So how do you use it? First, we need to ensure that the monitored service has health check dependencies. For example, if we monitor producer[DHP-micro-service-producer-hystrix], we need to ensure that producer maven configuration has health check dependencies:
And the related configuration is required:
Then start the producer and enter the corresponding producer’s address in the Hystrix dashboard to monitor all accesses to that address:
If you access the relevant interface of the producer, you can see the relevant statistics:
As for the meaning of each of the data, I believe that it is certainly difficult to fall the majority of you children’s shoes, after all, there is a problem to find Baidu, as we all know, conditional on Google, no problem can stumple us.
Turbine
If you’re careful, you’ll notice that on the front page of the Hystrix-Dashboard, we’ve seen a note like this:
Translation, that is, tell us the way, if is the use of turbine monitoring address format is the turbine – the hostname: port/turbine stream, if is single hystrix – app, address format is hystrix – app: port/act Uator/Hystrix.stream, that’s what we used to do with turbine.
We said above that Dashboard can only monitor a certain micro-service, but the reality is that a micro-service production system is far more than one micro-service. We need to monitor all micro-services, and dashboard obviously cannot meet our needs, while turbine can, so turbine’s operation should be done It can monitor multiple microservices at the same time. In order to facilitate the demonstration of turbine’s monitoring of multiple micro-services, we built a module[DHP-micro-service-user-hystrix]:
Then add the parent project:
Then configure maven dependencies in three steps:
Then configure application.properties:
The configuration of the main class is described in detail in the previous article.
Then code:
Start eureka-server, then start user and producer:
You can see that both services are registered with Eureka, then use the dashboard to test:
There is no problem, indicating that it is ok. Next, we use Turbine to monitor producer and user services at the same time. In order to facilitate comparison with the previous dashboard, we add a turbine module[dhp-micro-service-turbine-dashboard]:
Add it to the parent project:
Then, as usual, first configure maven dependencies:
Then configure application.properties:
The most important thing is to configure turbine information. App-config identifies the services to be monitored, which are separated by commas. From the name, we can see that it is the service name of the service registered in Eureka:
Added main class configuration:
Eureka-server is started, user[DHp-micro-service-user-hystrix] and producer[DHp-micro-service-producer-hystrix] are started, and Dashboa is started Rd [DHP-Micro-service-Hystrix-Dashboard], finally start turbine[DHP-Micro-service-Dashboard], then access Dashboard [DHP-Micro-service] -Hystrix-dashboard] and monitor turbine’s address:
Then ask user and producer, respectively:
Then take a look at the Hystrix-Dashboard:
Only userController is monitored, but ProducerController is not. Why? Are we misconfigured? Don’t worry, let’s take a look at the console information:
The prompt message told us that a connection was rejected, so we should give up turbine’s monitoring. The failed address is 192.168.1.13:7301, which is the address of our producer service. In addition, status401, Error and message in the prompt message all reminded us. Unauthorized logins. Recall that our producer project introduced DHP-micro-service-Auth for security authentication, requiring a user name and password. Therefore, we found the cause: unauthorized logins from the producer caused monitoring failures. It is a pity that turbine can monitor both the situation where all services have passwords and the situation where all services have no passwords. However, for the situation where some services have passwords and some services have no passwords,turbine cannot do anything. If adaptation is really needed for production, we can only modify DHP-micro-servI Use ce-auth to disable /actuator/hystrix.stream and /turbine.
Restart producer, access user and Producer again, and look at the dashboard:
At this point, both producerController and UserController were successfully monitored by Turbine.
To recap, in this article we introduced The Spring-Cloud circuit breaker Hystrix and the Hystrix-Dashboard that monitors hystrix for a single service and turbine for multiple services. In the next article, we will continue to introduce the gateway Zuul. Stay tuned!
Github address for this article
This article is published by OpenWrite!