Quand Golang rencontre une mise à mort instantanée à haute concurrence ~

Ce qui suit est tiré de la colonne tutoriel Golang pour vous présenter lorsque Golang rencontre des pics de concurrence élevés. J'espère que cela vous sera utile. amis dans le besoin !

C'est aussi une occasion occasionnelle de rencontrer le langage GO. Je fais des choses liées à l'architecture au travail, je dois donc faire attention aux langages nouveaux et populaires. De cette façon, je suis entré dans le monde du langage GO. GO m'a apporté une nouvelle expérience

Les gens qui faisaient une chose se retrouvent souvent piégés par une chose. Quand j'ai commencé à pratiquer le langage GO, je me suis toujours senti. Tout est gênant, notamment en ce qui concerne la structure en tant que classe et l'héritage de la structure. L'aspect écriture est vraiment difficile à gérer quand on réfléchit trop. Mais au fur et à mesure que j'écris, je m'y habitue progressivement, et cela devient même de plus en plus agréable à mes yeux.

Après m'être familiarisé avec GO pendant un moment, je me suis arrêté un moment et j'ai continué à penser à la simplicité de GO (le style de code est le même, il est concis et pas bâclé à utiliser, le déploiement est extrêmement simple , et la vitesse de compilation peut être qualifiée de rapide) ), quels changements cela peut-il apporter au système et à l'architecture du projet. Mais à ce moment-là, je ne m'attendais vraiment pas à ce que cela soit utile. Plus tard, le système a progressivement commencé à être implémenté avec GO. Après l'avoir utilisé davantage, j'ai lentement découvert :

Hé ~, tu n'es plus. besoin de créer un environnement dépendant pour le déploiement (non Lors du déploiement des versions de l'environnement, je n'y étais vraiment pas habitué au début. J'ai toujours eu l'impression qu'il manquait quelque chose ;

Je n'ai ressenti aucune résistance en regardant le code écrit par d'autres. Bien qu'une partie du code n'ait pas été écrite par moi-même, quand je le lis attentivement, j'ai l'impression de l'avoir écrit moi-même. Lorsque j'écris JAVA et PHP, je refuse du fond du cœur de lire le code ; sera en ligne dans quelques secondes ~;

Ce qui précède parle principalement de ma rencontre avec GO et de l'impact initial que GO a eu sur moi. Une nuit seulement, une idée m'est soudainement venue à l'esprit. La simplicité du langage GO a apporté de nombreuses améliorations et le système architectural dans lequel je suis engagé. in GO peut-il également être utilisé pour simplifier et réduire la complexité du système? Cette idée me trotte dans la tête depuis qu'elle est apparue. En repensant à l'époque où j'ai commencé à travailler sur l'architecture, j'étais très enthousiasmé lorsque j'ai vu les principes du middleware et les optimisations qui pourraient améliorer les performances. J'ai étudié dur jusqu'à ce que je sente que je le maîtrisais (bien sûr, je veux toujours), et. Ensuite, j'ai juré de l'utiliser. Dans le système, je pense que plus le système utilise de composants middleware, mieux c'est. Plus le système a de composants middleware, plus il devient puissant. Mais à mesure que vous le faites pendant une période plus longue, vous constaterez que le système doit simplement être utilisable et que vous ne pouvez pas le construire pour des raisons d'architecture. Soustraire à la pile technologique traditionnelle nécessite également des connaissances approfondies, car ce n'est qu'en comprenant pleinement les principes techniques que nous pouvons la remplacer, et alors seulement pouvons-nous oser penser et le faire sans causer de problèmes. Comme le dit le proverbe : « Tous les continents mènent à Rome ». D'un point de vue personnel, l'architecture doit être adaptée à l'entreprise de l'époque. Le but de la conception architecturale est de réaliser le plus de choses possible au moindre coût. consommant des ressources du serveur. Dans certains cas, il peut prendre en charge plusieurs fois, voire des dizaines de requêtes. Lorsque le même volume de requêtes est atteint, la mise en œuvre et le déploiement sont très simples et exploitables. Les pensées de GO m'ont subtilement influencé pendant cette période.

