Comunicazione tra servizi in una configurazione di microservizi

Last reviewed 2023-09-20 UTC

Questo documento è il terzo di una serie di quattro parti sulla progettazione, la creazione e il deployment di microservizi. Questa serie descrive i vari elementi dell'architettura dei microservizi. La serie include informazioni sui vantaggi e sugli svantaggi del pattern dell'architettura dei microservizi e su come applicarlo.

  1. Introduzione ai microservizi
  2. Refactoring di un monolite in microservizi
  3. Comunicazione tra servizi in una configurazione di microservizi (questo documento)
  4. Tracciamento distribuito in un'applicazione di microservizi

Questa serie è destinata agli sviluppatori di applicazioni e agli architetti che progettano e implementano la migrazione per il refactoring di un'applicazione monolitica in un'applicazione di microservizi.

Questo documento descrive i compromessi tra la messaggistica asincrona e le API sincrone nei microservizi. Il documento illustra la decostruzione di un'applicazione monolitica e mostra come convertire una richiesta sincrona nell'applicazione originale in un flusso asincrono nella nuova configurazione basata su microservizi. Questa conversione include l'implementazione di transazioni distribuite tra i servizi.

Applicazione di esempio

In questo documento utilizzerai un'applicazione di e-commerce predefinita denominata Boutique online. L'applicazione implementa flussi e-commerce di base, come la navigazione degli articoli, l'aggiunta di prodotti a un carrello e il pagamento. L'applicazione offre anche consigli e annunci in base alla selezione degli utenti.

Separazione logica dei servizi

In questo documento, il servizio di pagamento viene isolato dal resto dell'applicazione. Tutti i flussi nell'applicazione originale Online Boutique sono sincroni. Nell'applicazione sottoposta a refactoring, il processo di pagamento viene convertito in un flusso asincrono. Pertanto, quando ricevi una richiesta di acquisto, anziché elaborarla immediatamente, fornisci all'utente una conferma di "richiesta ricevuta". In background, viene attivata una richiesta asincrona al servizio di pagamento per l'elaborazione del pagamento.

Prima di spostare i dati di pagamento e la logica in un nuovo servizio, devi isolare i dati e la logica di pagamento dal monolite. Isolando i dati e la logica di pagamento nel monolite, è più facile eseguire il refactoring del codice nello stesso codebase se i confini dei servizi di pagamento sono errati (logica di business o dati).

I componenti dell'applicazione monolitica in questo documento sono già modularizzati, quindi sono isolati l'uno dall'altro. Se la tua applicazione ha interdipendenze più strette, devi isolare la logica di business e creare classi e moduli separati. Devi inoltre disaccoppiare le dipendenze del database nelle proprie tabelle e creare classi di repository separate. Quando disaccoppi le dipendenze del database, possono esistere relazioni di chiave esterna tra le tabelle divise. Tuttavia, una volta disaccoppiato completamente il servizio dal monolite, queste dipendenze cessano di esistere e il servizio interagisce esclusivamente tramite i contratti API o RPC predefiniti.

Transazioni distribuite ed errori parziali

Dopo aver isolato il servizio e averlo suddiviso dal monolite, una transazione locale nel sistema monolitico originale viene distribuita tra più servizi. Nell'implementazione del monolite, la procedura di pagamento ha seguito la sequenza mostrata nel diagramma seguente.

La sequenza di pagamento è distribuita tra più servizi.

Figura 1. Sequenza di una procedura di pagamento in un'implementazione monolitica.

Nella Figura 1, quando l'applicazione riceve un ordine di acquisto, il controller di pagamento chiama il servizio di pagamento e il servizio degli ordini per elaborare il pagamento e salvare l'ordine, rispettivamente. Se uno o più passaggi hanno esito negativo, è possibile eseguire il rollback della transazione del database. Considera uno scenario di esempio in cui la richiesta di ordine viene archiviata correttamente nella tabella degli ordini, ma il pagamento non va a buon fine. In questo scenario, viene eseguito il rollback dell'intera transazione e la voce viene rimossa dalla tabella degli ordini.

Dopo aver disaccoppiato il pagamento nel servizio dedicato, il flusso di pagamento modificato è simile al seguente diagramma:

La procedura di pagamento comprende più servizi e database.

