Harrigan.
Et bienvenue à nouveau.
Dans la vidéo d'aujourd'hui, nous allons aborder les principes de base du service Amazon US.
Maintenant, avant de nous lancer dans une discussion détaillée, prenons un cas d'utilisation simple qui nous
permettra de comprendre les avantages qu'il offre.
Le cas d'utilisation de la vidéo d'aujourd'hui est une application qui sert principalement à restaurer une image.
Supposons donc qu'une entreprise moyenne conçoive une application qui améliorera et restaurera les images que les
utilisateurs soumettent au portail en ligne.
Il existe donc de nombreuses applications où vous pouvez donner l'image et où ils
l'amélioreront.
C'est donc ce que la Medium Corp est en train de construire.
Maintenant, dans le cadre de l'architecture de l'application, il y a deux composants qui sont impliqués.
Le premier est le collecteur d'images et le second est l'exhausteur d'images.
Le collecteur d'images est donc chargé de prendre l'image de l'utilisateur via le bouton de téléchargement.
Ainsi, dès qu'un utilisateur télécharge une image, celle-ci est transmise à l'application
de collecte d'images, puis cette dernière l'envoie à l'outil d'amélioration d'image, qui est chargé de l'améliorer
et de la convertir.
Ce type d'architecture a l'air bien.
Maintenant, l'un des défis à relever est de savoir ce qui se passe lorsque cette image améliore le serveur et qu'elle tombe en panne.
Ainsi, le collecteur d'images fonctionne bien, l'utilisateur peut télécharger l'image, mais lorsque le collecteur d'images
envoie l'image à l'exhausteur d'images, le serveur est bloqué.
C'est donc l'un des défis à relever dans le cadre d'une architecture actuelle.
Le deuxième type de défi est lié à la haute disponibilité.
Supposons donc qu'en raison de la popularité de l'application et de l'énorme pic de trafic, Medium Core a décidé d'ajouter un plus
grand nombre de serveurs d'extension.
Donc maintenant vous en avez deux.
Donc maintenant, la société moyenne a ajouté deux serveurs d'amélioration supplémentaires.
Ainsi, si l'un des serveurs tombe en panne, le collecteur d'images sera en mesure d'envoyer le trafic vers les
autres serveurs.
Ainsi, pour que le collecteur d'images découvre les derniers serveurs en fonctionnement, il faut créer une base
de données et un fichier de configuration contenant les informations pertinentes.
Donc, dans ce cas, vous avez un fichier de configuration qui contient quatre serveurs.
Vous avez donc un serveur A, un serveur B, un serveur C, un serveur D, et chaque serveur a une adresse IP associée.
Et ce que fait le collecteur d'images, c'est d'envoyer les images à travers chacune des adresses IP.
Maintenant, bien que cela semble bon, mais l'un des défis qui se présente est de dire que ce serveur
est tombé en panne.
Le collecteur d'images n'a aucun moyen de savoir que le serveur est hors service. Il faut donc prévoir une logique supplémentaire
au niveau du serveur d'images pour vérifier l'état de santé de tous les serveurs.
Et si le contrôle de santé échoue, l'entrée du fichier de configuration associée à ce serveur doit également être
supprimée.
L'application de collecte d'images doit donc faire plus que simplement collecter des images, ce qui pose
de nombreux défis.
Pour surmonter ce problème, il existe une meilleure architecture qui consiste à utiliser une file d'attente.
Donc, ce qui se passe ici, c'est que vous concevez une file d'attente et ce que le collecteur d'images va faire.
Tout ce qu'il doit faire, c'est envoyer l'image à la file d'attente, puis au rehausseur d'image.
Tout ce qu'ils sont responsables de faire, c'est de prendre le message dans la file d'attente et c'est
tout.
Vous n'avez pas vraiment besoin de vous soucier d'autre chose.
Ainsi, au niveau du collecteur d'images, il n'est pas vraiment nécessaire d'obtenir les dernières adresses IP des serveurs, de faire
le contrôle de santé et de créer une logique supplémentaire.
Très bien.
Voilà donc ce qu'est la file d'attente.
L'une des principales fonctions du service de file d'attente de messages est de prendre un message d'un éditeur et
de le transmettre à un consommateur.
Ainsi, dans notre architecture, l'éditeur devient le collecteur d'images et le consommateur devient l'exhausteur
d'images.
Il s'agit donc d'une architecture de haut niveau.
Il faut s'assurer que, puisque le collecteur d'images envoie les images à la file
d'attente, celle-ci doit être toujours disponible, car si la file d'attente tombe en panne, aucune
des images ne pourra être prise par le rehausseur d'images.
Il s'agit donc de l'un des composants architecturaux les plus critiques dans ce cas d'utilisation spécifique dont
nous avons discuté, et ce défi d'avoir une file d'attente fiable et hautement disponible est relevé par le service Amazon Queues.
Pour résumer, Amazon asks est un service de mise en file d'attente des messages rapide, fiable, évolutif
et entièrement géré, qui permet de découpler les composants d'une application spécifique de manière
simple et rentable.
Ce que vous devez faire maintenant, c'est que vous avez déjà un collecteur d'images, vous avez déjà un exhausteur d'images.
Ce que vous faites, c'est que vous créez un hautement.
Fiabilité et fiabilité.
Q Avec l'aide de Sky Service et configurer votre collecteur d'images pour envoyer un message à la file d'attente et configurer
le rehausseur d'image pour prendre le message de la Q Et c'est tout.
Il s'agit donc de l'architecture de base, alors allons-y et essayons-la afin de mieux la comprendre.
Donc actuellement je suis dans la console Amazon et actuellement nous en avons une.
Q Avec le nom du message.
Q Et actuellement, il n'y a aucun message disponible.
Maintenant, nous avons également deux instances EC deux pour la démo d'aujourd'hui.
L'une porte le nom d'image, la seconde porte le nom d'amplificateur d'image.
Ainsi, pour la démonstration d'aujourd'hui, le collecteur d'images, easy to instance, enverra certains messages à ce Q et
le rehausseur d'images, easy to instance, ira chercher le message dans les UGS.
Q Donc c'est l'architecture de base, quelque chose à ce que nous verrons.
Alors essayons.
Actuellement, dans mon terminal de recherche, j'ai créé deux onglets.
Le premier onglet est associé à la galerie d'images.
Le deuxième onglet est associé au rehausseur d'image.
Donc à l'intérieur, allons-y et exécutons le script et le nom d'un script est envoyer des messages.
Donc cela va aller de l'avant et envoyer des messages aux États-Unis.
Q. Alors laissez-moi le faire.
Donc, actuellement, vous voyez qu'il a envoyé cinq messages aux États-Unis.
Q. Maintenant, ici, si nous rafraîchissons rapidement la page, vous voyez que les messages qui sont disponibles sont au nombre de cinq maintenant
à partir de l'amplificateur d'image, qui est responsable de la consommation du message.
Nous avons également un script supplémentaire disponible.
Les collègues reçoivent un message qui est : "Exécutons-le".
Donc, à ce stade, vous voyez qu'il a reçu un ensemble de messages des États-Unis.
Q Maintenant, si vous courez encore une fois, il a reçu une autre série de messages des États-Unis.
Q Donc, par exemple, disons que le premier est l'image.
Il a donc pris l'image, il a terminé le travail.
Maintenant encore, il va aller chercher un nouvel ensemble d'images qui font partie des États-Unis.
Q Et ensuite il traitera les images.
Une fois le traitement terminé, il ira chercher les images les plus récentes qui font partie des États-Unis.
Q Donc, si je rafraîchis rapidement la page, vous voyez que les messages disponibles sont maintenant réduits à deux.
Maintenant, en fait, les messages qui font partie des États-Unis.
Q Vous pouvez également le visualiser depuis la console.
Donc, si je fais rapidement une recherche complète des messages ici, vous devriez voir qu'il y a plusieurs messages disponibles et
ceci est essentiellement le corps du message.
Maintenant que nous avons compris les bases de la voix.
Q Allons de l'avant et comprenons certains des concepts importants spécifiquement liés à un système étroitement couplé
et un système faiblement couplé.
Ainsi, dans un système à couplage étroit, les composants de l'architecture d'un système communiquent directement
entre eux et dépendent fortement les uns des autres.
Ainsi, par exemple, vous avez un producteur et un consommateur.
Le producteur envoie donc directement un message au consommateur.
Ainsi, si un consommateur est en panne, le producteur commencera essentiellement à envoyer l'autre message aux
utilisateurs.
C'est ce qu'on appelle un système à couplage étroit.
Le deuxième type de système est appelé système à couplage lâche, dans lequel les composants de
l'architecture du système peuvent traiter l'information sans être directement connectés.
Donc, vous avez un producteur, vous avez un Q, vous avez un consommateur.
Donc maintenant, si les consommateurs sont en baisse, le producteur n'a pas vraiment besoin de s'inquiéter.
Donc, tout ce que le producteur peut faire, c'est de prendre l'image de l'utilisateur et de l'envoyer à la file d'attente,
puis de renvoyer un message de réussite à l'utilisateur.
C'est à peu près tout.
Une fois que l'ensemble des consommateurs est de nouveau en ligne, ils vont chercher le message dans la file d'attente, puis
ils effectuent le niveau de traitement nécessaire.
Il s'agit donc d'un type d'architecture bien meilleur.
Et en fait, la plupart des architectures que vous verrez dans l'environnement de production sont
basées sur le système à couplage lâche.
C'est très important.
C'est génial.
Il s'agit donc d'une vue d'ensemble de très haut niveau sur le service et c'est ainsi que se termine la vidéo d'aujourd'hui.