API Gateway vs Load Balancer

Avec le développement de la technologie Internet, le nombre de demandes de données réseau a considérablement augmenté, ce qui exerce une pression accrue sur les serveurs. Dans l'architecture système des débuts, un équilibreur de charge était généralement utilisé pour répartir le trafic réseau sur plusieurs serveurs, réduisant ainsi la charge sur un seul serveur.

Cependant, de nos jours, de nombreux types de services backend exposent des API à l'extérieur, ce qui entraîne une augmentation du nombre d'API. Par conséquent, les limites de l'architecture système reposant principalement sur des équilibreurs de charge sont devenues évidentes, car ils opèrent principalement au niveau 4 et ont des fonctionnalités limitées au niveau 7. Cela a conduit à l'émergence d'une infrastructure appelée API Gateway, qui fonctionne principalement au niveau 7 et offre des capacités d'extension étendues.

Dans cet article, nous présenterons les caractéristiques distinctes des équilibreurs de charge et des API Gateway, et explorerons leurs différences pour aider les lecteurs à mieux comprendre leur relation.

Qu'est-ce qu'un équilibreur de charge ?

Le rôle principal d'un équilibreur de charge est de fournir une fonctionnalité d'équilibrage de charge pour plusieurs services backend, permettant de répartir le trafic en fonction de différents algorithmes d'équilibrage de charge. L'histoire des équilibreurs de charge est vaste et peut être grossièrement catégorisée en plusieurs étapes :

• Première étape : Les équilibreurs de charge de cette étape sont généralement composés de matériels, qui offrent une haute performance et une grande fiabilité, mais sont peu flexibles et coûteux.

• Deuxième étape : Les équilibreurs de charge ont commencé à être implémentés en logiciel, plus flexibles et évolutifs, apparaissant souvent dans des distributions logicielles et donc moins coûteux. LVS (Linux Virtual Server) en est un exemple.

• Troisième étape : Avec l'essor de la technologie cloud, les équilibreurs de charge ont également commencé à avoir des versions cloud. Un avantage significatif de ces équilibreurs de charge est qu'ils permettent aux entreprises d'obtenir des services d'équilibrage de charge haute performance à moindre coût. Un autre avantage est qu'ils peuvent tirer parti de l'évolutivité et de l'élasticité du cloud pour améliorer la disponibilité globale. Les exemples d'équilibreurs de charge cloud incluent le Classic Load Balancer, l'Application Load Balancer et le Network Load Balancer d'AWS.

En plus de répartir le trafic et d'améliorer l'évolutivité du réseau, les équilibreurs de charge peuvent également être utilisés pour renforcer la sécurité du réseau. Par exemple, ils peuvent être utilisés pour isoler les serveurs internes de l'internet public, empêchant les attaques malveillantes et les accès non autorisés. Un cas d'utilisation simple est un serveur interne contenant des informations sensibles, qu'un équilibreur de charge peut isoler au sein du réseau interne pour protéger efficacement sa sécurité.

Qu'est-ce qu'un API Gateway ?

À court terme, un API Gateway est une infrastructure qui gère et transmet le trafic API, fonctionnant principalement au niveau 7. Il offre une robuste extensibilité que les équilibreurs de charge n'ont pas, incluant l'authentification, l'observabilité, et des plugins personnalisés. Certaines de ses caractéristiques clés sont :

• Stratégies de routage riches : Comme l'API Gateway fonctionne au niveau 7, il peut analyser les données au niveau HTTP/HTTPS. Ainsi, il peut diriger les requêtes vers divers serveurs upstream en fonction de conditions comme le chemin de la requête, le domaine ou l'en-tête.

• Authentification : L'API Gateway prend en charge plusieurs méthodes d'authentification au niveau de l'API pour empêcher les requêtes non autorisées, comme OAuth2 et JWT. L'authentification peut être séparée de la logique métier et maintenue indépendante pour être non intrusive ou peu intrusive dans le code métier.

• Limitation de débit : Une limitation de débit fine peut être appliquée à différents niveaux de routage pour empêcher les attaques malveillantes et éviter la surcharge des services backend.

• Observabilité : L'observabilité fait référence à la capacité d'observer l'état de fonctionnement et l'utilisation des ressources du programme interne depuis l'extérieur du système. L'API Gateway prend en charge la liaison des logs à Kafka, Google Cloud Logging Service, Elasticsearch, etc., et la liaison des métriques pertinentes à prometheus, datadog, etc.

• Extension : Comme l'API Gateway lui-même est une passerelle, il est conçu pour s'adapter à différents scénarios d'application de différentes entreprises, comme différentes authentifications d'identité, déploiement canari, politiques de sécurité, et collecte de logs. De plus, l'API Gateway doit permettre aux utilisateurs de sélectionner des extensions ou de réaliser des développements personnalisés ; par conséquent, l'extensibilité est forte, et la sélection des extensions disponibles est assez variée. Par exemple, Apache APISIX dispose de 13 extensions d'authentification différentes, couvrant presque tous les besoins d'authentification courants sur le marché.

Actuellement, il existe de nombreux API Gateway disponibles sur le marché, comme Apache APISIX, Kong, Tyk, Zuul, etc. Les développeurs peuvent sélectionner l'API Gateway le plus approprié selon leurs besoins spécifiques.

Principales différences entre API Gateway et équilibreur de charge

Domaines de concentration distincts

Bien que l'API Gateway et l'équilibreur de charge prennent en charge les proxies de niveau 4 et 7, l'API Gateway se concentre principalement sur le niveau 7 tandis que l'équilibreur de charge se concentre principalement sur le niveau 4.

Par conséquent, l'équilibreur de charge, fonctionnant au niveau 4, possède de nombreuses caractéristiques avantageuses. Premièrement, il réduit la surcharge d'analyse de protocole par rapport à l'API Gateway, ce qui se traduit par une capacité de débit plus élevée. Deuxièmement, il prend en charge le transfert transparent de l'adresse IP du client, alors que l'API Gateway transmet généralement les adresses IP des clients via les en-têtes HTTP.

Richesse des fonctionnalités

Par exemple, les équilibreurs de charge ont des capacités de traitement HTTP niveau 7 plus faibles et manquent souvent de fonctionnalités telles que l'authentification, l'autorisation, la logique de routage complexe et la collecte de logs. Alors que les API Gateway ont des capacités de traitement de protocole niveau 7 plus fortes et peuvent attacher diverses extensions de fonctionnalités telles que le contrôle d'accès, la journalisation, la gestion d'API et le calcul serverless.

Développement personnalisé

Dans le marché technologique en évolution rapide d'aujourd'hui, de nombreuses entreprises nécessitent la capacité de prendre en charge le développement personnalisé. Les API Gateway offrent diverses options de développement personnalisé, comme le support de différents langages de programmation et la capacité d'injecter une logique de traitement personnalisée à différentes étapes du transfert de trafic. D'un autre côté, les équilibreurs de charge n'offrent aucune option de développement personnalisé.

Méthodes de distribution du trafic

Les équilibreurs de charge utilisent généralement la distribution directe du trafic pour réaliser l'équilibrage de charge. Via des algorithmes, les données de trafic sont envoyées directement à des nœuds de serveur backend spécifiques, ce qui signifie que chaque instance de service attendant de recevoir du trafic doit se comporter de manière cohérente, réduisant ainsi une certaine flexibilité. En revanche, les API Gateway distribuent le trafic en fonction de différentes dimensions telles que URL Path, Domain, et Header. Par conséquent, les instances de service attendant de recevoir du trafic peuvent varier, comme une API privée ou une API GRPC, rendant la distribution du trafic très flexible.

Cas d'utilisation

Cas d'utilisation des microservices

