Nous prenons souvent les cadres pour acquis. Hystrix avec l'annotation Javanica en est un. Cela peut sembler aussi simple qu'une commande @Hystrix sur une méthode et peut facilement dégénérer en un problème complexe de performances ou d'épuisement des ressources.
Passons en revue les divers comportements d'Hystrix, tels que:
- Le circuit est ouvert
- est fermé
- Le nombre de sémaphores de secours atteint
- Expiration du délai d'attente Hystrix avant expiration du délai de lecture du socket
- Comportement du sémaphore et du pool de threads lorsque le délai d'expiration de Hystrix est dépassé
- L'appel à la commande Hystrix situé sous @HystrixCommand. Ici, vous pouvez choisir Sémaphore ou pool de threads, notez qu'il existe une différence de comportement dont nous parlerons plus tard.
- La programmation orientée aspect (Spring AOP) recherche l'annotation et exécute un ensemble de métriques relatives à Hystrix. Cela inclut de vérifier si le circuit est ouvert.
- Si le circuit est ouvert:
- Vérifiez si le décompte du pool de threads / sémaphores du repli est atteint (11)
- S'il est atteint, lève une exception sur l'impossibilité d'exécuter la méthode de repli
- Si tout est correct, la commande de repli est exécutée .
- La propriété fallback.isolation.semaphore.maxConcurrentRequests est utilisée pour définir le nombre d'exécution de repli.
- Les propriétés de requêtes simultanées de repli doivent être spécifiées, de préférence égales à la taille du nombre de sémaphores du pool de threads. 19659016] Si le circuit est fermé:
- Si le thread est disponible pour exécuter la commande hystrix, récupérez-le pour l'exécuter.
- Si la taille maximale du pool de threads est atteinte, lève une exception contenant les messages liés à la taille du thread actuellement utilisée et à la taille maximale. du pool de threads.
- Suivez ensuite le même flux puisqu'un circuit est ouvert par étapes.
- Si le circuit est fermé et qu'un thread est disponible pour exécuter la commande:
- Vérifiez si le pool de connexions HTTP a un thread pour exécuter notre appel d'échange REST.
- Si disponible, établissez une connexion dans CONNECITON_TIMEOUT. S'il est impossible de créer une connexion, émettez une exception et passez au repli.
- Si la connexion est établie, exécutez l'appel en attente et attendez la réponse SOCKET_TIMEOUT ou complète. (10)
- Notez que le délai d'attente de la socket est le temps qui s'écoule entre chaque paquet sur le réseau filaire et non la durée totale de l'appel http.
- Désormais, dans un scénario où le thread http attend la lecture du socket, il est possible que le délai d’hystrix soit dépassé. Dans ce cas :
- Hystrix démarre un thread de minuterie pour exécuter la commande de repli. Ce fil spécial ne contient pas les données ThreadContext et est nouveau. Donc, si vous utilisez le contexte du thread log4j, attendez-vous à des incohérences dans votre journalisation. (8)
- Si vous utilisez threadpool, le point d'exécution passe au repli et est renvoyé immédiatement au client.
- Mais si vous utilisez un sémaphore, il ne sera pas renvoyé au client. immédiatement!! Il faudra attendre jusqu'à ce que la lecture de la socket http soit terminée, puis revenir au client à partir de la méthode de repli.
Pool de threads vs Semaphore sur ce comportement:
Voici un schéma simplifié. Le comportement expliqué ci-dessus soulève une question! Si nous avons un nombre de pools de threads de 4 et un nombre de sémaphores de 4. Cela nous donne une meilleure isolation en termes de pool de threads http consommé.
Dans un scénario de pool de threads, le nombre maximal de threads http pouvant être utilisé La valeur obtenue est 4. Comme toute demande, le temps pendant lequel les 4 threads sont utilisés entraînera une exécution de secours.
En effet, le nombre de pools de threads hystrix reste à 4 et les threads hystrix ne sont pas libérés avant que les threads http ne soient utilisés. ont fini leur travail. Ainsi, si vous avez une taille de pool de threads hystrix de 1 et une taille de pool HTTP de 10, après votre première demande, toutes les requêtes passent en exécution de secours jusqu'à ce que le premier thread http termine son travail, quel que soit le délai d'expiration hystrix.
En cas de sémaphore, tant que le thread est en attente de lecture du socket, le délai d'attente hystrix entraîne le déplacement de l'exécution dans un thread du minuteur. Mais en même temps, il met également à jour le nombre de sémaphores. Cela pourrait être un problème potentiel car la prochaine requête finirait par exécuter la commande hystrix dans un autre thread, même si un thread attend la lecture du socket.