RxJava & Hystrix - Perfect match for distributed applications

48
Czyli dwa pierwsze importy w architekturze rozproszonej RxJava & Hystrix Mateusz ‘Serafin’ Gajewski confitura 2015

Transcript of RxJava & Hystrix - Perfect match for distributed applications

Czyli dwa pierwsze importy w architekturze rozproszonej

RxJava & Hystrix

Mateusz ‘Serafin’ Gajewskiconfitura 2015

Kim jestem?

@wendigo

Solutions Architect obszarów:❖ Finansowego,❖ Płatnościowego,❖ Analityki danych

Główne zainteresowania:❖ Skalowalność,❖ Odporność na awarie,❖ Przetwarzanie danych,❖ Klastry obliczeniowe

Mateusz Gajewski

Agenda

❖ Rozproszone i reaktywne systemy,

❖ Jak ułatwić sobie życie narzędziami OSS,

❖ Kilka luźnych przemyśleń

Architektura rozproszona

Architektura rozproszona

Główne cechy:

❖ współbieżność komponentów,❖ niezależne awarie komponentów,❖ brak globalnego zegara

Czego oczekują użytkownicy?

Systemy reaktywne

❖ responsywność,❖ odporność na błędy,❖ elastyczność,❖ sterowanie zdarzeniami i wiadomościami

responsywność ~ górne ograniczenie na czas przetwarzania

potrzebne: optymalizacja i zrównoleglenie nieblokujących operacji

odporność ~ tolerancja na błędy i awarie

potrzebne: izolacja i obsługa

Platforma Allegro

❖ architektura master-master,

❖ 250+ mikrousług na JVM (kolejne w drodze),

❖ 4 prywatne AZ w 2 DC (4.500 VMs) + AWS,

❖ setki różnych technologii,

❖ dziesiątki niezależnych systemów storage’owych…

Co złego się może

wydarzyć?

Źródła opóźnień

❖ GC (JVM),❖ noisy neighbours (cloud),❖ stan sieci,❖ wolumen danych,❖ nieoptymalna implementacja,❖ obciążenie klastra...

Źródła awarii

❖ logika biznesowa,❖ implementacja techniczna,❖ problemy sieciowo-sprzętowe,❖ błąd operatora,❖ prawo Murphy’ego ;)

Smutna prawda:

spontaniczne awarie i wzrost czasów

odpowiedzi będą zdarzać się cały czas

Musimy nauczyć się niwelować ich efekty

używając odpowiednich narzędzi.

RxJava 1.0+ Hystrix 1.4+

&

RxJava

“Biblioteka do tworzenia asynchronicznych i opartych o

zdarzenia programów z wykorzystaniem obserwowalnych

sekwencji”

Programowanie reaktywne

Programowanie reaktywne

Observable<T>

onNext(T value)

onCompleted()

onError(Throwable t)

Observer API:

Observable<T> vs pozostałe typy

wartości skalarne sekwencje

sync T getData() Iterable<T> getData()

async Future<T> getData() Observable<T> getData()

Składanie operatorów

getDataFromNetwork() // Observable<T>

.skip(10)

.take(5)

.map(value -> value + " transformed")

.subscribe(value -> {

System.out.println("Received => " + value);

});

Jak nas to przybliża do responsywności i

odporności na błędy?

Cała magia leży w dostępnych operatorach

(100+) ;)

merge

źródło: http://reactivex.io

flatMap

źródło: http://reactivex.io

zipWith

źródło: http://reactivex.io

retry

źródło: http://reactivex.io

timeout

źródło: http://reactivex.io

onErrorResumeNext

źródło: http://reactivex.io

Zunifikowana obsługa błędów

a.zipWith(b, (x, y) -> x + " " + y)

.subscribe(

value -> { System.out.println("onNext(" + value + ")"); },

error -> { System.out.println("onError(" + error + ")"); },

() -> { System.out.println("onCompleted"); }

);

Reactive pull back-pressure

Operatory: onBackpressure*, sample, throttle,...

Przykład z warsztatów RX Allegro

client .getServices() // Observable<Service> .flatMap( service -> client .getInstances(service) // Observable<Instance> .onErrorResumeNext(Observable.<Instance>empty()) .timeout(500, TimeUnit.MILLISECONDS) .retry(3), 16) .subscribe(System.out::println);

RxJava - podsumowanie

❖ łatwe tworzenie kodu asynchronicznego,❖ zunifikowana obsługa błędów,❖ dostepność operatorów z zaawansowaną mechaniką (DRY),❖ wysoka wydajność (ring buffers FTW),❖ ukrywamy wewnętrzną implementację (sync vs async),❖ kontrola nad back-pressure,❖ testowalność kodu (wirtualny czas)

Hystrix

“Biblioteka zaprojektowana do kontroli opóźnień, zapewnienia

niezawodności oraz izolacji dostępu do zdalnych systemów. ”

Bezpiecznik

źródło: http://github.com/netflix/Hystrix

Hystrix(Observable)Command

Hystrix(Observable)Command =

logika biznesowa +logika statycznego fallbacku +

strategia izolacji +konfiguracja +

metryki

Strategia izolacji

Pozwala oddzielić od siebie, przerwać po przekroczeniu czasu i ograniczyć ilość równolegle wykonywanych komend:

❖ Oparta o pule wątków❖ Oparta o semafory

Etapy wykonywania

źródło: http://github.com/netflix/Hystrix

Izolacja

Izolujemy siebie od awarii zdalnego systemu

Chronimy zdalny system od “zalania” go żądaniami po odzyskaniu

sprawności

Co jeszcze fajnego?

❖ dynamiczna zmiana parametrów (Archaius),❖ strumień metryk (SSE),❖ dashboard (Turbine),❖ łatwe użycie za pomocą AOP,❖ batchowanie komend (Request Collapsing),❖ cache’owanie komend (Request Caching),❖ natywne wsparcie RxJava

RxJava + Hystrix = ❤

Wnioski

❖ programowanie asynchroniczne nie musi być trudne,

❖ domeny awarii mogą być ograniczone,❖ opóźnienia można kontrolować,❖ RxJava i Hystrix można wprowadzić w

każdym momencie życia projektu ;)

Pytania?

Dzięki!

Znajdziesz nas:Blog: allegrotech.io

Twitter: @allegrotechblog

pracuj z namikariera.allegro.pl