Est-ce une bonne pratique de renvoyer le serveur backend ip: port vers le client via l'équilibreur de charge

Question

Dans le cadre de mon apprentissage des systèmes distribués, je construis une application de chat. Actuellement, ma conception consiste à faire connaître à chaque serveur les clients auxquels ils sont connectés (c'est l'état qui sera répliqué à l'aide d'un algorithme de consensus).

Il existe un équilibreur de charge auquel le client se connecte initialement et l'équilibreur de charge répond avec le serveur auquel le client doit ensuite s'adresser. Les commandes suivantes du client vont directement à l'instance à laquelle il a été assigné. Pour gérer l'état, je pense utiliser Raft algorithm pour un consensus.

Answer 1

Je ne sais pas pourquoi vous implémenteriez un algorithme de consensus comme Raft ici. Traditionnellement RAFT est utilisé pour élire un leader. Ne semble pas avoir besoin de ça. Quelque chose comme:

client

> équilibreur de charge (haproxy)> pool de serveurs de chat

haproxy (équilibreur de charge) peut effectuer des contrôles de santé contre votre pool de serveurs. Si un serveur meurt, il sera supprimé d'un pool. Lorsqu'un serveur devient chaud/stressé, les vérifications de santé peuvent être supprimées du pool (les serveurs backend doivent afficher un statut 503 http via des contrôles de santé) Lorsque le trafic diminue, le serveur est de nouveau ajouté au pool. Vous pouvez alerter/surveiller le nombre de membres du pool de serveurs de discussion en bonne santé.

Gérer les erreurs côté client. Si une erreur est détectée, reconnectez-vous à l'équilibreur de charge et récupérez un nouveau serveur. Tous les états de conversation ne doivent pas être conservés sur l'instance de serveur de discussion éphémère, mais dans une sorte de magasin de données global comme Redis.

Cela vous permet d'être hautement évolutif. À l'échelle extrême, vous pourriez avoir des problèmes de stockage de données avec Redis, mais cela peut être atténué avec Redis Cluster ou en partageant vos discussions.