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) ou Extensible Service Proxy V2 bêta (ESPv2 bêta) pour l'injection de la fonctionnalité 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.

La compatibilité avec ESP est assurée sur les plates-formes suivantes :

ESPv2 bêta

ESPv2 bêta est un proxy évolutif hautes performances basé sur Envoy qui s'exécute devant un backend d'API OpenAPI ou gRPC. Sur ESPv2 bêta, Endpoints est compatible avec la version 2 de la spécification OpenAPI et les spécifications gRPC.

ESPv2 bêta s'intègre à l'infrastructure de services Google pour proposer des fonctionnalités de gestion d'API à grande échelle, telles que l'authentification, les rapports de télémétrie, les métriques et la sécurité.

La compatibilité avec ESPv2 bêta est assurée sur les plates-formes suivantes :

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

Service Management

Avec Service Management, vous décrivez le comportement de votre service gRPC dans un fichier YAML appelé configuration Endpoints. Vous déployez la configuration Endpoints et vos fichiers .proto compilés sur Service Management à l'aide du SDK Cloud, qui configure les règles de gestion des 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 fait appel à Cloud Console pour divulguer les données de surveillance et de journalisation envoyées par ESP (ou ESPv2 bêta) et enregistrées par Service Control, ainsi que pour partager les API avec d'autres développeurs, ce qui permet à ceux-ci de générer des clés API pour appeler ces API.

Scénarios de déploiement

Les options de déploiement varient en fonction de l'utilisation d'ESP ou d'ESPv2 bêta en tant que proxy Endpoints. ESPv2 bêta peut être déployé en tant que proxy distant ; ESPv2 bêta et ESP peuvent tous deux être déployés en mode side-car, comme expliqué dans les sections suivantes.

Mode proxy distant

Si vous utilisez ESPv2 bêta, Endpoints peut être déployé en tant que proxy distant. Ce mode permet de gérer les applications exécutées sur des plates-formes sans serveur telles que Cloud Run, Cloud Functions et App Engine pour les environnements standards.

Dans ce mode, ESPv2 bêta est déployé en tant qu'application Cloud Run. L'application est configurée pour faire appel à ESPv2 bêta en tant que backend distant à l'aide du champ x-google-backend de la configuration du service OpenAPI. Lorsqu'il est utilisé comme proxy distant dans ce mode de déploiement, une seule version d'ESPv2 bêta peut prendre en charge plusieurs backends distants.

Consultez la section Configurer Endpoints pour plus d'informations.

Mode side-car

ESP et ESPv2 bêta sont compatibles avec le déploiement dans 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.

L'équilibrage de charge est généralement appliqué avant que le trafic n'atteigne ESP (ou ESPv2 bêta). 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 (ou ESPv2 bêta) 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 (ou ESPv2 bêta) crée un jeton de trace pour Cloud Trace.

Ensuite, ESP (ou ESPv2 bêta) 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 (ou ESPv2 bêta) effectue toutes les étapes d'authentification pour la méthode spécifiée.

Si la validation JWT est nécessaire, ESP (ou ESPv2 bêta) 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 (ou ESPv2 bêta) 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 (ou ESPv2 bêta) 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 ou ESPv2 bêta 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. L'architecture est la même pour un déploiement side-car avec ESPv2 bêta.

Présentation de Endpoints sur Kubernetes

Étapes suivantes