文章目录

  • 什么是 Docker？
    • 操作系统上的 Docker
    • Docker 镜像存储
    • Docker vs. Virtual Machines
    • Docker 入门
    • AWS 中的 Docker Containers Management
  • Amazon ECS
    • EC2 Launch Type
    • Fargate Launch Type
    • ECS 的 IAM Roles
    • Load Balancer Integrations
    • Data Volumes (EFS)
    • ECS Service Auto Scaling
    • EC2 Launch Type – Auto Scaling EC2 实例
  • Amazon ECR
  • Amazon EKS 概述
    • Amazon EKS – Diagram
    • Amazon EKS – 节点类型
    • Amazon EKS – 数据卷
    • AWS App Runner
  • Serverless 概述
    • 什么是无服务？
    • AWS 中的无服务
    • 为什么选择 AWS Lambda
    • AWS Lambda 的优点
    • AWS Lambda 语言支持
    • AWS Lambda 集成
    • AWS Lambda 定价：示例
    • AWS Lambda 的限制（per region）
    • Customization At The Edge
    • CloudFront Functions vs. Lambda[@Edge ](/Edge )
      • CloudFront Functions
      • Lambda[@Edge ](/Edge )
    • 总结
      • CloudFront Functions
      • Lambda[@Edge ](/Edge )
    • 默认的 Lambda
    • VPC 中的 Lambda
    • 带有 RDS 代理的 Lambda
  • Amazon DynamoDB
    • DynamoDB – 基础知识
    • DynamoDB – 表示例
    • DynamoDB – 读/写容量模式
    • DynamoDB 加速器 (DAX)
      • DynamoDB 加速器 (DAX) vs. ElastiCache
    • DynamoDB – 流处理
      • DynamoDB 流
      • Kinesis Data Streams（较新）
    • DynamoDB Global Tables
    • DynamoDB – 生存时间 (TTL)
    • DynamoDB – 用于灾难恢复的备份
    • DynamoDB – 与 Amazon S3 集成

什么是 Docker？

  • Docker 是一个用于部署应用程序的软件开发平台
  • Docker 容器可以在任何操作系统上运行，应用程序运行在容器中
  • 应用程序运行过程相同，无论它们在何处运行 —> 行为可预测
  • 无兼容性问题，更易于维护和部署
  • 减少工作量
  • 使用案例：微服务架构、将应用程序从本地直接迁移到 AWS 云，…

操作系统上的 Docker

