In questo modulo, distribuirai l'applicazione node.js come un set di servizi interconnessi dietro a un Application Load Balancer (ALB). Utilizzerai ALB per spostare in modo ottimale il traffico dal monolito ai microservizi. Inizia a creare

Questo è il processo che ti permetterà di impostare i microservizi e far transitare in modo sicuro il traffico dell'applicazione fuori dal monolito.

panoramica dell'architettura
  1. Monolito distribuito
    Questa è la configurazione iniziale. L'applicazione monolitica node.js è in esecuzione in un container su Amazon ECS.
  2. Avvia i microservizi
    Utilizzando le tre immagini di container che hai creato e caricato su Amazon ECR nel modulo precedente, avvierai tre microservizi sul tuo cluster Amazon ECS esistente.
  3. Configura Gruppi di destinazione
    Come nel Modulo 2, aggiungerai un gruppo di destinazione a ciascun servizio e aggiornerai le regole di ALB per collegare i nuovi microservizi.
  4. Commuta il traffico e spegni il monolito
    Modificando una regola nell'ALB, comincerai a inviare il traffico ai microservizi in esecuzione. Quando sarà tutto a posto, spegni il monolito.

Segui i passaggi indicati nelle istruzioni seguenti per distribuire i microservizi. Fai clic sul numero della fase per espandere la sezione.