Figura 2. Una sequenza della procedura di pagamento dopo che il pagamento è stato disaccoppiato nel proprio servizio.

Nella Figura 2, la transazione interessa più servizi e i relativi database, quindi è una transazione distribuita. Alla ricezione di una richiesta di ordine, il titolare del trattamento dei dati salva i dettagli dell'ordine nel proprio database locale e chiama altri servizi per completare l'ordine. Questi servizi, come il servizio di pagamento, possono utilizzare il proprio database locale per archiviare i dettagli dell'ordine.

Nell'applicazione monolitica, il sistema di database garantisce che le transazioni locali siano atomiche. Tuttavia, per impostazione predefinita, il sistema basato su microservizi con un database separato per ogni servizio non dispone di un coordinatore globale delle transazioni che copre i vari database. Poiché le transazioni non sono coordinate a livello centrale, un errore nell'elaborazione di un pagamento non esegue il rollback delle modifiche apportate al servizio degli ordini. Pertanto, il sistema è in uno stato incoerente.

I seguenti pattern vengono comunemente utilizzati per gestire le transazioni distribuite:

  • Protocollo di commit a due fasi (2PC): parte di una famiglia di protocolli di consenso, 2PC coordina il commit di una transazione distribuita e mantiene le garanzie di atomicità, coerenza, isolamento, durabilità (ACID). Il protocollo è suddiviso nelle fasi di prepare e prepare. Una transazione viene confermata solo se tutti i partecipanti hanno votato a favore. Se i partecipanti non raggiungono un accordo, viene eseguito il rollback dell'intera transazione.
  • Saga: il pattern Saga consiste nell'esecuzione di transazioni locali all'interno di ogni microservizio che costituisce la transazione distribuita. Un evento viene attivato al termine di ogni operazione riuscita o non riuscita. Tutti i microservizi coinvolti nella transazione distribuita sono abbonati a questi eventi. Se i seguenti microservizi ricevono un evento di successo, eseguono la loro operazione. In caso di errore, i microservizi precedenti completano le azioni di compensazione per annullare le modifiche. Saga fornisce una visione coerente del sistema garantendo che, al completamento di tutti i passaggi, tutte le operazioni abbiano esito positivo o che compensi le azioni annullino tutto il lavoro.

Consigliamo Saga per le transazioni di lunga durata. In un'applicazione basata su microservizi, prevedi chiamate e comunicazioni tra servizi con sistemi di terze parti. Pertanto, è meglio progettare per la coerenza finale: riprova per errori recuperabili ed espone eventi compensatori che alla fine modificano gli errori non recuperabili.

Esistono vari modi per implementare Saga, ad esempio puoi utilizzare motori di flusso di lavoro e attività come Apache Airflow, Apache Camel o Conductor. Puoi anche scrivere gestori di eventi personalizzati utilizzando sistemi basati su Kafka, RabbitMQ o ActiveMQ.

L'applicazione Online Boutique utilizza il servizio di pagamento per orchestrare i servizi di pagamento, spedizione e notifica via email. Il servizio di pagamento gestisce anche il flusso di lavoro dell'attività e degli ordini. In alternativa alla creazione di un motore di flusso di lavoro personalizzato, puoi utilizzare componenti di terze parti come Zeebe. Zeebe fornisce un creatore di modelli basato sull'interfaccia utente. Ti consigliamo di valutare attentamente le scelte per l'orchestratore di microservizi in base ai requisiti della tua applicazione. Questa scelta è una parte fondamentale dell'esecuzione e della scalabilità dei microservizi.

Applicazione sottoposta a refactoring

Per abilitare le transazioni distribuite nell'applicazione di cui è stato eseguito il refactoring, il servizio di pagamento gestisce la comunicazione tra il servizio di pagamento, spedizione ed email. Il flusso di lavoro BPMN (Business Process Model and Notation) generico utilizza il seguente flusso:

Le transazioni in un'applicazione sottoposta a refactoring seguono un flusso di lavoro BPMN.

Figura 3. Un flusso di lavoro degli ordini che aiuta a garantire transazioni distribuite in microservizi tipici.

