Distribuire microservizi con App contenitore di Azure e Dapr

Questo articolo descrive una soluzione per l'esecuzione di un sistema di gestione degli ordini come set di servizi in contenitori in App contenitore di Azure. La soluzione usa i building block di Dapr (Distributed Application Runtime) per la comunicazione e l'accesso allo stato e Kubernetes Event-driven Autoscaling (KEDA) per il ridimensionamento basato su eventi.

Dapr è un marchio della rispettiva società. Nessuna verifica dell'autenticità è implicita nell'uso di questo marchio.

Architettura

Scaricare un file PowerPoint di questa architettura.

Flusso di dati

Questa soluzione descrive un sistema di gestione degli ordini fittizio e la relativa infrastruttura di supporto Azure. L'architettura usa un ambiente di Container Apps che ospita i servizi di .NET, un'interfaccia utente di Vue.js e un bootstrapper. Container Apps fornisce un livello di ingress basato su Envoy gestito, quindi il carico di lavoro non implementa il proprio livello proxy. Le chiamate interne da servizio a servizio usano la chiamata al servizio Dapr, che instrada attraverso l'infrastruttura proxy dell'ambiente. La soluzione usa l'SDK di Dapr per l'integrazione con le risorse di Azure tramite blocchi predefiniti di publish-subscribe, stato, chiamata al servizio e binding. I servizi usano regole di scalabilità basate su KEDA per ridimensionare in risposta al traffico HTTP e al volume di messaggi di bus di servizio di Azure.

Il flusso di dati seguente corrisponde al diagramma precedente.

1. Ingresso gestito: Container Apps offre un livello di ingresso gestito basato su Envoy. Una configurazione di routing basata su regole a livello di ambiente pubblica un nome host, serve l'interfaccia utente dal percorso radice e inoltra i percorsi API del dashboard ai servizi accounting e Makeline. Questi due servizi usano l'ingresso interno perché una configurazione di route può essere indirizzata a un'app che non è esposta esternamente.

2. Interfaccia utente: Dashboard che mostra i dati sugli ordini in tempo reale e i dati aggregati sulle vendite per il sistema di gestione degli ordini.

3. Cliente virtuale: un programma di simulazione clienti che simula i clienti che effettua ordini tramite il servizio ordini.

4. Servizio ordini: API di creazione, lettura, aggiornamento ed eliminazione per l'inserimento e la gestione degli ordini.

5. Servizio contabilità: servizio che elabora, archivia e aggrega i dati degli ordini. Trasforma gli ordini dei clienti in metriche di vendita significative visualizzate dall'interfaccia utente.

6. Servizio di ricezione: programma di archiviazione che genera e archivia le ricevute degli ordini per scopi di controllo e cronologia.

7. Servizio fedeltà: un servizio che gestisce il programma fedeltà monitorando i punti di ricompensa dei clienti in base alla spesa dell'ordine.

8. Servizio Makeline: Servizio che gestisce una coda di ordini correnti in attesa di essere evaso. Tiene traccia dell'elaborazione e del completamento degli ordini dal servizio di lavoro virtuale.

9. Lavoro virtuale:programma di simulazione di lavoro che simula il completamento degli ordini dei clienti.

Container Apps supporta solo un subset dei componenti disponibili nel progetto open source Dapr. I componenti bus di servizio, Azure Cosmos DB e gestione rete virtuale di Azure in questa architettura sono componenti di livello 1. L'archivio stati Redis e l'associazione Cron sono componenti di livello 2, che ricevono una priorità di supporto inferiore. Esaminare i livelli di supporto dei componenti Dapr correnti in Container Apps e verificare che ogni componente soddisfi i requisiti di supporto del carico di lavoro.

Componenti

• Application Insights è un servizio di gestione delle prestazioni delle applicazioni. In questa architettura si strumenta il codice dell'applicazione per inviare richieste, dipendenze, eccezioni e tracce distribuite ad Application Insights. Container Apps non fornisce la strumentazione automatica di Application Insights.

