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 SaaS (Software as a Service), servizi di Azure e servizi Web esistenti nell'organizzazione.
Architettura
Scaricare un file di Visio di questa architettura.
Flusso di lavoro
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 endpoint REST o SOAP.
App per la logica di Azure. In questa architettura le app per la logica vengono attivate dalle 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 OIDC (OpenID Connessione). I client ottengono un token di accesso da Microsoft Entra ID e il gateway API convalida il token per autorizzare la richiesta. Se si usa il livello Standard o Premium di Gestione API, Microsoft Entra ID può anche contribuire a proteggere l'accesso al portale per sviluppatori.
Componenti
- Integration Services è una raccolta di servizi che è possibile usare 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.
- Gestione API è 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 di 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
Integration Services è una raccolta di servizi che è possibile usare per integrare applicazioni, dati e processi per l'azienda. 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 gli scenari di integrazione di base in cui il flusso di lavoro viene attivato da chiamate sincrone ai 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 di Azure Gestione API 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.
Area
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 set di principi guida che è possibile usare per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.
Affidabilità
L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.
Esaminare il contratto per ogni servizio:
Se si distribuisce Gestione API tra due o più aree con il livello Premium, è idoneo per 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 costi aggiuntivi perché si paga per l'istanza passiva, ma riduce il tempo di ripristino.
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 altre informazioni, vedere Limitare gli indirizzi IP in ingresso.
Per assicurarsi che gli utenti abbiano livelli di accesso appropriati, usare il controllo degli accessi in base al ruolo 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 altre informazioni, vedere Proteggere un'API usando OAuth 2.0 con MICROSOFT Entra ID e Gestione API.
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 in un gruppo, è possibile usare il controllo degli accessi in base al ruolo 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, seguire l'infrastruttura come processo IaC (Code). I modelli semplificano l'automazione delle distribuzioni con Azure DevOps Services o altre soluzioni CI/CD.
Gestione temporanea
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. Prendere in considerazione anche una buona strategia di rollback per quando una distribuzione ha esito negativo. Ad esempio, è possibile ridistribuire automaticamente una distribuzione precedente e corretta dalla cronologia di distribuzione. Il --rollback-on-error parametro flag 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.
Le revisioni consentono agli amministratori api di apportare modifiche non di rilievo in un'API e di distribuire tali modifiche, insieme a un log delle modifiche per informare gli utenti dell'API sulle modifiche.
È 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, vedere:
- 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 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 del servizio, selezionare Metrica di capacità nel menu Metriche e quindi aumentare o ridurre le prestazioni 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. Ciò rende Gestione API idoneo per un contratto di servizio superiore e consente di effettuare il provisioning dei servizi vicino agli 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. Ecco alcune altre considerazioni.
Gestione API
Vengono addebitati i costi per tutte le istanze di Gestione API 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 nell'articolo successivo di questa serie:
È anche possibile che si sia interessati a questi articoli del Centro architetture di Azure: