Comunicazione con i clienti del front-end

Suggerimento

Questo contenuto è un estratto dell'eBook Architecting Cloud Native .NET Applications for Azure, disponibile in .NET Docs o come PDF scaricabile gratuito che può essere letto offline.

Scaricare il PDF

In un sistema nativo del cloud, i client front-end (applicazioni per dispositivi mobili, Web e desktop) richiedono un canale di comunicazione per interagire con microservizi back-end indipendenti.

Quali sono le opzioni?

Per semplificare le operazioni, un client front-end può comunicare direttamente con i microservizi back-end, come illustrato nella figura 4-2.

Figura 4-2. Comunicazione diretta da cliente a servizio

Con questo approccio, ogni microservizio ha un endpoint pubblico accessibile dai client front-end. In un ambiente di produzione, è necessario posizionare un servizio di bilanciamento del carico davanti ai microservizi, instradando il traffico in modo proporzionale.

Anche se semplice da implementare, la comunicazione client diretta sarebbe accettabile solo per semplici applicazioni di microservizio. Questo modello associa strettamente i client front-end ai servizi back-end principali, aprendo la porta per molti problemi, tra cui:

• Suscettibilità del client al refactoring dei servizi back-end.
• Una superficie di attacco più ampia perché i servizi back-end principali vengono esposti direttamente.
• Duplicazione di aspetti trasversali in ogni microservizio.
• Codice client eccessivamente complesso: i client devono tenere traccia di più endpoint e gestire gli errori in modo resiliente.

Al contrario, un modello di progettazione cloud ampiamente accettato consiste nell'implementare un servizio Gateway API tra le applicazioni front-end e i servizi back-end. Il modello è illustrato nella figura 4-3.

Figura 4-3. Modello di gateway API

Nella figura precedente si noti come il servizio Gateway API astrae i microservizi core back-end. Implementato come API Web, funge da proxy inverso, instradando il traffico in ingresso ai microservizi interni.

Il gateway isola il client dal partizionamento del servizio interno e dal refactoring. Se si modifica un servizio back-end, è possibile usarlo nel gateway senza interrompere il client. È anche la prima linea di difesa per questioni trasversali, ad esempio identità, memorizzazione nella cache, resilienza, misurazione e limitazione. Molte di queste problematiche trasversali possono essere delegati dai servizi core di back-end al gateway, semplificando i servizi di back-end.

È necessario prestare attenzione per mantenere il gateway API semplice e veloce. In genere, la logica di business viene mantenuta fuori dal gateway. Un gateway complesso rischia di diventare un collo di bottiglia e alla fine un monolite stesso. I sistemi più grandi espongono spesso più gateway API segmentati per tipo di client (mobile, Web, desktop) o funzionalità back-end. Il modello Back-end per front-end fornisce la direzione per l'implementazione di più gateway. Il modello è illustrato nella figura 4-4.

Figura 4-4. Back-end per il modello front-end

Si noti nella figura precedente come il traffico in ingresso viene inviato a un gateway API specifico, in base al tipo di client: Web, mobile o app desktop. Questo approccio ha senso perché le funzionalità di ogni dispositivo differiscono in modo significativo tra fattori di forma, prestazioni e limitazioni di visualizzazione. In genere, le applicazioni per dispositivi mobili espongono meno funzionalità di un browser o di applicazioni desktop. Ogni gateway può essere ottimizzato in modo da corrispondere alle abilità e alle funzionalità del dispositivo corrispondente.

Gateway semplici

Per iniziare, è possibile creare il proprio servizio Gateway API. Una rapida ricerca di GitHub fornirà molti esempi.

Per semplici applicazioni native del cloud .NET, è possibile prendere in considerazione il gateway Ocelot. Open source e creato per i microservizi .NET, è leggero, veloce e scalabile. Come qualsiasi gateway API, la funzionalità principale consiste nell'inoltrare le richieste HTTP in ingresso ai servizi downstream. Supporta inoltre un'ampia gamma di funzionalità configurabili in una pipeline middleware .NET.

YARP (Yet Another Reverse proxy) è un altro proxy inverso open source guidato da un gruppo di team di prodotti Microsoft. Scaricabile come pacchetto NuGet, YARP si collega al framework ASP.NET come middleware ed è altamente personalizzabile. È possibile trovare YARP ben documentato con vari esempi di utilizzo.

Per le applicazioni native del cloud aziendali, sono disponibili diversi servizi di Azure gestiti che consentono di avviare rapidamente le attività.

Gateway delle applicazioni di Azure

