Qu'est-ce qu'une API Gateway, et pourquoi est-elle essentielle ?

Introduction aux API

Qu'est-ce qu'une API (Application Programming Interface) ? Une API est une méthode standard d'échange de données entre différentes applications et systèmes. De nombreuses équipes de développement adoptent l'approche API-first, où l'itération se concentre sur l'API, de la conception, la mise en œuvre, les tests, la sécurisation, le déploiement, le dépannage et l'analyse des API, ce qui constitue le cycle de vie complet de la gestion des API (APIM).

Avant l'avènement des API, il n'existait pas de méthode standard pour échanger des données. Les programmes informatiques communiquaient entre eux en utilisant une variété de protocoles, tels que FTP, FTPS, SFTP, HTTPS, etc. L'absence de normes entraînait des coûts de développement élevés et des risques de sécurité cachés à plusieurs niveaux : contrôle des permissions, gestion des données, limitation du débit, audit, etc. C'est la "Tour de Babel" du monde informatique. Pour construire un produit suffisamment complexe, nous devons résoudre les problèmes causés par des systèmes développés dans différents langages et avec différents schémas de stockage de données.

L'émergence des API a résolu avec succès le problème de la "Tour de Babel". Les développeurs n'ont plus qu'à se concentrer sur les API exposées par d'autres systèmes, sans avoir besoin de comprendre les détails d'implémentation sous-jacents.

La connexion et la transmission de données entre les appareils clients et les serveurs pour les applications mobiles, les jeux en ligne, le streaming vidéo en direct, les conférences à distance et les appareils IoT dépendent tous des API. Les API jouent un rôle crucial dans leurs communications.

Pourquoi utiliser une passerelle API ?

La passerelle API est un composant essentiel dans la gestion du cycle de vie complet des API. Elle est responsable de la configuration, de la publication, de la gestion des versions, de la sécurité et de l'équilibrage de charge des API en environnement de production. De plus, la passerelle API est l'entrée de tout le trafic client, chargée de router les requêtes API des clients vers le bon service en amont pour traitement, puis de renvoyer les données retournées au demandeur d'origine, tout en garantissant la sécurité, la fiabilité et la faible latence de l'ensemble du processus.

Lorsqu'il n'y a pas beaucoup d'API au départ, la passerelle API est généralement un composant virtuel formé par le serveur web et les services en amont. Des fonctionnalités simples telles que le routage, le transfert, le proxy inverse et l'équilibrage de charge sont gérées par Apache, NGINX et d'autres composants ; d'autres fonctionnalités comme l'authentification et la limitation du débit reposent sur les services en amont.

Pourquoi avez-vous besoin d'une passerelle API ?

Cependant, à mesure que le nombre d'API augmente, les développeurs "paresseux" ont découvert un problème sérieux. Dans différentes parties des services en amont, les mêmes fonctions d'authentification, de limitation du débit, de journalisation et d'autres fonctionnalités sont codées à plusieurs reprises. Cela représente non seulement un gaspillage de ressources, mais aussi un cauchemar de gestion du code. Lorsqu'une partie du code est modifiée ou mise à niveau, le code dans d'autres endroits doit également être mis à jour. Comment résoudre ce problème ? Les développeurs intelligents ont rapidement trouvé une solution : extraire les fonctions communes et les placer dans un composant unique. Nous extrayons le code qui n'est pas lié à la logique métier des services en amont et améliorons les composants Apache et NGINX. C'est ainsi qu'est née la première génération de passerelles API.

L'évolution des passerelles API vise à intégrer autant de fonctionnalités non liées au métier que possible. Pour accélérer l'itération des produits, les développeurs front-end et back-end exigent de plus en plus des passerelles API, non seulement limitées aux fonctionnalités traditionnelles comme le routage, le transfert, le proxy inverse et l'équilibrage de charge, mais aussi des fonctionnalités d'observabilité comme gRPC et GraphQL.

