nginx front-end, le back-end est constitué de n conteneurs docker et le conteneur docker est nginx+php-fpm. On sait que chaque conteneur peut échouer. Lorsque le conteneur échoue, le front-end aura un 502 ou 504. erreur, et le front-end aura parfois des retards de réseau
Pratiques et problèmes actuels
En supposant que l'intervalle est défini sur 3 s et que la chute est de 2, alors si le backend raccroche immédiatement après la dernière vérification, c'est-à-dire que la demande sera toujours transmise au backend défectueux pendant près de 6 s
En supposant que le délai d'attente est défini sur 1 s, alors si le réseau frontal est retardé, tous les back-ends expireront instantanément et 502 seront renvoyés directement à l'utilisateur. Mais si vous augmentez la valeur du délai d'attente, le contrôle de santé n'aura pas beaucoup de sens. Normalement, le backend répondra dans un délai de 50 ms et ne pourra plus filtrer les backends à charge élevée
Comme ci-dessus, s'il meurt dans l'intervalle, certaines requêtes arrivent toujours au backend. Si la charge du backend fluctue fréquemment au seuil, alors les erreurs 5xx peuvent être plus que sans contrôle de santé et sysguard
Y a-t-il une solution ?
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Je ne sais pas à quoi ressemble votre scénario d'application front-end. Il semble que la charge soit très élevée. Il est peu probable que l'erreur soit directement exposée à l'utilisateur. Tout au plus, cela l'invitera à réessayer. plus tard, dans cette étude approfondie, nous devons encore examiner l'architecture technique. Trouver la racine du problème
.Personnellement, je pense que cette chose est inévitable. Lorsque la charge est lourde, j'optimiserai le programme ou augmenterai le cluster. L'erreur se produira toujours. J'écris simplement un nom vague.
.Taobao est aussi souvent occupé avec le système. Zhihu fournit son propre serveur lorsque rien ne se passe Question