Jusqu'à ce que notre entreprise décide de créer des microservices, nous utilisions Java pour créer des microservices au début. Plus tard, j'ai réfléchi à la question de savoir si d'autres langages pouvaient également créer des microservices, et naturellement j'ai pensé à GO. Après de nombreuses discussions, j'ai senti que tout allait bien, alors j'ai commencé à écrire des microservices en utilisant GO. écrire, j'ai trouvé que Golang est assez bon pour écrire des microservices. C'est pratique, c'est tellement efficace et vous n'avez pas besoin d'encapsuler Tomcat (il semble très inapproprié de mettre cette chose dans un package jar. Les binaires peuvent s'exécuter dans Docker sans). dépendances du système (essayez-le si vous ne me croyez pas). Du fond du cœur, ça va de mieux en mieux. Plus j'aime GO, plus je veux utiliser GO pour reconstruire les systèmes suivants (j'écris beaucoup de choses). Java, et quand je rencontre une telle commodité, j'ai l'impression d'avoir découvert Spring). GO a profondément affecté la vision de l'architecture du système.

Mais qu'est-ce que l'architecture exactement, et comment est formé un architecte ? Voici huit étapes de difficultés pour devenir architecte :

Le premier paragraphe : Déplacer les briques est divisé en ceux qui peuvent le faire. . Ceux qui sont doués pour déplacer des briques et ceux qui ne peuvent déplacer que des briques (un groupe de personnes reste dans le déplacement de briques, et les autres continuent de se développer) Deuxième paragraphe : Ceux qui peuvent déplacer des briques peuvent être divisés ; entre ceux qui ont besoin de comprendre les principes et ceux qui peuvent programmer et déplacer des briques

Le troisième paragraphe : Ceux qui comprennent les principes peuvent être divisés en ceux qui recherchent constamment et ceux qui ont un peu de connaissances ; ;

Le quatrième paragraphe : La recherche continue peut également être divisée en deux types : la recherche est approfondie, l'étendue et la connaissance superficielle L'ampleur ;

Cinquième paragraphe : Celles qui ont de la profondeur et de l'étendue ; l'étendue est divisée en types purement techniques et commerciaux (commençant à se différencier

Sixième paragraphe : Les types d'entreprise nécessitent une bonne communication, et Ceux qui ont certaines capacités de conception et de contrôle du système et des exigences ;

Paragraphe 7 : Il est facile pour quelqu'un de ce niveau d'utiliser simplement un middleware tas pour construire un système « architecture » (architecte junior) ;

Paragraphe 8 : Un point très important à ce niveau est de considérer le problème soigneusement, de manière complète et soyez bon en communication. Effectuez la mise en œuvre sous-jacente, comprenez les principes sous-jacents et partez de plusieurs perspectives en matière d'entreprise, de R&D, de tests, de déploiement, de maintenance et de mises à niveau. L'« architecture » construite en fonction des conditions locales est axée sur l'efficacité du développement, l'efficacité opérationnelle, la qualité du développement et la flexibilité commerciale. et la stabilité du fonctionnement. Pour faciliter la maintenance, ces personnes peuvent être appelées architectes (si vous avez de l'expérience dans ce domaine, pensez au nombre d'architectures qui sont belles en surface, mais qui sont en réalité inconfortables à utiliser).

Lors de la création d'un système de vente flash, la pile technologique traditionnelle qui vient à l'esprit au premier abord et la plus simple à penser est la session distribuée, le cluster Redis, le cache distribué, le proxy inverse nginx, l'optimisation en profondeur nginx, l'optimisation de la machine et les messages. file d'attente . Oui, M. Cap y avait également pensé à l'époque et pensait que l'application de ces technologies « matures » à notre système de vente flash ne poserait aucun problème. De plus, des discussions internes au sein de l'entreprise ont estimé qu'il n'y aurait aucun problème avec cela. ce. Et nous avons effectué des recherches approfondies, telles que :

1. Session distribuée Nous avons déployé beaucoup d'efforts pour utiliser le cluster Nginx+web+redis pour enregistrer la session afin d'atteindre l'objectif de vérification de session, un seul -point Session L'architecture est telle que présentée dans la figure ci-dessous :

À première vue, il n'y a pas de problème. C'est ainsi que cela se fait lorsque le trafic est vraiment important. , Nginx et le serveur Web sont ajoutés. Il répond à l'expansion horizontale, mais une fois que le trafic atteint des centaines de millions, le coût de notre porte est un peu élevé. Nous voulons également réduire le temps des sessions de requêtes réseau aller-retour (à). cette fois-là, j'ai toujours senti que quelque chose n'allait pas), et nginx apparaît également 504 de temps en temps sous un trafic élevé.

　2. Cache distribué, cette chose semble très simple, mais c'est une chose très compliquée dans un système à fort trafic et à haute concurrence. Les problèmes suivants peuvent être rencontrés principalement :

　1. ) Cohérence du cache (si vous l'utilisez, une survente se produira si elle n'est pas bien gérée)