Il diagramma precedente mostra il seguente flusso di lavoro:

  • Il servizio di frontend riceve una richiesta di ordine e poi effettua le seguenti operazioni:
    • Invia gli articoli dell'ordine al servizio carrello. Il servizio del carrello salva quindi i dettagli dell'ordine (Redis).
    • Reindirizza alla pagina di pagamento. Il servizio di pagamento recupera gli ordini dal servizio carrello, imposta lo stato dell'ordine su Pending e chiede al cliente il pagamento.
    • Conferma che l'utente ha pagato. Una volta confermato, il servizio di pagamento comunica al servizio email di generare un'email di conferma e inviarla al cliente.
  • Il servizio di pagamento elabora successivamente la richiesta.
    • Se la richiesta di pagamento va a buon fine, il servizio di pagamento aggiorna lo stato dell'ordine impostandolo su Complete.
    • Se la richiesta di pagamento non va a buon fine, il servizio di pagamento avvia una transazione compensativa.
      • La richiesta di pagamento è stata annullata.
      • Il servizio di pagamento modifica lo stato dell'ordine in Failed.
    • Se il servizio di pagamento non è disponibile, la richiesta scade dopo N secondi e il servizio di pagamento avvia una transazione compensativa.
    • Il servizio di pagamento modifica lo stato dell'ordine in Failed.

Obiettivi

  • Esegui il deployment dell'applicazione monolitica Online Boutique su Google Kubernetes Engine (GKE).
  • Convalida il flusso di pagamento monolitico.
  • Esegui il deployment della versione con microservizi dell'applicazione monolitica sottoposta a refactoring
  • Verifica che il nuovo flusso di pagamento funzioni.
  • Verifica che le transazioni distribuite e le azioni di compensazione funzionino in caso di errore.

Costi

In questo documento, utilizzi i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

Una volta completato questo documento, puoi evitare di continuare la fatturazione eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la sezione Pulizia.

Prima di iniziare

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  2. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

  3. Nella console Google Cloud, attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell che mostra un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installato e con valori già impostati per il progetto attuale. L'inizializzazione della sessione può richiedere alcuni secondi.

  4. Abilita le API per Compute Engine, Google Kubernetes Engine, Cloud SQL, Artifact Analysis e Container Registry:

     gcloud services enable \
     compute.googleapis.com \
     sql-component.googleapis.com \
     servicenetworking.googleapis.com\
     container.googleapis.com \
     containeranalysis.googleapis.com \
     containerregistry.googleapis.com \
     sqladmin.googleapis.com

  5. Esporta le seguenti variabili di ambiente:

    export PROJECT=$(gcloud config get-value project)
export CLUSTER=$PROJECT-gke
export REGION="us-central1"

Deployment del monolite di e-commerce

In questa sezione eseguirai il deployment dell'applicazione monolitica Online Boutique in un cluster GKE. L'applicazione utilizza Cloud SQL come database relazionale. Il seguente diagramma illustra l'architettura delle applicazioni monolitiche:

Un'applicazione utilizza un'architettura monolitica.

Figura 4. Un client si connette all'applicazione in un cluster GKE e l'applicazione si connette a un database Cloud SQL.

Per eseguire il deployment dell'applicazione, completa questi passaggi:

  1. Clona il repository GitHub:

    git clone https://github.com/GoogleCloudPlatform/monolith-to-microservices-example

  2. Sostituisci il segnaposto PROJECT_ID nel file manifest delle variabili Terraform:

    cd monolith-to-microservices-example/setup && \
sed -i -e "s/\[PROJECT_ID\]/$PROJECT/g" terraform.tfvars

  3. Esegui gli script Terraform per completare la configurazione dell'infrastruttura ed eseguire il deployment dell'infrastruttura. Per saperne di più su Terraform, consulta Introduzione a Terraform su Google Cloud:

    terraform init && terraform apply -auto-approve

    Lo script Terraform crea quanto segue:

    • Una rete VPC denominata PROJECT_ID-vpc
    • Cluster GKE denominato PROJECT_ID-gke
    • Un'istanza Cloud SQL denominata PROJECT_ID-mysql
      • Un database denominato ecommerce utilizzato dall'applicazione
      • Un utente root con password impostata su password

    Puoi modificare lo script Terraform per generare automaticamente una password. Questa configurazione utilizza un esempio semplificato che non dovresti utilizzare in produzione.

    Il provisioning dell'infrastruttura può richiedere fino a 10 minuti. Una volta eseguito correttamente lo script, l'output sarà simile al seguente:

    ...

Apply complete! Resources: 8 added, 0 changed, 0 destroyed.

Outputs:

kubernetes_cluster_name = PROJECT_ID-gke
sql_database_name = PROJECT_ID-mysql
vpc_name = PROJECT_ID-vpc

  4. Connettiti al cluster e crea uno spazio dei nomi denominato monolith. Esegui il deployment dell'applicazione nel proprio spazio dei nomi nel cluster GKE:

    gcloud container clusters get-credentials $CLUSTER \
   --region $REGION \
   --project $PROJECT && \
   kubectl create ns monolith

  5. L'applicazione in esecuzione su GKE utilizza i secret di Kubernetes per accedere al database Cloud SQL. Crea un secret che utilizza le credenziali utente per il database:

    kubectl create secret generic dbsecret \
  --from-literal=username=root \
  --from-literal=password=password -n monolith

  6. Crea l'immagine del monolite e caricala in Container Registry:

    cd ~/monolith
gcloud builds submit --tag gcr.io/$PROJECT_ID/ecomm

  7. Aggiorna il riferimento nel file deploy.yaml all'immagine Docker appena creata:

    cd ~/monolith
sed -i -e "s/\[PROJECT_ID\]/$PROJECT/g" deploy.yaml

  8. Sostituisci i segnaposto nei file manifest di deployment ed esegui il deployment dell'applicazione:

    cd .. && \
DB_IP=$(gcloud sql instances describe $PROJECT-mysql | grep "ipAddress:" | tail -1 | awk -F ":" '{print $NF}')

sed -i -e "s/\[DB_IP\]/$DB_IP/g" monolith/deploy.yaml
kubectl apply -f monolith/deploy.yaml

  9. Controlla lo stato del deployment:

    kubectl rollout status deployment/ecomm -n monolith

    L'output è simile al seguente.

    Waiting for deployment "ecomm" rollout to finish: 0 of 1 updated replicas are available...
deployment "ecomm" successfully rolled out

  10. Recupera l'indirizzo IP dell'applicazione di cui è stato eseguito il deployment:

    kubectl get svc ecomm -n monolith \
        -o jsonpath="{.status.loadBalancer.ingress[*].ip}" -w

    Attendi che l'indirizzo IP del bilanciatore del carico venga pubblicato. Per uscire dal comando, premi Ctrl+C. Prendi nota dell'indirizzo IP del bilanciatore del carico, quindi accedi all'applicazione all'URL http://IP_ADDRESS. Potrebbe essere necessario un po' di tempo prima che il bilanciatore del carico sia in stato integro e inizi a trasmettere il traffico.

Convalida il flusso di pagamento del monolite

In questa sezione creerai un ordine di prova per convalidare il flusso di pagamento.

  1. Vai all'URL che hai annotato nella sezione precedente, http://IP_ADDRESS.
  2. Nella home page dell'applicazione visualizzata, seleziona un prodotto qualsiasi, quindi fai clic su Aggiungi al carrello.
  3. Per creare un acquisto di prova, fai clic su Effettua l'ordine:
  4. Se il pagamento va a buon fine, viene visualizzata la finestra di conferma dell'ordine, con l'ID di conferma dell'ordine.

  5. Per visualizzare i dettagli dell'ordine, collegati al database:

    gcloud sql connect $PROJECT-mysql --user=root

    Puoi anche utilizzare qualsiasi altro metodo supportato per connetterti al database. Quando richiesto, inserisci la password come password.

  6. Per visualizzare i dettagli dell'ordine salvato, esegui questo comando:

    select cart_id from ecommerce.cart;

  7. L'output sarà simile al seguente:

    +--------------------------------------+
| cart_id                              |
+--------------------------------------+
| 7cb9ab11-d268-477f-bf4d-4913d64c5b27 |
+--------------------------------------+

Deployment dell'applicazione di e-commerce basata su microservizi

In questa sezione eseguirai il deployment dell'applicazione di cui è stato eseguito il refactoring. Questo documento si concentra solo sul disaccoppiamento dei servizi di frontend e pagamento. Il prossimo documento di questa serie, Tracciamento distribuito in un'applicazione di microservizi, descrive altri servizi, come i servizi per suggerimenti e annunci, che puoi disaccoppiare dal monolite. Il servizio di pagamento gestisce le transazioni distribuite tra il frontend e i servizi di pagamento e viene eseguito come servizio Kubernetes nel cluster GKE, come mostrato nel diagramma seguente:

