Condividi tramite

Eseguire la migrazione di un'app Web usando API Management di Azure

Gestione API di Azure
Monitoraggio di Azure
Servizio app di Azure

In questo scenario, un'azienda di e-commerce nel settore dei viaggi esegue la migrazione di un'app Web legacy usando Gestione API di Azure. La società ospita la nuova interfaccia utente come app PaaS (Platform as a Service) in Azure. La nuova interfaccia utente dipende dalle API HTTP esistenti e nuove. Queste API vengono distribuite con interfacce progettate in modo più efficace che migliorano le prestazioni, semplificano l'integrazione e consentono un'estendibilità futura.

Architecture

Diagramma che mostra i passaggi per eseguire la migrazione di un'app Web tramite Gestione API.

Scaricare un file di Visio di questa architettura.

Workflow

Il flusso di lavoro seguente corrisponde al diagramma precedente:

  1. L'app Web locale esistente continua a utilizzare direttamente i servizi Web locali esistenti.

  2. Le chiamate dalle app Web esistenti ai servizi HTTP esistenti rimangono invariate. Queste chiamate sono interne alla rete aziendale.

  3. Gestione API effettua chiamate da Azure ai servizi interni esistenti.

  4. La nuova API presenta le caratteristiche seguenti:

  5. La nuova app Web basata su browser dipende dall'istanza di Gestione API per l'API HTTP esistente e la nuova API.

  6. La società di e-commerce travel può indirizzare alcuni utenti alla nuova interfaccia utente per l'anteprima o il test mantenendo l'interfaccia utente precedente e le funzionalità esistenti affiancate.

Configurare l'istanza di Gestione API 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 o API legacy e nuove API.

In futuro, il team di progetto può spostare gradualmente le funzionalità nelle nuove API e ritirare i servizi originali. Il team gestisce queste modifiche all'interno della configurazione di Gestione API, lasciando invariata l'interfaccia utente front-end ed evitando il lavoro di riqualifica.

Components

  • Gestione API è una piattaforma di gestione e un gateway per le API in tutti gli ambienti. In questa architettura funge da facciata per le API legacy esistenti e le nuove API. La nuova app client usa una singola interfaccia coerente e il team può modernizzare i back-end legacy in modo incrementale dietro tale facciata con un impatto minimo sullo sviluppo front-end.

  • Il servizio app è una soluzione PaaS chiavi in mano per l'hosting Web che offre funzionalità predefinite, ad esempio sicurezza, bilanciamento del carico, scalabilità automatica e gestione automatica. In questa architettura, il servizio App Service offre un servizio di hosting flessibile e chiavi in mano, in modo che il team DevOps possa concentrarsi sulla consegna delle funzionalità.

Alternatives

  • Se l'organizzazione prevede di spostare l'infrastruttura, incluse le macchine virtuali (VM) che ospitano le app legacy, interamente in Azure, Gestione API può fungere da facciata per qualsiasi endpoint HTTP indirizzabile.

  • Se l'organizzazione mantiene privati gli endpoint esistenti e non li espone pubblicamente, l'istanza di Gestione API dell'organizzazione può collegarsi a una rete virtuale di Azure.

  • L'organizzazione può mantenere privata l'istanza di API Management distribuendola in modalità interna. L'organizzazione può quindi usare la distribuzione con il gateway applicazione di Azure per consentire l'accesso pubblico per alcune API, mentre altre rimangono interne. Per altre informazioni, vedere Integrare la Gestione delle API in una rete virtuale interna usando Application Gateway.

  • L'organizzazione potrebbe decidere di ospitare le API in locale. Un motivo per questa modifica potrebbe essere che l'organizzazione non può spostare le dipendenze del database downstream nell'ambito di questo progetto nel cloud. In questo scenario, l'organizzazione può sfruttare Gestione API in locale usando un gateway self-hosted.

    Il gateway self-hosted è una distribuzione in contenitori del gateway di Gestione API che si connette ad Azure in un socket in uscita. Per usare i gateway self-hosted, è necessario soddisfare i prerequisiti seguenti:

    • È necessario distribuire gateway self-hosted usando una risorsa principale in Azure, che aggiunge un costo aggiuntivo.

    • È necessario usare il livello Premium di Gestione API.

