Questo white paper è solo a scopo di riferimento storico. Alcuni contenuti potrebbero essere obsoleti e alcuni collegamenti potrebbero non essere disponibili.
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à.
# Esempi di modelli di architettura
Puoi implementare i modelli di architettura più diffusi utilizzando API Gateway e AWS Lambda come livello logico. Questo white paper include i modelli di architettura più diffusi che AWS Lambda sfruttano i livelli logici basati su livelli logici:
+ **Backend mobile:** un'applicazione mobile comunica con API Gateway e Lambda per accedere ai dati delle applicazioni. Questo modello può essere esteso a client HTTPS generici che non utilizzano risorse AWS serverless per ospitare risorse a livello di presentazione (come client desktop, server Web in esecuzione e così via). EC2
+ Applicazione a **pagina singola: un'applicazione** a pagina singola ospitata in Amazon S3 che CloudFront comunica con API Gateway e AWS Lambda per accedere ai dati dell'applicazione.
+ **Applicazione Web: l'applicazione** Web è un back-end di applicazioni Web generico, basato sugli eventi, che utilizza API AWS Lambda Gateway per la sua logica di business. Utilizza inoltre DynamoDB come database e Amazon Cognito per la gestione degli utenti. Tutti i contenuti statici sono ospitati utilizzando Amplify.
Oltre a questi due modelli, questo white paper illustra l'applicabilità di Lambda e API Gateway a un'architettura generale di microservizi. L'architettura a microservizi è un modello popolare che, sebbene non sia un'architettura standard a tre livelli, prevede il disaccoppiamento dei componenti delle applicazioni e la loro distribuzione come unità di funzionalità individuali senza stato che comunicano tra loro.
# Backend mobile
![\[Modello architettonico per un backend mobile senza server\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/arch-pattern-serverless-mobile-backend.png)
*Modello architettonico per backend mobile senza server*
*Tabella 1 - Componenti di livello di backend mobile*
| Livello | Componenti |
| --- | --- |
| Presentazione | Applicazione mobile in esecuzione su un dispositivo utente. |
| Logic (Logica) | Amazon API Gateway con AWS Lambda. Questa architettura mostra tre servizi esposti (`/tickets``/shows`, e`/info`). Gli endpoint API Gateway sono protetti dai pool di [utenti di Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html). Con questo metodo, gli utenti accedono ai pool di utenti di Amazon Cognito (utilizzando una terza parte federata, se necessario) e ricevono token di accesso e ID utilizzati per autorizzare le chiamate API Gateway. A ogni funzione Lambda viene assegnato il proprio ruolo Identity and Access Management (IAM) per fornire l'accesso all'origine dati appropriata. |
| Dati | DynamoDB viene utilizzato per `/tickets` i servizi and. `/shows` Per il `/info` servizio viene utilizzato Amazon RDS. Questa funzione Lambda recupera le credenziali Amazon RDS da AWS Secrets Manager e utilizza un'interfaccia di rete elastica per accedere alla sottorete privata. |
# Applicazione a pagina singola
![\[AWS architecture diagram showing interactions between services like CloudFront, S3, Lambda, and DynamoDB.\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/single-page-application.png)
*Modello architettonico per applicazioni a pagina singola senza server*
*Tabella 2 - Componenti dell'applicazione a pagina singola*
| Livello | Componenti |
| --- | --- |
| Presentazione | Contenuto statico del sito Web ospitato in Amazon S3, distribuito da. CloudFront AWS Certificate Manager consente di utilizzare un certificato SSL/TLS personalizzato. |
| Logic (Logica) | API Gateway con AWS Lambda. Questa architettura mostra tre servizi esposti (`/tickets``/shows`, e`/info`). Gli endpoint API Gateway sono protetti da un sistema di autorizzazione Lambda. Con questo metodo, gli utenti accedono tramite un provider di identità di terze parti e ottengono token di accesso e ID. Questi token sono inclusi nelle chiamate API Gateway e l'autorizzatore Lambda li convalida e genera una policy IAM contenente le autorizzazioni di avvio dell'API. A ogni funzione Lambda viene assegnato il proprio ruolo IAM per fornire l'accesso all'origine dati appropriata. |
| Dati | Amazon DynamoDB viene utilizzato per `/tickets` i servizi and. `/shows` Amazon ElastiCache viene utilizzato dal `/shows` servizio per migliorare le prestazioni del database. Gli errori di cache vengono inviati a DynamoDB. Amazon S3 viene utilizzato per ospitare contenuti statici utilizzati da. `/info service` |
# Applicazione Web
![\[Cloud AWS architecture diagram showing client interaction with various Servizi AWS.\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/web-application.png)
*Modello architettonico per applicazioni web*
*Tabella 3 - Componenti dell'applicazione Web*
| Livello | Componenti |
| --- | --- |
| Presentazione | L'applicazione front-end è composta da tutti i contenuti statici (HTML, CSS JavaScript e immagini) generati dalle utilità React come. create-react-app Amazon CloudFront ospita tutti questi oggetti. L'applicazione Web, una volta utilizzata, scarica tutte le risorse nel browser e inizia a funzionare da lì. L'applicazione Web si connette al backend chiamando il APIs. |
| Logic (Logica) | Il livello logico è creato utilizzando funzioni Lambda gestite da API Gateway REST. APIs Questa architettura mostra più servizi esposti. Esistono diverse funzioni Lambda, ognuna delle quali gestisce un aspetto diverso dell'applicazione. Le funzioni Lambda sono alla base di API Gateway e sono accessibili tramite percorsi URL API. L'autenticazione degli utenti viene gestita utilizzando pool di utenti Amazon Cognito o provider di utenti federati. API Gateway utilizza l'integrazione pronta all'uso con Amazon Cognito. Solo dopo l'autenticazione dell'utente, il client riceverà un token JSON Web Token (JWT) da utilizzare per effettuare le chiamate API. A ogni funzione Lambda viene assegnato il proprio ruolo IAM per fornire l'accesso all'origine dati appropriata. |
| Dati | In questo particolare esempio, DynamoDB viene utilizzato per l'archiviazione dei dati, ma è possibile utilizzare altri database o servizi di storage Amazon appositamente progettati a seconda del caso d'uso e dello scenario di utilizzo. |
# Microservizi con Lambda
![\[Cloud AWS architecture with API Gateways and Lambda functions across two accounts.\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/microservices-with-lambda.png)
*Modello architettonico per microservizi con Lambda*
Il modello di architettura a microservizi non è vincolato alla tipica architettura a tre livelli; tuttavia, questo modello popolare può ottenere vantaggi significativi dall'uso di risorse serverless.
In questa architettura, ciascuno dei componenti dell'applicazione è disaccoppiato e distribuito e gestito in modo indipendente. Un'API creata con Amazon API Gateway e le funzioni successivamente lanciate da AWS Lambda, sono tutto ciò di cui hai bisogno per creare un microservizio. Il tuo team può utilizzare questi servizi per disaccoppiare e frammentare l'ambiente al livello di granularità desiderato.
In generale, un ambiente di microservizi può presentare le seguenti difficoltà: sovraccarico ripetuto per la creazione di ogni nuovo microservizio, problemi di ottimizzazione della densità e dell'utilizzo dei server, complessità dell'esecuzione simultanea di più versioni di più microservizi e proliferazione dei requisiti di codice lato client per l'integrazione con molti servizi separati.
Quando si creano microservizi utilizzando risorse serverless, questi problemi diventano meno difficili da risolvere e, in alcuni casi, semplicemente scompaiono. Il modello di microservizi serverless riduce la barriera alla creazione di ogni microservizio successivo (API Gateway consente persino la clonazione di funzioni Lambda esistenti APIs e l'utilizzo di funzioni Lambda in altri account). L'ottimizzazione dell'utilizzo del server non è più rilevante con questo modello. Infine, Amazon API Gateway fornisce client generati programmaticamente SDKs in diversi linguaggi popolari per ridurre il sovraccarico di integrazione.