• gestione rete virtuale di Azure è l'archiviazione di oggetti per i dati non strutturati. In questa architettura, il servizio di ricezione usa un binding di output Dapr per archiviare le ricevute degli ordini in gestione rete virtuale di Azure.

• Redis gestito di Azure offre un archivio dati in memoria basato sul software Redis Enterprise. In questa architettura viene usato come componente dell'archivio di stati Dapr per il servizio Makeline per archiviare i dati relativi agli ordini in fase di elaborazione.

• Azure Cosmos DB è un servizio di database distribuito gestito. In questa architettura, il servizio fedeltà usa questo tramite un componente dell'archivio stati Dapr per archiviare i dati fedeltà dei clienti.

• Monitoraggio di Azure raccoglie e analizza i dati di telemetria dalle risorse e dalle applicazioni Azure. In questa architettura si usano Monitoraggio di Azure per metriche della piattaforma di Container Apps, log della console e del sistema, avvisi e dati di telemetria delle applicazioni di Application Insights.

• bus di servizio è un broker di messaggi aziendale completamente gestito che fornisce code e topic di pubblicazione-sottoscrizione. In questa architettura si usa il bus di servizio per l'implementazione del componente Dapr publish-subscribe. Più servizi usano questo componente. Il servizio ordini pubblica messaggi sul bus e i servizi Makeline, contabilità, servizio fedeltà e servizio ricevuta sottoscrivono questi messaggi.

• Container Apps è un servizio contenitore completamente gestito e serverless per le applicazioni containerizzate. In questa architettura ospita tutte le app container in un ambiente e fornisce un ingress gestito basato su Envoy per il routing esterno all'interfaccia utente. Considera un ambiente come una rete condivisa, un confine di distribuzione e di attendibilità e posiziona i carichi di lavoro che richiedono l'isolamento in ambienti separati.

• SQL Database è un servizio di database relazionale gestito. In questa architettura funge da archivio dati per il servizio di contabilità, che usa Entity Framework Core per accedere al database. Il bootstrapper crea gli oggetti di database necessari prima che il servizio contabilità inizi a elaborare gli ordini.

• Dapr è un runtime open source che fornisce API per le attività delle applicazioni distribuite. In questa architettura, Container Apps esegue un sidecar Dapr gestito insieme a ogni servizio abilitato e i servizi usano i blocchi predefiniti di pubblicazione-sottoscrizione, stato, associazione e chiamata al servizio.

• KEDA è un autoscaler open source basato sugli eventi. In questa architettura, l'integrazione KEDA gestita in Container Apps ridimensiona i servizi in base alla concorrenza HTTP e al numero di messaggi della sottoscrizione di bus di servizio.

Alternative

Questa architettura usa il livello di ingresso predefinito di Container Apps, che viene eseguito come proxy Envoy gestito, insieme a una configurazione di route a livello di ambiente. Questa combinazione sostituisce un contenitore proxy che il team del carico di lavoro altrimenti dovrebbe distribuire, ridimensionare e applicare patch. Le autorizzazioni di configurazione della route sono definite a livello di ambiente anziché per le singole app e una route a livello di ambiente può esporre un'app che altrimenti avrebbe un ingresso interno, quindi limita chi può creare route ed esamina ogni destinazione di route.

Per i carichi di lavoro di produzione con connessione Internet, usare un servizio di ingresso gestito con funzionalità WAF, ad esempio gateway applicazione di Azure o Frontdoor di Azure, in base ai requisiti di routing a livello di area o globale. Preferisci un ingress gestito rispetto a un proxy self-hosted in modo che il team del carico di lavoro non debba gestire l'immagine del proxy, l'applicazione delle patch per le vulnerabilità, la configurazione dell'alta disponibilità e il ciclo di vita della scalabilità. Usare un proxy self-hosted solo quando una funzionalità necessaria non è disponibile nelle opzioni gestite e documentare i processi di hardening, applicazione di patch, monitoraggio e ripristino.

