Harrigan.
Und willkommen zurück.
Im heutigen Video werden wir über die Grundlagen des Amazon US-Service sprechen.
Bevor wir nun im Detail über uns sprechen, nehmen wir einen einfachen Anwendungsfall, der es uns ermöglicht,
die Vorteile zu verstehen, die es bietet.
Der Anwendungsfall für das heutige Video ist eine Anwendung, die hauptsächlich zur Wiederherstellung eines Bildes dient.
Nehmen wir also an, dass ein mittelständisches Unternehmen eine Anwendung entwickelt, die die Bilder, die Benutzer an das Online-Portal
senden, verbessern und wiederherstellen soll.
Es gibt also viele Anwendungen, bei denen man das Bild eingeben kann und die es dann verbessern
und aufwerten.
Das ist es also, was die Medium Corp. baut.
Im Rahmen der Anwendungsarchitektur sind zwei Komponenten beteiligt.
Der erste ist der Image Collector und der zweite ist der Image Enhancer.
Der Image Gatherer ist also dafür verantwortlich, das Bild vom Benutzer über die Upload-Schaltfläche aufzunehmen.
Sobald ein Benutzer das Bild hochlädt, wird das Bild an die Bildsammler-Anwendung
weitergeleitet, die es dann an den Bildverbesserer sendet, der für die Verbesserung und Konvertierung
des Bildes verantwortlich ist.
Diese Art von Architektur klingt gut.
Eine der Herausforderungen besteht nun darin, was passiert, wenn dieses Bild, das den Server verbessert, ausfällt.
Der Image Gatherer funktioniert also gut, der Benutzer kann das Bild hochladen, aber wenn der Image Gatherer das Bild
an den Image Enhancer sendet, ist der Server erledigt.
Dies ist also eine der Herausforderungen, die in einer aktuellen Architektur zu bewältigen sein werden.
Die zweite Art der Herausforderung betrifft die hohe Verfügbarkeit.
Nehmen wir also an, dass aufgrund der Beliebtheit der Anwendung und des hohen Spitzenverkehrs der mittlere Kern beschlossen hat, eine größere
Anzahl von Enhancer-Servern hinzuzufügen.
Jetzt haben Sie also zwei.
Jetzt hat das Unternehmen zwei weitere Enhancer-Server hinzugefügt.
Wenn nun einer der Server ausfällt, kann der Image Gatherer den Datenverkehr an die anderen Server
weiterleiten.
Damit der Image Gatherer die neuesten laufenden Server ermitteln kann, muss eine Datenbank mit einer Konfigurationsdatei
erstellt werden, die die relevanten Informationen enthält.
In diesem Fall haben Sie also eine Konfigurationsdatei, die vier Server enthält.
Sie haben also Server A, Server B, Server C und Server D, und jeder Server hat eine zugehörige IP-Adresse.
Und der Image Gatherer sendet die Bilder an jede einzelne IP-Adresse.
Auch wenn dies gut zu sein scheint, besteht eine der Herausforderungen darin, dass der Server
jetzt ausgefallen ist.
Image Gatherer hat keine Möglichkeit zu wissen, dass der Server ausgefallen ist, also muss es eine zusätzliche
Logik auf dem Image Server geben, die den Zustand aller Server überprüft.
Wenn die Zustandsprüfung fehlschlägt, muss der Eintrag in der Konfigurationsdatei, der mit diesem Server verbunden ist, ebenfalls
entfernt werden.
Die Bildsammelanwendung muss also mehr tun als nur Bilder zu sammeln, was eine Reihe von Herausforderungen
mit sich bringt.
Um dies zu überwinden, gibt es auch eine bessere Architektur für die Verwendung einer Warteschlange.
Hier geht es also darum, eine Warteschlange zu entwerfen und festzulegen, was der Image Gatherer tun soll.
Es ist lediglich dafür verantwortlich, das Bild an die Warteschlange und dann an den Bildverbesserer zu senden.
Sie sind lediglich dafür verantwortlich, die Nachricht aus der Warteschlange zu nehmen, und das
war's.
Um alles andere brauchen Sie sich nicht zu kümmern.
Auf der Ebene des Image Gatherers ist es also nicht erforderlich, die aktuellen IP-Adressen der Server abzurufen, die Zustandsprüfung
durchzuführen und zusätzliche Logik zu erstellen.
Also gut.
Darum geht es also bei der Warteschlange.
Eine der Hauptfunktionen des Nachrichtenwarteschlangen-Dienstes besteht darin, eine Nachricht von einem Herausgeber entgegenzunehmen
und sie an einen Verbraucher weiterzuleiten.
In unserer Architektur wird also der Herausgeber zum Bildsammler und der Verbraucher zum Bildverbesserer.
Es handelt sich also um eine Architektur auf hohem Niveau.
Da der Bildsammler die Bilder an die Warteschlange sendet, muss die
Warteschlange immer verfügbar sein, denn wenn die Warteschlange ausfällt, kann der
Bildverbesserer kein einziges Bild aufnehmen.
Dies ist also eine der kritischsten Architekturkomponenten in diesem speziellen Anwendungsfall, den wir besprochen
haben, und diese Herausforderung, eine hochverfügbare, zuverlässige Warteschlange zu haben, wird vom Amazon Queues Service übernommen.
Auf einen Blick: Amazon fragt ist ein schneller, zuverlässiger, skalierbarer und vollständig verwalteter
Message-Queuing-Service, der die Entkopplung der Komponenten einer bestimmten Anwendung einfach
und kostengünstig macht.
Was Sie jetzt tun müssen, ist, dass Sie bereits einen Image Gatherer und einen Image Enhancer haben.
Sie erstellen ein Hoch.
Zuverlässig und verlässlich.
Q Mit Hilfe von Sky Service und konfigurieren Sie Ihren Image Gatherer so, dass er eine Nachricht an die Warteschlange sendet, und konfigurieren
Sie den Image Enhancer so, dass er die Nachricht von der Warteschlange entgegennimmt Q Das war's.
Dies ist also die grundlegende Architektur, die wir ausprobieren sollten, damit wir sie besser verstehen.
Zurzeit bin ich in der Amazon-Konsole, und zur Zeit haben wir eine.
Q Mit dem Namen der Nachricht.
F Und derzeit sind keine Nachrichten verfügbar.
Jetzt haben wir auch zwei EC-zwei-Instanzen für die heutige Demo.
Die eine heißt Image, die andere Image Enhancer.
Für die heutige Demo wird also der Image Collector easy to instance bestimmte Nachrichten an dieses Q senden und der
Image Enhancer easy to instance wird die Nachricht von den SKUs abrufen.
F Das ist also die grundlegende Architektur, etwas, das wir sehen werden.
Probieren wir es also aus.
Derzeit habe ich in meinem Suchterminal zwei Registerkarten erstellt.
Die erste Registerkarte ist mit der Bildergalerie verbunden.
Die zweite Registerkarte ist mit der Bildverbesserung verbunden.
Führen wir also das Skript aus, und der Name des Skripts lautet Nachrichten senden.
Damit werden also Nachrichten an die USA gesendet.
F Lassen Sie mich das überprüfen.
Zurzeit sehen Sie, dass sie fünf Nachrichten an die USA geschickt hat.
F Wenn wir hier die Seite schnell aktualisieren, sehen Sie, dass fünf Nachrichten aus dem Image Enhancer
verfügbar sind, der für den Konsum der Nachricht verantwortlich ist.
Wir haben noch ein weiteres Skript zur Verfügung.
Die Kollegen erhalten eine Nachricht, die lautet: Lasst es uns machen.
Sie sehen also, dass sie in diesem Stadium eine Reihe von Nachrichten aus den USA erhalten hat.
F Wenn Sie jetzt noch einmal laufen, hat sie eine weitere Reihe von Nachrichten aus den USA erhalten.
F Nehmen wir zum Beispiel an, dass das erste das Bild ist.
Es hat also das Bild aufgenommen, es hat das Werk vollendet.
Jetzt wird wieder ein neuer Satz von Bildern abgerufen, die Teil der USA sind.
F Und dann werden die Bilder verarbeitet.
Sobald die Verarbeitung abgeschlossen ist, werden die neueren Bilder, die Teil der USA sind, abgerufen.
F Wenn ich also die Seite schnell aktualisiere, sehen Sie, dass die Zahl der verfügbaren Nachrichten auf zwei gesunken ist.
Nun sind die Nachrichten, die Teil der USA sind, in der Tat.
Q Sie können sie auch über die Konsole anzeigen.
Wenn ich hier schnell eine vollständige Nachricht aufrufe, sollten Sie sehen, dass es mehrere Nachrichten gibt, die verfügbar sind,
und dies ist im Grunde der Nachrichtentext.
Nun, da wir die Grundlagen der Stimme verstanden haben.
F Lassen Sie uns fortfahren und einige der wichtigen Konzepte verstehen, die sich speziell auf ein eng gekoppeltes System und
ein lose gekoppeltes System beziehen.
In einem eng gekoppelten System kommunizieren die Komponenten einer Systemarchitektur also direkt
miteinander und sind auch stark voneinander abhängig.
So gibt es zum Beispiel einen Produzenten und einen Konsumenten.
Der Erzeuger sendet also direkt eine Nachricht an den Verbraucher.
Wenn also ein Konsument ausfällt, wird der Produzent im Wesentlichen auch damit beginnen, die andere Nachricht an die Benutzer
zu senden.
Man spricht hier also auch von einem eng gekoppelten System.
Die zweite Art von System wird als lose gekoppeltes System bezeichnet, bei dem die Komponenten einer Systemarchitektur
die Informationen verarbeiten können, ohne direkt miteinander verbunden zu sein.
Es gibt also einen Produzenten, ein Q und einen Konsumenten.
Wenn also die Verbraucher nicht mitmachen, braucht sich der Hersteller im Grunde keine Sorgen zu machen.
Alles, was der Produzent tun kann, ist, das Bild vom Benutzer zu nehmen, es an die Warteschlange zu senden und dann
eine Erfolgsmeldung an den Benutzer zurückzuschicken.
Das war's dann auch schon.
Sobald die Verbraucher wieder online sind, holen sie die Nachricht aus der Warteschlange ab und führen
die erforderliche Verarbeitung durch.
Es handelt sich also um eine viel bessere Art der Architektur.
Und in der Tat, die meisten der Architekturen, die Sie in der Produktionsumgebung sehen werden,
basieren auf dem lose gekoppelten System.
Dies ist sehr wichtig.
Das ist großartig.
Dies ist also ein sehr umfassender Überblick über den Dienst, und damit wird das heutige Video abgeschlossen.