Questa architettura di riferimento usa i servizi di integrazione di Azure Services per orchestrare le chiamate ai sistemi back-end aziendali. I sistemi back-end possono includere sistemi software come un servizio (SaaS), servizi di Azure e servizi Web esistenti nell'organizzazione.
Architettura
Scaricare un file di Visio di questa architettura.
Workflow
Sistemi back-end. A destra del diagramma ci sono i diversi sistemi back-end che l'organizzazione ha distribuito o sui cui si basa. Questi sistemi possono includere sistemi SaaS, altri servizi di Azure o servizi Web che espongono gli endpoint REST o SOAP.
App per la logica di Azure. In questa architettura, le app per la logica sono attivate da richieste HTTP. È inoltre possibile annidare i flussi di lavoro per un'orchestrazione più complessa. App per la logica usa connettori per integrarsi con i servizi di uso comune. App per la logica offre centinaia di connettori ed è possibile creare connettori personalizzati.
Gestione API di Azure. Gestione API consiste di due componenti correlati:
Gateway API. Il gateway API accetta le chiamate HTTP e le instrada al back-end.
Portale per sviluppatori. Ogni istanza di Gestione API di Azure offre accesso a un portale per sviluppatori. Il portale offre agli sviluppatori l'accesso alla documentazione e agli esempi di codice per chiamare le API. Nel portale per sviluppatori è possibile anche testare le API.
DNS di Azure. che fornisce la risoluzione dei nomi tramite l'infrastruttura di Azure. Ospitando i domini in Azure, è possibile gestire i record DNS usando le credenziali, le API, gli strumenti e il sistema di fatturazione degli altri servizi di Azure. Per usare un nome di dominio personalizzato, ad esempio contoso.com, creare record DNS che eseguono il mapping del nome di dominio personalizzato all'indirizzo IP. Per altre informazioni, vedere Configurare un nome di dominio personalizzato in Gestione API.
Microsoft Entra ID. Usare Microsoft Entra ID per autenticare i client che chiamano il gateway API. Microsoft Entra ID supporta il protocollo OpenID Connect (OIDC). I client ottengono un token di accesso da Microsoft Entra ID, e gateway API convalida il token per autorizzare la richiesta. Se si usa il livello Standard o Premium di API Management, Microsoft Entra ID consente anche di proteggere l'accesso al portale per sviluppatori.
Componenti
- Servizi di integrazione è un insieme di servizi che è possibile utilizzare per integrare applicazioni, dati e processi.
- App per la logica è una piattaforma serverless per la creazione di flussi di lavoro aziendali che integrano applicazioni, dati e servizi.
- API Management è un servizio gestito per la pubblicazione di cataloghi di API HTTP. È possibile usarlo per promuovere il riutilizzo e l'individuabilità delle API e per distribuire un gateway API alle richieste dell'API proxy.
- DNS di Azure è un servizio di hosting per i domini DNS
- Microsoft Entra ID è un servizio per la gestione delle identità e degli accessi basato sul cloud. I dipendenti aziendali possono usare Microsoft Entra ID per accedere alle risorse esterne e interne.
Dettagli dello scenario
Servizi di integrazione è un insieme di servizi che è possibile utilizzare per integrare applicazioni, dati e processi per aziende. Questa architettura usa due di questi servizi: App per la logica, per orchestrare i flussi di lavoro, e Gestione API, per creare cataloghi di API.
In questa architettura le API composite vengono costruite importando app per la logica come API. È anche possibile importare i servizi Web esistenti importando le specifiche di OpenAPI (Swagger) o importando le API SOAP dalle specifiche di WSDL.
Il gateway API consente di disaccoppiare i client front-end da quelli back-end. È possibile, ad esempio, riscrivere gli URL o trasformare le richieste prima che raggiungano il back-end. Gestisce anche molte problematiche trasversali come autenticazione, supporto della condivisione di risorse tra le origini (CORS) e memorizzazione nella cache della risposta.
Potenziali casi d'uso
Questa architettura è sufficiente per scenari di integrazione di base in cui il flusso di lavoro viene attivato da chiamate sincrone a servizi back-end. Un'architettura più sofisticata che usa code ed eventi si basa su questa architettura di base.
Consigli
I requisiti specifici dell'utente possono variare rispetto all'architettura generica descritta illustrata qui. Seguire le raccomandazioni contenute in questa sezione come punto di partenza.
Gestione API
Usare i livelli di Gestione API Basic, Standard o Premium perché offrono un contratto di servizio di produzione e supportano l'aumento del numero di istanze nell'area di Azure. La capacità della velocità effettiva per Gestione API viene misurata in unità. Ogni piano tariffario ha un numero massimo di istanze. Il livello Premium supporta anche la scalabilità orizzontale tra più aree di Azure. Scegliere il livello adeguato alle proprie esigenze in base al set di funzionalità e al livello di velocità effettiva necessaria. Per altre informazioni, vedere Prezzi di Gestione API e Capacità di un'istanza di Gestione API di Azure.
Ogni istanza API Management di Azure ha un nome di dominio predefinito, ovvero un sottodominio di azure-api.net, ad esempio contoso.azure-api.net. Si consiglia di configurare un dominio personalizzato per l'organizzazione.
App per la logica
App per la logica funziona in modo ottimale in scenari che non richiedono una bassa latenza per una risposta, ad esempio le chiamate API asincrone o a esecuzione quasi prolungata. Se è richiesta una latenza bassa, ad esempio nel caso di chiamate che bloccano un'interfaccia utente, usare una tecnologia diversa, ad esempio Funzioni di Azure o un'API Web distribuita nel Servizio app di Azure. Usare Gestione API a fronte dell'API per i consumer di API.
Paese
Per ridurre la latenza di rete, collocare Gestione API e App per la logica nella stessa area. In genere è consigliabile scegliere l'area più vicina agli utenti (o più vicina ai servizi back-end).
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 Microsoft Azure Well-Architected Framework.
Affidabilità
L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.
Esaminare il contratto per ogni servizio:
Se API Management è distribuito in due o più aree con il livello Premium, è idoneo a un contratto di servizio superiore. Vedere Prezzi di Gestione API.
Backup
Eseguire regolarmente il backup della configurazione di Gestione API. Archiviare i file di backup in una posizione o un'area di Azure diversa rispetto a quella in cui è distribuito il servizio. Scegliere una strategia di ripristino di emergenza in base all'RTO:
In caso di ripristino di emergenza effettuare il provisioning di una nuova istanza di Gestione API, ripristinare il backup nella nuova istanza ed eseguire un nuovo puntamento dei record DNS.
Mantenere un'istanza passiva del servizio Gestione API in un'altra area di Azure. Ripristinare regolarmente i backup nell'istanza, in modo da mantenerla sincronizzata con il servizio attivo. Per ripristinare il servizio durante un evento di ripristino di emergenza, occorre solo eseguire un nuovo puntamento dei record DNS. Questo approccio comporta un costo aggiuntivo perché l'istanza passiva è a pagamento, tuttavia riduce i tempi di recupero.
Per le app per la logica, è consigliabile un approccio di configurazione come codice per il backup e ripristino. Poiché le app per la logica sono serverless, è possibile ricrearle rapidamente da modelli di Azure Resource Manager. Salvare i modelli nel controllo del codice sorgente e integrare i modelli con il processo di integrazione continua/distribuzione continua (CI/CD). In un evento di ripristino di emergenza, distribuire il modello in una nuova area.
Se si distribuisce un'app per la logica in un'area diversa, aggiornare la configurazione in Gestione API. È possibile aggiornare la proprietà back-end dell'API usando uno script di PowerShell di base.
Sicurezza
La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.
Sebbene questo elenco non descriva completamente tutte le procedure consigliate per la sicurezza, ecco alcune considerazioni sulla sicurezza che si applicano nello specifico a questa architettura:
Il servizio Gestione API di Azure ha un indirizzo IP pubblico fisso. Limitare l'accesso per chiamare gli endpoint di App per la logica esclusivamente all'indirizzo IP di Gestione API. Per maggiori informazioni, consultare la sezione Limitazione degli indirizzi IP in ingresso.
Per assicurarsi che gli utenti dispongano dei livelli di accesso appropriati, usare il controllo degli accessi in base al ruolo (RBAC) di Azure.
Proteggere gli endpoint dell'API pubblici in Gestione API tramite OAuth o OpenID Connect. Per proteggere gli endpoint dell'API pubblici, configurare un provider di identità e aggiungere criteri di convalida JSON Web Token (JWT). Per maggiori informazioni, consultare la sezione Protezione di un AP usando OAuth 2.0 con Microsoft Entra ID e API Management.
Connettersi ai servizi back-end da Gestione API usando certificati basati sull'autenticazione reciproca.
Imporre HTTPS nelle API di Gestione API.
Archiviazione dei segreti
Non archiviare mai le password, le chiavi di accesso o le stringhe di connessione nel controllo del codice sorgente, Se questi valori sono necessari, usare le tecniche appropriate per distribuire e proteggere questi valori.
Se un'app per la logica richiede qualsiasi valore sensibile che non è possibile creare all'interno di un connettore, archiviare questo valore in Azure Key Vault e farvi riferimento da un modello di Resource Manager. Usare i parametri del modello di distribuzione e i file di parametri per ogni ambiente. Per altre informazioni consultare Proteggere i parametri e gli input all'interno di un flusso di lavoro.
In Gestione API i segreti vengono gestiti usando oggetti chiamati Valori denominati o Proprietà. Questi oggetti archiviano in modo sicuro valori a cui è possibile accedere attraverso i criteri di Gestione API. Per altre informazioni vedere Come usare i valori denominati nei criteri di Gestione API di Azure.
Eccellenza operativa
L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Panoramica del pilastro dell'eccellenza operativa.
DevOps
Creare gruppi di risorse separati per gli ambienti di produzione, sviluppo e test. L'uso di gruppi di risorse separati semplifica la gestione delle distribuzioni, l'eliminazione delle distribuzioni di test e l'assegnazione dei diritti di accesso.
Quando si assegnano risorse a gruppi di risorse, considerare i fattori seguenti:
Ciclo di vita. In generale, includere le risorse con un ciclo di vita identico nello stesso gruppo.
Accesso. Per applicare i criteri di accesso alle risorse di un gruppo, è possibile usare Controllo degli accessi in base al ruolo (RBAC) di Azure.
Fatturazione. È possibile visualizzare il riepilogo dei costi per il gruppo di risorse.
Piano tariffario per Gestione API. Per gli ambienti di sviluppo e test è opportuno usare un livello Developer. Per ridurre al minimo i costi durante la pre-produzione, distribuire una replica dell'ambiente di produzione, eseguire i test e quindi arrestare il sistema.
Distribuzione
Usare i Modelli di Azure Resource Manager per distribuire le risorse di Azure e seguire il processo IaC (Infrastructure as Code). I modelli semplificano l'automatizzazione delle distribuzioni usando Servizi DevOps di Azure o altre soluzioni CI/CD.
Staging
Prendere in considerazione la gestione temporanea dei carichi di lavoro, ovvero la distribuzione in varie fasi e l'esecuzione delle convalide in ogni fase prima di passare a quella successiva. Se si usa questo approccio, è possibile eseguire il push degli aggiornamenti negli ambienti di produzione in modo altamente controllato e ridurre al minimo i problemi di distribuzione imprevisti. La distribuzione blu-verde e le versioni Canary sono strategie di distribuzione consigliate per l'aggiornamento degli ambienti di produzione live. Valutare anche una buona strategia di rollback per quando una distribuzione ha esito negativo. Ad esempio, è possibile ridistribuire automaticamente una distribuzione precedente con esito positivo dalla cronologia della distribuzione. Il parametro flag --rollback-on-error nell'interfaccia della riga di comando di Azure è un buon esempio.
Isolamento del carico di lavoro
Aggiungere Gestione API e qualsiasi app per la logica individuale nei rispettivi modelli di Resource Manager separati. L'uso di modelli separati consente di archiviare le risorse in sistemi di controllo del codice sorgente. È possibile distribuire i modelli insieme o separatamente come parte di un processo CI/CD.
Versioni
Ogni volta che si modifica la configurazione di un'app per la logica o si distribuisce un aggiornamento attraverso un modello di Resource Manager, Azure conserva una copia di tale versione oltre a tutte le versioni che hanno una cronologia di esecuzione. È possibile usare queste versioni per tenere traccia delle modifiche cronologiche o per promuovere una versione come configurazione corrente dell'app per la logica. Ad esempio, è possibile eseguire il rollback di un'app per la logica a una versione precedente.
Gestione API include due concetti di controllo delle versioni distinti ma complementari:
Versioni: consentono ai consumer di API di scegliere una versione dell'API in base alle esigenze, ad esempio v1, v2, beta o di produzione.
Revisioni: consentono agli amministratori di API di apportare modifiche che non causano interruzioni e distribuirle insieme a un log delle modifiche per informare i consumer di API.
È possibile effettuare una revisione in un ambiente di sviluppo e distribuire la modifica in altri ambienti usando i modelli di Resource Manager. Per altre informazioni, vedere Pubblicare più versioni dell'API
È anche possibile usare le revisioni per testare un'API prima di rendere le modifiche attuali e accessibili agli utenti. Tuttavia, questo metodo non è consigliato per test di carico o test di integrazione. Usare invece ambienti di test o di preproduzione separati.
Diagnostica e monitoraggio
Usare Monitoraggio di Azure per il monitoraggio operativo sia in Gestione API che in App per la logica. Il servizio Monitoraggio di Azure include informazioni basate sulle metriche configurate per ogni servizio ed è abilitato per impostazione predefinita. Per altre informazioni, vedi:
- Monitorare le API pubblicate
- Monitorare lo stato, configurare la registrazione diagnostica e attivare gli avvisi per App per la logica di Azure
Ogni servizio dispone inoltre di queste opzioni:
Per un'analisi approfondita e la creazione di dashboard, inviare i registri di App per la logica ad Azure Log Analytics.
Per il monitoraggio DevOps, configurare Azure Application Insights per Gestione API.
Gestione API supporta il modello di soluzione Power BI per l'analisi personalizzata delle API. È possibile usare questo modello di soluzione per creare una soluzione di analisi personalizzata. Per gli utenti aziendali sono disponibili report in Power BI.
Efficienza prestazionale
L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per altre informazioni, vedere Panoramica del pilastro dell'efficienza delle prestazioni.
Per migliorare la scalabilità di Gestione API, aggiungere criteri di memorizzazione nella cache laddove appropriato e ridurre il carico sui servizi di back-end.
Per offrire una maggiore capacità, è possibile aumentare il numero di istanze per i livelli Basic, Standard e Premium di Gestione API di Azure in un'area di Azure. Per analizzare l'utilizzo per il servizio, selezionare Metrica della capacità nel menu Metriche, quindi aumentare o ridurre in base alle esigenze. Il processo di aggiornamento o ridimensionamento può richiedere da 15 a 45 minuti.
Elementi consigliati per la scalabilità di un servizio Gestione API:
Quando si scala un servizio, considerare i modelli di traffico. I clienti con modelli di traffico più volatili necessitano di una capacità maggiore.
Una capacità costante superiore al 66% può indicare la necessità di aumentare le prestazioni.
Una capacità costante inferiore al 20% può indicare un'opportunità per ridurre le prestazioni.
Prima di consentire il carico in produzione, è sempre consigliabile testare il carico nel servizio di Gestione API usando un carico rappresentativo.
Con il livello Premium, è possibile scalare un'istanza di Gestione API in più aree di Azure. Questo rende API Management idoneo a un SLA superiore e consente di eseguire il provisioning dei servizi in prossimità degli utenti in più aree.
Il modello serverless di App per la logica di Azure prevede che gli amministratori non debbano pianificare la scalabilità dei servizi. Il servizio offre scalabilità automatica per soddisfare la richiesta.
Ottimizzazione dei costi
In linea generale, usare il calcolatore dei prezzi di Azure per stimare i costi. Di seguito alcune ulteriori considerazioni.
Gestione API
Tutte le istanze di API Management comportano un addebito quando sono in esecuzione. Se sono state aumentate le prestazioni e tale livello di prestazioni non è costantemente necessario, passare manualmente a un piano inferiore o configurare la scalabilità automatica.
App per la logica
App per la logica funziona come modello senza server. La fatturazione viene calcolata in base all'esecuzione del connettore e dell'azione. Per altre informazioni, vedere Prezzi di App per la logica.
Per altre informazioni, vedere la sezione sui costi in Microsoft Azure Well-Architected Framework.
Passaggi successivi
Risorse correlate
Per una maggiore affidabilità e scalabilità, usare code ed eventi di messaggi per disaccoppiare i sistemi back-end. Questa architettura è illustrata nel prossimo articolo di questa serie:
È inoltre possibile che si sia interessati a questi articoli del Centro architetture di Azure: