Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Modello di routing dei percorsi
Il routing dei percorsi è il meccanismo che raggruppa più o tutte le API con lo stesso nome host e utilizza un URI di richiesta per isolare i servizi, ad esempio, api.example.com/service-a o api.example.com/service-b.
Caso d'uso tipico
La maggior parte dei team sceglie questo metodo perché desidera un'architettura semplice: uno sviluppatore deve ricordare solo un URL, ad esempio api.example.com per interagire con l'API HTTP. La documentazione delle API è spesso più facile da consultare perché spesso è tenuta tutta insieme anziché essere suddivisa su diversi portali o PDF.
Il routing basato sui percorsi è considerato un meccanismo semplice per condividere un'API HTTP. Tuttavia, comporta un sovraccarico operativo come configurazione, autorizzazione, integrazioni e latenza aggiuntiva dovuta a più hop. Richiede inoltre processi avanzati di gestione delle modifiche per garantire che un'errata configurazione non interrompa tutti i servizi.
Sono disponibili diversi modi per condividere un'API e indirizzare in modo efficace al servizio corretto. AWS Le sezioni seguenti illustrano tre approcci: proxy inverso del servizio HTTP, API Gateway e Amazon CloudFront. Nessuno degli approcci suggeriti per l'unificazione dei servizi API si basa sui servizi downstream in esecuzione su AWS. I servizi possono essere eseguiti ovunque senza problemi o con qualsiasi tecnologia, purché siano compatibili con HTTP.
Proxy inverso del servizio HTTP
È possibile utilizzare un server HTTP come NGINX
La seguente configurazione per NGINX mappa dinamicamente una richiesta HTTP di api.example.com/my-service/ a my-service.internal.api.example.com.
server { listen 80; location (^/[\w-]+)/(.*) { proxy_pass $scheme://$1.internal.api.example.com/$2; } }
Il diagramma seguente illustra il metodo proxy inverso del servizio HTTP.
Questo approccio potrebbe essere sufficiente per alcuni casi d'uso che non utilizzano configurazioni aggiuntive per avviare l'elaborazione delle richieste, consentendo all'API downstream di raccogliere parametri e log.
Per prepararti alla produzione operativa, ti consigliamo di aggiungere osservabilità a ogni livello dello stack, configurazioni aggiuntive o script per personalizzare il punto di ingresso dell'API e consentire funzionalità più avanzate come la limitazione della frequenza o i token di utilizzo.
Pro
L'obiettivo finale del metodo del proxy inverso del servizio HTTP è creare un approccio dimensionabile e gestibile per unificare le API in un unico dominio in modo che appaia coerente per qualsiasi consumer di API. Questo approccio consente inoltre ai team di assistenza di implementare e gestire le proprie API, con un sovraccarico minimo dopo l'implementazione. AWS i servizi gestiti per la tracciabilità, come AWS X-Ray
Contro
Il principale svantaggio di questo approccio è rappresentato dai numerosi test e dalla gestione dei componenti dell'infrastruttura necessari, anche se questo potrebbe non essere un problema se si dispone di team di ingegneria dell'affidabilità del sito (SRE).
Con questo metodo si verifica un punto critico in termini di costi. A volumi medio-bassi, è più costoso di alcuni degli altri metodi descritti in questa guida. A volumi elevati, è molto conveniente (circa 100.000 transazioni al secondo o più).
API Gateway
Il servizio Gateway Amazon APIapi.example.com e quindi inoltrare le richieste al servizio nidificato, ad esempio billing.internal.api.example.com.
Probabilmente non vorrai usare troppe informazioni dettagliate mappando ogni percorso di ogni servizio nel gateway API principale o root. Scegli invece percorsi con caratteri jolly, ad esempio /billing/* per inoltrare le richieste al servizio di fatturazione. Evitando di mappare tutti i percorsi del gateway API principale o root, si ottiene una maggiore flessibilità rispetto alle API, poiché non è necessario aggiornare il gateway API principale a ogni modifica dell'API.
Pro
Per controllare flussi di lavoro più complessi, come la modifica degli attributi della richiesta, le REST API utilizzano il Velocity Template Language (VTL) di'Apache per consentire di modificare la richiesta e la risposta. Le REST API possono offrire vantaggi aggiuntivi come i seguenti:
-
Autenticazione N/Z con AWS Identity and Access Management (IAM), Amazon Cognito o autorizzatori AWS Lambda
-
Token di utilizzo per raggruppare i consumer in diversi livelli (consulta Richieste API Throttle per una migliore velocità di trasmissione effettiva nella documentazione di Gateway API)
Contro
A volumi elevati, il costo potrebbe essere un problema per alcuni utenti.
CloudFront
Puoi utilizzare la funzione di selezione dinamica dell'origineapi.example.com.
Caso d'uso tipico
La logica di routing risiede come codice all'interno della funzione Lambda @Edge, quindi supporta meccanismi di routing altamente personalizzabili come test A/B, versioni canary, contrassegno delle funzionalità e riscrittura dei percorsi. Il diagramma seguente ne è l'illustrazione.
Pro
Se hai bisogno di memorizzare nella cache le risposte delle API, questo metodo è un ottimo modo per unificare una raccolta di servizi dietro un unico endpoint. È un metodo conveniente per unificare le raccolte di API.
Inoltre, CloudFront supporta la crittografia a livello di campo e l'integrazione con la limitazione della velocità di base e AWS WAF gli ACL di base.
Contro
Questo metodo supporta un massimo di 250 origini (servizi) che possono essere unificate. Questo limite è sufficiente per la maggior parte delle implementazioni, ma potrebbe causare problemi con un gran numero di API man mano che si amplia il portafoglio di servizi.
L'aggiornamento delle funzioni Lambda @Edge attualmente richiede alcuni minuti. CloudFront inoltre, richiede fino a 30 minuti per completare la propagazione delle modifiche a tutti i punti di presenza. Questo alla fine blocca ulteriori aggiornamenti fino al loro completamento.
