Webinaire ouvert "Développement de systèmes hautement chargés en PHP"

Bonsoir En prévision du début du cours «Développeur PHP Backend», nous avons traditionnellement organisé une leçon ouverte. Ils ont parlé de systèmes très chargés, de mise à l'échelle, d'architecture. Nous avons examiné en détail HighLoad, ainsi que les principales approches et tactiques dans le développement de systèmes hautement chargés.

Les objectifs suivants de la leçon ont été fixés:

• discuter de ce qu'est l'architecture du système et pourquoi elle est nécessaire;
• discuter de ce qu'est une charge élevée;
• envisager des tactiques architecturales;
• discuter du cours.

Conférencier - Igor Sakhankov , développeur chez Booking.com.

L'architecture

Il y a quelques centaines d'années, le roi suédois Gustaf II Adolf voulait construire le plus grand navire du monde. Il a invité le constructeur naval néerlandais Henrik Hubertsson et lui a donné ses instructions. Le capitaine n'a jamais rien construit de tel, mais il avait une vaste expérience dans la construction de navires de petites tailles. Il semblerait qu'il n'y ait rien de compliqué - prenez un dessin d'un petit navire et agrandissez-le le bon nombre de fois. Aussitôt dit, aussitôt fait. Et ainsi, après plusieurs années de travail, une construction merveilleuse et grandiose est apparue:



Tout irait bien, mais lors du lancement, ce navire n'a pas duré même une demi-heure, coulant immédiatement. C'était le navire de guerre à voile Vasa, et c'est arrivé en 1628.

Imaginez maintenant qu'on vous demande de faire un nichoir ou un nichoir pour chien. Bien sûr, la plupart d'entre nous devront faire face à cette tâche. Et si on lui demandait de faire un gratte-ciel?

Tous ces exemples suggèrent que plus le système est complexe, plus il présente diverses interdépendances, nuances de mise en œuvre et pièges. Et pour réussir à concevoir et créer des systèmes complexes, il n'y a que des modèles architecturaux.

En termes académiques, l'architecture des systèmes d'information est un concept qui définit le modèle, la structure, les fonctions et l'interconnexion des composants IP.

Cependant, revenons de la construction de navires et de maisons à la programmation. Regardez, nous avons toujours des exigences qui nous viennent de l'entreprise. Et l'architecture aide à les convertir en exigences techniques. En fonction des exigences techniques reçues, vous pouvez facilement décomposer le système, écrire les dépendances entre les modules et procéder à l'implémentation directe.



Ainsi, l'architecture:

• Aide à fournir des exigences système non fonctionnelles
• C'est un moyen de communication entre les parties prenantes;
• optimise les coûts, réduit le coût des grands systèmes;
• vous permet de réutiliser les modèles architecturaux, de prendre en compte l'expérience précédente, de ne pas répéter les erreurs passées

Charge élevée

Le concept de charge élevée en lui-même est très relatif et il n'y a pas de définition établie. Cependant, il est sûr de dire que ce moment arrive lorsque votre infrastructure actuelle cesse de faire face à la charge. Et cela signifie qu'il est temps de faire la mise à l'échelle. Ça arrive:

• vertical. L'essentiel est simple: si le fer ne peut pas faire face, nous achetons du neuf, super puissant, productif et cher;
• horizontal. Nous avons un serveur qui ne peut pas faire face. Nous achetons un deuxième serveur avec les mêmes caractéristiques, puis un troisième, et ainsi de suite. A la sortie, nous avons beaucoup de machines relativement sans prétention.

Tactiques architecturales

Tout le monde connaît une chose comme une file d'attente ( FIFO ). Il s'agit d'une façon d'organiser le traitement des données, qui vous permet de répondre à des exigences contradictoires en rationalisant le processus selon le principe du «premier arrivé, premier sorti». La file d'attente peut être utilisée comme moyen d'équilibrage de charge, de découplage du client et du serveur, et bien plus encore.

Avantages:

• mauvaise connectivité client et serveur;
• L'état de la tâche est connu.
• configuration à la volée;
• équilibrage de charge.

Inconvénients:

• entité supplémentaire dans le système;
• traitement des tâches plus complexe;
• perte / duplication de messages.

Parlons maintenant de ce que vous pouvez faire avec le référentiel . Le stockage fait référence à tout système de stockage, comme les bases de données relationnelles. Nous avons donc les options suivantes pour résoudre les problèmes de stockage:

1. Réplication.



L'un des problèmes de stockage connus est lié à la situation où nous avons beaucoup de lectures et pas assez d'enregistrements. Il peut s'agir d'un site d'actualités - tout le monde lit les actualités, mais seuls les administrateurs ajoutent de nouveaux documents. Ainsi, la réplication se situe à peu près au moment où notre stockage est tombé en lecture, et nous avons des retards dans le système. Il est important de noter ici que la réplication résout le problème de la lecture, mais pas de l'écriture. Non seulement cela, il dégrade quelque peu la capacité des bases de données à écrire, car il doit distribuer des parties de ses données sur des répliques, comme cela est visible dans l'image ci-dessus. Dans le cas le plus simple, lors de la configuration de la réplication, nous avons un maître - la base de données principale dans laquelle nous écrivons et des esclaves - des copies de la base de données (répliques à partir desquelles toutes les données sont lues).

2. Partitionnement . Supposons que nous ayons une grande table, mais nous n'utilisons que quelques données. Nous pouvons le briser en morceaux. Par exemple, nous prenons nos données et les mettons dans différentes assiettes selon le mois. Le résultat est de petites tables au lieu d'une grande et, par conséquent, des échantillons plus rapides pour un mois particulier. Cela optimise le temps d'exécution des requêtes.

CREATE TABLE my_table (id INT, amount DECIMAL(7,2), some_date DATE) ENGINE=INNODB PARTITION BY HASH( MONTH(some_date) ) PARTITIONS 6; 

3. Partage vertical . Dans le cas du partitionnement, nous parlions d'un serveur et d'une base de données. Dans le cas du sharding, nous avons plusieurs voitures et plusieurs bases. Nous prenons toutes nos données, les divisons en groupes logiques, et chaque groupe logique est stocké dans une base de données distincte.

 $users = new PDO("pgsql:db_name=my_db;host=192.168.1.1", "user", "password"); $photos = new PDO("pgsql:db_name=my_db;host=192.168.1.2", "user", "password"); $users->prepare('SELECT * FROM users ...'); $photos->prepare('SELECT * FROM photos ...'); 

La méthode est facile à mettre en œuvre et met bien à l'échelle la charge. Mais il présente également des inconvénients, qui sont décrits plus en détail dans la vidéo.

4. Partage horizontal . Ici, chaque fragment se trouve sur une machine distincte.



Recette

Les points suivants vous aideront à créer un système évolutif:

• simplifier au niveau des exigences!
• ne complique pas la décision
• essayez d'être apatride,
• cache
• surveillance + alerte,
• être compétent.

Chers collègues, le récit est plutôt concis, il est donc préférable de regarder l'intégralité du webinaire. Ne manquez pas non plus la journée portes ouvertes du cours "Backend PHP Developer".