Harrigan.
E bentornati.
Nel video di oggi parleremo delle basi del servizio Amazon US.
Ora, prima di procedere con una discussione dettagliata, prendiamo un semplice caso d'uso che
ci permetterà di capire i vantaggi che offre.
Il caso d'uso del video di oggi è un'applicazione che lavora principalmente per il ripristino di un'immagine.
Supponiamo che una media impresa stia progettando un'applicazione per migliorare e ripristinare le immagini
che gli utenti inviano al portale online.
Esistono quindi molte applicazioni che consentono di fornire l'immagine e che la migliorano e la rendono
molto più bella.
Ecco cosa sta costruendo la Medium Corp.
Nell'architettura dell'applicazione sono coinvolti due componenti.
Il primo è il raccoglitore di immagini e il secondo è il miglioratore di immagini.
Il raccoglitore di immagini è quindi responsabile del prelievo dell'immagine dall'utente tramite il pulsante di caricamento.
Quindi, non appena l'utente carica l'immagine, questa viene inviata all'applicazione
image gatherer, che la invia all'image enhancer, il quale è responsabile del miglioramento e della conversione
dell'immagine.
Questo tipo di architettura suona bene.
Ora, una delle sfide che si presentano è cosa succede quando l'immagine migliora il server.
Quindi il raccoglitore di immagini funziona bene, l'utente è in grado di caricare l'immagine, ma quando il raccoglitore di immagini invia
l'immagine al miglioratore di immagini, il server non funziona.
Questa è una delle sfide da affrontare in un'architettura attuale.
Il secondo tipo di sfida riguarda l'alta disponibilità.
Supponiamo quindi che, a causa della popolarità dell'applicazione e dell'enorme picco di traffico, medium core abbia deciso di aggiungere
un maggior numero di server di potenziamento.
Quindi ora ne avete due.
Ora la medium corp ha aggiunto altri due server di potenziamento.
Quindi, nel caso in cui uno dei server si guasti, il raccoglitore di immagini sarà in grado di inviare il traffico
agli altri server.
Quindi, affinché il raccoglitore di immagini scopra gli ultimi server in esecuzione, è necessario
creare un database e un file di configurazione con le informazioni pertinenti.
In questo caso si ha un file di configurazione che contiene quattro server.
Quindi ci sono il server A, il server B, il server C, il server D e ogni server ha un indirizzo IP associato.
E ciò che fa il raccoglitore di immagini è inviare le immagini attraverso ciascuno degli indirizzi IP.
Ora, anche se sembra una buona cosa, una delle sfide che si presentano è quella di dire che il
server è andato in tilt.
Image gatherer non ha modo di sapere che il server è inattivo, quindi è necessaria una logica aggiuntiva sul
server delle immagini che verifichi lo stato di salute di tutti i server.
Se il controllo dello stato di salute non è riuscito, anche la voce del file di configurazione associata a quel server deve essere
rimossa.
Pertanto, l'applicazione di raccolta delle immagini deve fare qualcosa di più della semplice raccolta delle immagini e questo
introduce molte sfide.
Per ovviare a questo problema, esiste un'architettura migliore che prevede l'uso di una coda.
Quindi, ciò che accade è che si progetta una coda e ciò che farà il raccoglitore di immagini.
Tutto ciò che deve fare è inviare l'immagine alla coda e poi al miglioratore d'immagine.
Tutto ciò che devono fare è prendere il messaggio dalla coda e basta.
Non dovete preoccuparvi di nient'altro.
Quindi, a livello di image gatherer, non è necessario ottenere gli indirizzi IP aggiornati dei server, eseguire il controllo
dello stato di salute e creare una logica aggiuntiva.
Va bene.
È questo il senso della coda.
Ora, una delle funzioni principali del servizio di coda di messaggi è prendere un messaggio da un editore
e inoltrarlo a un consumatore.
Nella nostra architettura, quindi, l'editore diventa il raccoglitore di immagini e il consumatore il miglioratore
di immagini.
Si tratta quindi di un'architettura di alto livello.
Ora, una cosa che deve essere garantita è che, poiché il raccoglitore di immagini invierà le
immagini alla coda, quest'ultima deve essere sempre disponibile perché, se la coda si interrompe, nessuna delle
immagini potrà essere acquisita dall'ottimizzatore di immagini.
Si tratta quindi di uno dei componenti più critici dell'architettura in questo specifico caso d'uso di
cui abbiamo parlato, e la sfida di avere una coda altamente disponibile e affidabile è affidata al servizio Amazon Queues.
In sintesi, Amazon asks è un servizio di accodamento di messaggi veloce, affidabile, scalabile e completamente
gestito, che rende semplice ed economico il disaccoppiamento dei componenti di un'applicazione
specifica.
Quindi, quello che dovete fare ora è avere già un raccoglitore di immagini, avete già un miglioratore di immagini.
Si crea un'alta qualità.
Affidabile e affidabile.
Q Con l'aiuto di Sky Service, configurare il raccoglitore di immagini per inviare un messaggio alla coda e configurare il
miglioratore di immagini per prendere il messaggio dalla coda Q E questo è tutto.
Questa è l'architettura di base, quindi andiamo avanti e proviamola per capire meglio.
Attualmente sono nella console Amazon e ne abbiamo una.
D Con il nome del messaggio.
D E attualmente i messaggi disponibili sono zero.
Ora abbiamo anche due istanze EC due per la demo di oggi.
Uno ha il nome di immagine, il secondo ha il nome di miglioratore d'immagine.
Quindi, per la dimostrazione di oggi, il raccoglitore di immagini, l'istanza easy to, invierà alcuni messaggi a questo Q e il miglioratore
di immagini, l'istanza easy to, recupererà il messaggio dagli SKU.
D Quindi questa è l'architettura di base, qualcosa di simile a ciò che vedremo.
Quindi proviamo.
Attualmente nel mio terminale di ricerca sono state create due schede.
La prima scheda è associata alla Galleria immagini.
La seconda scheda è associata al miglioratore d'immagine.
Procediamo quindi con l'esecuzione dello script e il nome dello script è inviare messaggi.
Quindi questo andrà avanti e invierà messaggi agli Stati Uniti.
D Allora, lasciatemi fare.
Al momento si vede che ha inviato cinque messaggi agli Stati Uniti.
D Ora qui dentro, se aggiorniamo rapidamente la pagina, si vede che i messaggi disponibili sono cinque
ora dall'image enhancer, che è responsabile del consumo del messaggio.
Abbiamo anche un'altra sceneggiatura disponibile.
I colleghi ricevono un messaggio che è: "Eseguiamolo".
In questa fase ha ricevuto una serie di messaggi dagli Stati Uniti.
D Ora, se si corre ancora una volta, ha ricevuto un'altra serie di messaggi dagli Stati Uniti.
D Quindi, per esempio, diciamo che la prima è l'immagine.
Quindi ha preso l'immagine, ha completato l'opera.
Ora si procederà a recuperare una nuova serie di immagini che fanno parte degli Stati Uniti.
D E poi elabora le immagini.
Una volta terminata l'elaborazione, si procederà a recuperare le immagini più recenti che fanno parte degli Stati Uniti.
D Quindi, se aggiorno rapidamente la pagina, si vede che i messaggi disponibili si sono ridotti a due.
Ora infatti i messaggi che fanno parte degli Stati Uniti.
Q È possibile visualizzarlo anche dalla console.
Quindi, se faccio rapidamente una ricerca completa dei messaggi qui, si dovrebbe vedere che ci sono più messaggi disponibili e questo
è fondamentalmente il corpo del messaggio.
Ora che abbiamo compreso le basi della voce.
D Andiamo avanti e cerchiamo di capire alcuni concetti importanti legati in particolare a un sistema strettamente accoppiato
e a un sistema non strettamente accoppiato.
Quindi, in un sistema strettamente accoppiato, i componenti di un'architettura di sistema comunicano direttamente
tra loro e hanno anche una forte dipendenza l'uno dall'altro.
Ad esempio, c'è un produttore e c'è un consumatore.
Quindi il produttore invia direttamente un messaggio al consumatore.
Quindi, se un consumatore non funziona, anche il produttore inizierà a inviare i messaggi
agli utenti.
Si tratta quindi di un sistema strettamente accoppiato.
Ora, il secondo tipo di sistema è definito sistema ad accoppiamento lasco, in cui i componenti di un'architettura
di sistema possono elaborare le informazioni senza essere direttamente collegati.
Quindi c'è un produttore, c'è un Q, c'è un consumatore.
Quindi, se i consumatori sono in calo, il produttore non deve preoccuparsi.
Quindi, tutto ciò che il produttore può fare è prendere l'immagine dall'utente e inviarla alla coda, per
poi restituire all'utente un messaggio di successo.
Questo è tutto.
Una volta che l'insieme dei consumatori è di nuovo in linea, recupera il messaggio dalla coda ed esegue
il livello di elaborazione necessario.
Si tratta quindi di un tipo di architettura molto migliore.
E in effetti, la maggior parte delle architetture che vedrete nell'ambiente di produzione
sono basate sul sistema loosely coupled.
Questo è molto importante.
È fantastico.
Questa è una panoramica di alto livello sul servizio e con essa si conclude il video di oggi.