文章目录
- 专题总览
- API Gateway
- API Gateway – 高级集成
- API Gateway – AWS 服务集成
- API Gateway - Endpoint Types
- API Gateway – 安全
- AWS Step Functions（AWS 步骤函数）
- Amazon Cognito（认证服务）
- Cognito User Pools (CUP) – 用户功能
- Cognito User Pools (CUP) - 集成
- Cognito Identity Pools（联合身份）
- Serverless Architectures
- 移动应用程序：MyTodoList
- 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
- 总结
- Serverless 托管网站：MyBlog.com
- 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
- 总结
- Micro Services 架构
- Micro Services Environment
- Discussions 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 上大大节省成本。
- 我们还将在可用性、网络带宽成本等方面节省。
- 这是一种使现有应用程序更具可扩展性和更便宜的简单方法！
