Einführung in Hystrix

1. Übersicht

Ein typisches verteiltes System besteht aus vielen Diensten, die zusammenarbeiten.

Diese Dienste sind anfällig für Fehler oder verzögerte Antworten. Wenn ein Dienst ausfällt, kann dies Auswirkungen auf andere Dienste haben, die die Leistung beeinträchtigen und möglicherweise andere Teile der Anwendung unzugänglich machen oder im schlimmsten Fall die gesamte Anwendung zum Erliegen bringen.

Natürlich gibt es Lösungen, die dazu beitragen, Anwendungen widerstandsfähig und fehlertolerant zu machen - ein solches Framework ist Hystrix.

Die Hystrix-Framework-Bibliothek hilft bei der Steuerung der Interaktion zwischen Diensten, indem Fehlertoleranz und Latenztoleranz bereitgestellt werden. Es verbessert die allgemeine Ausfallsicherheit des Systems, indem es die fehlerhaften Dienste isoliert und den Kaskadeneffekt von Fehlern stoppt.

In dieser Reihe von Beiträgen werden wir zunächst untersuchen, wie Hystrix bei einem Ausfall eines Dienstes oder Systems zur Rettung kommt und was Hystrix unter diesen Umständen leisten kann.

2. Einfaches Beispiel

Die Art und Weise, wie Hystrix Fehler- und Latenztoleranz bietet, besteht darin, Anrufe an Remotedienste zu isolieren und zu verpacken.

In diesem einfachen Beispiel schließen wir einen Aufruf in die run () -Methode des HystrixCommand ein:

class CommandHelloWorld extends HystrixCommand { private String name; CommandHelloWorld(String name) { super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup")); this.name = name; } @Override protected String run() { return "Hello " + name + "!"; } }

und wir führen den Aufruf wie folgt aus:

@Test public void givenInputBobAndDefaultSettings_whenCommandExecuted_thenReturnHelloBob(){ assertThat(new CommandHelloWorld("Bob").execute(), equalTo("Hello Bob!")); }

3. Maven Setup

Um Hystrix in einem Maven-Projekt verwenden zu können, benötigen wir im Projekt pom.xml die Abhängigkeit von Hystrix-Core und Rxjava-Core von Netflix :

 com.netflix.hystrix hystrix-core 1.5.4  

Die neueste Version finden Sie immer hier.

