Comment gRPC connaît l'adresse IP du service d'un microservice

gRPC est un framework d'appel de procédure à distance open source hautes performances permettant de créer des microservices dans des systèmes distribués. Lors de l'utilisation de gRPC, une question courante est de savoir comment informer le client de l'adresse IP du microservice. Tout d'abord, l'éditeur PHP Shinichi a expliqué le principe de fonctionnement de gRPC, qui utilise Protocol Buffers comme langage de définition d'interface et HTTP/2 comme protocole de transport. Ensuite, l'éditeur a introduit deux méthodes couramment utilisées pour résoudre le problème des adresses IP de service : la configuration statique et la découverte de services. La configuration statique code en dur l'adresse IP du service dans le code client. Cette méthode est simple et directe, mais nécessite une mise à jour manuelle de la configuration. La découverte de services consiste à obtenir dynamiquement l'adresse IP du service à l'aide d'outils d'enregistrement et de découverte de services, tels que Consul ou Etcd. Cette approche est plus flexible et automatisée, mais nécessite un déploiement et une maintenance supplémentaires. Quelle que soit la méthode que vous choisissez, vous devez implémenter la logique correspondante dans le code client pour obtenir l'adresse IP du service afin d'assurer le fonctionnement normal de gRPC.

Contenu de la question

J'ai commencé avec la démo des microservices de la plateforme Google Cloud. Je suis curieux de savoir comment fonctionnent les stubs grpc lorsque le service est déployé dans un conteneur.

D'après ce que j'ai compris, le conteneur d'un service spécifique est adressé par l'adresse IP du service spécifiée dans le fichier de configuration yaml. Alors, le serveur grpc du service doit-il écouter l'adresse IP du service ? Mais je suis tombé sur l'extrait de code suivant :

l, err := net.Listen("tcp", fmt.Sprintf(":%s", port))
if err != nil {
    log.Fatal(err)
}

Je veux savoir comment le serveur écoute une adresse sans IP ?

La solution

:{port} n'est pas « une adresse sans IP ».

La documentation de

Listen inclut "Si l'hôte dans le paramètre d'adresse est vide ou une adresse IP littérale non spécifiée, Listen écoute toutes les adresses IP unicast et anycast disponibles sur le système local."

Donc dans ce cas, sans adresse d'hôte, l'adresse effective serait 0.0.0.0 ，它对应于所有接口。由此推论，人们在使用容器时常犯的一个错误是将其代码绑定到 localhost (127.0.0.1) et le code ne serait pas accessible depuis l'extérieur du conteneur.

L'utilisation de 0.0.0.0 est une (bonne) pratique courante, en particulier lorsque vous travaillez avec des conteneurs, car elle délègue efficacement la liaison d'adresse au runtime du conteneur.

Votre application s'exécute donc sur {port} sur toutes les interfaces à l'intérieur du conteneur. Le runtime du conteneur lie ensuite une ou plusieurs de ces interfaces à l'interface de l'hôte et à votre eg. Le code client se connecte à l'adresse IP de l'hôte.

Lorsque vos conteneurs sont gérés par Kubernetes, Kubernetes attribue des adresses IP aux conteneurs exécutant votre application, et ces conteneurs sont généralement exposés à d'autres services utilisant les ressources du service Kubernetes, qui ont non seulement des adresses IP, mais également un DNS de cluster.

1. Kubernetes YAML peut spécifier le DNS du service.
2. Kubernetes résout les requêtes de nom DNS vers le conteneur sélectionné (IP et port)
3. Le runtime du conteneur achemine les requêtes entrantes sur le port hôte vers le port du conteneur
4. Votre serveur gRPC acceptera le trafic du runtime du conteneur sur l'interface net.Listen 的 {port} que vous avez définie comme net.Listen.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!