Pour les microservices, le modèle de conception couramment utilisé est API-Gateway. Je suis un peu confus quant à sa mise en œuvre et ses implications. Mes questions / préoccupations sont les suivantes:
D'après ce que je comprends, dans un environnement idéal, un serveur de passerelle traiterait les demandes des clients et répondrait après que les microservices aient effectué la tâche due.
De plus, je recherchais Spring Cloud Gateway. Cela semble être quelque chose que je recherche dans un serveur de passerelle, mais la fonctionnalité de routage de celui-ci me déroute s'il ne s'agit que d'un service de routage (redirection) et que le microservice serait directement responsable de la réponse au client.
3 Réponses :
Le modèle de passerelle est utilisé pour fournir une interface unique à un ensemble de microservices différents. Si vous disposez de plusieurs microservices fournissant des données pour votre API, vous ne souhaitez pas les exposer à vos clients. Bien mieux pour eux d'avoir un seul point d'entrée, sans avoir à penser à quel service interroger quelles données. C'est aussi bien de pouvoir centraliser les traitements courants tels que l'authentification. Comme tout modèle de conception, il peut être très bien appliqué à certaines solutions et ne fonctionne pas bien pour d'autres.
Si le débit devient un problème, la passerelle est très évolutive. Vous pouvez simplement ajouter d'autres passerelles et les équilibrer la charge
Il existe des différences subtiles entre le modèle de proxy et le modèle de passerelle API. Je recommande cet article pour une explication assez simple https://blog.akana.com/api-proxy-or-gateway/ < / a>
Dans le domaine des microservices, l'API-Gateway est un modèle éprouvé. Il présente plusieurs avantages par exemple:
Implémenter toutes ces fonctionnalités dans un proxy n'est pas anodin. Il existe quelques passerelles API qui fournissent toutes ces fonctionnalités et plus comme Netflix-Zuul, Spring-Gateway ou Akana Gateway.
De plus, pour éviter que votre API-Gateway ne soit un goulot d'étranglement, vous pouvez:
1.Pourquoi les autres modèles de microservices ne sont généralement pas abordés? S'ils le sont, les ai-je manqués? Il existe de nombreux modèles de microservices dans différentes catégories telles que base de données, service, etc.C'est un très bon article https: / /microservices.io/patterns/index.html
2.Si nous déployons un serveur de passerelle, n'est-ce pas un goulot d'étranglement?
Oui dans une certaine mesure. L'image des réponses de Q3 répondra à cela.
3.Le serveur de passerelle n'est-il pas vulnérable aux pannes / pannes dues à des requêtes excessives en un seul point? Je pense que la charge serait énorme à ce stade (et en gardant à l'esprit que Netflix fait quelque chose comme ça). Corrigez-moi si je ne comprends pas bien.
Les données 4.Stream/download/upload (comme des fichiers, des vidéos, des images) passeront également par le serveur de passerelle avec d'autres services middleware? Pourquoi ne pouvons-nous pas utiliser le modèle de proxy au lieu de Gateway?
Le cas d'utilisation d'un proxy API par rapport à une passerelle API dépend des types de fonctionnalités dont vous avez besoin et de votre position dans le cycle de vie de l'API. Si vous disposez déjà d'une API existante qui ne nécessite pas les fonctionnalités avancées qu'une passerelle API peut offrir, un proxy d'API serait une route recommandée.
Vous pouvez économiser une bande passante d'ingénierie précieuse car les proxys sont beaucoup plus faciles à gérer et vous ne subirez aucune perte de performances négligeable. Si vous avez besoin de fonctionnalités spécifiques qu’un proxy n’offre pas, vous pouvez également développer une couche interne pour répondre à votre cas d’utilisation. Si vous êtes plus tôt dans le cycle de vie de l'API ou si vous avez besoin des fonctionnalités supplémentaires qu'une passerelle API peut fournir, investir dans l'une d'elle rapporterait des dividendes.
Une passerelle API est aussi un mec proxy
«API-Gateway» est un terme si général. Même un proxy est une sorte de passerelle.