Per requisiti gateway semplici, è possibile considerare l'Azure Application Gateway. Disponibile come servizio PaaS di Azure, include funzionalità di gateway di base, ad esempio routing url, terminazione SSL e web application firewall. Il servizio supporta le funzionalità di bilanciamento del carico di livello 7 . Con il livello 7, è possibile instradare le richieste in base al contenuto effettivo di un messaggio HTTP, non solo ai pacchetti di rete TCP di basso livello.

In questo libro viene illustrato come ospitare sistemi nativi del cloud in Kubernetes. Un agente di orchestrazione dei contenitori, Kubernetes automatizza la distribuzione, il ridimensionamento e i problemi operativi dei carichi di lavoro in contenitori. Il Gateway applicativo di Azure può essere configurato come gateway API per il cluster di Azure Kubernetes Service.

Il Application Gateway Ingress Controller consente all'Azure Application Gateway di lavorare direttamente con l'Azure Kubernetes Service. La figura 4.5 mostra l'architettura.

Figura 4-5. Controller di ingresso del gateway applicazione

Kubernetes include una funzionalità predefinita che supporta il bilanciamento del carico HTTP (livello 7), denominata Ingresso. Ingress definisce un set di regole per il modo in cui le istanze di microservizi all'interno di AKS possono essere esposte al mondo esterno. Nell'immagine precedente il controller di ingresso interpreta le regole di ingresso configurate per il cluster e configura automaticamente il gateway applicazione di Azure. In base alle seguenti regole, l'Application Gateway instrada il traffico ai microservizi in esecuzione all'interno di AKS. Il controller di ingressi rileva le modifiche alle regole di ingresso e apporta le modifiche appropriate all'Azure Application Gateway.

Gestione API di Azure

Per i sistemi nativi del cloud su larga scala, è possibile prendere in considerazione Gestione API di Azure. Si tratta di un servizio basato sul cloud che non solo risolve le esigenze del gateway API, ma offre un'esperienza di sviluppo e amministrazione completa. Gestione delle API è illustrata nella Figura 4-6.

Figura 4-6. Gestione API di Azure

Per iniziare, Gestione API espone un server gateway che consente l'accesso controllato ai servizi back-end in base a regole e criteri configurabili. Questi servizi possono trovarsi nel cloud di Azure, nel data center locale o in altri cloud pubblici. Le chiavi API e i token JWT determinano chi può eseguire le operazioni. Tutto il traffico viene registrato a scopo analitico.

Per gli sviluppatori, Gestione API offre un portale per sviluppatori che fornisce l'accesso a servizi, documentazione e codice di esempio per richiamarli. Gli sviluppatori possono usare Swagger/Open API per esaminare gli endpoint di servizio e analizzarne l'utilizzo. Il servizio funziona nelle principali piattaforme di sviluppo: .NET, Java, Golang e altro ancora.

Il portale di pubblicazione espone un dashboard di gestione in cui gli amministratori espongono le API e ne gestiscono il comportamento. È possibile concedere l'accesso al servizio, monitorare l'integrità dei servizi e raccogliere i dati di telemetria del servizio. Gli amministratori applicano criteri a ogni endpoint per influire sul comportamento. I criteri sono istruzioni predefinite che vengono eseguite in sequenza per ogni chiamata al servizio. I criteri vengono configurati per una chiamata in ingresso, una chiamata in uscita o richiamati in caso di errore. I criteri possono essere applicati in ambiti di servizio diversi per abilitare l'ordinamento deterministico durante la combinazione di criteri. Il prodotto viene fornito con un numero elevato di criteri predefiniti.

Ecco alcuni esempi di come i criteri possono influire sul comportamento dei servizi nativi del cloud:

• Limitare l'accesso al servizio.
• Applicare l'autenticazione.
• Limitare le chiamate da un'unica origine, se necessario.
• Abilita la memorizzazione nella cache.
• Bloccare le chiamate da indirizzi IP specifici.
• Controllare il flusso del servizio.
• Convertire le richieste da SOAP a REST o tra formati di dati diversi, ad esempio da XML a JSON.

Gestione API di Azure può esporre servizi back-end ospitati ovunque, nel cloud o nel data center. Per i servizi legacy che è possibile esporre nei sistemi nativi del cloud, supporta le API REST e SOAP. Anche altri servizi di Azure possono essere esposti tramite Gestione API. È possibile inserire un'API gestita su un servizio di backup di Azure, ad esempio il bus di servizio di Azure o App per la logica di Azure. Azure API Management non include il supporto predefinito per il bilanciamento del carico e dovrebbe essere utilizzato in combinazione con un servizio di bilanciamento del carico.

Gestione API di Azure è disponibile in quattro livelli diversi:

