In questo scenario un'azienda di e-commerce operante nel settore dei viaggi esegue la migrazione di un'applicazione Web legacy con Gestione API di Azure. La nuova interfaccia utente sarà ospitata come applicazione PaaS (Platform as a Service) in Azure e dipenderà dalle API HTTP esistenti e nuove. Queste API verranno fornite con un set di interfacce progettato meglio, che consentirà prestazioni migliori, integrazione più semplice e estendibilità futura.
Architettura
Scaricare un file di Visio di questa architettura.
Workflow
- L'applicazione Web locale esistente continua a utilizzare direttamente i servizi Web locali esistenti.
- Le chiamate dall'app Web esistente ai servizi HTTP esistenti rimangono invariate. Queste chiamate sono interne alla rete aziendale.
- Le chiamate in ingresso vengono effettuate da Azure ai servizi interni esistenti:
- Il team di sicurezza consente al traffico dall'istanza di Gestione API di passare attraverso il firewall aziendale ai servizi locali esistenti usando il trasporto sicuro (HTTPS o SSL).
- Il team operativo consente chiamate in ingresso ai servizi solo dall'istanza di Gestione API. Soddisfa questo requisito aggiungendo l'indirizzo IP dell'istanza di Gestione API all'elenco di indirizzi consentiti all'interno del perimetro della rete aziendale.
- Un nuovo modulo viene configurato nella pipeline di richiesta locale per i servizi HTTP (per agire solo sulle connessioni che hanno origine esternamente). La pipeline convalida un certificato fornito Gestione API.
- La nuova API:
- Viene visualizzata solo tramite l'istanza di Gestione API, che fornisce la facciata DELL'API. La nuova API non è accessibile direttamente.
- Viene sviluppato e pubblicato come app per le API Web PaaS di Azure.
- È configurato (tramite le impostazioni per la funzionalità App Web del servizio app Azure) per accettare solo l'IP virtuale Gestione API.
- È ospitato in App Web con trasporto sicuro (HTTPS o SSL) attivato.
- Dispone dell'autorizzazione abilitata, fornita dal servizio app Azure tramite Microsoft Entra ID e OAuth 2.
- La nuova applicazione Web basata su browser dipende dall'istanza di Azure Gestione API per l'API HTTP esistente e la nuova API.
L'istanza di Gestione API è configurata per eseguire il mapping dei servizi HTTP legacy a un nuovo contratto API. In questa configurazione, la nuova interfaccia utente Web non è a conoscenza dell'integrazione con un set di servizi/API legacy e nuove API.
In futuro, il team del progetto convertirà gradualmente la funzionalità alle nuove API e ritirerà i servizi originali. Il team gestirà queste modifiche all'interno di Gestione API configurazione, lasciando invariata l'interfaccia utente front-end ed evitando il lavoro di riqualifica.
Componenti
Alternative
Se l'organizzazione prevede di spostare interamente l'infrastruttura in Azure, incluse le macchine virtuali (VM) che ospitano le applicazioni legacy, Gestione API è comunque un'ottima opzione perché può fungere da facciata per qualsiasi endpoint HTTP indirizzabile.
Se l'organizzazione aveva deciso di mantenere privati gli endpoint esistenti e non di esporli pubblicamente, l'istanza di Gestione API dell'organizzazione potrebbe essere collegata a una rete virtuale di Azure:
- In uno scenario di "lift-and-shift" di Azure collegato a una rete virtuale di Azure distribuita, l'organizzazione potrebbe indirizzare direttamente il servizio back-end tramite indirizzi IP privati.
- Nello scenario locale, l'istanza di Gestione API potrebbe tornare al servizio interno privatamente tramite un gateway VPN di Azure e una connessione VPN IPSec da sito a sito o Azure ExpressRoute. Questo scenario diventerà quindi un ibrido di Azure e locale.
L'organizzazione può mantenere privata l'istanza di Gestione API distribuendola in modalità interna. L'organizzazione può quindi usare la distribuzione con app Azure lication Gateway per abilitare l'accesso pubblico per alcune API, mentre altre rimangono interne. Per altre informazioni, vedere Integrare Gestione API in una rete virtuale interna con gateway applicazione.
L'organizzazione potrebbe decidere di ospitare le API in locale. Una delle cause di questa modifica potrebbe essere che l'organizzazione non è riuscita a spostare le dipendenze del database downstream nell'ambito di questo progetto nel cloud. In tal caso, l'organizzazione può comunque sfruttare Gestione API in locale usando un gateway self-hosted.
Il gateway self-hosted è una distribuzione in contenitori del gateway Gestione API che si connette ad Azure in un socket in uscita. Il primo prerequisito è che i gateway self-hosted non possono essere distribuiti senza una risorsa padre in Azure, che comporta costi aggiuntivi. In secondo luogo, è necessario il livello Premium di Gestione API.
Nota
Per informazioni generali sulla connessione Gestione API a una rete virtuale, vedere questo articolo.
Dettagli dello scenario
Un'azienda di e-commerce nel settore dei viaggi sta modernizzando lo stack di software basato su browser legacy. Anche se lo stack esistente è principalmente monolitico, alcuni servizi HTTP basati su SOAP esistono da un progetto recente. L'azienda sta considerando la creazione di flussi di ricavi aggiuntivi per monetizzare alcune delle proprietà intellettuali interne che ha sviluppato.
Gli obiettivi per il progetto includono la gestione del debito tecnico, il miglioramento della manutenzione periodica e l'accelerazione dello sviluppo di funzionalità con meno bug di regressione. Il progetto userà un processo iterativo per evitare rischi, con alcuni passaggi eseguiti in parallelo:
- Il team di sviluppo modernizzerà il back-end dell'applicazione, costituito da database relazionali ospitati nelle macchine virtuali.
- Il team di sviluppo interno scriverà nuove funzionalità di business che verranno esposte tramite nuove API HTTP.
- Un team di sviluppo di contratti compilerà una nuova interfaccia utente basata su browser, che sarà ospitata in Azure.
Le nuove funzionalità dell'applicazione verranno distribuite in più fasi. Queste funzionalità sostituiranno gradualmente la funzionalità dell'interfaccia utente client/server basata su browser (ospitata in locale) che ora supporta l'azienda di e-commerce.
I membri del team di gestione non vogliono modernizzare inutilmente. Vuole anche mantenere il controllo dell'ambito e dei costi. A tale scopo, hanno deciso di mantenere i servizi HTTP SOAP esistenti. Intende anche ridurre al minimo le modifiche all'interfaccia utente esistente. Possono usare Azure Gestione API per soddisfare molti dei requisiti e dei vincoli del progetto.
Potenziali casi d'uso
Questo scenario evidenzia la modernizzazione degli stack software basati su browser legacy.
È possibile usare questo scenario per:
- Scopri in che modo l'azienda può trarre vantaggio dall'uso dell'ecosistema di Azure.
- Pianificare la migrazione dei servizi ad Azure.
- Informazioni su come un passaggio ad Azure influisce sulle API esistenti.
Considerazioni
Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che consentono di migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.
Disponibilità e scalabilità
- È possibile aumentare le istanze di Azure Gestione API scegliendo un piano tariffario e quindi aggiungendo unità.
- Il ridimensionamento può verificarsi automaticamente anche con la scalabilità automatica.
- La distribuzione in più aree abilita le opzioni di failover e può essere eseguita nel livello Premium.
- Considerare l'integrazione con Azure Application Insights, che espone le metriche tramite Monitoraggio di Azure per il monitoraggio.
Ottimizzazione dei costi
L'ottimizzazione dei costi consiste nel trovare modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.
Gestione API è disponibile in quattro livelli: Developer, Basic, Standard e Premium. Per indicazioni dettagliate sulle differenze in questi livelli, vedere il materiale sussidiario sui prezzi di Azure Gestione API.
È possibile ridimensionare Gestione API aggiungendo e rimuovendo unità. La capacità di ogni unità dipende dal livello.
Nota
È possibile usare il livello Sviluppatore per la valutazione delle funzionalità di Gestione API. Non usarlo per la produzione.
Per visualizzare i costi previsti e personalizzare in base alle esigenze di distribuzione, è possibile modificare il numero di unità di scala e servizio app istanze nel calcolatore prezzi di Azure.
Distribuire lo scenario
Per iniziare, creare un'istanza di Gestione API di Azure nel portale.
In alternativa, è possibile scegliere un modello di avvio rapido di Azure Resource Manager adatto al caso d'uso specifico.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- Ben Gimblett | Senior Customer Engineer
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
Documentazione sui prodotti:
Moduli learn:
- Esplorare app Azure Servizio
- Distribuire un sito Web in Azure con il servizio app Azure
- Proteggere le API in Azure Gestione API