Écrit par Naveen M
En tant que membre de notre équipe de plateforme Kubernetes, nous sommes confrontés au défi constant de fournir une visibilité en temps réel sur les charges de travail des utilisateurs. De la surveillance de l'utilisation des ressources au suivi de l'activité du cluster Kubernetes et de l'état des applications, il existe de nombreuses solutions open source disponibles pour chaque catégorie spécifique. Cependant, ces outils sont souvent dispersés sur différentes plateformes, ce qui entraîne une expérience utilisateur fragmentée. Pour résoudre ce problème, nous avons exploité la puissance du streaming côté serveur, nous permettant de fournir en direct l'utilisation des ressources, les événements Kubernetes et l'état des applications dès que les utilisateurs accèdent à notre portail de plateforme.
En implémentant le streaming côté serveur, nous pouvons diffuser de manière transparente des données vers l'interface utilisateur, fournissant des informations à jour sans avoir besoin d'actualisations manuelles ou d'appels API constants. Cette approche révolutionne l'expérience utilisateur, permettant aux utilisateurs de visualiser instantanément l'état et les performances de leurs charges de travail de manière unifiée et simplifiée. Qu'il s'agisse de surveiller l'utilisation des ressources, de rester informé des événements Kubernetes ou de garder un œil sur l'état des applications, notre solution de streaming côté serveur rassemble toutes les informations critiques dans un tableau de bord unique en temps réel, mais cela sera applicable à tous ceux qui souhaitent fournir des données de diffusion en direct à l'interface utilisateur.
Il est révolu le temps où il fallait naviguer à travers plusieurs outils et plateformes pour recueillir des informations essentielles. Grâce à notre approche rationalisée, les utilisateurs peuvent accéder à un aperçu complet de leur environnement Kubernetes dès qu'ils accèdent à notre portail de plateforme. En exploitant la puissance du streaming côté serveur, nous avons transformé la façon dont les utilisateurs interagissent avec leurs charges de travail et les surveillent, rendant leur expérience plus efficace, intuitive et productive.
À travers notre série de blogs, nous visons à vous guider à travers les subtilités de la configuration du streaming côté serveur avec des technologies telles que React.js, Envoy, gRPC et Golang.
Il y a trois composantes principales impliquées dans ce projet :
1. Le backend, qui est développé à l'aide de Golang et utilise le streaming côté serveur gRPC pour transmettre des données.
2. Le proxy Envoy, qui est chargé de rendre le service backend accessible au monde extérieur.
3. Le frontend, qui est construit à l'aide de React.js et utilise grpc-web pour établir la communication avec le backend.
La série est divisée en plusieurs parties pour s'adapter aux diverses préférences linguistiques des développeurs. Si vous êtes spécifiquement intéressé par le rôle d'Envoy dans le streaming ou si vous souhaitez en savoir plus sur le déploiement d'un proxy Envoy dans Kubernetes, vous pouvez passer à la deuxième partie (Envoy en tant que proxy frontend dans Kubernetes) et explorer cet aspect ou simplement vous intéresser au partie frontale, vous pouvez alors simplement consulter la partie frontale du blog.
Dans cette première partie, nous nous concentrerons sur le segment le plus simple de la série : « Comment configurer le streaming côté serveur gRPC avec Go ». Nous allons montrer des exemples d'applications avec streaming côté serveur. Heureusement, il existe une multitude de contenus disponibles sur Internet sur ce sujet, adaptés à votre langage de programmation préféré.
Il est temps de mettre notre plan à exécution ! En supposant que vous ayez une compréhension de base des concepts suivants, passons directement à la mise en œuvre :
Maintenant, commençons par l'implémentation du code.
Étape 1 : Créer le fichier proto
Pour commencer, nous devons définir un fichier protobuf qui sera utilisé à la fois côté client et côté serveur. Voici un exemple simple :
syntax = "proto3"; package protobuf; service StreamService { rpc FetchResponse (Request) returns (stream Response) {} } message Request { int32 id = 1; } message Response { string result = 1; }
Dans ce fichier proto, nous avons une seule fonction appelée FetchResponse qui prend un paramètre Request et renvoie un flux de messages de réponse.
Before we proceed, we need to generate the corresponding pb file that will be used in our Go program. Each programming language has its own way of generating the protocol buffer file. In Go, we will be using the protoc library.
If you haven't installed it yet, you can find the installation guide provided by Google.
To generate the protocol buffer file, run the following command:
protoc --go_out=plugins=grpc:. *.proto
Now, we have the data.pb.go file ready to be used in our implementation.
Step 3: Server side implementation
To create the server file, follow the code snippet below:
package main import ( "fmt" "log" "net" "sync" "time" pb "github.com/mnkg561/go-grpc-server-streaming-example/src/proto" "google.golang.org/grpc" ) type server struct{} func (s server) FetchResponse(in pb.Request, srv pb.StreamService_FetchResponseServer) error { log.Printf("Fetching response for ID: %d", in.Id) var wg sync.WaitGroup for i := 0; i < 5; i++ { wg.Add(1) go func(count int) { defer wg.Done() time.Sleep(time.Duration(count) time.Second) resp := pb.Response{Result: fmt.Sprintf("Request #%d for ID: %d", count, in.Id)} if err := srv.Send(&resp); err != nil { log.Printf("Error sending response: %v", err) } log.Printf("Finished processing request number: %d", count) }(i) } wg.Wait() return nil } func main() { lis, err := net.Listen("tcp", ":50005") if err != nil { log.Fatalf("Failed to listen: %v", err) } s := grpc.NewServer() pb.RegisterStreamServiceServer(s, server{}) log.Println("Server started") if err := s.Serve(lis); err != nil { log.Fatalf("Failed to serve: %v", err) } }
In this server file, I have implemented the FetchResponse function, which receives a request from the client and sends a stream of responses back. The server simulates concurrent processing using goroutines. For each request, it streams five responses back to the client. Each response is delayed by a certain duration to simulate different processing times.
The server listens on port 50005 and registers the StreamServiceServer with the created server. Finally, it starts serving requests and logs a message indicating that the server has started.
Now you have the server file ready to handle streaming requests from clients.
Stay tuned for Part 2 where we will continue to dive into the exciting world of streaming data and how it can revolutionize your user interface.
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!