Développement gRPC pour une communication haute performance entre microservices

gRPC est le meilleur choix pour la communication inter-services où la performance est importante — l'encodage binaire Protobuf est 3 à 10 fois plus compact que JSON, et le multiplexage HTTP/2 élimine le blocage en tête de file. Utilisez gRPC lorsque : les services communiquent à haute fréquence (>1000 RPS par paire) ; vous avez besoin d'un streaming bidirectionnel ; vous souhaitez des clients polyglotte générés automatiquement ; ou vous opérez dans un environnement de microservices polyglotte. Utilisez REST lorsque : l'API est consommée directement par des navigateurs ; la mise en cache est importante (REST HTTP se met en cache au niveau CDN) ; ou la simplicité l'emporte sur la performance.

Protobuf est un format de sérialisation binaire, schéma en premier. Il est 3 à 10 fois plus compact que le JSON équivalent et 5 à 10 fois plus rapide à analyser. Contrairement à JSON, Protobuf nécessite un schéma .proto pour sérialiser et désérialiser — c'est une fonctionnalité, pas une limitation : le schéma est le contrat, appliqué au niveau du type dans le code généré. JSON est lisible par l'homme et facultativement schématisé ; Protobuf est optimisé pour les machines et requiert obligatoirement un schéma.

Les navigateurs ne peuvent pas utiliser gRPC natif (les trailers HTTP/2 sont inaccessibles à JavaScript). Nous utilisons l'une de deux approches : gRPC-Web (un sous-ensemble de gRPC compatible avec les navigateurs, avec transcodage Envoy côté serveur) ou grpc-gateway (un proxy inverse qui traduit les appels REST+JSON en gRPC). gRPC-Web préserve le support du streaming ; grpc-gateway est plus simple à intégrer avec les outils OpenAPI existants. Le choix dépend de la nécessité de streaming pour les clients navigateurs.

Les connexions HTTP/2 longue durée contournent l'équilibrage de charge L4 de kube-proxy — tout le trafic va vers un seul pod. Nous utilisons l'une de ces solutions : Istio (équilibrage de charge gRPC L7 via sidecar Envoy), Linkerd (proxy L7 transparent), ou équilibrage de charge côté client avec le résolveur DNS intégré de grpc-go et la politique round-robin. Pour les services sans maillage de services, nous configurons des Services headless dans Kubernetes afin que le client gRPC résolve toutes les IP des pods et s'équilibre lui-même.

Nous exécutons buf breaking en IC par rapport à la dernière version de schéma publiée. Les changements cassants comprennent : la suppression ou le renommage des champs, la réutilisation des numéros de champ, la modification des types de champ, la suppression des valeurs d'énumération. Les changements additifs sont sûrs : ajout de nouveaux champs, nouveaux types de messages, nouvelles méthodes RPC. Nous suivons le guide de style Protobuf et réservons les numéros de champ pour les champs supprimés avec des instructions reserved afin d'éviter une réutilisation accidentelle future.

Les tests unitaires simulent l'interface du service gRPC générée par protoc. Les tests d'intégration utilisent Testcontainers (ou un serveur en processus) avec de vrais clients gRPC — grpcurl pour les tests ad hoc, des clients de test personnalisés pour les suites automatisées. Nous testons les quatre modes de streaming (unaire, streaming serveur, streaming client, bidirectionnel) et les scénarios d'erreur (codes de statut, délai dépassé, annulé). Les tests de contrat valident que l'implémentation du serveur correspond à la définition .proto.

Oui — l'interopérabilité multilangage est l'une des fonctionnalités clés de gRPC. protoc (ou buf generate) génère des stubs clients et serveurs pour Go, Java, Python, TypeScript, Ruby, C#, PHP et d'autres langages à partir du même fichier .proto. Tant que toutes les implémentations utilisent la même version .proto, un client Go peut appeler un serveur Java en toute transparence. Nous gérons les fichiers .proto dans un dépôt central et publions les clients générés dans des registres de paquets par langage via IC.