Un article pour comprendre le délai de livraison des microservices

                                                                                                            ？ Pourquoi avez-vous besoin d'un contrôle de délai d'attente ?

Un problème courant dans de nombreux scénarios de défaillance en cascade est que le serveur consomme beaucoup de ressources pour traiter les demandes qui ont déjà dépassé le délai du client. Le résultat est que le serveur consomme beaucoup de ressources sans effectuer de travail précieux, et le résultat est que le serveur consomme beaucoup de ressources pour traiter les demandes qui ont déjà dépassé le délai du client. la réponse a expiré. La demande n'a aucun sens. Le contrôle des délais d'attente peut être considéré comme une ligne de défense importante pour garantir la stabilité du service. Son essence est d'échouer rapidement. Une bonne stratégie de contrôle des délais d'attente peut éliminer les demandes à latence élevée dès que possible et libérer des ressources dès que possible pour éviter. l’accumulation des demandes.

Délai de livraison entre les services

Si une demande comporte plusieurs étapes, comme une série d'appels RPC, alors notre service doit vérifier la date limite avant le début de chaque étape pour éviter un travail inutile, c'est-à-dire vérifier s'il y a il reste suffisamment de temps pour traiter la demande. Une erreur d'implémentation courante consiste à définir un délai d'attente fixe dans chaque service RPC. Nous devons transmettre le délai d'attente entre chaque service. Le délai d'attente peut être défini au niveau supérieur de l'appel de service et l'ensemble du RPC est déclenché par la requête initiale. l’arbre fixera le même délai absolu. Par exemple, définissez le délai d'attente sur 3 secondes au niveau supérieur de la demande de service. Le service A demande le service B. Le service B prend 1 seconde pour s'exécuter, puis demande le service C. À ce stade, le délai d'attente reste de 2 secondes. 1s pour s'exécuter. C'est lorsque le service C demande ensuite le service D, le service D prend 500 ms pour s'exécuter, et ainsi de suite. Idéalement, le même mécanisme de livraison de délai d'attente est utilisé dans toute la chaîne d'appel.

Si le mécanisme de livraison du délai d'attente n'est pas utilisé, la situation suivante se produira :

Le service A envoie une demande au service B, et le délai d'expiration défini est de 3 s

Le service B prend 2 s pour traiter la demande, et continue Demander le service C

1. Si la livraison du délai d'attente est utilisée, le délai d'attente du service C doit être de 1 s, mais la livraison du délai d'attente n'est pas utilisée ici, donc le délai d'attente est de 3 s codé en dur dans la configuration
2. L'exécution continue du service C prend 2s. En fait, à ce moment-là, le délai d'attente défini par la couche supérieure a expiré et la requête suivante n'a aucun sens
3. Continuez à demander le service D
4. Si le service B adopte le mécanisme de livraison du délai d'attente, alors la requête devrait être abandonné immédiatement dans le service C, car le délai est peut-être atteint. Le client a peut-être signalé une erreur. Lorsque nous définissons le délai de livraison, nous réduisons généralement le délai de livraison, par exemple 100 millisecondes, afin de prendre en compte le temps de transmission réseau et le temps de traitement après que le client reçoit la réponse.

Transfert de délai d'attente en cours

Non seulement un transfert de délai d'attente est requis entre les services, mais également un transfert de délai d'attente au sein du processus est requis. Par exemple, Mysql, Redis et le service B sont appelés en série dans un processus, et la requête totale. le temps est défini sur 3 s. Mysql prend 1 s, puis demande à nouveau Redis. Le délai d'attente est de 2 secondes. L'exécution de Redis prend 500 ms, puis demande le service B. Le délai d'attente est de 1,5 s car chacun de nos middlewares ou services définira une valeur fixe dans la configuration. fichier. Pour le délai d'attente, nous devons prendre la valeur minimale du temps restant et du temps défini.

Context implémente la livraison avec délai d'attente

Le principe du contexte est très simple, mais sa fonction est très puissante. La bibliothèque standard de Go a également implémenté la prise en charge du contexte, et divers frameworks open source ont également implémenté la prise en charge du contexte. , le contexte est devenu une norme et la livraison en cas d'expiration dépend également du contexte. Nous définissons généralement le contexte initial en haut du service pour le transfert du contrôle du délai d'attente, par exemple, définissons le délai d'attente sur 3s

ctx, cancel := context.WithTimeout(context.Background(), time.Second*3)defer cancel()

Lorsque le contexte est transféré, comme demander Redis dans la figure ci-dessus, puis obtenez le temps restant dans de la manière suivante, puis comparez le délai d'attente défini par Redis et choisissez un délai plus petit

dl, ok := ctx.Deadline()

timeout := time.Now().Add(time.Second * 3)if ok := dl.Before(timeout); ok {
    timeout = dl}

Le transfert de délai d'attente entre les services fait principalement référence au transfert de délai d'attente lorsque RPC est appelé. Pour gRPC, nous n'avons pas besoin d'effectuer de traitement supplémentaire. gRPC lui-même prend en charge. transfert de délai d'attente.Principe Semblable à ce qui précède, il est transmis via des métadonnées et sera finalement converti en valeur de grpc-timeout, comme indiqué dans le code suivant

if v := r.Header.Get("grpc-timeout"); v != "" {
        to, err := decodeTimeout(v)
        if err != nil {
            return nil, status.Errorf(codes.Internal, "malformed time-out: %v", err)
        }
        st.timeoutSet = true
        st.timeout = to}

La livraison du délai d'attente est une ligne de défense importante pour assurer la stabilité du service. Le principe et la mise en œuvre sont très simples. Votre délai d'attente est-il implémenté dans le framework ? Sinon, agissez rapidement.

Livraison du délai d'attente en go-zero

go-zero peut configurer les services api gateway et rpc via le Timeout dans le fichier de configuration timeout et sera automatiquement transmis entre les services. Timeout 配置 api gateway 和 rpc 服务的超时，并且会在服务间自动传递。

之前的 一文搞懂如何实现 Go 超时控制 里面有讲解超时控制如何使用。

参考

《SRE：Google运维解密》

项目地址

github.com/zeromicro/go-zero

欢迎使用 go-zeroL'article précédent comprend comment implémenter le contrôle de délai d'attente Go

qui explique comment utiliser le contrôle de délai d'attente.

Référence

"SRE : Décryptage des opérations et de la maintenance de Google"🎜🎜Adresse du projet🎜🎜github.com/zeromicro/go-zero🎜🎜Bienvenue pour utiliser go-zero Et 🎜étoile/fourchette🎜 soutenez-nous ! 🎜🎜Recommandé : "🎜🎜Tutoriel Golang🎜🎜"🎜

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!