Websockets dans l'architecture de microservices
Supposons que nous ayons un service de notification qui lit un événement dans la file de messages et informe tous les clients Web en temps réel. Je sais comment fonctionne le socket Web, mais je suis perplexe face à la présence d'une passerelle API entre la façon dont la connexion de socket Web est maintenue entre le client, la passerelle API et le service de notification.
S'il vous plaît aider! Merci
Edition: Architecture: 
Vous ne devriez pas mélanger les concepts. Une passerelle API masque votre infrastructure à votre client. Il peut s'agir d'une interface unique pour de nombreux services, dans le sens de "Backends for frontends". Il peut également être responsable de nombreuses autres choses, telles que l'authentification.
Un serveur de socket Web peut être installé en parallèle de votre passerelle API. Un autre domaine ou un autre port. Supposons que vous utilisiez un serveur de socket Web tel que http://nchan.io . Les événements de votre application sont transmis à votre courtier de messages ou à tout modèle d'intégration de messagerie que vous utilisez. Un consommateur peut récupérer ces événements et les publier via le serveur Nchan. Les clients (par exemple, les navigateurs) se connectent au serveur Nchan et seront informés des événements.
Websockets
Une connexion websocket ouverte par un client doit éventuellement se connecter à un serveur websocket.
Passerelle API
Le travail de la passerelle d’API consiste à accepter une connexion Websocket entrante d’un client et à l’acheminer correctement vers un serveur Websocket. Une passerelle d’API redirige TOUTES les données envoyées par un client Websocket vers le bon service d’arrière-plan et maintient la connexion tout le temps.
Comment tout fonctionne ensemble ...
La racine de votre question est "comment un client avec une connexion websocket peut-il recevoir une mise à jour en direct du service de notification?". La réponse la plus simple serait de démarrer un serveur websocket sur le service de notification, de laisser chaque client se connecter à la passerelle API, puis de laisser la passerelle API acheminer ce trafic vers le service de notification.
- Client <=> API Gateway <=> Notification Service
Prenant plus loin ...
Si les clients exigent en outre de transformer les données provenant du service de notification, vous pouvez:
- Insérez cette logique métier dans le service de notification (non recommandé).
- Ou bien, ajoutez un autre service avec la logique de transformation entre la passerelle API et le service de notification, appelé modèle de conception backends for frontends microservice (recommandé):
- Client <=> API Gateway <=> Notification Server (logique de transformation) <=> Notification Service.
- Ou, si la passerelle d'API de votre choix est conçue pour contenir la logique métier et transformer les données; placez la logique de transformation directement dans la passerelle API.