31、AWS架构：弹性与高性能的实现

最新推荐文章于 2025-11-16 19:01:06 发布

咖啡因依赖

最新推荐文章于 2025-11-16 19:01:06 发布

阅读量14

点赞数

CC 4.0 BY-SA版权

分类专栏： AWS架构实战指南文章标签： AWS架构弹性计算高性能架构

本文链接：https://blog.youkuaiyun.com/numpy6sculptor/article/details/154474078

AWS架构实战指南专栏收录该内容

44 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

AWS架构：弹性与高性能的实现

在云计算领域，构建弹性和高性能的架构对于应用程序的成功部署和运行至关重要。本文将深入探讨AWS架构中的关键概念，包括可用性计算、应用类型差异、Auto Scaling配置等，同时介绍如何优化核心AWS服务的性能。

1. 考试要点

可用性计算 ：了解如何使用硬依赖和冗余组件计算总可用性。当一个资源依赖于另一个资源时，这就是硬依赖，例如应用程序依赖于数据库。而像一组相同的应用程序实例这样彼此不依赖的资源，则是冗余组件。
传统与云原生应用的区别 ：传统应用程序是为在Linux或Windows服务器上运行而编写的，通常使用标准数据库组件，如SQL服务器或非关系型数据库（如Redis或MongoDB）。云原生应用程序则使用仅在云中可用的计算、数据库或网络资源，如Lambda和DynamoDB。
EC2 Auto Scaling配置 ：Auto Scaling可以通过在需要时自动配置新实例来避免应用程序故障，防止因资源耗尽导致的实例故障。当实例发生故障时，Auto Scaling会介入并创建一个替换实例。
应用负载均衡器与EC2 Auto Scaling协同工作 ：当Auto Scaling创建新实例时，它会自动将其添加到关联的弹性负载均衡目标组中。当移除实例时，Auto Scaling会将该实例从关联的目标组中移除。
备份和恢复选项 ：
- S3 ：提供版本控制和跨区域复制功能。
- EBS ：可以手动或自动进行EBS快照来备份存储在EBS卷上的数据。
- EFS ：可以使用AWS Backup或将文件从一个EFS文件系统复制到另一个来备份EFS文件系统。
SQS队列类型差异 ：标准队列可以容纳比FIFO队列更多的消息，但可能会无序或多次传递消息。FIFO队列容纳的消息较少，但总是按顺序且仅传递一次消息。

2. 复习问题

以下是一些复习问题及其答案，帮助你巩固上述知识：
| 问题 | 选项 | 答案 |
| — | — | — |
| 要使每月停机时间不超过30分钟，所需的最低可用性级别是多少？ | A. 99%
B. 99.9%
C. 99.95%
D. 99.999% | C |
| 应用程序在一个可用区的两个EC2实例上运行，弹性负载均衡器将用户流量均匀分配到健康实例上，每个实例上的应用程序连接到单个RDS数据库实例。假设每个EC2实例的可用性为90%，RDS实例的可用性为95%，则应用程序的总可用性是多少？ | A. 94.05%
B. 99%
C. 99.9%
D. 99.95% | A |
| 组织正在设计一个新的应用程序以在AWS上运行，开发人员要求推荐一个在所有区域都能表现良好的数据库，为实现最大可用性应推荐哪个数据库？ | A. 使用MySQL的Multi - AZ RDS
B. DynamoDB
C. 使用Aurora的Multi - AZ RDS
D. 自托管SQL数据库 | C |
| 以下哪些可以帮助提高Web应用程序的可用性？（多选） | A. 将Web资产存储在S3存储桶中，而不是应用程序实例上。
B. 使用足够大的实例类来处理应用程序的峰值负载。
C. 缩小实例规模。
D. 扩大实例规模。 | ABD |
| 已配置一个EC2 Auto Scaling组以使用启动配置在多个实例上配置和安装应用程序，现在需要重新配置Auto Scaling以在新实例上安装额外的应用程序，应该怎么做？ | A. 修改启动配置。
B. 创建一个启动模板并配置Auto Scaling组使用它。
C. 修改启动模板。
D. 修改CloudFormation模板。 | B |

3. 高性能架构设计原则

为了充分发挥云资源的性能，需要遵循以下设计原则：
- 快速启动测试环境以进行实验和测量性能。
- 快速自动地根据需求进行操作的扩展和缩减。
- 使用托管服务自动化基础设施配置，抽象操作。
- 响应外部事件，自动化使用容器和无服务器技术。
- 通过脚本和模板自动化部署复杂的全栈基础设施。
- 基于系统数据的智能消费来理解和优化操作。

