gRPC sur Passerelle d’application pour conteneurs

Qu’est-ce que gRPC ?

gRPC est un framework moderne et hautes performances qui évolue le protocole RPC (Age-Old Remote Procedure Call). Au niveau de l’application, gRPC simplifie la messagerie entre les clients et les services principaux. Issu de Google, gRPC est open source et fait partie de l’écosystème de la Cloud Native Computing Foundation (CNCF) d’offres cloud-native. CNCF considère gRPC comme un projet d’incubation. L’incubation signifie que les utilisateurs finaux utilisent la technologie dans les applications de production, et que le projet a un nombre sain de contributeurs.

Une application cliente gRPC standard expose une fonction locale in-process qui implémente une opération d’entreprise. En coulisse, cette fonction locale appelle une autre fonction sur un ordinateur distant. Ce qui semble être un appel local devient essentiellement un appel transparent hors processus à un service distant. La plomberie RPC extrait la communication réseau point à point, la sérialisation et l’exécution entre les ordinateurs.

Dans les applications natives Cloud, les développeurs travaillent souvent entre des langages de programmation, des infrastructures et des technologies. Cette interopérabilité complique les contrats de messages et la plomberie requise pour la communication multiplateforme. gRPC fournit une « couche horizontale uniforme » qui récupère ces préoccupations. Les développeurs codent dans leur plateforme native axée sur les fonctionnalités métier, tandis que gRPC gère la plomberie des communications.

gRPC offre une prise en charge complète sur les piles de développement les plus populaires, notamment Java, JavaScript, C#, Go, Swift et NodeJS.

Avantages gRPC

gRPC utilise HTTP/2 pour son protocole de transport offrant de nombreuses fonctionnalités avancées :

  • Protocole d’encadrement binaire pour le transport de données, contrairement à HTTP 1.1, qui est basé sur du texte.
  • Prise en charge du multiplexage pour l’envoi de plusieurs requêtes parallèles sur la même connexion : HTTP 1.1 limite le traitement à un message de requête/réponse à la fois.
  • Communication bidirectionnelle en duplex intégral pour l’envoi simultané des requêtes clientes et des réponses du serveur.
  • Diffusion en continu intégrée permettant aux requêtes et aux réponses de diffuser en continu de manière asynchrone des jeux de données volumineux.
  • Compression d’en-tête qui réduit l’utilisation du réseau.

gRPC est léger et hautement performant. Il peut être jusqu’à 8 fois plus rapide que la sérialisation JSON avec des messages de 60 à 80 % plus petits.

Mémoires tampon de protocole

gRPC adopte une technologie open source appelée tampons de protocole. Ils fournissent un format de sérialisation hautement efficace et neutre sur la plateforme pour sérialiser des messages structurés que les services envoient les uns aux autres. À l’aide d’un langage IDL (Interface Definition Language) multiplateforme, les développeurs définissent un contrat de service pour chaque microservice. Le contrat, implémenté en tant que fichier textuel .proto , décrit les méthodes, les entrées et les sorties pour chaque service. Le même fichier de contrat peut être utilisé pour les clients et services gRPC basés sur différentes plateformes de développement.

À l’aide du fichier proto, le compilateur Protobuf, protoc, génère à la fois du code client et de service pour votre plateforme cible. Le code comprend les composants suivants :

  • Objets fortement typés, partagés par le client et le service, qui représentent les opérations de service et les éléments de données d’un message.
  • Classe de base fortement typée avec la plomberie réseau requise que le service gRPC distant peut hériter et étendre.
  • Stub client qui contient la plomberie requise pour appeler le service gRPC distant.

Au moment de l’exécution, chaque message est sérialisé en tant que représentation Protobuf standard et échangé entre le client et le service distant. Contrairement à JSON ou XML, les messages Protobuf sont sérialisés en tant qu’octets binaires compilés.

Cycle de vie de RPC

gRPC a quatre cycles de vie rpc pour la façon dont un client interagit avec le serveur gRPC.

RPC unaire

Dans le cycle de vie unaire, une requête est envoyée au serveur gRPC et une réponse est retournée.

Diagramme illustrant le cycle de vie gRPC unaire.

RPC avec diffusion en continu du client

Dans le cycle de vie de diffusion en continu du client, une requête est adressée au serveur gRPC, puis le client diffuse en continu une séquence de messages supplémentaires au serveur sans que le serveur ait besoin de retourner de réponses supplémentaires.

Diagramme du cycle de vie du streaming client gRPC.

RPC de diffusion en continu du serveur

Dans le cycle de vie de diffusion en continu du serveur, une requête est adressée au serveur gRPC, puis le serveur diffuse en continu une séquence de messages au client sans que le client ait besoin de retourner de réponses supplémentaires.

Diagramme illustrant le cycle de vie du streaming de serveur gRPC.

RPC avec diffusion en continu bidirectionnelle

Dans le cycle de vie de diffusion en continu bidirectionnelle, une requête est adressée au serveur gRPC, puis le client et le serveur, fonctionnant indépendamment l’un de l’autre, envoient une séquence de messages.

Diagramme illustrant le cycle de vie de streaming bidirectionnel gRPC.

Implémentation de gRPC dans Passerelle d’application pour conteneurs

Passerelle d’application pour conteneurs est capable de rediriger via proxy les requêtes après chacun des quatre cycles de vie : unaire, diffusion en continu du client, diffusion en continu du serveur et diffusion en continu bidirectionnelle.

Définition de gRPC

La configuration est implémentée via l’API de passerelle Kubernetes par la définition d’une ressource GRPCRoute (aucune prise en charge n’est proposée pour l'API Ingress de gRPC pour Application Gateway for Containers). Chaque ressource GRPCRoute doit référencer une ressource Gateway. Plusieurs ressources GRPCRoute peuvent référencer la même passerelle à condition que les règles de traitement de la requête soient uniques.

Par exemple, la ressource GRPCRoute suivante est attachée à une passerelle appelée Gateway-01.

apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
  name: grpc-route-example
  namespace: grpc-namespace
spec:
  parentRefs:
    - name: gateway-01
      namespace: gateway-namespace
  rules:
    - matches:
        - method:
            service: ChatBotService
            method: TalkBack
      backendRefs:
        - name: gRPC-TalkBack
          port: 8080

Remarque

gRPC est uniquement pris en charge à l’aide de l’API Gateway pour Application Gateway pour conteneurs.

Sondes d’intégrité

Par défaut, Passerelle d’application pour conteneurs tente d’établir une liaison TCP avec le port back-end exécutant le service gRPC. Si l’établissement d’une liaison aboutit, le back-end est considéré comme sain.

Si vous utilisez HealthCheckPolicy comme sonde d’intégrité personnalisée, la stratégie définie détermine le comportement de la sonde.

Voici un exemple de HealthCheckPolicy pour un back-end gRPC.

apiVersion: alb.networking.azure.io/v1
kind: HealthCheckPolicy
metadata:
  name: gateway-health-check-policy
  namespace: test-infra
spec:
  targetRef:
    group: ""
    kind: Service
    name: test-service
    namespace: test-infra
  default:
    interval: 5s
    timeout: 3s
    healthyThreshold: 1
    unhealthyThreshold: 1
    port: 8123
    grpc: {} # defined if probing a gRPC endpoint
    UseTLS: true

Dans cet exemple, le protocole, le port et UseTLS sont facultatifs. Toutefois, si le service contient plusieurs pods et que le pod gRPC est exposé sur un autre port, vous pouvez référencer explicitement la façon dont la sonde doit être lancée sur ce pod.

  • Last updated on