 com.netflix.rxjava rxjava-core 0.20.7 

Die neueste Version dieser Bibliothek finden Sie immer hier.

4. Remote Service einrichten

Beginnen wir mit der Simulation eines Beispiels aus der realen Welt.

Im folgenden Beispiel repräsentiert die Klasse RemoteServiceTestSimulator einen Dienst auf einem Remoteserver . Es gibt eine Methode, die nach dem angegebenen Zeitraum mit einer Nachricht antwortet. Wir können uns vorstellen, dass dieses Warten eine Simulation eines zeitaufwändigen Prozesses auf dem Remote-System ist, der zu einer verzögerten Antwort auf den anrufenden Dienst führt:

class RemoteServiceTestSimulator { private long wait; RemoteServiceTestSimulator(long wait) throws InterruptedException { this.wait = wait; } String execute() throws InterruptedException { Thread.sleep(wait); return "Success"; } }

Und hier ist unser Beispielclient , der den RemoteServiceTestSimulator aufruft .

Der Aufruf des Dienstes wird isoliert und in die run () -Methode eines HystrixCommand eingeschlossen. Diese Verpackung bietet die Widerstandsfähigkeit, die wir oben angesprochen haben:

class RemoteServiceTestCommand extends HystrixCommand { private RemoteServiceTestSimulator remoteService; RemoteServiceTestCommand(Setter config, RemoteServiceTestSimulator remoteService) { super(config); this.remoteService = remoteService; } @Override protected String run() throws Exception { return remoteService.execute(); } }

Der Aufruf wird ausgeführt, indem die Methode execute () für eine Instanz des RemoteServiceTestCommand- Objekts aufgerufen wird.

Der folgende Test zeigt, wie dies gemacht wird:

@Test public void givenSvcTimeoutOf100AndDefaultSettings_whenRemoteSvcExecuted_thenReturnSuccess() throws InterruptedException { HystrixCommand.Setter config = HystrixCommand .Setter .withGroupKey(HystrixCommandGroupKey.Factory.asKey("RemoteServiceGroup2")); assertThat(new RemoteServiceTestCommand(config, new RemoteServiceTestSimulator(100)).execute(), equalTo("Success")); }

Bisher haben wir gesehen, wie Remote-Service-Aufrufe in das HystrixCommand- Objekt eingeschlossen werden. Im folgenden Abschnitt sehen wir uns an, wie Sie mit einer Situation umgehen, in der sich der Remote-Dienst zu verschlechtern beginnt.

5. Arbeiten mit Remote Service und defensiver Programmierung

5.1. Defensive Programmierung mit Timeout

Es ist allgemeine Programmierpraxis, Zeitüberschreitungen für Anrufe an Remote-Dienste festzulegen.

Lassen Sie uns zunächst untersuchen, wie Sie das Zeitlimit für HystrixCommand festlegen und wie es durch Kurzschließen hilft:

@Test public void givenSvcTimeoutOf5000AndExecTimeoutOf10000_whenRemoteSvcExecuted_thenReturnSuccess() throws InterruptedException { HystrixCommand.Setter config = HystrixCommand .Setter .withGroupKey(HystrixCommandGroupKey.Factory.asKey("RemoteServiceGroupTest4")); HystrixCommandProperties.Setter commandProperties = HystrixCommandProperties.Setter(); commandProperties.withExecutionTimeoutInMilliseconds(10_000); config.andCommandPropertiesDefaults(commandProperties); assertThat(new RemoteServiceTestCommand(config, new RemoteServiceTestSimulator(500)).execute(), equalTo("Success")); }

In the above test, we are delaying the service's response by setting the timeout to 500 ms. We are also setting the execution timeout on HystrixCommand to be 10,000 ms, thus allowing sufficient time for the remote service to respond.

Now let's see what happens when the execution timeout is less than the service timeout call:

@Test(expected = HystrixRuntimeException.class) public void givenSvcTimeoutOf15000AndExecTimeoutOf5000_whenRemoteSvcExecuted_thenExpectHre() throws InterruptedException { HystrixCommand.Setter config = HystrixCommand .Setter .withGroupKey(HystrixCommandGroupKey.Factory.asKey("RemoteServiceGroupTest5")); HystrixCommandProperties.Setter commandProperties = HystrixCommandProperties.Setter(); commandProperties.withExecutionTimeoutInMilliseconds(5_000); config.andCommandPropertiesDefaults(commandProperties); new RemoteServiceTestCommand(config, new RemoteServiceTestSimulator(15_000)).execute(); }

Notice how we've lowered the bar and set the execution timeout to 5,000 ms.

We are expecting the service to respond within 5,000 ms, whereas we have set the service to respond after 15,000 ms. If you notice when you execute the test, the test will exit after 5,000 ms instead of waiting for 15,000 ms and will throw a HystrixRuntimeException.

This demonstrates how Hystrix does not wait longer than the configured timeout for a response. This helps make the system protected by Hystrix more responsive.

In the below sections we will look into setting thread pool size which prevents threads being exhausted and we will discuss its benefit.

5.2. Defensive Programming With Limited Thread Pool

Setting timeouts for service call does not solve all the issues associated with remote services.

When a remote service starts to respond slowly, a typical application will continue to call that remote service.

The application doesn't know if the remote service is healthy or not and new threads are spawned every time a request comes in. This will cause threads on an already struggling server to be used.

We don't want this to happen as we need these threads for other remote calls or processes running on our server and we also want to avoid CPU utilization spiking up.

Let's see how to set the thread pool size in HystrixCommand:

@Test public void givenSvcTimeoutOf500AndExecTimeoutOf10000AndThreadPool_whenRemoteSvcExecuted _thenReturnSuccess() throws InterruptedException { HystrixCommand.Setter config = HystrixCommand .Setter .withGroupKey(HystrixCommandGroupKey.Factory.asKey("RemoteServiceGroupThreadPool")); HystrixCommandProperties.Setter commandProperties = HystrixCommandProperties.Setter(); commandProperties.withExecutionTimeoutInMilliseconds(10_000); config.andCommandPropertiesDefaults(commandProperties); config.andThreadPoolPropertiesDefaults(HystrixThreadPoolProperties.Setter() .withMaxQueueSize(10) .withCoreSize(3) .withQueueSizeRejectionThreshold(10)); assertThat(new RemoteServiceTestCommand(config, new RemoteServiceTestSimulator(500)).execute(), equalTo("Success")); }

In the above test, we are setting the maximum queue size, the core queue size and the queue rejection size. Hystrix will start rejecting the requests when the maximum number of threads have reached 10 and the task queue has reached a size of 10.

The core size is the number of threads that always stay alive in the thread pool.

5.3. Defensive Programming With Short Circuit Breaker Pattern

However, there is still an improvement that we can make to remote service calls.

Let's consider the case that the remote service has started failing.

We don't want to keep firing off requests at it and waste resources. We would ideally want to stop making requests for a certain amount of time in order to give the service time to recover before then resuming requests. This is what is called the Short Circuit Breaker pattern.

Let's see how Hystrix implements this pattern:

@Test public void givenCircuitBreakerSetup_whenRemoteSvcCmdExecuted_thenReturnSuccess() throws InterruptedException { HystrixCommand.Setter config = HystrixCommand .Setter .withGroupKey(HystrixCommandGroupKey.Factory.asKey("RemoteServiceGroupCircuitBreaker")); HystrixCommandProperties.Setter properties = HystrixCommandProperties.Setter(); properties.withExecutionTimeoutInMilliseconds(1000); properties.withCircuitBreakerSleepWindowInMilliseconds(4000); properties.withExecutionIsolationStrategy (HystrixCommandProperties.ExecutionIsolationStrategy.THREAD); properties.withCircuitBreakerEnabled(true); properties.withCircuitBreakerRequestVolumeThreshold(1); config.andCommandPropertiesDefaults(properties); config.andThreadPoolPropertiesDefaults(HystrixThreadPoolProperties.Setter() .withMaxQueueSize(1) .withCoreSize(1) .withQueueSizeRejectionThreshold(1)); assertThat(this.invokeRemoteService(config, 10_000), equalTo(null)); assertThat(this.invokeRemoteService(config, 10_000), equalTo(null)); assertThat(this.invokeRemoteService(config, 10_000), equalTo(null)); Thread.sleep(5000); assertThat(new RemoteServiceTestCommand(config, new RemoteServiceTestSimulator(500)).execute(), equalTo("Success")); assertThat(new RemoteServiceTestCommand(config, new RemoteServiceTestSimulator(500)).execute(), equalTo("Success")); assertThat(new RemoteServiceTestCommand(config, new RemoteServiceTestSimulator(500)).execute(), equalTo("Success")); }
public String invokeRemoteService(HystrixCommand.Setter config, int timeout) throws InterruptedException { String response = null; try { response = new RemoteServiceTestCommand(config, new RemoteServiceTestSimulator(timeout)).execute(); } catch (HystrixRuntimeException ex) { System.out.println("ex = " + ex); } return response; }

In the above test we have set different circuit breaker properties. The most important ones are:

