Blog

Hystrix in der E-Commerce-Plattform Hybris nutzen

Hystrix in der SAP Commerce Cloud nutzen

Was ist Hystrix?

 

Hystrix ist vereinfacht gesagt eine Circuit Breaker Library, die im Microservices Umfeld zum Einsatz kommt. Sie wird von Netflix entwickelt und steht seit 2012 als OpenSource zur Verfügung. Die offizielle Beschreibung zeigt sehr gut, wo Hystrix zum Einsatz kommt und was es zu leisten vermag:

„Hystrix is a latency and fault tolerance library designed to isolate points of access to remote systems, services and 3rd party libraries, stop cascading failure and enable resilience in complex distributed systems where failure is inevitable.“

 

 

Was hat nun Hystrix mit einer E-Commerce-Plattform, speziell mit der SAP Commerce Cloud (früher bekannt als Hybris) zu tun?

 

Nun, moderne E-Commerce-Plattformen sind faktisch „complex distributed systems“. Sofern der Dienstleister einen guten Job gemacht hat, fühlt sich die Plattform an wie aus einem Guss. Unter der Haube arbeitet jedoch eine beliebige Anzahl an Systemen zusammen:

 

  • ein PIM-System, das die Produktinformationen zuliefert
  • ein ERP-System, das die Preise zuliefert, Bestellungen bearbeitet usw.
  • ein CRM-System für die Kundenstammdaten
  • eine Produktsuche
  • eine Contentsuche
  • ein Recommendation-Engine
  • ein System für Kundenbewertungen
  • mehrere Payment-Provider
  • ein Tracking- und Analytics-System
  • ein Social-Media-System
  • ein System zur Adressprüfung und Frauddetection

 

Das ist nur eine unvollständige Auswahl an Systemen, die sich fast beliebig erweitern lässt. Viele davon sind als „remote systems“ in die Plattform eingebunden. Nur wenn alle Systeme verfügbar sind und miteinander interagieren, kann die E-Commerce-Plattform ihre vollständige Funktionalität zur Verfügung stellen. Die Verfügbarkeit der Plattform ist also direkt abhängig von der Verfügbarkeit aller Teilsysteme.

 

Ein Beispiel:

Angenommen, die E-Commerce-Plattform besteht aus 30 Teilsystemen mit einer jeweils garantierten Verfügbarkeit von 99.99%. Dann bedeutet das für das Gesamtsystem eine Verfügbarkeit von 99.99^30 = 99.7%. Das heißt von 1.000.000 Requests laufen 3.000 Requests auf Grund der Nichtverfügbarkeit eines Systems auf Fehler.

Oder anders betrachtet, mehr als 2 Stunden Ausfall pro Monat. Und Sie haben eine Idee, was Sie investieren müssen, so dass ein System eine Verfügbarkeit von 99,99% garantieren kann.

 

Genug der Schwarzmalerei: Verteilte Systeme haben viele Vorteile

 

Stellen Sie sich nur kurz vor, Sie müssten ein System erschaffen, warten und betreiben, welches all die oben genannten Systeme und Funktionalitäten vereinigt. Die Erkenntnis muss also sein, dass die E-Commerce-Plattform für Ausfälle der Teilsysteme gerüstet sein muss. Und hier kommt Hystrix ins Spiel. Ursprünglich zwar für Microservices entwickelt, lässt es sich doch auch in klassische Commerce-Systeme gut integrieren.

 

Die Library selbst kann über die external-dependencies.xml als Maven-Dependency eingebunden werden:

<dependency>

<groupId>com.netflix.hystrix</groupId>

<artifactId>hystrix-core</artifactId>

<version>x.y.z</version>

</dependency>

Alternativ können auch die JARs direkt ins lib Verzeichnis der entsprechenden Extension kopiert werden.

 

Als nächster Schritt kann ein erster Remote-Aufruf in ein HystrixCommand verpackt werden:

public class CommandHelloWorld extends HystrixCommand<String> {

 

private final String name;

 

public CommandHelloWorld(String name) {

super(HystrixCommandGroupKey.Factory.asKey(„ExampleGroup“));

this.name = name;

}

 

@Override

protected String run() {

// a real example would do work like a network call here

return „Hello “ + name + „!“;

}

}

Dieses CommandHelloWorld kann nun innerhalb der DAO mittels „String s = new CommandHelloWorld(„Bob“).execute();“ benutzt werden.

 

Zwei wichtige Hinweise:

 

1. Innerhalb eines Commands stehen keine JaloSession und kein Tenant zur Verfügung, da der Standard Isolation Mode „Thread“ ist.

2. Falls Sie das Command über Spring managen, dann muss es prototype Scope sein!

 

Soweit die einfachste Integration, welche die E-Commerce-Plattform vor langsamen oder nicht verfügbaren Remote-Systemen schützt.

Ein zweiter wichtiger Mechanismus ist der Fallback. Sie können diesen implementieren, indem Sie die Methode „protected String getFallback()“ überschreiben.

Wann immer Sie eine Möglichkeit für einen sinnvollen Fallback haben: Nutzen Sie ihn!

Angenommen Ihre Produkt- und Kategorienavigation funktioniert über die Produktsuche, dann ist Ihre Plattform direkt abhängig von der Verfügbarkeit der Produktsuche. Ist diese nicht verfügbar kann kein Kunde die Webseite sinnvoll benutzen. Aber Sie können über den Fallback-Mechanismus z.B. einen datenbankbasierten Ersatz schaffen. Dieser wird nicht so ausgefeilt sein mit Facetten usw. aber bei weitem besser als wenn der Kunde beim Mitbewerber kauft.

 

Hystrix selbst verfügt über wesentlich mehr Funktionalität als „nur“ den Circuit Breaker mit Fallback. Für Details hierzu verweise ich auf die Github-Seite.

 

Für eine tiefe Integration in SAP Commerce Cloud (und das sollten Sie meiner Meinung nach anstreben) sind ein paar potentielle Fallstricke zu beachten:

  • Hystrix nutzt Archaius als Konfigurationsframework – SAP Commerce Cloud dagegen Apache Configuration
  • Hystrix nutzt Eureka als Cluster Discovery – SAP Commerce Cloud hat seinen eigenen Cluster Mechanismus
  • Der Programmierstil von Hystrix ist sehr anders als man das im SAP Commerce Cloud-Umfeld gewohnt ist. Nicht besser oder schlechter, nur anders.

 

Eine ausgiebige Erklärung des Setups und Quellcodes würde diesen Blog-Artikel sprengen. Falls Sie nähere Informationen wünschen, kontaktieren Sie mich gerne via E-Mail oder über die Kommentarfunktion.

 

Ein paar Tipps und Erkenntnisse aus meinen Projekten:

 

  • Default-Settings wie Timeouts und Metrics passen für Microservices sehr gut. Hier muss man höchstwahrscheinlich nachjustieren
  • Netzwerk-Timeouts sollten Sie weiterhin in der Remote-Connection setzen. Ansonsten terminiert zwar das Command rechtzeitig, die z.B. REST-Verbindung bleibt jedoch länger offen.
  • Nutzen Sie ein eigenes Command für jeden Request Typ; nutzen Sie einen Thread-Pool pro Remote System. Beispiel: SAP stellt drei Services bereit => drei Commands mit dem gleichen Thread Pool
  • Nutzen Sie Hystrix für jedes Remote-System. Netflix selbst schickt teilweise sogar Datenbankqueries durch Hystrix
  • Es muss nicht zwingend Hystrix sein. Es gibt auch andere Frameworks wie z.B. https://github.com/jhalterman/failsafe


Keine Kommentare

Hinterlassen Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.