Dettagli dello scenario

Una società di e-commerce nel settore dei viaggi vuole modernizzare lo stack di software legacy basato su browser. Lo stack esistente è principalmente monolitico, ma alcuni servizi HTTP basati su SOAP (Simple Object Access Protocol) esistono da un progetto recente. L'azienda considera la creazione di flussi di ricavi aggiuntivi per monetizzare alcune delle sue proprietà intellettuali interne.

Gli obiettivi del progetto includono la gestione del debito tecnico, i miglioramenti continui della manutenzione e l'accelerazione dello sviluppo delle funzionalità con un minor numero di bug di regressione. Il progetto usa un processo iterativo per evitare rischi ed esegue i passaggi seguenti in parallelo:

  • Il team di sviluppo modernizza il back-end dell'app, costituito da database relazionali ospitati nelle macchine virtuali.

  • Il team di sviluppo interno scrive nuove funzionalità aziendali e le espone tramite nuove API HTTP.

  • Un team di sviluppo del contratto crea una nuova interfaccia utente basata su browser, che ospita Azure.

L'azienda offre nuove funzionalità dell'app in fasi. Queste funzionalità sostituiscono gradualmente la funzionalità dell'interfaccia utente client e server basata su browser esistente ospitata in locale che alimentano l'attività di e-commerce dell'azienda.

I membri del team di gestione non desiderano modernizzare inutilmente l'applicazione. Vuole anche mantenere il controllo dell'ambito e dei costi. Per raggiungere questi obiettivi, decide di mantenere i servizi HTTP SOAP esistenti. Intende anche ridurre al minimo le modifiche all'interfaccia utente esistente. Possono usare Gestione API per soddisfare molti dei requisiti e dei vincoli del progetto.

Potenziali casi d'uso

Questo scenario illustra come modernizzare gli stack software legacy basati su browser.

È possibile usare questo scenario per le attività seguenti:

  • Informazioni su come l'azienda può trarre vantaggio dall'uso dell'ecosistema di Azure.
  • Pianificare una migrazione del servizio ad Azure.
  • Informazioni su come un passaggio ad Azure potrebbe influire sulle API esistenti.

Considerations

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 Well-Architected Framework.

Reliability

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'affidabilità.

  • Attivare le zone di disponibilità quando si distribuisce l'istanza di Gestione API. L'opzione per distribuire Gestione API nelle zone di disponibilità è disponibile solo nei livelli di servizio Premium.

  • Usa zone di disponibilità che hanno istanze gateway extra distribuite in regioni diverse. Questa combinazione migliora la disponibilità del servizio se un'area diventa offline. La distribuzione di più aree è disponibile solo nel livello di servizio Premium.

  • Eseguire l'integrazione con Application Insights, che illustra le metriche tramite Monitoraggio di Azure per il monitoraggio. Ad esempio, è possibile usare la metrica della capacità per determinare il carico complessivo sulla risorsa API Management e se sono necessarie unità di scalabilità orizzontale. Tenere traccia della capacità e dell'integrità delle risorse per migliorare l'affidabilità.

  • Assicurarsi che anche le dipendenze downstream, ad esempio i servizi back-end che ospitano le API coperte da Gestione API, siano resilienti.

Ottimizzazione dei costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per Ottimizzazione costi.

Gestione API ha otto livelli:

  • Consumo
  • Sviluppatore
  • Basic e Basic v2
  • Standard e Standard v2
  • Premium e Premium v2

Per altre informazioni sulle differenze in questi livelli, vedere Prezzi di Gestione API.

È possibile sfruttare la scalabilità di API Management aggiungendo o rimuovendo unità. La capacità di ogni unità dipende dal livello.

Note

È possibile usare il livello Developer per valutare le funzionalità di Gestione API. Non usarlo per la produzione.

Per visualizzare i costi previsti per le esigenze di distribuzione, è possibile modificare il numero di unità di scala e le istanze del servizio app nel calcolatore prezzi di Azure.

Contributors

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autore principale:

Altro collaboratore:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi