En parlant de Circuit Breaking de Springcloud me rappelle la rupture du circuit en bourse l'année dernière. J'ai réalisé de nombreux moments douloureux. L'impact de la rupture de circuits aléatoires sur l'ensemble du système est désastreux. Eh bien, parlons ensuite des questions sérieuses.
Fusible
Effet d'avalanche
Dans les architectures de microservice, il y a généralement plusieurs couches de service à appeler. La défaillance du service sous-jacent peut entraîner des défaillances en cascade, ce qui à son tour ne fait pas que l'ensemble du système ne soit pas disponible. Ce phénomène est appelé l'effet d'avalanche de service. L'effet d'avalanche de service est un processus dans lequel l'indisponibilité du «fournisseur de services» conduit à l'indisponibilité des «consommateurs de services» et amplifie progressivement l'indisponibilité.
Si la figure ci-dessous montre: A est le fournisseur de services, B est le consommateur de services de A, et C et D sont les consommateurs de services de B. L'indisponibilité d'une indisponibilité de B et lorsque l'indisponibilité est agrandie à C et D comme une boule de neige, l'effet d'avalanche est formé.
Brise-circuit
Le principe d'un fusible est très simple, comme un protecteur de surcharge de puissance. Il peut atteindre une défaillance rapide. S'il détecte de nombreuses erreurs similaires sur une période de temps, il obligera ses appels ultérieurs à échouer rapidement et à ne plus accéder au serveur distant, empêchant ainsi l'application d'essayer constamment d'effectuer des opérations de défaillance possibles, ce qui fait que l'application continue de s'exécuter sans attendre la correction de l'erreur ou de perdre le temps du CPU à attendre jusqu'à un long délai. Le fusible peut également permettre à l'application de diagnostiquer si l'erreur a été corrigée et si elle a été corrigée, l'application essaiera d'appeler l'opération.
Le mode fusible est comme un proxy qui peut facilement conduire à de mauvaises opérations. Ce proxy peut enregistrer le nombre d'erreurs qui se sont produites dans l'appel le plus récent, puis décider d'utiliser l'opération d'autorisation pour continuer ou de renvoyer l'erreur immédiatement.
La logique de la conversion mutuelle des commutateurs de fusible est la suivante:
Les fusibles sont la dernière ligne de défense pour protéger la haute disponibilité des services.
Fonctions Hystrix
1. Mécanisme de disjoncteur
Le disjoncteur est facile à comprendre. Lorsque la commande Hystrix demande des défaillances de service arrière dépasse une certaine proportion (par défaut de 50%), le disjoncteur de circuit passera à l'état ouvert (ouvert). Pour le moment, toutes les demandes échoueront directement sans envoyer au service back-end. Une fois le disjoncteur de circuit à l'état ouvert pendant une période de temps (par défaut 5 secondes), il passera automatiquement à l'état de demi-ouvert (demi-ouvert). À l'heure actuelle, le statut de retour de la prochaine demande sera jugé. Si la demande réussit, le disjoncteur reviendra à l'état du circuit fermé (fermé), sinon il passera à l'état ouvert (ouvert). Le disjoncteur de Hystrix est comme un fusible dans notre circuit d'origine. Une fois que le service back-end n'est pas disponible, le disjoncteur coupera directement le lien de demande pour éviter d'envoyer un grand nombre de demandes non valides pour affecter le débit du système. Le disjoncteur a la capacité de se détecter et de récupérer.
2.Balon-arrière
Le repli est équivalent à une opération de rétrogradation. Pour les opérations de requête, nous pouvons implémenter une méthode de secours. Lorsqu'une exception se produit dans un service de retour demandé, la valeur renvoyée par la méthode de secours peut être utilisée. La valeur de retour de la méthode de secours est généralement définie par la valeur par défaut ou provient du cache.
3. Isolement des ressources
Dans Hystrix, l'isolement des ressources est principalement réalisé via des pools de fil. Habituellement, lorsque nous l'utilisons, nous divisons plusieurs pools de threads en fonction du service distant que nous appelons. Par exemple, la commande qui appelle les services produit est placée dans un pool de threads, et la commande qui appelle les services de compte est placée dans le pool de threads B. Le principal avantage de cela est que l'environnement de course est isolé. De cette façon, même si le code qui appelle le service est bogué ou le pool de threads qui est consommé pour d'autres raisons, il n'affectera pas les autres services du système. Cependant, le coût est que le maintien de plusieurs pools de threads apportera des frais généraux de performances supplémentaires au système. Si vous avez des exigences de performances strictes et que vous êtes sûr qu'il n'y aura aucun problème avec le code client qui appelle le service, vous pouvez utiliser le mode signal de Hystrix (sémaphores) pour isoler les ressources.
Feigner Hystrix
Étant donné que le disjoncteur de circuit ne fonctionne que sur l'extrémité de l'appel de service, nous devons seulement modifier le code pertinent du projet Spring-Cloud-Consumer en fonction de l'exemple de code de l'article précédent. Étant donné que Feign dépend déjà de Hystrix, il n'est pas nécessaire d'apporter des modifications à la configuration Maven.
1. Fichier de configuration
Ajoutez ceci à Application.Properties:
feign.hystrix.enabled = true
2. Créez une classe de rappel
Créer l'héritage de la classe HelloreMoteHystrix et Helloremote pour implémenter des rappels
@ComponentPublic classe HelloreMoteHystrix implémente helloMote {@Override public String hello (@RequestParam (value = "name") String name) {return "hello" + name + ", ce message envoie l'échec"; }}3. Ajouter l'attribut de secours
Ajoutez la classe de secours spécifiée à la classe HelloreMote et renvoyez le contenu dans la classe de secours lorsque le service est circuit.
@FeignClient (name = "Spring-Cloud-Producer", Fallback = HelloreMoteHystrix.Class) Interface publique HelloMote {@RequestMapping (Value = "/ Hello") String public Hello (@RequestParam (value = "name") String Name);}C'est le point de changement, c'est très simple.
4. Test
Ensuite, le testons pour voir l'effet.
Commencez les trois projets Spring-Cloud-Eureka, Spring-Cloud-Producer et Spring-Cloud-Consumer.
Entrez dans le navigateur: http: // localhost: 9001 / Hello / neo
Retour: Bonjour Neo, c'est le premier message
Cela signifie qu'après avoir ajouté des informations liées au disjoncteur, cela n'affectera pas l'accès normal. Ensuite, nous arrêtons manuellement le projet Spring-Cloud-Producer et le testons à nouveau:
Entrez dans le navigateur: http: // localhost: 9001 / Hello / neo
Retour: Bonjour Neo, cet envoi de message a échoué
Selon le résultat du retour, le disjoncteur a été indiqué avec succès.
Exemple de code
Ce qui précède est tout le contenu de cet article. J'espère que cela sera utile à l'apprentissage de tous et j'espère que tout le monde soutiendra davantage Wulin.com.