亚马逊AWS官方博客
新的策略建议服务帮助简化 AWS 云迁移和现代化
确定成功将应用程序迁移至云和现代化进程的可行策略非常耗时。根据要分析的应用程序组合的规模和复杂性，可能还需要做大量工作。迄今为止，分析在很大程度上为手动流程，而且本质上是非标准的，因此很难大规模应用于大型应用程序组合。有很多种因素可能会加大工作量和增加复杂性，包括做出决策的时间有限、缺乏领域知识和云专业知识以及对可用现代化工具和服务的认识不足。
我很高兴地宣布推出 AWS Migration Hub 策略建议，以帮助自动分析应用程序组合。策略建议可分析正在运行的应用程序以确定运行时环境和进程依赖关系，选择性地分析源代码和数据库等。根据您优先考虑的一组业务目标，评估通过分析收集的数据，例如降低许可证成本、加快迁移速度、减少因使用托管式服务而产生的运营开销或使用云原生技术实现基础设施现代化。然后，这将会为您的应用程序迁移和现代化的可行途径提供建议。
任何给定的应用程序都可能会有多种迁移和现代化途径，包括更换主机、更换平台或重构。您将获得有关所有可行途径的建议，并且可以根据自己的需要选择忽略这些建议。无论是否有相关经验，每个人都可以使用策略建议来减少评估应用程序组合所需的工作量、时间和降低复杂性，无论它们是在本地等待迁移还是已经迁移到 AWS 云等待进一步现代化处理。
以典型的 N 层应用程序为例（使用 Microsoft SQL Server 数据库的 ASP.NET Web 应用程序），策略建议可帮助您分析各种组件，例如托管 Web 前端的服务器、后端服务器和数据库本身，来确定可用于迁移到 AWS 云并进行现代化的可行途径和工具。例如，如果您的目标是降低应用程序的许可成本，策略建议可能会建议您使用 Porting Assistant for .NET 将应用程序重构为 Linux 上的 .NET。
注册策略建议应用程序服务器
向 AWS Application Discovery Service 注册托管应用程序组合的服务器是策略建议的先决条件。要注册的服务器可以作为物理服务器或虚拟机（VM）在本地运行，也可以是已通过“直接迁移”流程迁移的应用程序的 Amazon Elastic Compute Cloud（Amazon EC2）实例。您可以在 AWS Application Discovery Service 用户指南中详细了解有关注册应用程序服务器的不同选项。
自动收集数据以用于分析
通过在 AWS Application Discovery Service 中注册的服务器，您可以使用由策略建议提供的无代理数据收集器，设置应用程序组合的流程级分析的自动收集。无代理收集器可以作为适用于 VMWare vCenter 环境的开放虚拟化设备（OVA）下载。如果您已将部分或全部应用程序迁移到 EC2，那么还有一个 EC2 Amazon Machine Image（AMI），其中包括收集器，可帮助进一步分析这些应用程序是否可现代化。
如果您不想或无法使用自动收集方法，或者已经使用其他工具或服务收集了此数据，则可以手动导入数据以进行分析。但是，您获得的有关手动导入数据的建议，其深入程度不及自动数据收集的建议。自动数据收集的另一个好处是，随着您的收集进度的进展，刷新数据也更加容易。
服务器上的应用程序和进程发现与语言无关。对于 GitHub 和 GitHub Enterprise 存储桶以及 Microsoft SQL Server 数据库中的 .NET 和 Java 应用程序，您可以选择包括对云反面模式的检测。请务必注意，如果您选择执行源代码或数据库分析，则不会将实际的代码或数据上传到策略建议，只会发送分析结果。补充一下，如果您选择手动导入数据进行分析，则不支持执行更深入的源代码和数据库分析这一选项。
分析应用程序组合
有关如何设置自动数据收集、分析选项和其他重要先决条件的完整详细信息，请参阅策略建议用户指南，在此将不做赘述。我们将看看如何开始分析已经迁移到 EC2 的应用程序组合，以便使用无代理收集器进一步实现现代化。如前所述，策略建议支持分析托管在物理本地服务器或虚拟机上或（如本文所示）托管在 EC2 实例上的应用程序组合。
要开始收集数据进行分析，我需要遵循以下几个步骤：
- 使用可下载的 OVA 或提供的 EC2 AMI 启动和配置策略建议无代理收集器。
- 将托管我的应用程序的每个 Windows 和 Linux 实例配置为允许从收集器访问。
- 配置我的初始业务优先级以及其他应用程序和数据库首选项，以获取我的初始建议。稍后我可能会对这些选项进行微调。
我的第一步是在 Migration Hub 控制台中，单击导航面板中的 Strategy（策略）以进入 Get started（入门）页面。单击 Download data collector（下载数据收集器）、Download import template（下载导入模板）或 Get recommendations（获取建议）按钮中的任一个后，系统将询问我是否同意创建与服务相关的角色，授予策略建议所需的权限以代表我访问其他服务。我同意后，我将从包含简短向导的 Configure data sources（配置数据源）页面开始。在这里，我可以查看以前注册的任何收集器的列表。我还可以下载 OVA 版本的数据收集器，以及我想手动导入的任何应用程序数据的导入模板，而不是自动收集。
我将使用基于 EC2 AMI 的收集器，因此，在继续执行此向导之前，我将在新的浏览器选项卡中打开 EC2 控制台以启动它。要查找策略建议数据收集器的镜像，我可以转到 AMI 页面，选择 Public images（公有映像），然后按所有者 703163444405 进行筛选，或者在启动实例向导的 Search（搜索）字段中输入名称 AWSMHubApplicationDataCollector。找到镜像后，我会像处理任何其他 AMI 一样继续执行启动向导。
收集器配置流程很简单，我使用了一系列问题来引导。正如我之前提到的，完整的信息在该用户指南中，在此不做赘述。要启动配置过程，我首先使用 SSH 连接到我的收集器实例，然后使用 docker exec -it application-data-collector bash 命令运行 Docker 容器。在正在运行的容器中，我使用命令 collector setup 启动配置问答。在此过程中，系统会要求您提供以下信息和数据：
- 使用协议和确认所有必需角色均已设置，然后是一组 AWS 访问和私有密钥。
- 对于不由 vCenter 或 EC2 Windows 实例托管的本地 Windows 应用程序服务器，我需要提供用户 ID 和密码，以便收集器能够使用 WinRM 连接到我的服务器。
- 如果我有 Linux 应用程序服务器，我可以选择收集器是使用 SSH 还是基于证书的身份验证进行连接。
- 最后，我可以为 GitHub 或 GitHub Enterprise 上的存储库中的 .NET 和 Java 应用程序配置源代码分析。而这些步骤需要 Git 用户名和个人访问令牌（PAT）。我还可以为 C# 应用程序配置其他更深入的源代码分析。但是，这确实需要一个运行 Windows 的独立服务器，我已经在该服务器上安装了 Porting Assistant for .NET。
完成这些步骤后，我的数据收集器就注册成功了，并可以开始检查我的服务器了。返回策略建议的 Configure data sources（配置数据源）页面，刷新一下页面，现在可以看到已列出的收集器。
第二步是允许从收集器访问我的应用程序服务器，有关详细信息，请参阅此用户指南中的“Step 4: Set up the Strategy Recommendations collector”（步骤 4：设置策略建议收集器）主题。对于我的 Windows 服务器，我使用 RDP 进行连接，然后从指南中提供的链接下载并运行两个 PowerShell 脚本来配置 WinRM。对于较大的服务器队列，您可以考虑使用 AWS Systems Manager Automation 来执行此任务。对于我的 Linux 服务器，在选择对收集器使用 SSH 身份验证之后，我需要将在收集器配置过程中生成的公有密钥材料复制到每个服务器。
此时，AWS Application Discovery Service 已知要分析的服务器，策略建议数据收集器已配置，每个服务器都配置为允许从收集器访问。现在我将执行第三步也是最后一步，即设定我的业务和其他事项优先级以进行分析，让服务开始生成我的建议。
回到策略建议的 Get started（入门）页面，由于我的收集器已注册，而且我没有要导入的手动应用程序数据，我只需选择 Next（下一步）。于是，我将进入 Specify Preferences（指定首选项）页面，在这里我可以设置业务优先级和其他首选项。我可以随时修改这些内容并重新分析。但就目前而言，我使用拖放功能将以下因素设置为我的最高优先级：License cost reduction（降低许可证成本）、Modernizing infrastructure using cloud-native technologies（使用云原生技术对基础设施进行现代化），以及Reduce operational overhead with managed services（减少因使用托管式服务而产生的运营开销）。然后我将剩余的应用程序和数据库首选项保持不变。
选择 Next（下一步），我将进入 Review（审阅）页面，其中汇总了我的选择，然后选择 Start data analysis（开始数据分析）。需要注意的一点是，系统将针对您在 Application Discovery Service 中配置的所有服务器运行分析，因此您可能会看到正在处理的服务器数量超过在前面步骤中导入的服务器数量（未配置为允许收集器访问的服务器将显示在收集状态为 data collection failed（数据收集失败）的结果中）。
分析完成后，系统将总结我的建议（尚未运行任何反面模式分析）。
我的一个服务器正在运行 Windows 并托管旧版本的 nopCommerce，最初是基于 .NET 框架的应用程序和一个相关的 SQL Server 数据库。由于我的最高业务优先级是降低许可证成本，因此我开始在该服务器上进行检查。到目前为止，可用的建议仅基于对服务器本身的检查。针对源代码和构成应用程序的组件的分析可能会影响这些建议，因此我要求通过深入到感兴趣的服务器和应用程序，进一步分析应用程序源代码。
代码分析会在 Amazon Simple Storage Service（Amazon S3）中创建一个 JSON 格式的报告文件，当我打开它时，会显示反面模式，例如使用 Windows 文件系统路径而不是基于云的服务访问日志文件，例如 Amazon CloudWatch、固定 IP 地址、特定于服务器的数据库连接等。
在进行代码分析之后，与仅基于服务器检查提出建议相比，这些建议略有更新。最初推荐用于更换平台方法的一个应用程序组件现在可以进行重构。
返回我感兴趣的服务器，单击 Strategy options（策略选项）选项卡查看建议。代码分析的结果以及我的业务优先级共同影响了权重。下图显示了初始建议，这些建议仅基于对服务器本身的分析。
根据源代码分析，以下是针对服务器的修订建议。
针对服务器的建议还包括将应用程序的 SQL Server 数据库平台更改为 Amazon Relational Database Service（RDS）上的 MySQL。此建议是因为在我的优先级中，我要求考虑托管式服务。在遵循此建议之前，我可能想对数据库执行额外的反面模式分析，我可以在 AWS Secrets Manager 中创建密钥以保存数据库凭证之后遵循此建议（详情请参阅用户指南中有关数据库分析的主题）。目前仅适用于 SQL Server 的数据库分析可识别迁移不兼容性，例如不受支持的数据类型。
在屏幕截图中，您会注意到其他可行的迁移和现代化途径。这适用于服务器和应用程序组件。如果我愿意，我可以通过选择可行的策略选项并单击 Set preferred（设置首选项），选择可行的途径而不是推荐的策略。在下面的屏幕截图中，对于 nopCommerce 应用程序组件，我更偏向使用 AWS App2Container 来更应用程序容器的路由平台。当然，我可以随时回头开始调整我的业务优先级和其他选项，然后重新分析我的数据。
采用初始建议，然后使用代码和数据库分析，或者修改分析的优先级和建议，为尝试多个“假设”选项提供了范围，以发现将应用程序组合迁移到云并实现其现代化的最佳策略。确定了最佳策略后，您就可以将其传达给下游团队，以开始应用程序组合的迁移和现代化进程。
立即获取有关迁移和现代化的建议
您可以立即使用 AWS Migration Hub 策略建议开始分析服务器和应用程序组合，无需额外付费，该功能已在美国东部（弗吉尼亚北部）、美国西部（俄勒冈）、亚太地区（悉尼）、亚太地区（东京）欧洲（法兰克福）、欧洲（爱尔兰）和欧洲（伦敦）区域推出。当然，您可以根据工具提供的建议将选择迁移和现代化的应用程序部署到所有区域。如前所述，您可以在用户指南中找到有关先决条件、收集器入门以及使用建议的更多详细信息。