I servizi raggiungono bus di servizio, Azure Cosmos DB, Azure Redis gestito e gestione rete virtuale di Azure tramite componenti Dapr e il servizio contabilità si connette direttamente al database SQL tramite Entity Framework Core. Quando due componenti implementano il comportamento dell'API Dapr compatibile, è spesso possibile modificare la configurazione del componente senza modificare il codice dell'applicazione. Le funzionalità dei componenti, i modelli di coerenza, i metodi di autenticazione, il comportamento operativo e i livelli di supporto di Container Apps differiscono, quindi convalidare la sostituzione prima di passare. La documentazione di Dapr elenca broker di pubblicazione-sottoscrizione alternativi, archivi di stato e binding di output.

Dettagli dello scenario

I microservizi forniscono confini di deployment e scalabilità indipendenti, ma introducono anche la complessità operativa e dei sistemi distribuiti. I servizi containerizzati necessitano di una piattaforma che fornisce funzionalità di deployment, rete, scalabilità e osservabilità.

Questa architettura usa l'integrazione gestita di Dapr in Container Apps. Dapr fornisce API per aspetti delle applicazioni distribuite, ad esempio la gestione dello stato, la messaggistica publish-subscribe, i binding e la chiamata al servizio.

Container Apps usa KEDA per ridimensionare le app contenitore in base al traffico HTTP e agli eventi provenienti da servizi come bus di servizio e Azure Managed Redis.

L'ingresso predefinito di Container Apps fornisce endpoint HTTPS, individuazione dei servizi interni, bilanciamento del carico e suddivisione del traffico tra revisioni. Questa architettura usa il routing basato su regole in modo che l'interfaccia utente e le API del dashboard condividano un nome host mentre i servizi back-end usano l'ingress interno. Aggiungere Frontdoor di Azure o Application Gateway quando il carico di lavoro richiede un WAF, un routing globale o altri controlli perimetrali.

Per altre informazioni, vedere Confrontare app contenitore con altre opzioni del contenitore di Azure.

Potenziali casi d'uso

Si consideri questa progettazione per sistemi di ordini e di evasione basati su eventi che necessitano di servizi HTTP e in background distribuibili in modo indipendente, messaggistica asincrona e archivi di stato gestiti. Lo scenario è rilevante per i carichi di lavoro nel retail, nei beni di largo consumo e nella manifattura.

Gli approcci architetturali correlati includono:

• Architettura di microservizi nel servizio Azure Kubernetes
• Architettura di microservizi in Funzioni di Azure
• Architetture guidate dagli eventi

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Well-Architected Framework.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'affidabilità.

Questa architettura usa un ambiente di Container Apps in un'area di Azure, quindi un'interruzione a livello di area rende il carico di lavoro non disponibile. Per una distribuzione di produzione, usare le procedure di affidabilità seguenti:

• Abilitare la ridondanza della zona quando si crea l'ambiente di Container Apps. Configurare almeno due repliche per i servizi che devono rimanere disponibili durante un guasto di zona. Per i servizi esposti tramite Ingress, prendere in considerazione almeno tre repliche, in base all'obiettivo di disponibilità e ai test di capacità.

• Configurare probe di integrità di avvio, idoneità e attività per ogni servizio. I probe consentono a Container Apps di riavviare i contenitori con errori e rimuovere le repliche non integre dal bilanciamento del carico.

• Impostare il numero minimo di repliche e le regole di ridimensionamento che mantengono la capacità necessaria dopo il guasto di una replica o di una zona. La scalabilità a zero è appropriata solo per i servizi che possono tollerare la latenza di avvio a freddo e periodi senza repliche in esecuzione.