I servizi di frontend e pagamento sono disaccoppiati dal monolite.

Figura 5. Il servizio di pagamento orchestra le transazioni tra il carrello, il pagamento e l'email.

Esegui il deployment dei microservizi

In questa sezione utilizzerai l'infrastruttura di cui hai eseguito il provisioning in precedenza per eseguire il deployment di microservizi nel loro spazio dei nomi microservice:

  1. Assicurati di soddisfare i seguenti requisiti:

    • Progetto Google Cloud
    • Ambiente Shell con gcloud, git e kubectl

  2. In Cloud Shell, clona il repository di microservizi:

    git clone https://github.com/GoogleCloudPlatform/microservices-demo
cd microservices-demo/

  3. Imposta il progetto e la regione Google Cloud e assicurati che l'API GKE sia abilitata:

    export PROJECT_ID=PROJECT_ID
export REGION=us-central1
gcloud services enable container.googleapis.com \
--project=${PROJECT_ID}

    Sostituisci con l'ID del tuo progetto Google Cloud.

  4. Crea un cluster GKE e recupera le credenziali:

    gcloud container clusters create-auto online-boutique \
    --project=${PROJECT_ID} --region=${REGION}

    La creazione del cluster potrebbe richiedere alcuni minuti.

  5. Esegui il deployment dei microservizi nel cluster:

    kubectl apply -f ./release/kubernetes-manifests.yaml

  6. Attendi che i pod siano pronti:

    kubectl get pods

    Dopo qualche minuto, vedi i pod nello stato Running.

  7. Accedi al frontend web in un browser utilizzando l'indirizzo IP esterno del frontend:

    kubectl get service frontend-external | awk '{print $4}'

    Visita http://EXTERNAL_IP in un browser web per accedere alla tua istanza di Boutique online.

Convalidare il nuovo flusso di pagamento

  1. Per verificare il flusso della procedura di pagamento, seleziona un prodotto ed effettua un ordine, come descritto nella sezione precedente Convalidare il flusso di pagamento del monolite.
  2. Quando completi il pagamento dell'ordine, la finestra di conferma non mostra un ID di conferma. ma la finestra di conferma ti invita a controllare l'email per i dettagli della conferma.

  3. Per verificare che l'ordine sia stato ricevuto, che il servizio di pagamento abbia elaborato il pagamento e che i dettagli dell'ordine siano stati aggiornati, esegui questo comando:

    kubectl logs -f deploy/checkoutservice --tail=100

    L'output sarà simile al seguente:

    [...]
{"message":"[PlaceOrder] user_id=\"98828e7a-b2b3-47ce-a663-c2b1019774a3\" user_currency=\"CAD\"","severity":"info","timestamp":"2023-08-10T04:19:20.498893921Z"}
{"message":"payment went through (transaction_id: f0b4a592-026f-4b4a-9892-ce86d2711aed)","severity":"info","timestamp":"2023-08-10T04:19:20.528338189Z"}
{"message":"order confirmation email sent to \"someone@example.com\"","severity":"info","timestamp":"2023-08-10T04:19:20.540275988Z"}

    Per uscire dai log, premi Ctrl+C.

  4. Verifica che il pagamento sia andato a buon fine:

    kubectl logs -f deploy/paymentservice -n --tail=100

    L'output sarà simile al seguente:

    [...]
{"severity":"info","time":1691641282208,"pid":1,"hostname":"paymentservice-65cc7795f6-r5m8r","name":"paymentservice-charge","message":"Transaction processed: visa ending 0454     Amount: CAD119.30128260"}
{"severity":"info","time":1691641300051,"pid":1,"hostname":"paymentservice-65cc7795f6-r5m8r","name":"paymentservice-server","message":"PaymentService#Charge invoked with request {\"amount\":{\"currency_code\":\"USD\",\"units\":\"137\",\"nanos\":850000000},\"credit_card\":{\"credit_card_number\":\"4432-8015-6152-0454\",\"credit_card_cvv\":672,\"credit_card_expiration_year\":2039,\"credit_card_expiration_month\":1}}"}

    Per uscire dai log, premi Ctrl+C.

  5. Verifica che l'email di conferma dell'ordine sia stata inviata:

    kubectl logs -f deploy/emailservice -n --tail=100

    L'output sarà simile al seguente:

    [...]
{"timestamp": 1691642217.5026057, "severity": "INFO", "name": "emailservice-server", "message": "A request to send order confirmation email to kalani@examplepetstore.com has been received."}

    I messaggi di log per ciascun microservizio indicano che la transazione distribuita nei servizi di pagamento, email e pagamento è stata completata correttamente.