  • The CircuitBreakerSleepWindow which is set to 4,000 ms. This configures the circuit breaker window and defines the time interval after which the request to the remote service will be resumed
  • The CircuitBreakerRequestVolumeThreshold which is set to 1 and defines the minimum number of requests needed before the failure rate will be considered

With the above settings in place, our HystrixCommand will now trip open after two failed request. The third request will not even hit the remote service even though we have set the service delay to be 500 ms, Hystrix will short circuit and our method will return null as the response.

We will subsequently add a Thread.sleep(5000) in order to cross the limit of the sleep window that we have set. This will cause Hystrix to close the circuit and the subsequent requests will flow through successfully.

6. Conclusion

Zusammenfassend ist Hystrix entwickelt, um:

  1. Bieten Sie Schutz und Kontrolle über Fehler und Latenz von Diensten, auf die normalerweise über das Netzwerk zugegriffen wird
  2. Beenden Sie die Kaskadierung von Fehlern, die darauf zurückzuführen sind, dass einige Dienste nicht verfügbar sind
  3. Scheitern Sie schnell und erholen Sie sich schnell
  4. Wenn möglich anmutig abbauen
  5. Echtzeitüberwachung und Alarmierung der Kommandozentrale bei Fehlern

Im nächsten Beitrag werden wir sehen, wie Sie die Vorteile von Hystrix mit dem Spring-Framework kombinieren können.

Der vollständige Projektcode und alle Beispiele finden Sie im Github-Projekt.