• Applicare la gestione degli errori temporanei alle chiamate tra servizi e alle dipendenze di Azure. Usare tentativi delimitati con backoff, timeout e circuit breaker. Coordinare i criteri di nuovo tentativo tra i livelli per evitare di moltiplicare i tentativi. Rendere idempotenti le operazioni ritentate e i gestori di messaggi perché i tentativi e la nuova consegna di bus di servizio possono ripetere il lavoro.

• Configurare le funzionalità di affidabilità e ripristino del database SQL, Azure Cosmos DB, Azure Managed Redis, bus di servizio e gestione rete virtuale di Azure per soddisfare gli obiettivi di ripristino del carico di lavoro. Container Apps non replica i dati dell'applicazione né fornisce il backup dei dati.

• Non usare Azure Managed Redis come sistema di riferimento autorevole per i dati che non è possibile ricostruire. Il servizio contabilità archivia ogni ordine e registra la data di completamento, mentre Azure Managed Redis contiene solo la coda di lavoro del servizio Makeline. Se lo stato Redis viene perso, la coda in sospeso deve essere ricostruita.

Se il carico di lavoro deve tollerare un'interruzione regionale, distribuire ambienti Container Apps separati e risorse dipendenti tra aree. Usare Frontdoor di Azure o Gestione traffico di Azure per il failover del traffico e definire una strategia di replica e ripristino dei dati tra aree.

Container Apps fornisce criteri di resilienza di individuazione dei servizi (anteprima) per le chiamate effettuate tramite l'individuazione dei servizi di Container Apps. Questi criteri non si applicano all'invocazione di servizio Dapr. Per le chiamate Dapr di questa architettura, implementare timeout, tentativi delimitati e circuit breaker nell'applicazione chiamante.

Per i servizi abilitati per Dapr, abilitare e configurare i controlli di integrità dell'app Dapr insieme ai probe di integrità delle app contenitore. Dapr collega lo stato di integrità del sidecar allo stato di integrità dell'applicazione.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.

Questa architettura di esempio assegna priorità alla dimostrazione di Dapr e ridimensionamento basato su eventi. Usa le credenziali di amministratore o le chiavi di accesso per diversi servizi dati, non distribuisce l'ambiente di Container Apps in una rete virtuale e non include un WAF. Non usare queste impostazioni per una distribuzione di produzione.

• Assegna un'identità gestita separata a ogni app contenitore. Concedi a ogni identità solo i ruoli del piano dati richiesti dal servizio. Usare l'autenticazione Microsoft Entra per database SQL, bus di servizio, gestione rete virtuale di Azure, Azure Cosmos DB e Azure Managed Redis in cui il client o il componente Dapr selezionato lo supporta.

• Configurare i componenti Dapr supportati da Azure per l'uso dell'identità gestita. Se un componente non supporta l'identità gestita, archiviare le credenziali in Azure Key Vault e farvi riferimento tramite un archivio segreti Dapr. Definire l'ambito di ogni componente Dapr solo per le app che lo usano.

• Usare l'identità gestita per bus di servizio l'autenticazione con regole di scalabilità KEDA. Non inserire stringhe di connessione a livello di spazio dei nomi nei segreti dell'app contenitore.

• Distribuisci l'ambiente di Container Apps in una rete virtuale. Usare endpoint privati per i servizi dati supportati e disabilitare il relativo accesso alla rete pubblica. Controllare il traffico in uscita con route definite dall'utente e Firewall di Azure quando il carico di lavoro richiede l'ispezione o le restrizioni in uscita.

• Proteggere il traffico HTTP pubblico con Web application firewall di Azure. Usare Application Gateway con Web application firewall per l'ingresso a livello di area oppure usare Frontdoor di Azure Premium con collegamento privato di Azure per l'ingresso globale. Le origini di collegamento privato richiedono il livello Premium e un ambiente dei profili di carico di lavoro. Disabilitare l'accesso alla rete pubblica nell'ambiente Container Apps quando tutto il traffico in ingresso usa la connettività privata.