break-the-monolith
  • Fase 1. Scrivi le definizioni delle attività per i tuoi servizi.

    Distribuirai tre nuovi microservizi sullo stesso cluster in esecuzione dal Modulo 2. Come nel Modulo 2 scriverai le definizioni delle attività per ciascun servizio.

    ⚐ NOTA: è possibile aggiungere più container a una definizione di attività, in questo modo potresti eseguire tutti e tre i microservizi come container differenti su un unico servizio. Tuttavia quest'azione sarebbe ancora monolitica visto che ogni container dovrebbe essere dimensionato in modo lineare con il servizio. Il tuo obiettivo è disporre di tre servizi indipendenti: ciascun servizio richiede la sua definizione dell'attività che esegua un container con l'immagine di quel servizio corrispondente.

    Puoi inserire le definizioni delle attività nell'interfaccia utente della console oppure accelerare la procedura utilizzando un file JSON. Per scrivere la definizione dell'attività come un file JSON, seleziona Configura tramite JSON in fondo alla schermata della nuova definizione dell'attività.

    I parametri per la definizione dell'attività sono:

    • Name (Nome) = [service-name] 
    • Image (Immagine) = [service ECR repo URL]:latest 
    • cpu = 256 
    • memory (memoria) = 256 
    • Container Port (Porta container) = 3000 
    • Host Post (Post di hosting) = 0



    Oppure con JSON:

    {
        "containerDefinitions": [
            {
                "name": "[service-name]",
                "image": "[account-id].dkr.ecr.us-west-2.amazonaws.com/[service-name]:[tag]",
                "memoryReservation": "256",
                "cpu": "256",
                "essential": true,
                "portMappings": [
                    {
                        "hostPort": "0",
                        "containerPort": "3000",
                        "protocol": "tcp"
                    }
                ]
            }
        ],
        "volumes": [],
        "networkMode": "bridge",
        "placementConstraints": [],
        "family": "[service-name]"
    }

    ♻ Ripeti il processo per creare una definizione dell'attività per ciascun servizio:

    • post
    • thread
    • utenti
  • Fase 2. Configura Application Load Balancer: gruppi di destinazione

    Come nel Modulo 2, configurerai i gruppi di destinazione per ciascuno dei tuoi servizi. I gruppi di destinazione consentono al traffico di raggiungere correttamente ciascun servizio.

    Controlla il nome del tuo VPC: lo stack di AWS CloudFormation ha il suo VPC, che probabilmente non è il tuo VPC predefinito. È importante configurare i tuoi gruppi di destinazione con il corretto VPC.

     

    Configura Gruppi di destinazione

    • Passa alla sezione Target Group (Gruppo di destinazione) della console EC2.
    • Seleziona Create target group (Crea gruppo di destinazione).
    • Configura il Gruppo di destinazione (non modificare le impostazioni predefinite se non sono specificate qui): Name (Nome) = [nome-servizio] Protocol (Protocollo) = HTTP Port (Porta HTTP) = 80 VPC = seleziona il VPC del sistema di bilanciamento del carico individuato nella fase precedente.
      • Impostazioni avanzate di controllo dello stato: Healthy threshold (Soglia integrità) = 2 Unhealthy threshold (Soglia danneggiamento) = 2 Timeout = 5 Interval (Intervallo) = 6.
    • Seleziona Create (Crea).

     

    ♻ Ripeti il processo per creare un gruppo di destinazione per ciascun servizio:

    • post
    • thread
    • utenti

     

    Infine, crea un quarto gruppo di destinazione

    • blocca-traffico

    Questo gruppo di destinazione è una destinazione fittizia. Lo utilizzerai per evitare che il traffico raggiunga il monolito quando i microservizi saranno pienamente operativi. Dovresti disporre di 5 gruppi di destinazione in totale nella tabella.

    gruppi di destinazione
  • Fase 3. Configura le regole del Listener

    Il Listener controlla le richieste di connessione in entrata all'ALB per instradare il traffico in modo appropriato.

    Al momento, tutti e quattro i servizi (il monolito e i tre microservizi) sono in esecuzione sotto lo stesso sistema di bilanciamento del carico. Per effettuare la transizione dal monolito ai microservizi, inizierai a inviare traffico ai microservizi arrestando il traffico verso il monolito.

    Apri il Listener

     

    Aggiorna le regole del Listener

    • Seleziona View/edit rules (Visualizza/modifica regole) > per il listener.
    • Seleziona + e inserisci la regola.
    • I criteri della regola sono:
      • IF Path = /api/[nome-servizio]* THEN Forward to [nome-servizio]
      • Ad esempio: Path = /api/posts* inoltra ai post
    • Crea quattro nuove regole, una per mantenere il traffico verso il monolito e una per ciascun servizio. Avrai un totale di cinque regole, inclusa quella predefinita. Assicurati di aggiungere le regole in quest'ordine:
      • api: /api* inoltra ad api
      • utenti: /api/users* inoltra agli utenti
      • thread: /api/threads* inoltra ai thread
      • post: /api/posts* inoltra ai post
    • Seleziona la freccia in alto a sinistra della pagina per tornare indietro alla console del sistema del bilanciamento del carico.
    configura le regole del listener
  • Fase 4. Distribuisci i microservizi

    Ora distribuirai i tre servizi nel cluster. Ripeti questi passaggi per ognuno dei tre servizi:

    • Vai al menu "Clusters" sul lato sinistro della console di Amazon ECS.
    • Seleziona il tuo cluster: BreakTheMonolith-Demo-ECSCluster.
    • Nella scheda Services (Servizi), seleziona Create (Crea).
    • Configura il servizio (non modificare i valori predefiniti) Task definition (Definizione dell’attività) = seleziona il valore più alto per X: [nome-servizio]:X (X deve essere = 1 per la maggior parte dei casi) Service name (Nome del servizio) = [nome-servizio] Number of tasks (Numero di attività) = 1
    • Seleziona Configure ELB (Configura ELB)
      • Tipo di ELB = Application Load Balancer
      • Come ruolo IAM, seleziona BreakTheMonolith-Demo-ECSServiceRole
      • Seleziona la demo del sistema di bilanciamento del carico
      • Seleziona Add to ELB (Aggiungi a ELB)
    • Aggiungi il tuo servizio al gruppo di destinazione:
      • porta Listener = 80:HTTP
      • Target group name (Nome gruppo di destinazione) = seleziona il tuo gruppo: [service-name].
    • Seleziona Save (Salva).
    • Seleziona Create Service (Crea servizio).
    • Seleziona View Service (Visualizza servizio).


    Tutti i tuoi servizi inizieranno in pochi secondi. Controlla che tutti i servizi siano in esecuzione e funzionino correttamente prima di continuare.

    distribuzione di microservizi
  • Fase 5. Trasferisci il traffico ai microservizi

    In questo momento i microservizi sono in esecuzione ma tutto il traffico sta ancora transitando verso il servizio del monolito.

    Aggiorna i regolatori del Listener per reinstradare il traffico verso i microservizi:

    Le regole dovrebbero avere la sintassi seguente:

    trasferisci il traffico ai microservizi

    Disattiva il monolito: ora il traffico è diretto ai microservizi e puoi disattivare il servizio del monolito.

    • Torna al cluster Amazon ECS BreakTheMonolith-Demo-ECSCluster.
    • Seleziona il servizio api e Update (Aggiorna).
    • Cambia il numero di attività a 0.
    • Seleziona Update Service (Aggiorna servizio).

     

    Amazon ECS ora filtrerà qualsiasi connessione che il servizio ha distribuito dai container al cluster e arresterà i container. Se dopo circa 30 secondi aggiornerai le liste di Deployments (Distribuzione) o Tasks (Attività) vedrai il numero di attività calare a 0. Il servizio è ancora attivo, perciò se per qualche ragione dovessi annullare l'operazione, potrai semplicemente aggiornarlo per distribuire altre attività.

    • Seleziona il servizio api, Delete (Elimina) e conferma l'eliminazione.


    Hai trasferito completamente node.js dal monolito ai microservizi senza tempi di inattività!

  • Fase 6. Convalida la distribuzione

    Trova l’URL del tuo servizio: questo è lo stesso URL che hai utilizzato nel Modulo 2 di questo tutorial.

    • Vai alla sezione Load Balancers (Sistemi di bilanciamento del carico) della console EC2.
    • Seleziona i microservizi della demo del sistema di bilanciamento del carico.
    • Copia e incolla il valore per il nome DNS nel tuo browser.
    • Dovrebbe essere visualizzato il messaggio Ready to receive requests (Pronto per ricevere richieste).

     

    Guarda i valori per ogni microservizio: il tuo ALB instrada il traffico in base all'URL della richiesta. Per visualizzare ciascun servizio, è sufficiente aggiungere il nome alla fine del nome DNS, ad esempio:

    • http://[DNS name]/api/users
    • http://[DNS name]/api/threads
    • http://[DNS name]/api/posts
    Guarda i valori per ciascun microservizio

    ⚐ NOTA: questi URL funzionano allo stesso modo della distribuzione del monolito. Questo è molto importante perché qualsiasi API o consumatore che vuole connettersi a quest'applicazione non sarà interessato dalle modifiche apportate. Passare da monolito ai microservizi non necessita di alcuna modifica ad altre parti dell'infrastruttura.

    È inoltre possibile utilizzare strumenti come Postman per testare le API.