Modèles de déploiement d'API Gateway
December 16, 2022
Les API changent la façon dont nous construisons des applications et dont nous exposons les données, à la fois à l'intérieur et à l'extérieur de nos organisations. De plus, le succès de nos API dépend de leur intégrité, de leur disponibilité et de leurs performances. Avec une passerelle API telle que Apache APISIX, nous pouvons atteindre ces indicateurs de succès.
En ce qui concerne le déploiement des passerelles API, il existe 4 modèles bien connus : Passerelle centralisée en périphérie, Passerelle à deux niveaux, Micro-passerelle et Sidecar. Dans cet article, nous allons parcourir ces modèles et vous donner une idée pour choisir le bon modèle de déploiement de passerelle API pour votre entreprise.
Qu'est-ce qu'une passerelle API ?
Une passerelle API est un outil de gestion qui se situe à la périphérie d'un système entre un consommateur et un ensemble de services backend et agit comme un point d'entrée unique pour un groupe défini d'API. Le consommateur peut être une application ou un appareil utilisateur final, comme une application web monopage ou une application mobile, un autre système interne, ou une application ou un système tiers.
Composants de déploiement d'une passerelle API
Une passerelle API est mise en œuvre avec deux composants fondamentaux de haut niveau : un plan de contrôle et un plan de données. Ces composants peuvent généralement être regroupés ou déployés séparément. Le plan de contrôle est l'endroit où les opérateurs interagissent avec la passerelle et définissent les routes, les politiques et la télémétrie requise. Le plan de données est l'endroit où tout le travail spécifié dans le plan de contrôle se produit, où les paquets réseau sont acheminés, les politiques appliquées et la télémétrie émise. Par exemple, APISIX propose trois modes de déploiement différents (traditionnel, découplé et autonome) pour différents cas d'utilisation en production.
Passerelle centralisée en périphérie
Une passerelle API est généralement déployée à la périphérie d'un système, mais la définition de "système" dans ce cas peut être assez flexible. Pour les startups et de nombreuses petites et moyennes entreprises, une passerelle API sera souvent déployée à la périphérie du centre de données ou du cloud. Dans ces situations, il peut n'y avoir qu'une seule passerelle API (déployée et exécutée via plusieurs instances pour une haute disponibilité) qui agit comme la porte d'entrée de l'ensemble du backend, et la passerelle API fournira toutes les fonctionnalités de périphérie.
Une passerelle API fournit des exigences transversales telles que l'authentification des utilisateurs, l'autorisation, la limitation du taux de requêtes, la mise en cache, les délais d'attente/les nouvelles tentatives, la transformation des requêtes/réponses, peut fournir des métriques, des journaux et des données de traçage afin de soutenir la mise en œuvre de l'observabilité au sein du système.
De plus, de nombreuses passerelles API offrent des fonctionnalités supplémentaires qui permettent aux développeurs de gérer le cycle de vie d'une API, d'aider à l'intégration et à la gestion des développeurs utilisant les API (comme la fourniture d'un portail développeur et de l'administration des comptes et du contrôle d'accès associés), et de fournir une gouvernance d'entreprise.
Passerelle à deux niveaux
Pour les grandes organisations et les entreprises, une passerelle API sera généralement déployée à plusieurs endroits, souvent dans le cadre de la pile de périphérie initiale à la périphérie d'un centre de données, et des passerelles supplémentaires peuvent être déployées dans le cadre de chaque produit, ligne de métier ou département organisationnel. Dans ce contexte, ces passerelles seraient plus typiquement des implémentations séparées et pourraient offrir des fonctionnalités différentes selon la localisation géographique (gouvernance requise) ou les capacités de l'infrastructure (fonctionnant sur des ressources de calcul de périphérie à faible puissance).
Comme le montre le diagramme ci-dessous, la passerelle API Apache APISIX se situe souvent entre l'internet public et la zone démilitarisée (DMZ) d'un réseau privé.
Micro-passerelle
Les Micro-passerelles sont conçues entièrement pour la communication interne entre microservices. Chaque micro-passerelle individuelle peut avoir un ensemble différent de politiques, de règles de sécurité, et nécessiter l'agrégation de la surveillance et des métriques de plusieurs services.
Le concept est de fournir la capacité (une passerelle dédiée) à l'équipe individuelle gérant les microservices pour contrôler la manière dont ils vont exposer les services de manière sécurisée. La même équipe de développeurs gérera et maintiendra ses microservices et micro-passerelles, afin qu'elle puisse corriger les bugs, fournir des mises à jour, effectuer des améliorations de manière indépendante, et pousser rapidement les changements en production avec moins d'interaction avec les autres dépendances et sans impacter les autres applications dans le déploiement.
Passerelle API Sidecar
Le Sidecar implémente une passerelle API en tant que conteneur attaché à un service dans un runtime indépendant, comme Kubernetes. Le Sidecar est un modèle qui correspond à un sidecar attaché à une moto, de la même manière, il est attaché à une application parente (un composant logiciel appelé maillage de services) et fournit des fonctionnalités de support pour l'application. Le sidecar partage également le même cycle de vie que l'application parente, est créé et retiré en même temps que le parent, et introduit des fonctionnalités supplémentaires telles que la surveillance, la journalisation, la configuration et les services de réseau.
Les avantages de l'adoption de ce modèle sont que chaque runtime de service peut configurer sa propre passerelle API de la meilleure manière. Parce que les exigences pour activer les fonctionnalités et les configurations de la passerelle API peuvent varier d'un service à l'autre. En même temps, cela sépare les préoccupations si un problème survient dans l'infrastructure partagée de la passerelle API, alors tous les services ne sont pas impactés. Par exemple, Amesh est une autre solution de maillage de services basée sur Apache APISIX.
Le diagramme précédent illustre un point d'entrée agissant comme un équilibreur de charge API et un routeur de ressources vers chaque point de terminaison de service. Le point d'entrée pour le service n'est pas le point de terminaison de service lui-même, mais plutôt une passerelle API sidecar. Le sidecar peut alors exécuter toutes les capacités offertes par la passerelle API en plus de router le trafic vers le point de terminaison de service.
Conclusion
Comme nous l'avons compris, il n'existe pas de modèle de déploiement unique qui convienne à toutes les conditions. Parfois, vous pouvez utiliser une ou plusieurs passerelles dans votre système. Le choix du déploiement dépend de la complexité et des besoins de votre entreprise. Si vous avez besoin d'aide pour décider quel modèle de déploiement serait le meilleur pour vous, vous pouvez rejoindre notre communauté sur le canal Slack et des experts vous aideront à prendre une décision.
Ressources connexes
➔ Modèles de déploiement d'Apache APISIX.
➔ Qu'est-ce qu'une passerelle API, et pourquoi est-elle essentielle à l'ère du cloud-native ?.
Contenu recommandé
➔ Lisez les articles de blog :