Risposte:
In generale, l'obiettivo del modello di paratia è quello di evitare guasti in una parte di un sistema per abbattere l'intero sistema. Il termine deriva dalle navi in cui una nave è divisa in compartimenti stagni separati per evitare che una singola breccia nello scafo allaghi l'intera nave; allagherà solo una paratia.
Le implementazioni del modello di paratia possono assumere molte forme a seconda del tipo di guasto da cui si desidera proteggere il sistema. In questa risposta discuterò solo il tipo di errori che Hystrix gestisce.
Penso che il motivo della paratia sia stato reso popolare dal libro Release It! di Michael T. Nygard.
L'implementazione della paratia in Hystrix limita il numero di chiamate simultanee a un componente . In questo modo, il numero di risorse (in genere thread) in attesa di una risposta dal componente è limitato.
Si supponga di avere una richiesta in base, l'applicazione filettato multi (ad esempio una tipica applicazione web) che utilizza tre componenti diverse, A , B , e C . Se le richieste al componente C iniziano a bloccarsi, alla fine tutti i thread di gestione delle richieste si bloccheranno in attesa di una risposta da C . Ciò renderebbe l'applicazione completamente non reattiva. Se le richieste a C vengono gestite lentamente, abbiamo un problema simile se il carico è sufficientemente alto.
L'implementazione di Hystrix del modello di paratia limita il numero di chiamate simultanee a un componente e in questo caso avrebbe salvato l'applicazione. Supponiamo di avere 30 fili richiesta movimentazione e c'è un limite di 10 chiamate simultanee C . Quindi al massimo 10 thread di gestione delle richieste possono bloccarsi quando si chiama C , gli altri 20 thread possono ancora gestire le richieste e utilizzare i componenti A e B .
Hystrix 'ha due diversi approcci alla paratia, all'isolamento del thread e all'isolamento del semaforo.
L'approccio standard consiste nel trasferire tutte le richieste al componente C a un pool di thread separato con un numero fisso di thread e nessuna coda di richieste (o una piccola).
L'altro approccio è quello di avere tutti i chiamanti acquisire un permesso (con 0 timeout) prima richieste a C . Se non è possibile acquisire un permesso dal semaforo, le chiamate a C non vengono passate.
Il vantaggio dell'approccio del pool di thread è che le richieste passate a C possono essere scadute, cosa che non è possibile quando si usano i semafori.
Ecco un buon esempio con la spiegazione del runtime per la paratia in Resilience4j che si ispira a Netflix Hystrix.
Le configurazioni di esempio di seguito potrebbero fornire una certa chiarezza di utilizzo.
Configurazioni di esempio: consente un massimo di 5 chiamate simultanee in qualsiasi momento. Tenere le altre chiamate in attesa fino al termine di una delle 5 chiamate simultanee in corso o fino a un massimo di 2 secondi.
L'idea è di non appesantire alcun sistema con un carico più di quanto possa consumare. Se il carico in entrata è maggiore del consumo, attendere un tempo ragionevole o semplicemente il timeout e passare al percorso alternativo.