Quel est le modèle de cloison utilisé par Hystrix?
Hystrix, une API Netflix pour la latence et la tolérance aux pannes dans les systèmes distribués complexes, utilise la technique Bulkhead Pattern pour l'isolation de threads. Quelqu'un peut-il s'il vous plaît élaborer.
Général
En général, l'objectif du modèle de cloison est d'éviter que des erreurs d'une partie du système ne mettent tout le système en panne. Le terme vient des navires où un navire est divisé en plusieurs compartiments étanches à l'eau pour éviter qu'une seule brèche dans la coque ne submerge tout le navire; il n'inondera qu'une cloison.
Les mises en œuvre du modèle de cloison peuvent prendre de nombreuses formes, en fonction du type de défaillance que vous souhaitez protéger. Je ne parlerai que du type de défaut traité par Hystrix dans cette réponse.
Je pense que le modèle de cloison a été popularisé par le livre Release It! de Michael T. Nygard.
Que résout Hystrix
L'implémentation de la cloison dans Hystrix limite le nombre d'appels simultanés à un composant. De cette façon, le nombre de ressources (généralement des threads) en attente d'une réponse du composant est limité.
Supposons que vous ayez une application multithread basée sur une requête (par exemple une application Web typique) qui utilise trois composants différents, A , B , et C . Si les demandes du composant C commencent à se bloquer, tous les threads de traitement des demandes devront attendre en attendant une réponse de C . Cela rendrait la demande totalement non conforme. Si les demandes à C sont traitées lentement, nous avons un problème similaire si la charge est suffisamment élevée.
L'implémentation du modèle de cloison par Hystrix limite le nombre d'appels simultanés à un composant et aurait enregistré l'application dans ce cas. Supposons que nous ayons 30 threads de traitement des demandes et qu'il y ait une limite de 10 appels simultanés à C . Ensuite, au plus 10 threads de traitement des demandes peuvent se bloquer lors de l'appel C , les 20 autres threads peuvent toujours gérer les requêtes et utiliser des composants A et B .
Les approches d'Hystrix
Hystrix 'utilise deux approches différentes pour la cloison, l'isolation du filetage et l'isolation du sémaphore.
Isolation du fil
L'approche standard consiste à transférer toutes les demandes au composant C à un pool de threads séparé avec un nombre fixe de threads et aucune (ou une petite) file d'attente de demandes.
Isolement de sémaphore
L'autre approche consiste à faire en sorte que tous les appelants obtiennent un permis (avec un délai d'attente égal à 0) avant les demandes adressées à C . Si un permis ne peut pas être acquis à partir du sémaphore, les appels à C ne sont pas transmis.
Différences
L’avantage de l’approche en pool de threads est que les demandes passées à C peuvent être temporisées, ce qui n’est pas possible avec l’utilisation de sémaphores.