Docker 镜像存储

  • Docker 镜像存储在 Docker Repositories
  • Docker Hub (https://hub.docker.com)
    • 公共存储库
    • 查找多种技术或操作系统的基础映像（例如 Ubuntu、MySQL…）
  • Amazon ECR（Amazon Elastic Container Registry）
    • 私有存储库
    • 公共存储库（Amazon ECR Public Gallery: https://gallery.ecr.aws）

Docker vs. Virtual Machines

  • Docker 趋近于一种虚拟化技术，但并不完全是
  • 区别：与主机共享资源 => 一台服务器上有许多容器

Docker 入门

AWS 中的 Docker Containers Management

  • Amazon 弹性容器服务 (Amazon ECS)
    • Amazon 自己的容器平台
  • Amazon Elastic Kubernetes 服务 (Amazon EKS)
    • Amazon 托管的 Kubernetes（开源）
  • AWS Fargate
    • Amazon 自己的无服务容器平台
    • 可与 ECS 和 EKS 配合使用
  • Amazon ECR:
    • 存储容器的镜像

Amazon ECS

EC2 Launch Type

  • ECS = 弹性容器服务
  • 在 AWS 上启动 Docker 容器 = 在 ECS 集群上启动 ECS Tasks
  • EC2 启动类型：用户必须配置和维护基础设施（EC2 实例）
  • 每个 EC2 实例必须运行 ECS Agent 才能在 ECS 集群中注册
  • AWS 负责启动/停止容器

Fargate Launch Type

  • 在 AWS 上启动 Docker 容器
  • 用户无需配置基础设施（无需管理 EC2 实例）
  • 一切都是无服务的！
  • 用户只需创建任务定义
  • AWS 只是根据用户需要的 CPU/RAM 为用户运行 ECS Tasks
  • 如果要扩展，只需增加 Task 数量即可。 简单 —— 不会有更多的 EC2 实例

ECS 的 IAM Roles

  • EC2 实例配置文件（仅限 EC2 启动类型）：
    • 由 ECS Agent 使用
    • 对 ECS 服务进行 API 调用
    • 将容器日志发送到 CloudWatch Logs
    • 从 ECR 拉取 Docker 镜像
    • 引用 Secrets Manager 或 SSM 参数存储中的敏感数据
  • ECS Task Role：
    • 允许每个任务具有特定的角色
    • 对不同 ECS 服务使用不同的角色
    • Task Role 是在 Task Definition 中定义

Load Balancer Integrations

  • 应用程序负载均衡器(ALB)：支持并适用于大多数用例
  • 网络负载均衡器(NLB)：建议仅用于高吞吐量/高性能用例，或将其与 AWS Private Link 配对
  • 弹性负载均衡器(ELB)：支持但不推荐（无高级功能 – 如 Fargate）

Data Volumes (EFS)

  • 将 EFS 文件系统挂载到 ECS Tasks 上
  • 适用于 EC2 和 Fargate 启动类型
  • 在任何 AZ 中运行的任务将共享 EFS 文件系统中的相同数据
  • Fargate + EFS = Serverless
  • 使用案例：EFS 作为多可用区共享存储，实现容器的持久化
  • 注意：
    • Amazon S3 无法作为文件系统安装

ECS Service Auto Scaling

  • 自动增加/减少所需的 ECS Tasks 数量
  • ECS 实现自动扩展的方式是使用 AWS Application Auto Scaling 服务
    • ECS 服务平均 CPU 利用率
    • ECS 服务 RAM 上的 平均内存利用率规模
    • 每个目标的 ALB 请求计数 (来自 ALB 的指标)
  • 目标跟踪(Target Tracking): 根据特定 CloudWatch 指标的目标值进行扩展
  • 步进扩展(Step Scaling): 根据指定的 CloudWatch 警报进行扩展
  • 计划扩展(Scheduled Scaling): 根据指定日期/时间进行扩展（可预测的变化）
  • ECS Service Auto Scaling（任务级别）≠ EC2 Auto Scaling（EC2 实例级别）
  • Fargate Auto Scaling 更容易设置（因为无服务）

EC2 Launch Type – Auto Scaling EC2 实例

  • 通过添加底层 EC2 实例来适应 ECS 服务扩展
  • Auto Scaling Group (ASG)
    • 根据CPU 利用率扩展用户的 ASG
    • 随着时间的推移添加 EC2 实例
  • ECS Cluster Capacity Provider
    • 用于自动配置和扩展 ECS Tasks的基础设施
    • 通常与 ASG 配合使用
    • 当用户缺少容量（CPU、RAM…）时添加 EC2 实例

ECS Scaling – Service CPU 使用示例

Event Bridge 调用的 ECS Tasks

Event Bridge Schedule 调用的 ECS Tasks

ECS – SQS 队列示例

Amazon ECR

  • ECR = Elastic Container Registry
  • 在 AWS 上存储和管理 Docker 映像
  • 私有和公共存储库（Amazon ECR 公共库 https://gallery.ecr.aws）
  • 与 ECS 完全集成，由 Amazon S3 支持
  • 访问通过 IAM 控制（权限错误 => 策略）
  • 支持镜像漏洞扫描、版本控制、镜像标签、镜像生命周期…

Amazon EKS 概述

  • Amazon EKS = Amazon Elastic Kubernetes Service
  • 这是在 AWS 上启动托管 Kubernetes 集群的一种方法
  • Kubernetes 是一个开源系统，用于自动部署、扩展和管理容器化（通常是 Docker）应用程序
  • EKS 是 ECS 的一种替代方案，目标类似但 API 不同
  • EKS 支持 EC2（如果要部署工作节点），也支持 Fargate（如果要部署无服务器容器）。
  • 使用案例：如果用户的公司已在本地或其他云中使用 Kubernetes，并且希望使用 Kubernetes 迁移到 AWS
  • Kubernetes 与云无关（可以在任何云中使用 – Azure、GCP…）
  • 对于多个区域，需要在每个区域部署一个 EKS 集群
  • 使用 CloudWatch Container Insights 收集日志和指标

Amazon EKS – Diagram

Amazon EKS – 节点类型

  • 受托管节点组
    • 为用户创建和管理节点（EC2 实例）
    • 节点是EKS 管理的ASG 的一部分
    • 支持按需实例或 Spot 实例
  • 自我管理节点
    • 由用户创建并注册到 EKS 集群并由 ASG 管理的节点
    • 用户可以使用预构建的 AMI – Amazon EKS 优化的 AMI
    • 支持按需实例或 Spot 实例
  • AWS Fargate
    • 无需维护； 没有管理节点

Amazon EKS – 数据卷

  • 需要在 EKS 集群上指定 StorageClass 清单
  • 利用 Container Storage Interface (CSI) 兼容的驱动程序
  • 支持…
    • Amazon EBS
    • Amazon EFS（与 Fargate 配合使用）
    • Amazon FSx for Lustre
    • 适用于 NetApp ONTAP 的 Amazon FSx

AWS App Runner

  • 完全托管的服务，可以轻松大规模部署 Web 应用程序和 API
  • 无需基础架构经验
  • 从源代码或容器映像开始
  • 自动构建和部署 Web 应用程序
  • 自动扩展、高可用性、负载均衡器、加密
  • VPC 访问支持
  • 连接到数据库、缓存和消息队列服务
  • 使用案例：Web 应用程序、API、微服务、快速生产部署

Serverless 概述

什么是无服务？

  • 无服务是一种新范式，开发人员无需再管理服务器…
  • 只部署xx代码、xx功能！
  • 最初，无服务 == FaaS（函数即服务）
  • 无服务由 AWS Lambda 开创，但现在还包括任何托管内容：“数据库、消息传递、存储等”。

AWS 中的无服务

  • AWS Lambda
  • DynamoDB
  • AWS Cognito
  • AWS API Gateway
  • Amazon S3
  • AWS SNS & SQS
  • AWS Kinesis Data Firehose
  • Aurora Serverless
  • Step Functions
  • Fargate
    |

为什么选择 AWS Lambda

  • Amazon EC2
    • 云中的虚拟服务器
    • 受 RAM 和 CPU 限制
    • 连续运行
    • 扩展意味着需要人工干预去添加/删除服务器
  • Amazon Lambda
    • 虚拟功能——无需管理服务器！
    • 受时间限制 – 执行时间短
    • 按需运行
    • 缩放是自动的！

AWS Lambda 的优点

  • 轻松定价：
    • 按请求和计算时间付费
    • 提供免费的使用额度，包括1,000,000个AWS Lambda请求和400,000 GB的计算时间
  • 与整个 AWS 服务套件集成
  • 与多种编程语言集成
  • 通过AWS CloudWatch 轻松监控
  • 轻松为函数获取更多资源（高达 10GB RAM！）
  • 增加 RAM 也能提高CPU和网络性能

AWS Lambda 语言支持

  • Node.js (JavaScript)
  • Python
  • Java（兼容 Java 8）
  • C#（.NET 核心）
  • Go 语言
  • C# / Powershell
  • 红宝石
  • 自定义运行时 API（社区支持，例如 Rust）
  • Lambda 容器映像
    • 容器映像必须实现Lambda Runtime API
    • ECS / Fargate 是运行任意 Docker 镜像的首选

AWS Lambda 集成

Main ones

示例：无服务缩略图创建

示例：无服务 CRON 作业

AWS Lambda 定价：示例

  • 用户可以在此处找到总体定价信息：
    https://aws.amazon.com/lambda/pricing/
  • 按调用量付费：
    • 前 1,000,000 个请求免费
    • 此后每 100 万个请求 0.20 美元（每个请求 0.0000002 美元）
  • 按持续时间付费：（以 1 毫秒为增量）
    • 每月免费 400,000 GB-秒 的计算时间
      • exp: 400,000 秒（如果函数为 1GB RAM）
      • exp: 3,200,000 秒（如果函数为 128 MB RAM）
    • 此后 600,000 GB 秒 1.00 美元
  • 运行 AWS Lambda 通常非常便宜，因此非常受欢迎

AWS Lambda 的限制（per region）

  • 执行：
    • 内存分配：128 MB ～ 10GB（1 MB 增量）
    • 最长执行时间：900 秒（15 分钟）
    • 环境变量 (4 KB)
    • “功能容器”中的磁盘容量（/tmp）：512 MB 至 10GB
    • 并发执行：1000（可以增加）
  • 部署：
    • Lambda 函数部署大小（压缩的.zip）：50 MB
    • 未压缩部署的大小（代码+依赖项）：250 MB
    • 可以使用/tmp目录在启动时加载其他文件
    • 环境变量的大小：4 KB

Customization At The Edge

  • 许多现代应用程序在边缘执行某种形式的逻辑
  • 边缘功能：
    • 用户编写并附加到 CloudFront 分配的代码
    • 靠近用户运行以最大限度地减少延迟
  • CloudFront 提供两种类型：CloudFront Functions 和 Lambda@Edge
  • 用户无需管理全球部署的任何服务器
  • 使用案例：定制CDN 内容
  • 仅按使用量付费
  • 完全无服务

CloudFront Functions vs. Lambda@Edge


用例：

  • 网站安全和隐私
  • 边缘的动态 Web 应用程序
  • 搜索引擎优化（SEO）
  • 智能路由跨源和数据中心
  • 边缘机器人缓解
  • 实时图像转换
  • A/B 测试
  • 用户身份验证和授权
  • 用户优先级
  • 用户跟踪和分析

CloudFront Functions

  • 用 JavaScript 编写的轻量级函数
  • 适用于大规模、延迟敏感的 CDN 定制
  • 亚毫秒级启动时间，每秒数百万个请求
  • 用于更改查看器请求和响应：
    • 查看者请求：CloudFront 收到查看者的请求后
    • 查看器响应：在 CloudFront 将响应转发给查看器之前
  • CloudFront 的本机功能（完全在 CloudFront 内管理代码）

Lambda@Edge

  • 用 NodeJS 或 Python 编写的 Lambda 函数
  • 可扩展到每秒 1000 个请求
  • 用于更改 CloudFront 请求和响应：
    • 查看者请求：CloudFront 收到查看者的请求后
    • 源请求：在 CloudFront 将请求转发到源之前
    • 源响应：CloudFront 收到来自源的响应后
    • 查看器响应：在 CloudFront 将响应转发给查看器之前
  • 在一个 AWS 区域 (us-east-1) 中编写用户的函数，然后 CloudFront 复制到其位置

总结

CloudFront Functions

  • 缓存键规范化
    • 转换请求属性（标头、cookie、查询字符串、URL）以创建最佳缓存键
  • Header 操作
    • 在请求或响应中插入/修改/删除 HTTP 标头
  • URL 重写或重定向
  • 请求身份验证和授权
    • 创建并验证用户生成的令牌（例如 JWT）以允许/拒绝请求

Lambda@Edge

  • 较长的执行时间（几毫秒）
  • 可调节CPU或内存
  • 用户的代码依赖于第三个库（例如，用于访问其他 AWS 服务的 AWS SDK）
  • 网络访问以使用外部服务进行处理
  • 文件系统访问或对 HTTP 请求正文的访问

默认的 Lambda

  • 默认情况下，用户的 Lambda 函数在用户自己的 VPC 外部（在 AWS 拥有的 VPC 中）启动
  • 因此，它无法访问用户的VPC 中的资源（RDS、ElastiCache、内部ELB…）

VPC 中的 Lambda

  • 用户必须定义 VPC ID、子网和安全组
  • Lambda 将在用户的子网中创建 ENI（弹性网络接口）

带有 RDS 代理的 Lambda

  • 如果 Lambda 函数直接访问用户的数据库，它们可能会在高负载下打开太多连接
  • RDS 代理
    • 通过池化和共享数据库连接来提高可扩展性
    • 通过减少 66% 的故障转移时间并保留连接来提高可用性
    • 通过在 Secrets Manager 中强制执行 IAM 身份验证和存储凭证来提高安全性
  • Lambda 函数必须部署在用户的 VPC 中，因为 RDS Proxy 永远无法公开访问

Amazon DynamoDB

  • 完全托管、高度可用，可跨多个可用区进行复制
  • NoSQL 数据库，具有事务支持
  • 可扩展到海量工作负载、分布式数据库
  • 每秒数百万个请求、数万亿行、数百TB 存储
  • 快速且一致的性能（个位数毫秒）
  • 与 IAM 集成以实现安全、授权和管理
  • 低成本和自动扩展功能
  • 无需维护或修补，始终可用
  • 标准和不频繁访问 (IA) 表类

DynamoDB – 基础知识

  • DynamoDB 由表组成
  • 每个表都有一个主键（必须在创建时决定）
  • 每个表可以有无限数量的项目（= 行）
  • 每个项目都有属性（可以随着时间的推移添加 – 可以为空）
  • 项目的最大大小为 400KB
  • 支持的数据类型有：
    • 标量类型 – 字符串、数字、二进制、布尔值、空值
    • 文档类型 – 列表、地图
    • 集合类型 – 字符串集合、数字集合、二进制集合
  • 因此，在 DynamoDB 中，用户可以快速发展架构

DynamoDB – 表示例

DynamoDB – 读/写容量模式

  • 控制管理表容量的方式（读/写吞吐量）
  • 配置模式（默认）
    • 用户指定每秒读/写的数量
    • 用户需要提前规划容量
    • 支付预配置的读取容量单位 (RCU) 和写入容量单位 (WCU) 费用
    • 可以为 RCU 和 WCU 添加自动缩放模式
  • 点播模式
    • 读/写会根据用户的工作负载自动扩展/缩减
    • 无需进行容量规划
    • 按使用量付费，价格更高 ($$$)
    • 非常适合不可预测的工作负载、陡峭的突然峰值

DynamoDB 加速器 (DAX)

  • DynamoDB 的完全托管、高可用性、无缝内存缓存
  • 通过缓存帮助解决读取拥塞
  • 缓存数据的微秒级延迟
  • 不需要修改应用程序逻辑（与现有的DynamoDB API 兼容）
  • 5 分钟 TTL 缓存（默认）

DynamoDB 加速器 (DAX) vs. ElastiCache

DynamoDB – 流处理

  • 表中项目级修改（创建/更新/删除）的有序流
  • 用例：
    • 实时响应变化（向用户发送欢迎电子邮件）
    • 实时使用情况分析
    • 插入衍生表
    • 实施跨区域复制
    • 对 DynamoDB 表的更改调用 AWS Lambda

DynamoDB 流

  • 24 小时保留期
  • 消费者数量有限
  • 使用 AWS Lambda 触发器或 DynamoDB Stream Kinesis 适配器进行处理

Kinesis Data Streams（较新）

  • 保留 1 年
  • 消费者数量多
  • 使用 AWS Lambda、Kinesis Data Analytics、Kineis Data Firehose、AWS Glue Streaming ETL 进行处理…

DynamoDB 流

DynamoDB Global Tables

  • 使 DynamoDB 表可在多个区域中以低延迟进行访问
  • 主动-主动复制
  • 应用程序可以读取和写入任何区域的表
  • 必须启用 DynamoDB Streams 作为先决条件

DynamoDB – 生存时间 (TTL)

  • 在过期时间戳后自动删除项目
  • 使用案例：通过仅保留当前项目来减少存储的数据、遵守监管义务、Web 会话处理…

DynamoDB – 用于灾难恢复的备份

  • 使用时间点恢复 (PITR) 进行连续备份
    • 可选择在过去 35 天内启用
    • 时间点恢复到备份窗口内的任何时间
    • 恢复过程创建一个新表
  • 按需备份
    • 完整备份可长期保留，直至明确删除
    • 不影响性能或延迟
    • 可以在AWS Backup 中进行配置和管理（支持跨区域复制）
    • 恢复过程创建一个新表

DynamoDB – 与 Amazon S3 集成

  • 导出到S3（必须启用PITR）
    • 适用于过去 35 天内的任何时间点
    • 不影响表的读取容量
    • 在DynamoDB 之上执行数据分析
    • 保留快照以供审核
    • 在导入回 DynamoDB 之前对 S3 数据进行 ETL
    • 以DynamoDB JSON 或ION 格式导出
  • 导入到 S3
    • 导入 CSV、DynamoDB JSON 或 ION 格式
    • 不消耗任何写入容量
    • 创建一个新表
    • 导入错误记录在CloudWatch Logs 中


示例：构建无服务 API