Este whitepaper é apenas para referência histórica. Alguns conteúdos podem estar desatualizados e alguns links podem não estar disponíveis.
As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Exemplos de padrões de arquitetura
Você pode implementar padrões de arquitetura populares usando o API Gateway e AWS Lambda como sua camada lógica. Este whitepaper inclui os padrões de arquitetura mais populares que utilizam camadas lógicas AWS Lambda baseadas em:
+ **Back-end móvel -** Um aplicativo móvel se comunica com o API Gateway e o Lambda para acessar os dados do aplicativo. Esse padrão pode ser estendido para clientes HTTPS genéricos que não usam recursos da AWS sem servidor para hospedar recursos de nível de apresentação (como clientes de desktop, servidor web em EC2 execução e assim por diante).
+ Aplicativo de **página única - Um aplicativo** de página única hospedado no Amazon S3 e CloudFront se comunica com o API Gateway AWS Lambda para acessar os dados do aplicativo.
+ **Aplicativo Web** — O aplicativo Web é um back-end de aplicativo Web de uso geral, orientado por eventos, que é usado com o API AWS Lambda Gateway para sua lógica de negócios. Ele também usa o DynamoDB como banco de dados e o Amazon Cognito para gerenciamento de usuários. Todo o conteúdo estático é hospedado usando o Amplify.
Além desses dois padrões, este whitepaper discute a aplicabilidade do Lambda e do API Gateway a uma arquitetura geral de microsserviços. A arquitetura de microsserviços é um padrão popular que, embora não seja uma arquitetura padrão de três camadas, envolve desacoplar os componentes do aplicativo e implantá-los como unidades individuais de funcionalidade sem estado que se comunicam entre si.
# Back-end móvel
![\[Padrão arquitetônico para back-end móvel sem servidor\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/arch-pattern-serverless-mobile-backend.png)
*Padrão arquitetônico para back-end móvel sem servidor*
*Tabela 1 - Componentes do nível de back-end móvel*
| Tier | Componentes |
| --- | --- |
| Apresentação | Aplicativo móvel em execução em um dispositivo de usuário. |
| Logic (Lógica) | Amazon API Gateway com AWS Lambda. Essa arquitetura mostra três serviços expostos (`/tickets``/shows`, e`/info`). Os endpoints [do API Gateway são protegidos pelos grupos de usuários do Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html). Nesse método, os usuários fazem login nos grupos de usuários do Amazon Cognito (usando um terceiro federado, se necessário) e recebem tokens de acesso e ID que são usados para autorizar chamadas do API Gateway. Cada função do Lambda recebe sua própria função de Identity and Access Management (IAM) para fornecer acesso à fonte de dados apropriada. |
| Dados | O DynamoDB é usado para `/tickets` os serviços e. `/shows` O Amazon RDS é usado para o `/info` serviço. Essa função Lambda recupera as credenciais do Amazon RDS do AWS Secrets Manager e usa uma interface de rede elástica para acessar a sub-rede privada. |
# Aplicação de página única
![\[AWS architecture diagram showing interactions between services like CloudFront, S3, Lambda, and DynamoDB.\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/single-page-application.png)
*Padrão arquitetônico para aplicativo de página única sem servidor*
*Tabela 2 - Componentes do aplicativo de página única*
| Tier | Componentes |
| --- | --- |
| Apresentação | Conteúdo estático do site hospedado no Amazon S3, distribuído por. CloudFront O AWS Certificate Manager permite que um certificado SSL/TLS personalizado seja usado. |
| Logic (Lógica) | API Gateway com AWS Lambda. Essa arquitetura mostra três serviços expostos (`/tickets``/shows`, e`/info`). Os endpoints do API Gateway são protegidos por um autorizador Lambda. Nesse método, os usuários fazem login por meio de um provedor de identidade terceirizado e obtêm acesso e tokens de ID. Esses tokens são incluídos nas chamadas do API Gateway, e o autorizador Lambda valida esses tokens e gera uma política do IAM contendo permissões de iniciação da API. Cada função do Lambda recebe sua própria função do IAM para fornecer acesso à fonte de dados apropriada. |
| Dados | O Amazon DynamoDB é usado para `/tickets` os serviços e. `/shows` A Amazon ElastiCache é usada pelo `/shows` serviço para melhorar o desempenho do banco de dados. As falhas de cache são enviadas para o DynamoDB. O Amazon S3 é usado para hospedar conteúdo estático usado pelo. `/info service` |
# Aplicativo Web
![\[Nuvem AWS architecture diagram showing client interaction with various Serviços da AWS.\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/web-application.png)
*Padrão arquitetônico para aplicativo web*
*Tabela 3 - Componentes do aplicativo Web*
| Tier | Componentes |
| --- | --- |
| Apresentação | O aplicativo front-end é todo conteúdo estático (HTML, CSS JavaScript e imagens) que é gerado por utilitários do React, como. create-react-app A Amazon CloudFront hospeda todos esses objetos. O aplicativo web, quando usado, baixa todos os recursos para o navegador e começa a ser executado a partir daí. O aplicativo web se conecta ao back-end chamando o. APIs |
| Logic (Lógica) | A camada lógica é criada usando funções Lambda lideradas pelo API Gateway REST. APIs Essa arquitetura mostra vários serviços expostos. Há várias funções Lambda diferentes, cada uma tratando de um aspecto diferente do aplicativo. As funções do Lambda estão por trás do API Gateway e podem ser acessadas usando caminhos de URL da API. A autenticação do usuário é feita usando grupos de usuários do Amazon Cognito ou provedores de usuários federados. O API Gateway usa integração imediata com o Amazon Cognito. Somente depois que um usuário for autenticado, o cliente receberá um token JSON Web Token (JWT) que deverá ser usado ao fazer as chamadas de API. Cada função do Lambda recebe sua própria função do IAM para fornecer acesso à fonte de dados apropriada. |
| Dados | Neste exemplo específico, o DynamoDB é usado para o armazenamento de dados, mas outros serviços específicos de banco de dados ou armazenamento da Amazon podem ser usados dependendo do caso de uso e do cenário de uso. |
# Microsserviços com Lambda
![\[Nuvem AWS architecture with API Gateways and Lambda functions across two accounts.\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/microservices-with-lambda.png)
*Padrão arquitetônico para microsserviços com Lambda*
O padrão de arquitetura de microsserviços não está vinculado à arquitetura típica de três camadas; no entanto, esse padrão popular pode obter benefícios significativos com o uso de recursos sem servidor.
Nessa arquitetura, cada um dos componentes do aplicativo é desacoplado e implantado e operado de forma independente. Uma API criada com o Amazon API Gateway e funções lançadas posteriormente pelo AWS Lambda, é tudo o que você precisa para criar um microsserviço. Sua equipe pode usar esses serviços para desacoplar e fragmentar seu ambiente até o nível de granularidade desejado.
Em geral, um ambiente de microsserviços pode apresentar as seguintes dificuldades: sobrecarga repetida para criar cada novo microsserviço, problemas com a otimização da densidade e utilização do servidor, complexidade de executar várias versões de vários microsserviços simultaneamente e proliferação de requisitos de código do lado do cliente para integração com muitos serviços separados.
Quando você cria microsserviços usando recursos sem servidor, esses problemas se tornam menos difíceis de resolver e, em alguns casos, simplesmente desaparecem. O padrão de microsserviços sem servidor reduz a barreira para a criação de cada microsserviço subsequente (o API Gateway permite até mesmo a clonagem de funções Lambda existentes e o uso de APIs funções Lambda em outras contas). A otimização da utilização do servidor não é mais relevante com esse padrão. Por fim, o Amazon API Gateway fornece clientes gerados programaticamente SDKs em várias linguagens populares para reduzir a sobrecarga de integração.