Distribuire microservizi con App contenitore di Azure e Dapr

Questo articolo descrive una soluzione per l'esecuzione di un sistema di gestione degli ordini con 10 microservizi nelle app contenitore di Azure. La soluzione usa anche le procedure consigliate per i microservizi tramite Distributed Application Runtime (Dapr) e il ridimensionamento basato su eventi con la scalabilità automatica guidata dagli eventi di Kubernetes (KEDA).

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 di Red Dog fittizio e l'infrastruttura di Azure di supporto. L'architettura è costituita da un singolo ambiente app contenitore che ospita 10 applicazioni di microservizi .NET. App contenitore di Azure usa un livello di ingresso basato su Envoy gestito per instradare il traffico esterno dagli utenti all'interfaccia utente esposta pubblicamente. Le chiamate interne da servizio a servizio non passano attraverso questo ingresso. Invece, usano l'invocazione del servizio Dapr e l'individuazione dei servizi di Container Apps all'interno dell'ambiente. La soluzione usa Dapr SDK per l'integrazione con le risorse di Azure tramite blocchi predefiniti di pubblicazione-sottoscrizione, stato e associazione. I servizi usano anche regole di scalabilità KEDA per consentire il ridimensionamento in base a trigger di eventi e scenari da scala a zero.

Il flusso di dati seguente corrisponde al diagramma precedente:

1. Ingresso gestito: App contenitore di Azure fornisce un livello di ingresso basato su Envoy gestito per il routing delle richieste degli utenti agli endpoint dell'interfaccia utente e dell'API che supportano il dashboard interattivo.

2. 'interfaccia utente: un dashboard che mostra l'ordine in tempo reale e i dati aggregati sulle vendite per il sistema di gestione degli ordini red dog.

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

4. Servizio di ordine: Un'API di creazione, lettura, aggiornamento ed eliminazione per inserire e gestire gli ordini.

5. Servizio contabilità: servizio che elabora, archivia e aggrega i dati degli ordini. Trasforma gli ordini dei clienti in metriche di vendita significative presentate 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.

Componenti

• Application Insights è un servizio estendibile di gestione delle prestazioni delle applicazioni che è possibile usare per monitorare le applicazioni in tempo reale e rilevare automaticamente le anomalie delle prestazioni. In questa architettura si usa Application Insights con Monitoraggio di Azure per visualizzare i log dei contenitori e raccogliere le metriche dai microservizi.

• Archiviazione BLOB è una soluzione basata sul cloud per l'archiviazione di grandi quantità di dati non strutturati, ad esempio file di testo o binari. In questa architettura, un servizio di ricevute usa gestione rete virtuale di Azure tramite un'associazione di output Dapr per archiviare le ricevute degli ordini.

• 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 sugli ordini in fase di elaborazione.

• Azure Cosmos DB è un servizio di database gestito con più modelli NoSQL. In questa architettura, viene utilizzato come componente dell'archivio di stato Dapr per il servizio di fedeltà, al fine di archiviare i dati di fedeltà dei clienti.

• Monitoraggio di Azure è una piattaforma unificata che consente di raccogliere, analizzare e agire sui dati sui contenuti dei clienti negli ambienti di infrastruttura di Azure. In questa architettura si usa Monitoraggio di Azure con Application Insights per visualizzare i log dei contenitori e raccogliere le metriche dai microservizi.

• Il bus di servizio è un broker di messaggi aziendale completamente gestito con code e argomenti 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 di container serverless completamente gestito, usato per creare e distribuire app moderne su ampia scala. In questa architettura si ospitano tutti i microservizi nelle app contenitore e li si distribuisce in un singolo ambiente app contenitore. Questo ambiente funge da limite sicuro intorno al sistema e fornisce ingresso basato su Envoy gestito per il routing esterno all'interfaccia utente.

• Il database SQL è un servizio di database relazionale intelligente e scalabile creato per il cloud. In questa architettura funge da archivio dati per il servizio di contabilità, che usa Entity Framework Core per interfacciarsi con il database. Il servizio bootstrapper è responsabile della configurazione delle tabelle SQL nel database. Viene quindi eseguito una volta prima di stabilire la connessione al servizio di contabilità.

Alternative

In questa architettura, il percorso di routing predefinito usa il livello di ingresso integrato di Container Apps, implementato tramite un proxy Envoy gestito. Se un carico di lavoro richiede un comportamento personalizzato di middleware o protocollo oltre le funzionalità di ingresso native, i proxy dedicati, ad esempio NGINX o HAProxy , sono alternative.

Tutta l'infrastruttura di Azure, ad eccezione del database SQL, usa i componenti Dapr per l'interoperabilità. Un vantaggio di Dapr è che è possibile scambiare tutti questi componenti modificando la configurazione di distribuzione delle app contenitore. In questo scenario, bus di servizio, Azure Cosmos DB, Azure Managed Redis e Archiviazione BLOB presentano alcuni dei più di 70 componenti Dapr disponibili. Un elenco di broker di pubblicazione-sottoscrizionealternativi, archivi di stato e associazioni di output sono disponibili nella documentazione di Dapr.

Dettagli dello scenario

I microservizi sono uno stile architetturale ampiamente adottato. Offrono vantaggi come scalabilità, agilità e distribuzioni indipendenti. È possibile usare i contenitori come meccanismo per distribuire applicazioni di microservizi e quindi usare un agente di orchestrazione di contenitori come Kubernetes per semplificare le operazioni. Esistono molti fattori da considerare per le architetture di microservizi su larga scala. In genere, la piattaforma dell'infrastruttura richiede una conoscenza significativa di tecnologie complesse come gli agenti di orchestrazione dei contenitori.

Container Apps è un servizio di container serverless completamente gestito per l'esecuzione di applicazioni moderne su vasta scala. Consente di distribuire app in contenitori tramite un'astrazione della piattaforma sottostante. Usando questo metodo, non è necessario gestire un'infrastruttura complessa.

Questa architettura usa l'integrazione di App contenitore con una versione gestita di Dapr. Dapr è un progetto open source che consente agli sviluppatori di superare le sfide intrinseche nelle applicazioni distribuite, ad esempio la gestione dello stato e la chiamata al servizio.

Le Container Apps forniscono anche una versione gestita di KEDA. KEDA consente ai contenitori di ridimensionarsi automaticamente in base agli eventi in ingresso da servizi esterni, ad esempio il bus di servizio e Azure Managed Redis.

Container Apps fornisce anche un ingress gestito basato su Envoy, così puoi esporre endpoint HTTP, usare domini personalizzati e TLS gestito e supportare scenari di suddivisione del traffico senza distribuire un livello proxy separato.

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

Questo articolo descrive una soluzione per eseguire un sistema di gestione degli ordini con 10 microservizi sulle App contenitore. La soluzione usa anche le procedure consigliate per i microservizi tramite Dapr e il ridimensionamento basato su eventi con KEDA.

Potenziali casi d'uso

Questa soluzione si applica a qualsiasi organizzazione che usa microservizi senza stato e con stato per i sistemi distribuiti. La soluzione è ideale per l'industria dei beni di consumo confezionati e per le industrie manifatturiere che dispongono di un sistema di ordinazione e adempimento.

Le soluzioni seguenti hanno progettazioni simili:

• 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à.

L'Container Apps è basato su Kubernetes, che opera come infrastruttura sottostante. I meccanismi di resilienza sono integrati in Kubernetes che monitorano e riavviano i contenitori o i pod, in caso di problemi. I meccanismi di resilienza includono un servizio di bilanciamento del carico predefinito che distribuisce il traffico tra più repliche di ogni app contenitore. Questa ridondanza consente al sistema di rimanere operativi, anche se una replica non è più disponibile.

Container Apps fornisce anche criteri di rilevamento dei servizi e resilienza che possono essere usati per applicare timeout e il comportamento del circuit breaker tra i servizi. Per i servizi che utilizzano Dapr, configurare le impostazioni di integrità dell'applicazione in modo che le repliche non sane vengano rilevate più tempestivamente e che il traffico venga allontanato dalle istanze degradate prima che i guasti si propaghino ai componenti downstream.

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.

L'elenco seguente illustra diverse funzionalità di sicurezza omesse in questa architettura, insieme ad altre raccomandazioni e considerazioni:

• Questa architettura non usa endpoint privati, che consentono una connettività più sicura e privata ai servizi di Azure assegnando loro un indirizzo IP dalla rete virtuale. Quando si usano endpoint privati, l'accesso alla rete pubblica può essere disabilitato. Questo approccio mantiene il traffico sul backbone Microsoft e migliora la sicurezza e la conformità.

  In alternativa agli endpoint privati, è consigliabile usare Azure perimetro di sicurezza di rete per limitare l'accesso alla rete a Microsoft.ServiceBus/namespaces e Microsoft.Storage/storageAccounts. Un perimetro di sicurezza di rete consente di associare queste risorse a un perimetro condiviso e definire regole di accesso in ingresso. In questa architettura, Container Apps non è distribuito con una rete virtuale personalizzata né con un indirizzo IP in uscita statico, quindi limita la regola in ingresso alla sottoscrizione che ospita l'ambiente di Container Apps anziché a un intervallo di indirizzi IP, poiché quest'ultimo richiede un indirizzo IP di origine stabile e noto per essere efficace.

• L'attività di rete deve essere monitorata continuamente per rilevare e prevenire abusi. È possibile ottenere questo approccio usando firewall di Azure e tabelle di route. Le tabelle di route consentono al traffico che lascia una rete virtuale di passare prima dal firewall. Questo processo è un passaggio importante per garantire che l'architettura non sia vulnerabile agli attacchi di esfiltrazione dei dati.

• Usare un web application firewall (WAF) per proteggersi da vulnerabilità comuni. Usare Front Door di Azure o il Gateway Applicazione di Azure per implementare un WAF in questa architettura.

• Prendere in considerazione l'uso della funzionalità predefinita di autenticazione e autorizzazione per le app contenitore, nota come Autenticazione semplice. L'autenticazione semplice gestisce l'integrazione con provider di identità all'esterno dell'app Web, riducendo così la quantità di codice da gestire.

• Uso delle identità gestite per i carichi di lavoro. Identità gestita elimina la necessità che gli sviluppatori gestiscano le credenziali di autenticazione. Ad esempio, l'architettura di base esegue l'autenticazione a SQL Server tramite password in una stringa di connessione. Quando possibile, usare gli ID Microsoft Entra per eseguire l'autenticazione in Azure SQL Server.

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 il calcolatore prezzi di Azure per stimare il costo dei servizi in questa architettura.

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.

Dapr aggiunge un livello di portabilità tra i servizi e l'infrastruttura di supporto. Questo livello fornisce valore quando si prevede che i servizi di backup vengano modificati o quando si vuole scambiare un componente, ad esempio un archivio stati o un broker di messaggi, tramite la configurazione anziché il codice. Dapr aggiunge anche una dipendenza e un livello di indirezione. Quando si dispone di un set abbastanza stabile di endpoint nativi di Azure che non si prevede di sostituire, chiamare direttamente il Azure SDK nativo è un'alternativa ragionevole che rimuove l'astrazione Dapr. Valutare la flessibilità dei componenti Dapr rispetto alla semplicità operativa delle chiamate DIRETTE ALL'SDK.

È possibile usare Monitoraggio di Azure e Application Insights per monitorare le app contenitore. Per le applicazioni distribuite, usare una pipeline basata su OpenTelemetry per inviare tracce, log e metriche a Monitoraggio di Azure e Application Insights. È anche possibile visualizzare i log dei contenitori passando, nel portale, al riquadro Logs di ogni app contenitore e quindi eseguendo la query Kusto seguente. Questo esempio mostra i log per l'app del servizio Makeline.

ContainerAppConsoleLogs_CL |
    where ContainerAppName_s contains "make-line-service" |
    project TimeGenerated, _timestamp_d, ContainerGroupName_s, Log_s |
    order by _timestamp_d asc

La mappa delle applicazioni in Application Insights mostra anche come i servizi comunicano in tempo reale. È quindi possibile usarli per gli scenari di debug. Passare alla mappa dell'applicazione sotto la risorsa di Application Insights per visualizzare una mappa simile alla seguente.

Per ulteriori informazioni, vedere Monitorare un'app 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 si basa principalmente sull'implementazione KEDA in App contenitore per il ridimensionamento basato sugli eventi. Quando si implementa il servizio clienti virtuale, gli ordini vengono continuamente effettuati. Questa azione di ridimensionamento fa sì che il servizio ordini possa aumentare le prestazioni tramite una regola di scalabilità HTTP. Man mano che il servizio degli ordini pubblica gli ordini nel bus di servizio, le regole di scalabilità di bus di servizio fanno sì che i servizi di contabilità, scontrini, Makeline e fedeltà vengano scalati verso l'alto. L'interfaccia utente e il servizio Makeline possono anche usare le regole di scalabilità HTTP in modo che le app si ridimensionano man mano che più utenti accedono al dashboard.

Quando il cliente virtuale non è in esecuzione, tutti i microservizi in questa soluzione vengono ridimensionati su zero, ad eccezione dei servizi di lavoro virtuale e makeline. Il lavoratore virtuale non scala verso il basso perché controlla continuamente l'evasione degli ordini. 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. In questo diagramma il servizio Ordini e il servizio Contabilità vengono visualizzati in un profilo dedicato perché gestiscono il lavoro transazionale e supportano le metriche aziendali in tempo reale. Il servizio di ricezione e il servizio fedeltà vengono visualizzati in un profilo a consumo perché sono servizi basati su eventi che possono sfruttare al meglio l'elasticità serverless.

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 delle App Container
• Confrontare le app contenitore con altre opzioni di contenitore di Azure

Risorse correlate

• Architettura di microservizi su AKS
• Architettura avanzata dei microservizi AKS
• Integrazione continua e delivery continuo per le app AKS con Azure Pipelines