Le rôle des passerelles API

Pour rendre la passerelle API plus flexible et efficace, les développeurs de passerelles API ont apporté de nombreuses innovations à la structure sous-jacente, telles que :

• Plugins de fonctionnalités. À mesure que de plus en plus de fonctionnalités sont intégrées à la passerelle API, comment séparer chaque fonctionnalité pour faciliter le développement ? Un mécanisme de plugin de type Lego serait la solution parfaite. Les passerelles API grand public utilisent toutes des plugins. Dans Apache APISIX, cela s'appelle des "plugins". Dans Envoy, cela s'appelle des "filtres". Les plugins libèrent les développeurs de passerelle des détails d'implémentation, et moins de ressources de développement sont nécessaires pour implémenter de nouvelles fonctionnalités.
• Séparation du plan de données et du plan de contrôle. Dans la première génération de passerelles API, le plan de données et le plan de contrôle sont implémentés dans le même processus informatique. Cela facilite le déploiement et l'utilisation pour les utilisateurs, mais cela crée des risques de sécurité importants. Le plan de données fournit des services directement à l'extérieur. Si des pirates informatiques pénètrent dans le plan de données depuis l'extérieur, ils pourraient obtenir des permissions de contrôle et les données du plan de contrôle (comme les certificats SSL), causant potentiellement des dommages plus dévastateurs. Par conséquent, la plupart des passerelles API open source déploient désormais DP et CP séparément et utilisent des bases de données relationnelles ou etcd pour la gestion et la synchronisation des configurations.

Prenons Apache APISIX comme exemple, le diagramme d'architecture suivant illustre ces innovations :

Défis du Cloud-Natif

Le changement technologique le plus important dans l'IT au cours de la dernière décennie a été le cloud-native. Docker, né en 2013, a ouvert le rideau du cloud-native. Depuis, les machines physiques et les machines virtuelles ont été remplacées par des conteneurs, et les architectures monolithiques ont été remplacées par des microservices. Cependant, le cloud-native n'est pas une simple révolution technologique. La force motrice derrière cela vient du développement rapide et de la concurrence féroce des produits Internet. Les technologies liées au cloud-native sont nées au bon moment et sont rapidement devenues populaires, remplaçant de nombreuses architectures et solutions techniques précédentes. Plus précisément, les défis des passerelles API dans le cloud-native proviennent principalement des deux aspects suivants :

Du Monolithique aux Microservices

Après que l'architecture microservices a gagné en popularité parmi les développeurs, elle a libéré d'énormes dividendes techniques. Les microservices peuvent être mis à niveau et publiés à leur propre rythme sans se soucier du couplage avec d'autres services. Les itérations de produits sont donc agiles, avec des dizaines, voire des centaines de publications par jour.

Cependant, le développement des microservices apporte également quelques effets secondaires, tels que :

• Le nombre d'API et de microservices est passé de dizaines à des milliers, voire des dizaines de milliers.
• Comment localiser rapidement quelle API a causé l'erreur ?
• Comment assurer la sécurité de l'API ?
• Comment réaliser la coupure de service et la dégradation de service ?

La passerelle API ne peut pas résoudre seule les problèmes de sécurité, d'observabilité et de publication canari. Elle doit coopérer avec de nombreux autres projets open source et services SaaS tels que Prometheus, Zipkin, Skywalking, Datadog, Okta, etc., pour fournir de meilleures solutions aux entreprises.

Gestion Dynamique et de Cluster

Le premier défi vient de l'écosystème, tandis que le second vient de la technologie.

Dynamique

La popularité des conteneurs et de Kubernetes a fait de la dynamique une fonctionnalité standard de tous les composants fondamentaux du cloud-native. Dans l'environnement Kubernetes, les conteneurs sont constamment créés et détruits, et la mise à l'échelle élastique est devenue une nécessité plutôt qu'une option.

Imaginez un scénario : une entreprise de commerce électronique lance une promotion, et des millions d'utilisateurs affluent en une heure et partent après la fin de la promotion. Dans ce scénario, les entreprises avec une architecture traditionnelle doivent acheter un lot de serveurs physiques pour faire face au trafic API aux heures de pointe. En revanche, les entreprises avec une architecture cloud-native peuvent utiliser les ressources élastiques du cloud public à tout moment. Elles peuvent ajuster automatiquement l'échelle du réseau, de la puissance de calcul, des bases de données et d'autres ressources en fonction du nombre de requêtes API.

Il y a également des défis techniques associés à la mise à l'échelle élastique des conteneurs :

• Les services en amont changent fréquemment d'adresses IP et de ports.
• Mises à jour fréquentes des listes d'autorisation et de refus d'IP.
• Détection et gestion des exceptions de santé des services.
• Publications régulières des API.
• Rapidité de l'enregistrement et de la découverte des services.
• Renouvellement à chaud et rotation automatique des certificats SSL.

Au cœur de la résolution de ces défis techniques se trouve la dynamique.

Les passerelles API de première génération représentées par NGINX ont des capacités dynamiques faibles. Parce que NGINX est piloté par des fichiers de configuration statiques locaux, tout changement de configuration nécessite un rechargement du service NGINX pour prendre effet, ce qui est inacceptable pour les entreprises à l'ère du cloud-native. C'est le premier point de douleur technique des passerelles API de première génération.

Gestion de Cluster

Le deuxième point de douleur technique est la gestion de cluster.

WPS, une entreprise de logiciels de bureau SaaS en Chine, qui fournit des logiciels comme Microsoft Office 365. Ils ont des centaines de machines physiques exécutant Apache APISIX, près de 10 000 cœurs de CPU traitant les requêtes API des clients, et traitant des dizaines de milliards d'API par jour.

Dans cet environnement de passerelle API à très grande échelle, il est impossible pour les développeurs de modifier la configuration de chaque passerelle API une par une et de les recharger ensuite. Au lieu de cela, ils veulent une console intégrée pour opérer l'ensemble du cluster. Malheureusement, lorsque la première génération de passerelles API est née, il n'y avait pas une telle échelle d'instances, donc les développeurs de la première génération de passerelles n'ont pas pris en compte les besoins de gestion de cluster.

La Passerelle API de Nouvelle Génération

Les défis et points de douleur ci-dessus ont progressivement donné naissance à une nouvelle génération de passerelles API.

Caractéristiques de la Passerelle API de Nouvelle Génération

Contrairement à la première génération de passerelles API, la communauté open source est la principale force motrice du développement de la nouvelle génération de passerelles API à l'ère du cloud-native. Avec la puissance de la communauté et de nombreux contributeurs open source, ces passerelles API ont l'opportunité de former un cycle d'itération et d'évolution positif :

• Capable de collecter les besoins et points de douleur des développeurs et utilisateurs beaucoup plus rapidement
• Essayer de résoudre ces problèmes dans des projets open source
• Les projets open source deviennent plus faciles à utiliser, attirant plus de développeurs

Dans ce processus, la passerelle API de nouvelle génération dépasse le positionnement de l'équilibrage de charge et du proxy inverse des passerelles traditionnelles et assume plus de responsabilités, telles que la connexion, la planification, le filtrage, l'analyse, la conversion de protocole, la gouvernance et l'intégration (voir ci-dessous).

La Passerelle API prend en charge le développement secondaire à moindre coût

En même temps, permettre aux développeurs de réaliser des développements personnalisés à moindre coût est également devenu un point fort de la passerelle API de nouvelle génération. L'intégration est l'une des fonctions essentielles de la passerelle API. Pour l'aval, il s'agit de l'analyse et de la conversion de protocoles, y compris GraphQL, gRPC, Dubbo, etc. ; pour l'amont, elle intègre Okta, Keycloak, Datadog et Prometheus pour les services d'authentification et d'observabilité, ainsi que les services internes de certification, de journalisation, d'audit, etc.

La passerelle API ne peut pas couvrir tous les composants du processus d'intégration. Par conséquent, il est inévitable que les développeurs réalisent des développements personnalisés via des plugins pour répondre à leurs propres besoins métier.

Différentes passerelles API fournissent différents langages de programmation et méthodes de développement pour les développements personnalisés. Par exemple, Apache APISIX et Kong peuvent tous deux utiliser Lua pour écrire des plugins natifs, tandis qu'Envoy utilise C++ pour écrire des plugins natifs. En même temps, Apache APISIX peut également utiliser Go, Python, Node.js, Java et Wasm pour développer des plugins. Presque tous les développeurs utilisent l'un de ces langages de programmation grand public.

L'open source et le développement personnalisé facile sont les caractéristiques les plus importantes de la passerelle API de nouvelle génération. Elles offrent plus de choix aux développeurs. En même temps, les développeurs peuvent utiliser en toute confiance la passerelle API dans un environnement multi-cloud ou hybride, sans craindre d'être enfermés par les fournisseurs de services cloud.

Exemple : Passerelle API pour le trafic du Black Friday

Ensuite, expliquons ce que fait une passerelle API avec un exemple concret.

Lors du Black Friday, les entreprises de commerce électronique proposent de nombreuses promotions, et le volume de requêtes API pendant cette période est des dizaines de fois supérieur à la normale. Tout d'abord, examinons quelle serait l'architecture technique s'il n'y avait pas de passerelle API :

Comme vous pouvez le voir sur l'image ci-dessus, les fonctions d'authentification et de journalisation sont dupliquées dans les services de commande et de paiement. Un service de commerce électronique est généralement composé de milliers de services différents. À ce moment-là, une grande partie des codes et des procédures seront répétés.

La figure suivante est le diagramme d'architecture après l'ajout de la passerelle API :

Comme vous pouvez le voir ci-dessus, nous avons intégré les services communs au niveau de la passerelle API. En conséquence, les services back-end n'ont plus qu'à se concentrer sur leur propre métier, offrant plus de possibilités pour la mise à l'échelle élastique.

Lorsque la promotion commence, des millions de requêtes API des clients affluent vers la passerelle API, et le service back-end doit effectuer une mise à l'échelle élastique rapide. Pour protéger les activités critiques contre l'impact d'un trafic soudain, nous devons identifier les robots malveillants sur la passerelle API et mettre en œuvre la limitation, la dégradation de service et la coupure de service.

Nous pouvons également temporairement désactiver certains services, tels que l'évaluation des produits, les demandes de livraison, etc. Cependant, les activités de base telles que les informations sur les stocks, l'achat et le paiement ne doivent pas échouer. Par conséquent, nous devons gérer le service de conteneur via K8s et générer plus de copies de service pour maintenir son bon fonctionnement. À ce moment-là, la passerelle API doit router la requête API du client vers le nouveau service répliqué et supprimer automatiquement le service défaillant, comme le montre la figure suivante :

Résumé

En résumé, la passerelle API n'est pas un nouveau middleware. Cependant, elle a gagné de plus en plus d'importance à mesure que les architectures techniques évoluent et que les produits itèrent de plus en plus rapidement. L'émergence de la passerelle API cloud-native de nouvelle génération résout les points de douleur des utilisateurs en termes de gestion de cluster, de dynamique, d'écosystème, d'observabilité et de sécurité.

La passerelle API peut gérer non seulement le trafic API, mais aussi le trafic de Kubernetes Ingress et de service mesh, réduisant ainsi la courbe d'apprentissage des développeurs et aidant les entreprises à gérer le trafic de manière intégrée.

Contactez-nous pour en savoir plus sur Apache APISIX, API7 Enterprise Edition et les produits API7 Cloud.