4. 优化核心AWS服务性能

4.1 计算资源优化

EC2实例类型选择 ：特定EC2实例类型的性能由多个配置变量定义。在构建部署时，应尽可能选择与预期工作负载匹配的实例类型。必要时可以更改正在运行的实例类型或添加更多相同类型的实例。
以下是实例类型参数描述表：
| 实例参数 | 描述 |
| — | — |
| ECUs | EC2计算单元，用于比较不同实例类型的计算能力 |
| vCPUs | 从此实例类型构建的实例分配的虚拟CPU数量 |
| 物理处理器 | 主机服务器使用的处理器家族（如基于Arm的AWS Graviton2） |
| 时钟速度 | 主机服务器使用的时钟速度 |
| 内存 | 从此实例类型构建的实例分配的RAM量 |
| 实例存储 | 此实例类型使用的本地（临时）实例存储卷的大小 |
| EBS优化可用 | 此类实例是否可以配置为使用EBS优化以实现专用I/O吞吐量 |
| 网络性能 | 从此实例类型构建的实例允许的数据传输速率 |
| IPv6支持 | 是否提供IPv6地址支持 |
| Intel AES - NI | 硬件主机是否使用高级加密标准 - 新指令（AES - NI）加密指令集 |
| Intel AVX | 硬件主机是否使用浮点密集型指令集以提高图形/分析性能 |
| Intel Turbo | 硬件主机是否可以从短期性能提升中受益 |
Auto Scaling ：当单个EC2实例无法满足需求时，可以进行横向扩展。Auto Scaling是一种AWS工具，可以根据需求自动启动或关闭实例。Auto Scaling组围绕启动配置构建，你可以指定预加载应用程序的自定义EC2 AMI，也可以选择标准AMI并在启动时传递用户数据进行配置。

以下是使用Auto Scaling配置和启动应用程序的步骤：
1. 从EC2仪表板，在快速启动选项卡上使用Ubuntu Server LTS AMI和t2.micro实例类型创建一个启动配置。
2. 在创建启动配置页面上，为配置命名。本练习不需要选择IAM角色或启用监控。
3. 将以下命令保存到本地计算机的文件中，命名为start.sh，展开高级详细信息部分，点击“作为文件”单选按钮，并从计算机中选择start.sh脚本。这将安装Apache Web服务器并创建一个简单的index.html网页：

#!/bin/bash
apt-get update
apt-get install -y apache2
echo "Welcome to my website"> index.html
cp index.html /var/www/html

选择（或创建）一个允许所有通过端口80的HTTP流量的安全组，然后创建配置，确保选择有效的密钥对，以便日后必要时可以使用SSH登录实例。
创建一个将使用新启动配置的Auto Scaling组。为组命名，并将组大小值保留为1个实例。
选择实例将启动的虚拟专用云（VPC），在子网字段内点击一次，选择实例要所在的子网。假设使用默认VPC，显示的任何公共子网都可以。
在配置扩展策略页面上，将最小容量设置为1，最大容量设置为2。
选择目标跟踪扩展策略，将指标类型值保留为平均CPU利用率，并将目标值编辑为5%。这个异常低的值将更容易确认自动扩展是否工作，通常70% - 80%的值更合理。
本练习不需要配置通知或标签。点击创建以完成组的创建。
组将立即尝试启动第一个实例。加载可能需要几分钟时间。完成后，将浏览器指向与实例关联的IP地址（可以从EC2实例仪表板获取）。

由于index.html页面很小，可能很难让Auto Scaling工具启动第二个实例。你可能需要在服务器命令行上运行一个繁忙工作命令，如 $ while true; do true; done 来提高CPU水平。

无服务器工作负载 ：可以在不使用EC2实例的情况下构建弹性计算基础设施。容器工具（如Docker）或仅代码的函数（如Lambda）可以提供超轻量级和“即时启动”的计算功能，比运行完整服务器所需的开销要少得多。

以下是不同计算技术类别适用的用例：
| 技术 | 用例 |
| — | — |
| EC2实例 | 长期运行、更复杂的Web应用程序；需要深入监控和跟踪的进程 |
| ECS容器 | 高度可扩展、自动化的应用程序；需要完全控制底层资源的应用程序 |

