ThreeMammals/Ocelot

How to avoid calling down service in load balancer option

Open

#1 041 ouverte le 17 oct. 2019

Voir sur GitHub
 (14 commentaires) (0 réactions) (0 assignés)C# (1 617 forks)batch import
Health CheckLoad BalancerQoSacceptedbughelp wantedhighmedium effort

Métriques du dépôt

Stars
 (8 137 stars)
Métriques de merge PR
 (Merge moyen 10j 13h) (4 PRs mergées en 30 j)

Description

Expected Behavior / New Feature

Load balancer should able to recognize the down service and stop calling service or up the service.

Actual Behavior / Motivation for New Feature

Load balancer is calling the service although the service is down and returning 500 internal server on every call.

Steps to Reproduce the Problem

  1. Created two instance of the same module and run on different port.
  2. Added load balance option for those two service instance of type RoundRobin.
  3. Kill the second service and now Ocelot still redirect to down service.

Specifications

  • Version: 13.5.2
  • Platform: Windows 10
  • Subsystem:

Guide contributeur

Direction de recherche
Cette demande de fonctionnalité demande à la passerelle API Ocelot d'éviter de router vers un service indisponible. La solution implique probablement la mise en œuvre de contrôles de santé qui sondent périodiquement les backends et mettent à jour l'état du répartiteur de charge. Commencez par examiner l'implémentation existante du répartiteur de charge dans Ocelot, en particulier la classe RoundRobin et comment elle sélectionne les services en aval. Ensuite, examinez tout middleware de contrôle de santé existant ou discutez avec les mainteneurs dans le fil de l'issue pour clarifier la conception souhaitée (par exemple, contrôles de santé passifs vs actifs). Fichiers suggérés à étudier : src/Ocelot/LoadBalancer/LoadBalancers/ et les tests associés.
Stack technique
csharp
Domaine
backendapiperformance
Type d'issue
Fonctionnalité
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
Une demi journée
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
En attente d'un mainteneur
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Investigation requise
Prérequis
C#load balancing concepts
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
30