　2) Pénétration du cache

　3) Avalanche du cache

　4) Cache trou noir Question :

5) Effet pile de chien

…..Il y a beaucoup de choses auxquelles il faut prêter attention. En bref, le cache distribué est très polyvalent et précieux, mais la construction d'un système de cache distribué capable de répondre à une concurrence élevée et à un trafic important nécessite une équipe technique très solide. Support, la mise en œuvre est également très compliquée, donc je n'entrerai pas dans les détails ici

Cependant, notre solution apparemment sans problème a d'énormes problèmes. Elle est « trop difficile » à mettre en œuvre, et le seuil est. haut. Le coût des ressources est également assez élevé. La session doit répondre à l'expansion horizontale, et le cache Web doit également répondre à l'expansion horizontale, y compris le cluster redis. Le seul moyen est d'ajouter continuellement des clusters

Donnez un exemple simple (Mettant de côté les autres). facteurs, afin d'illustrer l'importance de l'architecture), supposons que nous ayons désormais une seule machine, que l'interface ait une capacité de traitement de 5000 QPS (8 cœurs et 8G), et qu'elle doive gérer des centaines de millions de trafic pour la vente flash Le trafic instantané au début de la vente flash est estimé à 300W, et le temps d'attente moyen est calculé sur la base de 7 secondes (l'interface tolère jusqu'à 3,5WQPS). Le résultat est que notre système nécessite près de 90 interfaces. Cela n'inclut pas les autres serveurs de support avec les mêmes exigences. Ces serveurs de support sont brièvement décrits comme suit ;

1. Tout d'abord, le niveau nginx doit avoir le même niveau de capacités de traitement (chaque unité est d'environ 1 000 $). 2WQPS sans optimisation, estimé à environ 20 unités);

2. L'interface Web doit également être étendue au niveau correspondant (Estimé à 90 unités

3. Le cluster Reids comporte plusieurs produits); dans certains cas (pour les produits individuels, le cluster est inutile lorsqu'il y a un grand nombre de visites)

Ce qui précède est distribué. Les exigences de la machine auxquelles Session doit répondre n'incluent pas le cache distribué. à quel point il est difficile de créer et de mettre en œuvre un système de vente flash, et la complexité du déploiement n'a pas été prise en compte. C'est vraiment compliqué à mettre en œuvre, et une ou deux personnes avec 4 à 5 ans d'expérience ne peuvent vraiment pas le réaliser en peu de temps. Pouvez-vous penser à d’autres moyens de le simplifier ? La réponse est : oui. Premièrement, il faut comprendre le principe, et deuxièmement, il faut faire des soustractions à l'architecture. Si vous ne l'utilisez pas, il n'est pas nécessaire de l'optimiser.

Où devrions-nous optimiser ?

1) La session peut être omise dans la simultanéité Flash Kill sur la base du principe de vérification des autorisations

2) Nous ne pouvons pas utiliser la mise en cache distribuée ( remplacé par interface);

3) Omettre nginx (réduit la difficulté de fonctionnement et de maintenance);

4) Le cluster redis peut également être omis

De cette façon ; , comment faire des ventes flash ? Ce n'est pas que cela ne puisse pas être réalisé avec Java et PHP, mais cela peut être difficile à mettre en œuvre, mais maintenant cela peut être combiné avec les fonctionnalités du langage GO pour nous fournir de nouvelles idées

1. Nginx peut être omis, utilisez directement GO pour démarrer le service d'exposition de port (nginx peut être omis ici

2. Utilisez la méthode cookie ou la méthode wt pour remplacer la solution de session distribuée et le serveur-) ; vérification du niveau de code latéral ;

3. Oversell utilise le formulaire d'interface au lieu du cluster Redis ;

4. L'équilibrage de charge utilise un SLB bon marché (en évitant Nginx) ; , l'architecture présidentielle peut être affichée comme la structure ci-dessous, méthode détaillée Veuillez vous référer à "Go High Concurrency Flash Kill Practice" :

D'après les résultats de la transformation, nous avons principalement listez les éléments suivants :

1. Les applications Web utilisent toutes Go Pour la méthode de déploiement des fichiers binaires, le serveur centos n'a besoin de suivre aucune dépendance (ce qui facilite grandement le déploiement) :

2. Utilisez SLB une solution bon marché et pratique pour éviter le proxy inverse nginx, et même les scripts Lua avancés peuvent l'éviter ;

3. Le cluster Redis est également évité ici et les services sont fournis via des interfaces

L'ensemble de la pile technologique n'a besoin que de connaître : GO, RabbitMQ et Mysql pour réaliser des ventes flash à haute concurrence. Le système est très attractif en termes de facilité d'utilisation, vous pouvez le déduire sur la base de l'architecture ajustée ci-dessous (actuellement autonome) ; GO fournit une interface Web, qui peut probablement atteindre 2WQPS sans optimisation) :

1. Les performances de vérification des autorisations de l'interface GO sur une seule machine ont été améliorées de 4 fois et la complexité du déploiement peut être considérée comme proche de zéro (pas de nginx, pas de cluster Redis et pas d'environnement dépendant pour le fonctionnement) ;

2. À mesure que le niveau de trafic continue d'augmenter, pour vous améliorer, il vous suffit d'ajouter des serveurs Web et des serveurs de contrôle de quantité, et il y a aucune autre surcharge de service (on peut dire que l'évolutivité réduit les coûts autant que possible, avec un modèle de croissance proportionnel et aucun goulot d'étranglement de performances

　3. Comparaison Avec la solution traditionnelle, le nombre de serveurs est réduit) ; par plus de 4 fois (vous pouvez le calculer sur la base d'origine)

La solution ci-dessus est implémentée sur la base de la simplicité du langage GO. Il arrive que la commodité du déploiement de GO améliore la facilité de déploiement. En termes de mise en œuvre, il arrive que GO puisse fournir des services Web et réduire les dépendances externes (les performances du service Web lui-même sont également très élevées). Avec les deux fonctionnalités juste à temps de GO, il n'est pas difficile de mettre en œuvre le système de vente flash dans son ensemble en soustrayant l'architecture correspondante. Bien sûr, Java et PHP peuvent implémenter l'architecture de vente flash ajustée dans l'image ci-dessus. mais à bien des égards, le président a toujours un net avantage sur GO.

En repensant au plan, j'ai l'impression que Go a entraîné des changements dans les modes de pensée, que sa simplicité a conduit à une mise en œuvre simple, et que sa grande efficacité et sa stabilité ont conduit à une optimisation architecturale. Une bonne architecture système doit être simple, efficace et facile à mettre en œuvre ;

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!