Convalida l'azione di risarcimento in una transazione distribuita

Questa sezione simula uno scenario in cui un cliente sta effettuando un ordine e il servizio di pagamento non è disponibile.

  1. Per simulare l'indisponibilità del servizio, elimina il deployment e il servizio dei pagamenti:

    kubectl delete deploy paymentservice && \
kubectl delete svc paymentservice

  2. Accedi di nuovo all'applicazione e completa il flusso di pagamento. In questo esempio, se il servizio di pagamento non risponde, la richiesta scade e viene attivata un'azione di compensazione.

  3. Nel frontend dell'interfaccia utente, fai clic sul pulsante Effettua ordine. L'output è simile al seguente:

    HTTP Status: 500 Internal Server Error
rpc error: code = Internal desc = failed to charge card: could not charge the card: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing: dial tcp: lookup paymentservice on 34.118.224.10:53: no such host"
failed to complete the order
main.(*frontendServer).placeOrderHandler
    /src/handlers.go:360

  4. Esamina i log del servizio frontend:

    kubectl logs -f deploy/frontend --tail=100

    L'output è simile al seguente:

    [...]
{"error":"failed to complete the order: rpc error: code = Internal desc = failed to charge card: could not charge the card: rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp: lookup paymentservice on 34.118.224.10:53: no such host\"","http.req.id":"0a4cb058-ee9b-470a-9bb1-3a965636022e","http.req.method":"POST","http.req.path":"/cart/checkout","message":"request error","session":"96c94881-a435-4490-9801-c788dc400cc1","severity":"error","timestamp":"2023-08-11T18:25:47.127294259Z"}

  5. Esamina i log del servizio di pagamento:

    kubectl logs -f deploy/frontend --tail=100

    L'output è simile al seguente:

    [...]
{"message":"[PlaceOrder] user_id=\"96c94881-a435-4490-9801-c788dc400cc1\" user_currency=\"USD\"","severity":"info","timestamp":"2023-08-11T18:25:46.947901041Z"}
{"message":"[PlaceOrder] user_id=\"96c94881-a435-4490-9801-c788dc400cc1\" user_currency=\"USD\"","severity":"info","timestamp":"2023-08-11T19:54:21.796343643Z"}

    Tieni presente che non è prevista alcuna chiamata al servizio email per l'invio della notifica. Non esiste un log delle transazioni, come payment went through (transaction_id: 06f0083f-fa47-4d91-8258-6d61edfab1ca)

  6. Esamina i log del servizio email:

    kubectl logs -f deploy/emailservice --tail=100

    Tieni presente che non sono state create voci di log per la transazione non riuscita sul servizio email.

Come agente di orchestrazione, se una chiamata di servizio non va a buon fine, il servizio di pagamento restituisce uno stato di errore e chiude la procedura di pagamento.

Esegui la pulizia

Per evitare che al tuo Account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Se prevedi di completare i passaggi nel prossimo documento di questa serie, Tracciamento distribuito in un'applicazione di microservizi, puoi riutilizzare il progetto e le risorse anziché eliminarli.

Elimina il progetto

  1. Nella console Google Cloud, vai alla pagina Gestisci risorse.

    Vai a Gestisci risorse

  2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
  3. Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Elimina le risorse

Se vuoi conservare il progetto Google Cloud che hai utilizzato in questo documento, elimina le singole risorse.

  1. In Cloud Shell, esegui questo comando:

    cd setup && terraform destroy -auto-approve

  2. Per eliminare il cluster di microservizi utilizzando Google Cloud CLI, esegui questo comando:

    gcloud container clusters delete online-boutique \
    --location $REGION

Passaggi successivi