通过合理运用这些知识和技术，你可以构建出更具弹性和高性能的AWS架构，满足不同应用场景的需求。

5. 存储、数据库与网络优化

5.1 存储优化

不同的存储服务有不同的优化方式和备份恢复策略：
- S3 ：S3提供了版本控制和跨区域复制功能。版本控制可以保护数据免受意外删除或覆盖，跨区域复制可以确保数据在不同区域都有副本，提高数据的可用性和安全性。
- EBS ：对于存储在EBS卷上的数据，可以通过手动或自动进行EBS快照来备份。手动快照可以在特定时间点进行，而自动快照可以按照预设的时间间隔进行。
- EFS ：可以使用AWS Backup或将文件从一个EFS文件系统复制到另一个来备份EFS文件系统。AWS Backup提供了自动化的备份解决方案，而文件复制则提供了更灵活的备份方式。

5.2 数据库优化

例如，如果需要在所有区域都表现良好的数据库，使用Aurora的Multi - AZ RDS是一个不错的选择，因为它具有高性能和自动扩展的能力。

5.3 网络优化

网络优化对于确保应用程序的高性能和可用性至关重要：
- 子网规划 ：在创建VPC中的子网时，要预留足够的空间以添加更多子网。原因如下：
- 可能需要为应用程序添加另一个层级。
- AWS可能会在某个区域添加更多可用区。
- IP地址规划 ：在部署大量EC2实例时，要选择合适的子网CIDR。例如，计划部署50个EC2实例，每个实例有两个私有IP地址，可以选择10.0.0.0/21这样的子网CIDR。
- 连接方式 ：如果当前通过办公室的10 Gbps互联网连接访问AWS资源，并且全球有终端用户访问相同资源，可以考虑使用Direct Connect。原因如下：
- 降低延迟，提高响应速度。
- 提高安全性，提供专用的网络连接。

6. SQS队列的使用与优化

6.1 SQS队列类型

6.2 SQS队列的相关设置

可见性超时 ：默认可见性超时为30秒。当消费者从队列中获取消息后，该消息在可见性超时期间对其他消费者不可见。如果消费者在超时前未处理完消息，消息会重新变为可见，其他消费者可以再次获取。
保留期 ：默认保留期为4天。消息在队列中保留的最长时间，超过保留期的消息会被自动删除。
延迟队列 ：可以设置特定消息在一段时间后才变为可用，适用于需要延迟处理的场景。
长轮询 ：可以减少空响应，提高效率。长轮询会等待一段时间，直到队列中有消息或者超时。

6.3 SQS队列问题处理

重复消息问题 ：如果应用程序因重复消息而崩溃，可以使用FIFO队列，因为FIFO队列可以确保消息仅传递一次。
消息丢失问题 ：如果使用短轮询，可能会出现消息丢失的情况。可以使用长轮询来解决这个问题，长轮询会等待队列中有消息才返回。
死信队列 ：当消费者多次无法处理特定消息时，可以将这些消息发送到死信队列。例如，消息在队列中停留时间过长、不同消费者多次处理相同消息等情况都可以使用死信队列来处理。

7. 总结与实践建议

通过对AWS架构中弹性和高性能实现的探讨，我们了解了多个方面的知识和技术：
- 在计算资源方面，要根据工作负载选择合适的EC2实例类型，并合理使用Auto Scaling和无服务器技术。
- 在存储方面，要根据不同的存储服务选择合适的备份和恢复策略。
- 在数据库方面，要根据应用需求选择合适的数据库类型和优化策略。
- 在网络方面，要进行合理的子网和IP地址规划，并根据情况选择合适的连接方式。
- 在SQS队列方面，要根据场景选择合适的队列类型，并合理设置相关参数。

以下是实践建议的流程图：

graph LR
    A[明确应用需求] --> B[选择计算资源]
    B --> C[选择存储服务]
    C --> D[选择数据库类型]
    D --> E[进行网络规划]
    E --> F[选择SQS队列类型]
    F --> G[配置相关参数]
    G --> H[测试与优化]

在实践中，要不断测试和优化架构，根据实际情况调整配置，以实现弹性和高性能的AWS架构。例如，在使用Auto Scaling时，可以根据实际的CPU利用率调整目标值；在选择数据库时，可以根据应用的读写频率和数据一致性要求进行选择。通过不断的实践和优化，才能构建出满足不同应用场景需求的优质架构。