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à. # Modelli di routing delle API In ambienti di sviluppo agili, i team autonomi (ad esempio squadre e tribù) possiedono uno o più servizi che includono molti microservizi. I team espongono questi servizi in modo APIs da consentire ai propri consumatori di interagire con il loro gruppo di servizi e azioni. Esistono tre metodi principali per esporre HTTP APIs ai consumatori upstream utilizzando nomi host e percorsi: | | | **Metodo** | **Descrizione** | **Esempio** | | --- |--- |--- | | [**Routing dei nomi host**](api-routing-hostname.md) | Esponi ogni servizio come hostname. | `billing.api.example.com` | | [**Routing dei percorsi**](api-routing-path.md) | Esponi ogni servizio come percorso. | `api.example.com/billing` | | [**Routing basato su intestazione**](api-routing-http.md) | Esponi ogni servizio come intestazione HTTP. | `x-example-action: something` | Questa sezione descrive i casi d'uso tipici di questi tre metodi di routing e i relativi compromessi per aiutarti a decidere quale metodo si adatta meglio alle tue esigenze e alla tua struttura organizzativa. # Modello di routing dei nomi host Il routing per nome host è un meccanismo per isolare i servizi API assegnando a ciascuna API il proprio nome host; ad esempio, `service-a.api.example.com` o `service-a.example.com`. ## Caso d'uso tipico Il routing tramite i nomi host riduce l'attrito nelle release, perché nulla viene condiviso tra i team di assistenza. I team sono responsabili della gestione di tutto, dagli inserimenti DNS alle operazioni di servizio in produzione. ![\[Schema di routing dei nomi host per esporre HTTP ai consumatori upstream. APIs\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/cloud-design-patterns/images/routing-1.png) ## Pro Il routing dei nomi host è di gran lunga il metodo più semplice e scalabile per il routing delle API HTTP. Puoi utilizzare qualsiasi AWS servizio pertinente per creare un'architettura che segua questo metodo: puoi creare un'architettura con [Amazon API Gateway [AWS AppSync](https://aws.amazon.com/appsync/)](https://aws.amazon.com/api-gateway/), [Application Load Balancers](https://aws.amazon.com/elasticloadbalancing/) e [Amazon Elastic Compute Cloud ( EC2Amazon](https://aws.amazon.com/ec2/)) o qualsiasi altro servizio conforme a HTTP. I team possono utilizzare il routing dei nomi host per possedere completamente il proprio sottodominio. Inoltre, semplifica l'isolamento, il test e l'orchestrazione delle distribuzioni per versioni o specifiche, ad esempio o. Regioni AWS `region.service-a.api.example.com` `dev.region.service-a.api.example.com` ## Contro Quando utilizzi il routing dei nomi host, i consumer devono ricordare diversi nomi host per interagire con ogni API che si espone. Puoi mitigare questo problema fornendo un SDK per il client. Tuttavia, il cliente deve affrontare SDKs una serie di sfide. Ad esempio, devono supportare aggiornamenti continui, più lingue, il controllo delle versioni, la comunicazione delle modifiche più importanti causate da problemi di sicurezza o correzioni di bug, la documentazione e così via. Quando si utilizza il routing dei nomi host, è inoltre necessario registrare il sottodominio o il dominio ogni volta che si crea un nuovo servizio. # Modello di routing dei percorsi Il routing per percorsi è il meccanismo che raggruppa più o tutti APIs sotto lo stesso nome host e utilizza un URI di richiesta per isolare i servizi; ad esempio, o. `api.example.com/service-a` `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 digerire perché spesso viene tenuta insieme anziché essere suddivisa su diversi portali o. PDFs 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. Sì AWS, esistono diversi modi per condividere un'API e indirizzarla in modo efficace al servizio corretto. 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](https://www.f5.com/go/product/welcome-to-nginx) per creare configurazioni di routing dinamiche. In un'architettura [Kubernetes](https://kubernetes.io/), puoi anche creare una regola di ingresso per abbinare un percorso a un servizio. (Questa guida non copre l'accesso a Kubernetes; consulta la [documentazione di Kubernetes](https://kubernetes.io/docs/concepts/services-networking/ingress/#the-ingress-resource) per ulteriori informazioni.) 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. ![\[Utilizzo di un proxy inverso del servizio HTTP per il routing dei percorsi.\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/cloud-design-patterns/images/routing-2.png) 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 reverse proxy del servizio HTTP è creare un approccio scalabile e gestibile all'unificazione APIs in un unico dominio in modo che appaia coerente per qualsiasi utente di API. Questo approccio consente inoltre ai team di assistenza di implementare e gestire i propri sistemi APIs, con un sovraccarico minimo dopo l'implementazione. AWS i servizi gestiti per la tracciabilità, come [AWS X-Ray](https://aws.amazon.com/xray/)o [AWS WAF](https://aws.amazon.com/waf/), sono ancora applicabili in questo caso. ### 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 [Amazon API Gateway](https://aws.amazon.com/api-gateway/) (REST APIs e HTTP APIs) può instradare il traffico in modo simile al metodo reverse proxy del servizio HTTP. L'utilizzo di un gateway API in modalità proxy HTTP offre un modo semplice per inserire molti servizi in un punto di ingresso al sottodominio di primo livello `api.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 principale, otterrai una maggiore flessibilità rispetto al tuo APIs, perché non devi aggiornare il gateway API root a ogni modifica dell'API. ![\[Routing dei percorsi tramite Gateway API.\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/cloud-design-patterns/images/routing-3.png) ### Pro Per controllare flussi di lavoro più complessi, come la modifica degli attributi della richiesta, REST APIs utilizza l'Apache Velocity Template Language (VTL) per consentire di modificare la richiesta e la risposta. REST APIs può offrire vantaggi aggiuntivi come questi: + [Autenticazione N/Z con AWS Identity and Access Management (IAM),](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-net-applications-security/authentication.html) [[Amazon](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-net-applications-security/cognito.html) Cognito o autorizzatori AWS Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html) + [AWS X-Ray per tracciare](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-understanding-xray-traces.html) + [Integrazione con AWS WAF](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html) + [Limitazione della velocità di base](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) + Token di utilizzo per raggruppare i consumer in diversi livelli (consulta [Richieste API Throttle per una migliore velocità di trasmissione effettiva](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) 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'origine](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html) di [Amazon CloudFront](https://aws.amazon.com/cloudfront/) per selezionare in modo condizionale un'origine (un servizio) per inoltrare la richiesta. Puoi utilizzare questa funzionalità per indirizzare una serie di servizi attraverso un singolo nome host, ad esempio `api.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 A/B come test, versioni canary, feature flagging e riscrittura dei percorsi. Il diagramma seguente ne è l'illustrazione. ![\[Instradamento del percorso. CloudFront\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/cloud-design-patterns/images/routing-4.png) ### 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. APIs Inoltre, CloudFront supporta la [crittografia a livello di campo](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/field-level-encryption.html) e l'integrazione con la limitazione della velocità di base e AWS WAF di base. ACLs ### 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 molte di esse APIs 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. # Modello di routing delle intestazioni HTTP Il routing basato su intestazioni consente di indirizzare il servizio corretto per ogni richiesta specificando un'intestazione HTTP nella richiesta HTTP. Ad esempio, l'invio dell'intestazione `x-service-a-action: get-thing` consentirebbe di eseguire `get thing` da `Service A`. Il percorso della richiesta è comunque importante, perché offre indicazioni sulla risorsa su cui stai cercando di lavorare. Oltre a utilizzare il routing degli header HTTP per le azioni, è possibile utilizzarlo come meccanismo per il routing delle versioni, l'attivazione di feature flag, A/B test o esigenze simili. In realtà, probabilmente utilizzerai l'header routing con uno degli altri metodi di routing per creare un routing robusto. APIs L'architettura per il routing delle intestazioni HTTP in genere prevede un sottile livello di routing davanti ai microservizi che indirizza al servizio corretto e restituisce una risposta, come illustrato nel diagramma seguente. Questo livello di routing può coprire tutti i servizi o solo alcuni servizi per consentire un'operazione come il routing basato sulla versione. ![\[Routing delle intestazioni HTTP.\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/cloud-design-patterns/images/routing-5.png) ## Pro Le modifiche alla configurazione richiedono uno sforzo minimo e possono essere automatizzate facilmente. Questo metodo è inoltre flessibile e supporta modi creativi per esporre solo le operazioni specifiche che si desidera utilizzare in un servizio. ## Contro Analogamente al metodo di routing del nome host, il routing delle intestazioni HTTP presuppone che l'utente abbia il pieno controllo sul client e che sia possibile manipolare intestazioni HTTP personalizzate. I proxy, le reti di distribuzione dei contenuti (CDNs) e i sistemi di bilanciamento del carico possono limitare la dimensione dell'intestazione. Sebbene sia improbabile che ciò costituisca un problema, potrebbe trattarsi di un problema a seconda del numero di intestazioni e cookie aggiunti.