• Abilitare l'autenticazione e l'autorizzazione di Container Apps per gli endpoint rivolti all'utente quando il carico di lavoro soddisfa i requisiti di identità. Applicare l'autorizzazione nel carico di lavoro per le decisioni a livello di risorsa. La chiamata al servizio Dapr fornisce TLS reciproco per le chiamate tra le app abilitate per Dapr, ma non sostituisce l'autorizzazione dell'applicazione.

• Archiviare le immagini in un'istanza di Registro Azure Container privata. Eseguire il pull delle immagini usando l'identità gestita, bloccare le immagini distribuibili tramite digest o un tag di versione non modificabile, analizzare le immagini nella pipeline di distribuzione ed evitare contenitori con privilegi.

• Eseguire lo scrub delle credenziali, dei dati personali e dei dati aziendali sensibili dai log dell'applicazione e di Dapr. Inviare log rilevanti per la sicurezza a una destinazione centrale e configurare avvisi per autenticazioni non riuscite, traffico in uscita imprevisto e modifiche alle identità o all'accesso alla rete.

Ottimizzazione costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

Usare questa stima preconfigurata nel calcolatore prezzi Azure come punto di partenza per una distribuzione rappresentativa di produzione a singola area. La stima riguarda le app contenitore e le relative allocazioni di risorse sidecar dapr, scalabilità basata su KEDA, database SQL, Azure Cosmos DB, Azure Redis gestito, bus di servizio, gestione rete virtuale di Azure, Monitoraggio di Azure, Application Insights, Key Vault, Registro Contenitori, endpoint privati e Frontdoor di Azure Premium con WAF e supporto collegamento privato.

La stima usa i prezzi con pagamento in base al consumo e il volume delle richieste rappresentative, i conteggi delle repliche, la capacità dei dati, la capacità di messaggistica e l'inserimento dei dati di telemetria. Esclude piani di supporto, ambienti di sviluppo e test, ripristino di emergenza in una seconda area e Application Gateway. Modificare i presupposti di area, capacità, disponibilità, trasferimento dei dati e utilizzo in modo che corrispondano al carico di lavoro.

• Scegliere il piano di Container Apps e i profili del carico di lavoro in base ai requisiti misurati di CPU, memoria e traffico. Ridimensionare i servizi a zero solo quando i requisiti di disponibilità e avvio a freddo lo consentono. L'impostazione di un numero minimo di repliche più elevato può migliorare l'affidabilità, ma aumenta anche i costi di calcolo. Tenere conto della replica in esecuzione continua del worker virtuale e del relativo polling del servizio Makeline. L'arresto del traffico dei clienti e del dashboard non elimina i costi di calcolo per questi due servizi.

• Considera come viene fatturato ogni profilo di carico di lavoro. Fatture a consumo per le risorse usate dalle repliche in esecuzione. Fatture dedicate per ogni istanza del profilo allocata, indipendentemente dal fatto che le app in esecuzione siano attive, oltre a una tariffa di gestione del piano dedicata per l'ambiente. Gli endpoint privati nell'ambiente comportano anche la tariffa di gestione, anche se non si usano profili dedicati. Per ulteriori informazioni, vedere Fatturazione nelle Container Apps.

• Includi il consumo delle risorse sidecar Dapr quando dimensioni ogni replica. Impostare allocazioni esplicite di CPU e memoria per i contenitori di applicazioni, monitorare l'uso effettivo e tenere conto del sovraccarico sidecar gestito nella pianificazione della capacità.

• Considerare database SQL, Azure Cosmos DB, Azure Redis gestito, bus di servizio, gestione rete virtuale di Azure, Log Analytics, Application Insights, endpoint privati e un WAF perimetrale come driver di costo separati. Questi servizi possono continuare a generare addebiti quando le app contenitore vengono ridimensionate a zero.

• Impostare deliberatamente il campionamento dei dati di telemetria, le categorie di log e i periodi di conservazione. La console con volumi elevati, HTTP, dipendenze e dati di traccia può creare costi significativi di acquisizione e conservazione.

• Creare budget e avvisi relativi ai costi. Usare tag coerenti per allocare i costi al carico di lavoro e ai relativi ambienti e confrontare regolarmente la capacità con l'uso osservato.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.

Definire l'ambiente delle app contenitore, le app contenitore, i componenti dapr, le identità, le assegnazioni di ruolo, le regole di scalabilità e la configurazione di monitoraggio usando l'infrastruttura come codice. Usare le versioni delle immagini non modificabili e le revisioni di Container Apps per supportare distribuzioni in staging, convalida dell'integrità, rollback e suddivisione del traffico.

Configurare l'ambiente per l'uso della destinazione di registrazione Monitoraggio di Azure e instradare i log della console e di sistema tramite le impostazioni di diagnostica. La destinazione legacy Log Analytics scrive nelle tabelle personalizzate ContainerAppConsoleLogs_CL e ContainerAppSystemLogs_CL. L'API HTTP Data Collector sottostante ha raggiunto la fine del supporto il 14 settembre 2026. L'acquisizione continua per i client che usano TLS 1.2 o versione successiva, ma l'API riceve solo correzioni di sicurezza critiche, quindi eseguire la migrazione per rimuovere la dipendenza. Per indicazioni sulla migrazione, vedere Modificare la registrazione di Container Apps da Log Analytics ad Monitoraggio di Azure.

La query seguente usa la tabella Monitoraggio di Azure specifica della risorsa per visualizzare i log recenti del servizio Makeline:

ContainerAppConsoleLogs
| where ContainerAppName == "make-line-service"
| project TimeGenerated, RevisionName, ContainerName, Log
| order by TimeGenerated desc

Integra ogni applicazione con OpenTelemetry o un SDK di Application Insights. Container Apps non strumenta automaticamente il codice dell'applicazione. È possibile usare l'agente OpenTelemetry gestito per instradare i log e le tracce generati ad Application Insights o a un'altra destinazione supportata, ma l'applicazione deve comunque generare i dati di telemetria.

Quando il tracciamento distribuito viene configurato tra i servizi, la mappa delle applicazioni di Application Insights visualizza le relazioni tra servizi e dipendenze. Usalo con log e metriche per analizzare guasti e latenza.

Lo screenshot seguente mostra una mappa delle applicazioni in Application Insights.

Creare avvisi per revisioni non riuscite, repliche non integre o riavviate, errori di richiesta e latenza, saturazione della replica, errori delle regole di scalabilità, crescita dei messaggi non recapitabili in bus di servizio, errori del componente Dapr e dipendenze non riuscite. Connettere gli avvisi a un processo di risposta agli incidenti e testare le notifiche. Per altre informazioni, vedere Observability in Container Apps.

Efficienza delle prestazioni

L'efficienza delle prestazioni si riferisce alla capacità del carico di lavoro di ridimensionarsi per soddisfare in modo efficiente le esigenze degli utenti. Per altre informazioni, vedere Elenco di controllo per la revisione del design per l'efficienza delle prestazioni.

Questa soluzione usa l'implementazione KEDA in Container Apps per il ridimensionamento basato sugli eventi. Il servizio clienti virtuale inserisce gli ordini tramite il servizio ordini, che viene ridimensionato in base alla concorrenza HTTP. Il servizio ordini pubblica messaggi in un topic di bus di servizio. I servizi di contabilità, Receipt, Makeline e fedeltà si ridimensionano in base al numero di messaggi attivi nei loro abbonamenti. L'app container dell'interfaccia utente viene scalata in base alla concorrenza HTTP.

Impostare il numero di messaggi di destinazione, la concorrenza HTTP, le repliche minime, le repliche massime, l'intervallo di polling e il periodo di raffreddamento in base ai risultati del test di carico. Includi l'uso della risorsa sidecar dapr e il tempo di avvio nel test. Il numero di repliche è un obiettivo di scalabilità, non una garanzia di disponibilità, quindi verificare che il massimo configurato possa soddisfare la domanda di picco e che i servizi dati downstream possano gestire la concorrenza risultante.

Rendere idempotenti gli handler di messaggi, definire il comportamento di ripetizione dei tentativi e dead-letter e ottimizzare la durata e la concorrenza del blocco dei messaggi in modo che la scalabilità orizzontale non causi l'elaborazione duplicata o il throttling delle dipendenze.

Quando il cliente virtuale non è in esecuzione, nessun utente accede all'interfaccia utente e le sottoscrizioni bus di servizio non hanno messaggi rimanenti, i servizi ordini, contabilità, ricevute, fedeltà e interfaccia utente possono essere ridimensionati a zero se i numeri minimi di repliche sono zero.

In questo esempio il worker virtuale viene mantenuto con una sola replica perché il ruolo di lavoro esegue continuamente il polling del servizio Makeline per l'evasione degli ordini. Tali chiamate di invocazione Dapr vengono conteggiate come traffico in ingresso per la regola di scalabilità HTTP di Makeline, anche quando non sono in sospeso ordini. Affinché Makeline rimanga scalato a zero, arrestare il polling del worker virtuale e il traffico del cliente e del dashboard, svuotare la sottoscrizione bus di servizio e impostare il numero minimo di repliche su zero. Per i servizi che devono evitare l'avvio a freddo o rimanere disponibili in caso di guasto, impostare il numero minimo di repliche su almeno uno. Per altre informazioni, vedere Impostare le regole di ridimensionamento in App per container.

Profili del carico di lavoro

Usare i profili di carico di lavoro per separare i servizi che necessitano di capacità a caldo dai servizi che traggono il massimo vantaggio dall'elasticità serverless. Nel diagramma dell'architettura il servizio ordini e il servizio di contabilità vengono visualizzati in esecuzione in un profilo dedicato perché gestiscono il lavoro transazionale e supportano le metriche aziendali in tempo reale. Il servizio di ricezione e il servizio loyalty vengono visualizzati in esecuzione in un profilo Consumption perché sono servizi basati su eventi che possono sfruttare al meglio l'elasticità serverless.

Questa suddivisione è illustrativa. I servizi in questo esempio non hanno le esigenze di utilizzo sostenuto, i requisiti delle risorse o le necessità di isolamento che richiedono un profilo dedicato; inoltre, un profilo a consumo con un numero minimo di repliche maggiore di zero mantiene la capacità attiva. Scegliere un profilo dedicato quando un servizio richiede l'isolamento del calcolo su tenant singolo, una quantità maggiore di CPU o memoria per replica rispetto a quanto offre il profilo a consumo o un utilizzo sufficientemente elevato da far sì che la fatturazione per istanza costi meno della fatturazione a consumo.

Le regole di scalabilità basate su KEDA funzionano sia nei profili di carico di lavoro a consumo che in quello dedicato. Il consumo è ideale per i servizi che possono essere ridimensionati a zero, mentre Dedicato è migliore per i servizi che traggono comunque vantaggio dalla scalabilità automatica, ma richiedono capacità calda o prestazioni più costanti.

Collaboratori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autore principale:

• Alice Gibbons | Specialista Globale di Cloud Native

Altri contributori:

• Lynn Orrell | Principal Solution Specialist (GBB)
• Kendall Roden | Senior Program Manager

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

• Documentazione di Container Apps
• Confrontare le app contenitore con altre opzioni di contenitore di Azure

Risorse correlate

• Architettura di microservizi su AKS
• Architettura avanzata dei microservizi AKS
• Creare una pipeline CI/CD per le app AKS usando Azure Pipelines