• Sviluppatore
• Fondamentale
• Normale
• Di alta qualità

Il livello Developer è destinato a carichi di lavoro e valutazione non di produzione. Gli altri livelli offrono progressivamente maggiore potenza, funzionalità e contratti di servizio superiori. Il livello Premium offre il supporto di Rete virtuale di Azure e multi-area. Tutti i livelli hanno un prezzo fisso all'ora.

Il cloud di Azure offre anche un livello serverless per Gestione API di Azure. Detto piano tariffario a consumo, il servizio è una variante della Gestione API basata sul modello di elaborazione serverless. A differenza dei piani tariffari "preallocati" illustrati in precedenza, la modalità di consumo permette un provisioning immediato e il pagamento in base all'azione.

Abilita le funzionalità del gateway API per i casi d'uso seguenti:

• Microservizi implementati usando tecnologie serverless, ad esempio Funzioni di Azure e App per la logica di Azure.
• Risorse del servizio di backup di Azure, ad esempio code e argomenti del bus di servizio, archiviazione di Azure e altri.
• I microservizi in cui il traffico presenta occasionalmente grandi picchi, ma rimane basso la maggior parte del tempo.

Il livello a consumo usa gli stessi componenti di Gestione API del servizio sottostante, ma usa un'architettura completamente diversa in base alle risorse allocate in modo dinamico. Si allinea perfettamente al modello di elaborazione serverless:

• Nessuna infrastruttura da gestire.
• Nessuna capacità inutilizzata.
• Disponibilità elevata.
• Scalabilità automatica.
• Il costo è basato sull'utilizzo effettivo.

Il nuovo livello di consumo è un'ottima scelta per i sistemi nativi del cloud che espongono le risorse serverless come API.

Comunicazione in tempo reale

La comunicazione in tempo reale, o push, è un'altra opzione per le applicazioni front-end che comunicano con sistemi nativi del cloud back-end tramite HTTP. Le applicazioni, ad esempio financial-ticker, l'istruzione online, i giochi e gli aggiornamenti dello stato del lavoro, richiedono risposte istantanee e in tempo reale dal back-end. Con la normale comunicazione HTTP, non è possibile che il client sappia quando sono disponibili nuovi dati. Il client deve eseguire continuamente il polling o inviare richieste al server. Con la comunicazione in tempo reale , il server può eseguire il push di nuovi dati al client in qualsiasi momento.

I sistemi in tempo reale sono spesso caratterizzati da flussi di dati ad alta frequenza e da un numero elevato di connessioni client simultanee. L'implementazione manuale della connettività in tempo reale può diventare rapidamente complessa, richiedendo un'infrastruttura non semplice per garantire scalabilità e messaggistica affidabile ai client connessi. È possibile trovare se stessi gestendo un'istanza di Cache Redis di Azure e un set di servizi di bilanciamento del carico configurati con sessioni permanenti per l'affinità client.

Il servizio Azure SignalR è un servizio di Azure completamente gestito che semplifica la comunicazione in tempo reale per le applicazioni native del cloud. I dettagli dell'implementazione tecnica, come il provisioning della capacità, il ridimensionamento e le connessioni persistenti, sono gestiti in modo astratto. Sono gestiti per te con un contratto di servizio di livello 99.9%. Ci si concentra sulle funzionalità dell'applicazione, non sull'infrastruttura.

Una volta abilitato, un servizio HTTP basato sul cloud può eseguire il push degli aggiornamenti del contenuto direttamente ai client connessi, incluse le applicazioni browser, per dispositivi mobili e desktop. I client vengono aggiornati senza la necessità di eseguire il polling del server. Azure SignalR astrae le tecnologie di trasporto che creano connettività in tempo reale, tra cui WebSockets, eventi Server-Side e Long Polling. Gli sviluppatori si concentrano sull'invio di messaggi a tutti o specifici subset di client connessi.

La figura 4-7 mostra un set di client HTTP che si connettono a un'applicazione nativa del cloud con Azure SignalR abilitato.

Figura 4-7. Azure SignalR

Un altro vantaggio del servizio Azure SignalR è l'implementazione di servizi nativi del cloud serverless. Ad esempio, il codice viene eseguito su richiesta con i trigger di Funzioni di Azure. Questo scenario può essere complicato perché il codice non mantiene connessioni lunghe con i client. Il servizio Azure SignalR può gestire questa situazione perché il servizio gestisce già automaticamente le connessioni.

Il servizio Azure SignalR si integra strettamente con altri servizi di Azure, ad esempio il database SQL di Azure, il bus di servizio o cache Redis, aprendo molte possibilità per le applicazioni native del cloud.

PrecedenteAvanti