Pour les systèmes d'architecture microservices, un API Gateway est essentiel. Premièrement, il peut facilement gérer et router divers services backend. Deuxièmement, un API Gateway pourrait fournir de nombreuses fonctionnalités avancées telles que l'authentification, l'autorisation, la limitation de débit, le transfert et la journalisation. Par conséquent, les différents microservices n'ont plus besoin de réimplémenter des fonctions telles que la limitation de débit et l'authentification, rendant la mise en œuvre des fonctions de chaque microservice plus ciblée et réduisant les coûts de développement.

L'architecture Microservices implique de nombreux services, rendant les équilibreurs de charge niveau 4 inadaptés pour l'équilibrage de charge de plusieurs services backend. Au lieu de cela, ils sont plus adaptés pour être utilisés avec des services backend monolithiques. Par ailleurs, les équilibreurs de charge niveau 7 ne peuvent généralement pas offrir de fonctionnalités avancées, ce qui rend leurs avantages par rapport aux API Gateway dans les microservices moins significatifs.

Gestion et déploiement d'API

L'API Gateway est également très adapté dans les scénarios où il est nécessaire de gérer et de déployer un grand nombre d'API, car il possède de puissantes capacités de gestion d'API. Dans ce cas, vous pourriez facilement activer ou désactiver une API spécifique, modifier rapidement la configuration de transfert d'une API, et ajouter des fonctionnalités telles que la limitation de débit, l'authentification et la journalisation à une API sans avoir besoin de redémarrer l'API Gateway.

Prenant Apache APISIX comme exemple, il s'agit d'un projet open-source de premier niveau sous la fondation Apache et est actuellement le projet de passerelle open-source le plus actif. En tant qu'API Gateway open-source dynamique, en temps réel et haute performance, Apache APISIX fournit diverses fonctions de gestion de trafic telles que l'équilibrage de charge, l'upstream dynamique, le déploiement canari, le disjoncteur, l'authentification d'identité, l'observabilité, etc.

D'un autre côté, les équilibreurs de charge traditionnels sont relativement plus faibles en matière de gestion d'API et ont besoin de fonctionnalités avancées aussi riches.

Accès réseau haute performance

Pour les scénarios nécessitant un trafic élevé et une stabilité extrêmement élevée pour l'accès réseau, un équilibreur de charge niveau 4 est évidemment plus adapté. Il peut directement distribuer le trafic réseau original de niveau 4 à chaque service backend sans l'impact de multiples analyses de protocoles de couche application dans les couches intermédiaires, le rendant plus capable de gérer un débit plus élevé.

En revanche, l'API Gateway fonctionnant au niveau 7, en tant que point d'entrée unifié, aura une certaine limite de débit en raison de la nécessité d'analyser les protocoles. Même si l'utilisation d'un API Gateway niveau 4 pour l'accès réseau n'est pas particulièrement avantageuse car cette couche n'est pas le point focal de l'API Gateway. Comparé aux nombreuses années d'accumulation technique des équilibreurs de charge à ce niveau, les avantages des API Gateway sont bien moins significatifs.

Résumé

En général, l'API Gateway et l'équilibreur de charge sont des solutions d'infrastructure utilisées pour résoudre différents problèmes. L'API Gateway est principalement utilisé comme un proxy pour les interfaces API backend, fournissant un point d'entrée unique pour accéder à différents types d'API et des fonctions indépendantes telles que la limitation de débit, l'authentification, et la surveillance. D'un autre côté, un équilibreur de charge est principalement utilisé pour la distribution de trafic niveau 4, répartissant les requêtes sur plusieurs serveurs backend pour équilibrer la charge des requêtes et améliorer la disponibilité globale et la tolérance aux pannes du système.

Sous une conception architecturale raisonnable, l'API Gateway et l'équilibreur de charge sont généralement utilisés ensemble. Un équilibreur de charge est l'accès réseau pour l'ensemble du système, distribuant le trafic à plusieurs instances d'API Gateway. Chaque instance d'API Gateway route, authentifie et autorise ensuite les requêtes séparément pour rendre l'ensemble du réseau plus robuste, fiable et évolutif.