文章目录
专题总览API GatewayAPI Gateway – 高级集成API Gateway – AWS 服务集成API Gateway - Endpoint TypesAPI Gateway – 安全
AWS Step Functions（AWS 步骤函数）Amazon Cognito（认证服务）Cognito User Pools (CUP) – 用户功能Cognito User Pools (CUP) - 集成Cognito Identity Pools（联合身份）
Serverless Architectures移动应用程序：MyTodoListMobile app: REST API layerMobile app: giving users access to S3Mobile app: high read throughput, static dataMobile app: caching at the API Gateway总结
Serverless 托管网站：MyBlog.comServing static content, globallyServing static content, globally, securelyAdding a public serverless REST APILeveraging DynamoDB Global TablesUser Welcome email flowThumbnail Generation flow总结
Micro Services 架构Micro Services EnvironmentDiscussions on Micro Services软件更新的 offloading (卸载)
App 当前架构为什么选择 CloudFront？
专题总览
包含专题内容总览和系列博客目录 https://blog.csdn.net/weixin_40815218/article/details/135590291
API Gateway
AWS API Gateway 是一项 AWS 服务，它具有以下功能：
AWS Lambda + API Gateway => 无需管理基础架构的API管理支持 WebSocket 协议处理 API 版本控制（如v1、v2等）处理不同的环境（如开发、测试、生产等）处理安全性（身份验证和授权）创建 API 密钥，处理请求限流支持 Swagger / Open API 导入，快速定义API转换和验证请求和响应生成 SDK 和 API 规范缓存 API 响应
API Gateway – 高级集成
Lambda 函数
调用 Lambda 函数可以便捷地借助 AWS Lambda，暴露 REST API HTTP
在后端暴露 HTTP 端点例子：内部 HTTP API，应用程序负载均衡器…为什么？添加速率限制、缓存、用户认证、API密钥等… AWS服务
通过 API 网关暴露任何 AWS API例子：启动 AWS Step Function 工作流程，向 SQS 发布消息为什么？添加身份验证，公开部署，速率控制…
API Gateway – AWS 服务集成
Kinesis Data Streams示例
API Gateway - Endpoint Types
Edge-Optimized（默认）：适用于全球客户
请求通过 CloudFront 边缘位置路由（提高延迟）API Gateway 仍位于一个区域中 区域：
适用于同一区域内的客户可以手动与 CloudFront 结合使用（更多对缓存策略和分发的控制） 私有：
只能通过 VPC 使用界面 VPC 端点（ENI）访问使用资源策略来定义访问
API Gateway – 安全
用户身份验证通过
IAM 角色（适用于内部应用程序）Cognito（用于外部用户身份认证 - 例如移动用户）自定义授权者（您自己的逻辑） 通过与 AWS 证书管理器（ACM）集成实现自定义域名的HTTPS 安全性
如果使用 Edge-Optimized 终端点，则证书必须位于us-east-1 区域如果使用Regional终端点，则证书必须位于 API Gateway 所在的区域必须在 Route 53 中设置 CNAME 或 A-别名记录
AWS Step Functions（AWS 步骤函数）
可以构建无服务器的可视化工作流程，用于编排 Lambda 函数功能包括：顺序执行、并行执行、条件判断、超时处理、错误处理等可以与 EC2、ECS、本地服务器、API Gateway、SQS 队列等进行集成可以实现人工审批功能应用场景：订单处理、数据处理、Web应用程序等任何工作流程
Amazon Cognito（认证服务）
为用户提供身份以与我们的Web或移动应用程序进行交互Cognito 用户池：
为应用程序用户提供登录功能与API Gateway和应用程序负载均衡器集成 Cognito 身份池（联合身份）：
为用户提供AWS凭证，使他们可以直接访问AWS资源与 Cognito 用户池集成作为身份提供者 Cognito 与 IAM 的比较：“数百个用户”，“移动用户”，“使用SAML进行身份验证”
Cognito User Pools (CUP) – 用户功能
为您的 Web 和移动应用程序创建无服务器用户数据库简单登录：用户名（或电子邮件）/密码组合密码重置电子邮件和电话号码验证多因素身份验证（MFA）联合身份：来自 Facebook、Google、SAML 等的用户
Cognito User Pools (CUP) - 集成
CUP 可以与 API Gateway 和应用程序负载均衡器进行集成
Cognito Identity Pools（联合身份）
为“用户”获取身份，以获取临时的 AWS 凭证用户的来源可以是 Cognito 用户池、第三方登录等用户可以直接访问 AWS 服务，或通过 API Gateway 访问凭证所应用的 IAM 策略在 Cognito 中定义可以根据 user_id 进行细粒度控制进行自定义针对已验证和访客用户的默认 IAM 角色
Cognito Identity Pools（CIP）允许在 DynamoDB 中实现行级别的安全性
Serverless Architectures
移动应用程序：MyTodoList
我们希望创建一个具备以下要求的移动应用程序：
以HTTPS的方式暴露为REST API采用无服务器架构用户应能直接与其在S3中的文件夹进行交互用户应通过托管的无服务器服务进行身份验证用户可以编写和阅读待办事项，但他们主要是阅读它们数据库应具备可伸缩性，并具备一定的高读取吞吐量
Mobile app: REST API layer
Mobile app: giving users access to S3
Mobile app: high read throughput, static data
Mobile app: caching at the API Gateway
总结
无服务器 REST API: HTTPS、API Gateway、Lambda、DynamoDB使用 Cognito 通过 STS 生成临时凭证来访问带有受限策略的 S3 存储桶。应用程序用户可以通过这种方式直接访问 AWS 资源。这种模式可以应用于DynamoDB、Lambda 等。使用 DAX 在 DynamoDB 上缓存读取操作在 API Gateway 层级上缓存 REST 请求使用 Cognito 和 STS 进行身份验证和授权的安全性
Serverless 托管网站：MyBlog.com
这个网站应该具备全球范围的可扩展性博客很少写入，但经常被读取网站的一部分是纯静态文件，另一部分是动态的 REST API尽可能实现缓存任何新订阅的用户都应该收到欢迎邮件博客中上传的任何照片都应该生成缩略图
Serving static content, globally
Serving static content, globally, securely
Adding a public serverless REST API
Leveraging DynamoDB Global Tables
User Welcome email flow
Thumbnail Generation flow
总结
我们使用 CloudFront 和 S3 来分发静态内容。REST API 采用无服务器架构，不需要 Cognito，因为是公开的。我们利用了全球 DynamoDB 表来全球提供数据服务。（我们也可以使用 Aurora 全球数据库）我们启用了 DynamoDB Streams 来触发 Lambda 函数。Lambda 函数具有 IAM 角色，可以使用 SES。SES (Simple Email Service) 被用于以无服务器方式发送电子邮件。S3 可以触发 SQS / SNS / Lambda 来通知事件。
Micro Services 架构
我们希望转向微服务架构。许多服务直接使用 REST API 进行交互。每个微服务的架构可能因形式和结构而异。我们希望采用微服务架构，以便每个服务都有更精简的开发生命周期。
Micro Services Environment
Discussions on Micro Services
可以自由设计每个微服务Synchronous patterns：API Gateway、负载均衡器Asynchronous patterns：SQS、Kinesis、SNS、Lambda 触发器（S3）微服务面临的挑战：
创建每个新微服务的重复开销。优化服务器密度/利用率的问题。同时运行多个版本的多个微服务的复杂性。客户端代码需求的增加，以与许多单独的服务集成。 一些挑战可以通过无服务器模式解决：
API Gateway 和 Lambda 可以自动扩展，并按使用量付费。可以轻松克隆 API，复制环境。通过 Swagger 集成为 API Gateway 生成客户端 SDK。
软件更新的 offloading (卸载)
我们在 EC2 上运行一个应用程序，偶尔会分发软件更新。当有新的软件更新时，我们会收到大量请求，并且内容会在网络上大规模分发。这非常昂贵。我们不想改变我们的应用程序，但希望优化成本和 CPU，我们该怎么做？
App 当前架构
为什么选择 CloudFront？
不需要更改架构。它将在边缘缓存软件更新文件。软件更新文件是静态的（永不更改）。我们的 EC2 实例不是无服务器的，但 CloudFront 是，它会为我们扩展。我们的 ASG 不会扩展那么多，我们将在 EC2 上大大节省成本。我们还将在可用性、网络带宽成本等方面节省。这是一种使现有应用程序更具可扩展性和更便宜的简单方法！
精彩链接
您阅读本篇文章共花了：
发表评论