Comunicazione client front-end

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 client 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 microservizi. Questo modello associa strettamente i client front-end ai servizi back-end principali, aprendo la porta a molti problemi, tra cui:

• La suscettività del client al refactoring del servizio back-end.
• Una superficie di attacco più ampia perché i servizi back-end principali vengono esposti direttamente.
• La duplicazione di problemi di monitoraggio incrociato in ogni microservizio.
• Un codice client eccessivamente complesso: i client devono tenere traccia di più endpoint e gestire gli errori in modo resiliente.

Al contrario, uno schema progettuale cloud ampiamente accettato consiste nell'implementare un servizio Gateway API tra le applicazioni front-end e i servizi back-end. Lo schema è illustrato nella figura 4-3.

Figura 4-3. Schema gateway API

Nella figura precedente, puoi notare come il servizio Gateway API astrae i microservizi back-end principali. 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 modifichi un servizio back-end, puoi usarlo nel gateway senza interrompere il client. È anche la prima linea di difesa per problemi di monitoraggio incrociato, ad esempio identità, memorizzazione nella cache, resilienza, misurazione e limitazione. Molte di queste problematiche possono essere trasferite dai servizi back-end principali al gateway, semplificando i servizi 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 o persino un monolite. I sistemi più grandi espongono spesso più gateway API segmentati per tipo di client (mobile, Web, desktop) o funzionalità back-end. Lo schema Back-end per front-end fornisce la direzione per l'implementazione di più gateway. Lo schema è illustrato nella figura 4-4.

Figura 4-4. Schema back-end per front-end

Nella figura precedente puoi notare che 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 per 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 per rispondere alle caratteristiche e alle funzionalità del dispositivo corrispondente.

Gateway semplici

Per iniziare, puoi creare il tuo servizio Gateway API. Una rapida ricerca di GitHub fornirà molti esempi.

Per semplici applicazioni native del cloud .NET, puoi 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 serie di funzionalità configurabili in una pipeline middleware .NET.

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

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

Gateway applicazione di Azure

Per requisiti gateway semplici, puoi prendere in considerazione il gateway applicazione di Azure. Disponibile come servizio PaaS di Azure, include funzionalità 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, puoi 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. Agente di orchestrazione, Kubernetes automatizza la distribuzione, il ridimensionamento e i problemi operativi dei carichi di lavoro nei contenitori. Il gateway applicazione di Azure può essere configurato come gateway API per il cluster del servizio Azure Kubernetes.

Il controller in ingresso del gateway applicazione consente al gateway applicazione di Azure di usare direttamente il servizio Azure Kubernetes. 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. L'ingresso definisce un insieme di regole che determinano il modo in cui le istanze di microservizi all'interno del servizio Azure Kubernetes possono essere esposte all'esterno. Nell'immagine precedente il controller in ingresso interpreta le regole di ingresso configurate per il cluster e configura automaticamente il gateway applicazione di Azure. In base a queste regole, il gateway applicazione instrada il traffico ai microservizi in esecuzione all'interno del servizio Azure Kubernetes. Il controller in ingresso rimane in ascolto delle modifiche alle regole di ingresso e apporta le modifiche appropriate al gateway applicazione di Azure.

Gestione API di Azure

Per i sistemi nativi del cloud di dimensioni moderate o grandi, puoi prendere in considerazione Gestione API di Azure. Si tratta di un servizio basato sul cloud che non solo soddisfa le esigenze del gateway API, ma offre un'esperienza di sviluppo e amministrazione completa. Gestione API è illustrato 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ò fare cosa. 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 API Swagger/Open per esaminare gli endpoint di servizio e analizzarne l'utilizzo. Il servizio funziona nelle principali piattaforme di sviluppo: .NET, Java, Golang e altre 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 ai servizi, monitorare l'integrità dei servizi e raccogliere i dati di telemetria dei servizi. Gli amministratori applicano criteri a ogni endpoint per determinarne il 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 a diversi ambiti di servizio 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 a 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 a 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. Puoi inserire un'API gestita su un servizio di backing di Azure, come il bus di servizio di Azure o le App per la logica di Azure. Gestione API di Azure non include il supporto predefinito per il bilanciamento del carico e deve essere usato insieme a un servizio di bilanciamento del carico.

Gestione API di Azure è disponibile in quattro diversi livelli:

• Sviluppatore
• Basic
• Standard
• Premium

Il livello Developer è destinato a carichi di lavoro non di produzione e alla valutazione. Gli altri livelli offrono progressivamente maggiore potenza, funzionalità e contratti di servizio superiori. Il livello Premium offre il supporto multi-area e Rete virtuale di Azure. 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 di Gestione API progettata sul modello di elaborazione serverless. A differenza dei piani tariffari "pre-allocati" illustrati in precedenza, il livello a consumo fornisce provisioning immediato e prezzi in base all’azione effettuata.

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 backing di Azure, ad esempio code e argomenti del bus di servizio, archiviazione di Azure e altri.
• Microservizi in cui il traffico ha picchi occasionali, ma rimane basso per la maggior parte del tempo.

Il livello a consumo usa gli stessi componenti di Gestione API del servizio sottostante, ma impiega 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à inattiva.
• 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 come indicatori finanziari, istruzione online, giochi e aggiornamenti sull’andamento 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, poiché richiede un'infrastruttura non semplice per garantire scalabilità e messaggistica affidabile ai client connessi. Potresti trovarti a gestire 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, ad esempio il provisioning della capacità, il ridimensionamento e le connessioni persistenti, vengono astratti. Sono gestiti automaticamente con un contratto di servizio del 99,9%. Tu ti concentrerai 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, inclusi WebSocket, eventi lato server e polling lungo. Gli sviluppatori si concentrano sull'invio di messaggi a tutti i subset o a subset specifici dei 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 dal momento che il servizio gestisce già automaticamente le connessioni.

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