Présentation de l'architecture Cloud Endpoints

Cloud Endpoints est un système de gestion d'API distribué comprenant des services, des environnements d'exécution et des outils. Cloud Endpoints assure les tâches de gestion, de surveillance et d'authentification.

Cloud Endpoints est constitué des éléments suivants :

  • Extensible Service Proxy (ESP), qui permet d'injecter les fonctionnalités Cloud Endpoints.

  • Service Control, qui permet d'appliquer les règles de gestion des API.

  • Service Management, qui permet de configurer les règles de gestion des API.

  • SDK Cloud, qui permet le déploiement et la gestion.

  • Google Cloud Console, qui permet la journalisation, la surveillance et le partage.

Architecture Endpoints

Architecture Endpoints

Éléments Cloud Endpoints

ESP

ESP est un proxy basé sur NGINX qui s'exécute avant le backend et injecte des fonctionnalités Endpoints telles que l'authentification, la surveillance et la journalisation. ESP récupère une configuration de service à partir de Service Management et s'en sert pour valider les requêtes entrantes.

ESP est conçu pour être déployé sur un environnement conteneurisé et pour valider les jetons JWT et les jetons d'ID Google. Il utilise diverses techniques telles que la mise en cache intensive et les appels asynchrones pour rester léger et performant.

Service Control

Service Control applique les règles de gestion des API lors de l'exécution, telles que l'authentification par clé, la surveillance et la journalisation. Service Control utilise les méthodes suivantes :

  • Vérification : vérifie les clés d'authentification et les clés API et indique si un appel doit être autorisé.

  • Rapport : notifie les systèmes lors d'enregistrements de journalisation et de surveillance

Gestion du service

Avec Service Management, vous utilisez la spécification OpenAPI pour décrire la surface et le comportement de l'API dans un fichier texte appelé configuration Endpoints. Vous déployez la configuration Endpoints sur Service Management à l'aide du SDK Cloud qui configure les règles de gestion de l'API. D'autres tâches liées à la configuration sont également effectuées ici, telles que le partage de votre API avec d'autres développeurs, l'activation et la désactivation de l'API dans différents projets et la génération de clés API.

Le SDK Cloud

Le SDK Cloud intègre l'outil de ligne de commande gcloud, avec lequel vous pouvez appeler divers services Google Cloud. Utilisez l'outil de ligne de commande gcloud pour déployer la configuration Endpoints sur Service Management.

Google Cloud Console

Cloud Console est l'interface utilisateur graphique de Google Cloud. Endpoints se sert de Cloud Console pour exposer les données de surveillance et de journalisation envoyées depuis ESP et enregistrées par Service Control, ainsi que pour partager les API avec d'autres développeurs, permettant à ceux-ci de générer des clés API pour appeler l'API.

Scénarios de déploiement

ESP est conçu pour être déployé sur un conteneur avec chaque instance de votre backend. Cette topologie locale au serveur est idéale pour les API Web ainsi que pour les microservices. Elle évite les sauts de réseau généralement associés aux proxys centralisés et permet une gestion des API performante et évolutive.

Généralement, l’équilibrage de charge est appliqué avant que le trafic n’atteigne ESP. Sur App Engine, l'équilibrage de charge est automatique. Sur Compute Engine, cette opération est réalisée par Cloud Load Balancing. Pour les déploiements Kubernetes, un proxy d'entrée peut être utilisé pour l'équilibrage de charge. Dans Google Kubernetes Engine, Cloud Load Balancing ou un proxy d'entrée peut être utilisé pour l'équilibrage de charge.

Au démarrage, ESP obtient sa configuration de service auprès de Service Management. La configuration du service est générée à partir de la spécification OpenAPI ou depuis gRPC, le fichier YAML de configuration du service. Il indique au proxy ESP la surface de l'API à gérer ainsi que les règles, telles que les méthodes nécessitant une authentification et celles requérant des clés API.

Routage des requêtes

Lorsqu'une requête est reçue, ESP crée un jeton de trace pour Cloud Trace.

Ensuite, ESP fait correspondre le chemin d'accès des requêtes entrantes avec la surface de l'API. Après avoir trouvé le chemin correspondant, ESP effectue toutes les étapes d'authentification pour la méthode spécifiée.

Si la validation JWT est nécessaire, ESP valide l'authentification à l'aide de la clé publique appropriée pour le signataire et valide le champ d'audience dans le JWT. Si une clé API est requise, ESP appelle l'API Service Control pour la valider.

Service Control recherche la clé pour la valider et s'assure que le projet associé à la clé a activé l'API. Si la clé n'est pas valide ou si le projet n'a pas activé l'API, l'appel est rejeté et il est enregistré via l'API Service Control.

Si Service Control valide la clé, la requête, ainsi que tous les en-têtes d'origine, et l'en-tête de validation JWT le cas échéant, sont transmis au backend.

Lorsqu'une réponse est reçue du backend, ESP renvoie la réponse à l'appelant et envoie les informations de date et heure finales à Stackdriver Trace. Les points d'appel sont enregistrés par l'API Service Control, qui écrit les métriques et les journaux dans les destinations appropriées.

ESP sur Kubernetes

Le schéma suivant illustre l'architecture globale dans laquelle ESP s'exécute en tant que conteneur "side-car" devant le conteneur d'applications de service d'API, avec l'API my-api hébergée sur my-api.com et reposant sur un service Kubernetes.

Présentation de Endpoints sur Kubernetes

Étapes suivantes