本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# AWS 应用程序设计和迁移策略
<a name="aws-application-design-and-migration-strategy"></a>

设计和记录应用程序的未来状态是成功迁移的关键因素。我们建议为任何类型的迁移策略创建设计，无论多么简单或复杂。创建设计将揭示潜在的障碍、依赖关系和优化应用程序的机会，即使在架构预计不会发生变化的情况下。此外，由此产生的设计将作为迁移后进一步发展的基础。 

除了设计过程的重要性外，它还可能成为阻碍因素并影响迁移速度。之所以发生这种情况，是因为为本地系统构思了传统的架构审查流程。我们建议您审查您的架构审查和批准流程，并专注于建立可以预先批准的架构模式或类型。不要低估审查成百上千个应用程序的架构所付出的努力，并借此机会实现流程的现代化。

以下列表包含有助于设计过程的资源：
+ [AWS 架构中心](https://aws.amazon.com/architecture/)结合了工具和指南，例如 AWS Well-Architected 框架。此外，它还提供了可用于应用程序的参考架构。
+ [Amazon Builders](https://aws.amazon.com/builders-library/) Library 包含一些关于亚马逊如何构建和运营软件的资源。
+ [AWS 解决方案库](https://aws.amazon.com/solutions/)提供了一系列经过 AWS 审查的基于云的解决方案，可解决数十个技术和业务问题。它包括大量参考架构。
+ [AWS 规范性指导](https://aws.amazon.com/prescriptive-guidance/)提供了有助于设计过程和迁移最佳实践的策略、指南和模式。
+ [AWS Documentation](https://docs.aws.amazon.com/)包含有关 AWS 服务的信息，包括用户指南和 API 参考。
+ [入门资源中心](https://aws.amazon.com/getting-started/)提供了几个动手教程和深入研究，以学习基础知识，以便您可以开始进行构建 AWS。

根据您在云之旅中所处的位置， AWS 基础可能已经存在。这些 AWS 基础包括以下内容：
+ AWS 区域 已被识别。
+ 账户已创建或可以按需获取。
+ 通用联网已经实现。
+ 基础 AWS 服务已在账户中部署。 

相反，你可能还处于早期阶段， AWS 基础尚未建立。缺乏既定的基础可能会限制应用程序设计的范围，或者需要进一步的工作来定义它们。如果是这样的话，我们建议与应用程序设计工作并行定义和实现着陆区的基础设计。应用程序设计有助于确定 AWS 账户 结构、网络、虚拟私有云 (VPC)、无类 Inter-Domain 路由 (CIDR) 范围、共享服务、安全和云运营等需求。 

 [AWS Control Tower](https://aws.amazon.com/controltower/)提供了设置和管理安全的多账户 AWS 环境（称为 landing zone）的最简单方法。 AWS Control Tower 使用创建您的 landing zone AWS Organizations，它提供持续的账户管理和治理，并在成千上万的客户迁移到云端时实施基于 AWS 最佳实践的体验。

## 应用程序 future 状态
<a name="application-future-state"></a>

首先为该应用程序制定初始迁移策略。目前，该策略被认为是初步的，因为它可能会随着未来状态设计的一部分而发生变化，从而发现潜在的局限性。要验证初始假设，请参阅 [6 R 决策树](prioritization-and-migration-strategy.md#migration-r-type)。此外，还要记录潜在的迁移阶段。例如，是否会在单个事件中迁移此应用程序（同时迁移所有组件）？ 还是分阶段迁移（有些组件稍后会迁移）？

请注意，给定应用程序的迁移策略可能不是唯一的。这是因为可以使用多个 R 类型来迁移应用程序组件。例如，最初的方法可能是在不做任何更改的情况下提升和转移应用程序。但是，应用程序的组件可能位于不同的基础设施资产中，可能需要不同的处理方式。例如，一个应用程序由三个组件组成，每个组件在单独的服务器上运行，其中一个服务器运行云端不支持的旧操作系统。该组件将需要采用重新平台的方法，而在支持的服务器版本中运行的另外两个组件可以重新托管。为要迁移的每个应用程序组件和关联的基础架构分配迁移策略是至关重要的。

接下来，记录上下文和问题，并链接定义当前状态的现有工件：
+ 为什么要迁移此应用程序？ 
+ 拟议的变更有哪些？ 
+ 有什么好处？ 
+ 有重大风险或阻碍因素吗？ 
+ 目前的缺点是什么？ 
+ 范围之内和范围外有什么？ 

## 可重复性
<a name="repeatability"></a>

在整个设计工作中，请考虑如何将该应用程序的解决方案和架构重复用于其他应用程序。这个解决方案可以概括吗？

## 要求
<a name="requirements"></a>

记录此应用程序的功能和非功能要求，包括安全性。这包括当前和未来的状态要求，具体取决于所选择的迁移策略。使用在详细的应用程序评估期间收集的信息来指导此过程。

## To-be 建筑
<a name="to-be-architecture"></a>

描述此应用程序的 future 架构。考虑创建一个可重复使用的逻辑示意图模板，其中包含源环境（本地）和目标 AWS 环境（例如目标、账户 AWS 区域、VPC 和可用区）的构建块。

创建一个表，列出正在迁移的组件和将要迁移的新组件。包括与该应用程序交互的其他应用程序和服务（本地或云端）。

下表列出了示例组件。它不代表参考架构或经过审查的配置。


| 
| 
| Name | 说明 | Details | 
| --- |--- |--- |
| 应用程序 | 外部服务（入站连接） | 服务使用来自公开的 API 的数据。 | 
| DNS | 名称解析（内部） | Amazon Route 53 作为基本账户设置的一部分进行部署 | 
| 应用程序负载均衡器 | 在后端服务之间分配流量 | 取代本地负载均衡器。迁移池 A | 
| 应用程序安全性 | DDoS 防护 | 通过使用实现 AWS Shield | 
| 安全组 | 虚拟防火墙 | 限制通过端口 443（入站）访问应用程序实例。 | 
| Server A | Front-end | 使用亚马逊弹性计算云 (Amazon EC2) 进行重新托管。 | 
| Server B | Front-end | 使用亚马逊 EC2 进行重新托管。 | 
| 服务器 C | 应用程序逻辑 | 使用亚马逊 EC2 进行重新托管。 | 
| 服务器 D | 应用程序逻辑 | 使用亚马逊 EC2 进行重新托管。 | 
| 亚马逊关系数据库服务（亚马逊 RDS）— 亚马逊 Aurora | 数据库 | 取代服务器 E 和 F | 
| 监控和提醒 | 变更控制 | Amazon CloudWatch | 
| 审计日志记录 | 变更控制 | AWS CloudTrail | 
| 修补和远程访问 | Maintenance | AWS Systems Manager | 
| 资源访问权限 | 安全访问控制 | AWS Identity and Access Management (IAM) | 
| 身份验证 | 用户访问权限 | Amazon Cognito | 
| 证书 | SSL/TLS | AWS Certificate Manager | 
| API 1 | 外部 API | Amazon API Gateway | 
| 对象存储 | 图片托管 | Amazon Simple Storage Service（Amazon S3） | 
| 凭据 | 证书的管理和托管 | AWS Secrets Manager | 
| AWS Lambda 函数 | 检索数据库凭证和 API 密钥 | AWS Lambda | 
| 互联网网关 | 出站互联网接入 | 通往 VPC 的互联网网关 | 
| 私有子网 1 | 后端和数据库 | 可用区 1 — VPC 1 | 
| 私有子网 2 | 后端和数据库 | 可用区 2 — VPC 1 | 
| 公有子网 1 | Front-end | 可用区 1 — VPC 1 | 
| 公有子网 2 | Front-end | 可用区 2 — VPC 1 | 
| Backup 服务 | 数据库和 EC2 实例备份 | AWS Backup | 
| DR | 亚马逊 EC2 弹性 | AWS 弹性灾难恢复 | 

识别出组件后，使用您的首选工具将它们绘制在图表中。与应用程序的主要利益相关者共享初始设计，包括应用程序所有者、企业架构师以及平台和迁移团队。可以考虑问以下问题：
+ 团队普遍同意这个设计吗？
+ 运营团队能否提供支持？
+ 设计可以演变吗？
+ 还有其他选择吗？
+ 设计是否符合建筑标准和安全政策？
+ 是否缺少任何组件（例如，代码存储库、 CI/CD 工具、VPC 端点）？

## 架构决策
<a name="architectural-decisions"></a>

作为设计过程的一部分，您可能会为整体架构或其中的特定部分找到更多选项。将这些选项与首选或选定选项的理由一起记录下来。这些决策可以记录为架构决策。 

确保列出和描述主要选项时要有足够的细节，让新读者了解决定使用一个选项而不是另一个选项背后的选项和原因。

## 软件生命周期环境
<a name="software-lifecycle-environments"></a>

记录对当前环境的任何更改。例如，将在中重新创建测试和开发环境， AWS 而不是迁移。

## 标签
<a name="tagging"></a>

描述每个基础架构组件的必备标签和建议标记，以及此设计的标签值。

## 迁移策略
<a name="migration-strategy"></a>

到目前为止，应验证有关迁移策略的初始假设。确认已就所选的 R 策略达成共识。记录总体应用程序迁移策略和各个应用程序组件的策略。如前所述，不同的应用程序组件可能需要不同的 R 类型进行迁移。

此外，根据关键业务驱动因素和结果调整迁移策略。另外，请描述任何分阶段的迁移方法，例如不同迁移事件中组件的移动。

有关确定 6 R 的更多信息，请参阅[AWS Migration Hub 策略建议](https://aws.amazon.com/blogs/aws/new-strategy-recommendations-service-helps-streamline-aws-cloud-migration-and-modernization/)。

## 迁移模式和工具
<a name="migration-patterns-tools"></a>

通过为应用程序和基础架构组件定义的迁移策略，您现在可以探索特定的技术模式。例如，重新托管策略可以通过迁移工具来实现，例如[AWS Transform MGN](https://aws.amazon.com/application-migration-service/)。如果您不需要复制状态或数据，则可以通过使用 Amazon 系统映像 (AMI) 和应用程序部署管道重新部署应用程序来实现相同的结果。 

[同样，要对应用程序进行平台重构或重构（重新架构），可以使用诸如、() [AWS App2Container](https://aws.amazon.com/app2container/)、[AWS Database Migration Service (AWS DMS)](https://aws.amazon.com/dms/)、AWS Schema Conversion Tool之类的工具。AWS SCT[AWS DataSync](https://aws.amazon.com/datasync/)](https://aws.amazon.com/dms/schema-conversion-tool/)要进行容器化，你可以使用亚马逊[弹性容器服务 (Amazon ECS)、亚马逊 Elastic Kubernetes Service (Amazon EKS)](https://aws.amazon.com/ecs/) [或](https://aws.amazon.com/eks/)。[AWS Fargate](https://aws.amazon.com/fargate/)回购时，您可以将 AMI 用于特定产品或中的软件即服务 (SaaS) 解决方案。[AWS Marketplace](https://aws.amazon.com/marketplace/)

评估可用于实现目标的不同模式和选项。考虑利弊以及迁移操作准备情况。为了帮助您进行分析，请使用以下问题：
+ 迁移团队能否支持这些模式？
+ 成本和收益之间的平衡是什么？
+ 能否将此应用程序、服务或组件移至托管服务？
+ 为实现这种模式付出了哪些努力？
+ 是否有任何法规或合规政策禁止使用特定模式？
+ 这种模式可以重复使用吗？ 首选可重复使用的图案。但是，有时一种模式只能使用一次。考虑在一次性模式与替代可重复使用的模式之间取得平衡。

[AWS 规范性指导](https://aws.amazon.com/prescriptive-guidance/)包含各种迁移模式和技术。

## 服务管理和运营
<a name="service-management-and-operations"></a>

在创建要迁移到的应用程序设计时 AWS，请考虑操作就绪性。与您的应用程序和基础架构团队一起评估就绪性要求时，请考虑以下问题：
+ 他们准备好操作它了吗？ 
+ 是否定义了事件响应程序？ 
+ 预期的服务级别协议 (SLA) 是什么？ 
+ 是否需要职责分离？ 
+ 不同的团队准备好协调支持行动了吗？ 
+ 谁应对什么负责？

## 切换注意事项
<a name="cutover-considerations"></a>

考虑到迁移策略和模式，在应用程序迁移时需要了解哪些重要信息？ 切换计划是一项设计后的活动。但是，请记录可以预期的活动和要求的所有注意事项。例如，记录执行概念验证的要求（如果适用），并概述测试、审计或验证要求。

## 风险、假设、问题和依赖关系
<a name="risks-assumptions-issues-dependencies"></a>

记录所有未解决的风险、假设和尚未解决的潜在问题。为这些项目分配明确的所有权，并跟踪进度，以便批准总体设计和战略以供实施。此外，请记录实现此设计的关键依赖关系。

## 估算运行成本
<a name="estimating-run-cost"></a>

要估算目标 AWS 架构的成本，请使用[AWS 定价计算器](https://calculator.aws/)。根据您的设计添加基础架构组件，并获得估计的运行成本。将应用程序组件所需的软件许可证考虑在内，但尚未包含在将要 AWS 服务 使用的软件许可证中。