如何：从 Azure 访问控制服务迁移
警告
本内容适用于较旧版本的 Azure AD v1.0 终结点。 为新项目使用 Microsoft 标识平台。
Microsoft Azure 访问控制服务 (ACS) 是一种 Azure Active Directory (Azure AD) 服务，将于 2018 年 11 月 7 日停用。 在那之前，当前使用访问控制的应用程序和服务必须全部完整迁移到其他身份验证机制。 本文为打算弃用访问控制的当前客户提供相关建议。 如果当前未使用访问控制，则无需执行任何操作。
概述
访问控制是一种云身份验证服务，它提供了一种简单的方法来验证用户身份和授予用户对 Web 应用程序和服务的访问权限。 它允许将身份验证和授权的诸多功能从代码中分离出来。 Microsoft .NET 客户端、ASP.NET Web 应用程序和 Windows Communication Foundation (WCF) Web 服务的开发人员和架构师是访问控制的主要使用者。
访问控制用例主要可以分为三大类：
- 验证特定 Microsoft 云服务，包括 Azure 服务总线和 Dynamics CRM。 客户端应用程序从访问控制获取令牌，对这些服务进行验证，从而执行各种操作。
- 向 Web 应用程序添加身份验证，包括自定义和预打包的应用程序（如 SharePoint）。 通过使用访问控制“被动”身份验证，Web 应用程序可支持使用 Microsoft 帐户（以前称为 Live ID）以及 Google、Facebook、Yahoo、Azure AD 和 Active Directory 联合身份验证服务 (AD FS) 的帐户登录。
- 使用访问控制颁发的令牌保护自定义 Web 服务。 使用“主动”身份验证，Web 服务可确保只允许已通过访问控制验证的已知客户端进行访问。
下面各部分介绍了每个用例及其推荐迁移策略。
警告
在大多数情况下，必须大量更改代码，才能将现有应用和服务迁移到较新的技术。 建议立即开始计划和执行迁移，以避免出现任何潜在的中断或故障时间。
访问控制包括以下组件：
- 安全令牌服务 (STS)：用于接收身份验证请求并颁发安全令牌作为响应返回。
- Azure 经典门户：可在此创建、删除和启用/禁用访问控制命名空间。
- 单独的访问控制管理门户：可在此自定义和配置访问控制命名空间。
- 管理服务：可用于自动执行门户功能。
- 令牌转换规则引擎：可用于定义复杂逻辑，控制访问控制颁发的令牌的输出格式。
必须创建一个或多个访问控制命名空间，才能使用这些组件。 命名空间是访问控制的一个专用实例，应用程序和服务要与之进行通信。 命名空间独立于所有其他访问控制客户。 其他访问控制客户使用自己的命名空间。 访问控制中的命名空间具有专用 URL，如下所示：
https://<mynamespace>.accesscontrol.windows.net
与 STS 的所有通信以及管理操作都是通过此 URL 完成。 所用路径因用途而异。 若要确定应用程序或服务是否使用访问控制，可监视抵达 https://<命名空间>.accesscontrol.windows.net 的任何通信流。 流至此 URL 的任何流量都是由访问控制进行处理，需停止使用。
抵达 https://accounts.accesscontrol.windows.net 的任何流量除外。 流至此 URL 的流量已由其他服务进行处理，不受访问控制弃用影响。
有关访问控制的详细信息，请参阅访问控制服务 2.0（已存档）。
查明哪些应用将受影响
按照本部分中的步骤查明哪些应用程序将受 ACS 停用影响。
下载并安装 ACS PowerShell
转到 PowerShell 库并下载 Acs.Namespaces。
通过运行以下命令安装模块
Install-Module -Name Acs.Namespaces通过运行以下命令获取所有可能的命令的列表
Get-Command -Module Acs.Namespaces若要获取有关特定命令的帮助，请运行：
Get-Help [Command-Name] -Full其中，
[Command-Name]是 ACS 命令的名称。
列出 ACS 命名空间
使用 Connect-AcsAccount cmdlet 连接到 ACS。
您可能需要运行
Set-ExecutionPolicy -ExecutionPolicy Bypass，然后才能执行命令，并且需要是那些订阅的管理员，才能执行命令。使用 Get-AcsSubscription cmdlet 列出可用的 Azure 订阅。
使用 Get-AcsNamespace cmdlet 列出 ACS 命名空间。
检查哪些应用程序将受影响
使用上一步中的命名空间并转到
https://<namespace>.accesscontrol.windows.net例如，如果某个命名空间是 contoso-test，请转到
https://contoso-test.accesscontrol.windows.net在“信任关系”下，选择“信赖方应用”以查看将受 ACS 停用影响的应用列表。
对于你拥有的任何其他 ACS 命名空间，重复步骤 1-2。
停用计划
自 2017 年 11 月起，完全支持并可使用所有访问控制组件。 唯一的限制是无法通过 Azure 经典门户创建新的访问控制命名空间。
以下是访问控制组件停用计划：
- 2017 年 11 月：停用 Azure 经典门户中的 Azure AD 管理体验。 届时，将通过以下新专用 URL 管理访问控制命名空间：
https://manage.windowsazure.com?restoreClassic=true。 如有需要，可使用此 URL 查看现有命名空间、启用/禁用命名空间和删除命名空间。 - 2018 年 4 月 2 日：完全停用 Azure 经典门户，这意味着，不再可以通过任何 URL 管理访问控制命名空间。 此时，不能禁用/启用、删除或枚举访问控制命名空间。 但可通过
https://<namespace>.accesscontrol.windows.net访问功能完善的访问控制管理门户。 访问控制的其他所有组件继续正常运行。 - 2018 年 11 月 7 日：永久关闭所有访问控制组件。 这包括访问控制管理门户、管理服务、STS 和令牌转换规则引擎。 届时，将无法向访问控制（具体位于
<namespace>.accesscontrol.windows.net）发送任何请求。 应在此之前将所有现有应用和服务迁移到其他技术。
注意
策略会禁用在一段时间内未请求令牌的命名空间。 自 2018 年 9 月初起，这段时间目前是 14 天处于不活动状态，但在未来几周内将缩短为 7 天处于不活动状态。 如果有当前已禁用的访问控制命名空间，则可以下载并安装 ACS PowerShell 以重新启用命名空间。
迁移策略
下面各部分简要概述了从访问控制迁移到其他 Microsoft 技术的相关建议。
Microsoft 云服务客户端
所有接受访问控制颁发的令牌的 Microsoft 云服务现在都支持至少一种备用身份验证。 每个服务的身份验证机制各不相同。 建议参阅每个服务的特定文档，获取官方指南。 为方便起见，下面列出了各组文档：
| 服务 | 指南 |
|---|---|
| Azure 服务总线 | 迁移到共享访问签名 |
| Azure 服务总线中继 | 迁移到共享访问签名 |
| Azure 托管缓存 | 迁移到 Azure Cache for Redis |
| Azure DataMarket | 迁移到 Azure AI 服务 API |
| BizTalk 服务 | 迁移到 Azure 应用服务的逻辑应用功能 |
| Azure 媒体服务 | 迁移到 Azure AD 身份验证 |
| Azure 备份 | 升级 Azure 备份代理 |
SharePoint 客户
长期以来，SharePoint 2013、2016 和 SharePoint Online 客户都是使用 ACS 在云、本地和混合场景中进行身份验证。 有些 SharePoint 功能和用例会受 ACS 停用的影响，但有些则不会。 下表汇总了对利用 ACS 的某些最流行 SharePoint 功能进行迁移的指导：
| 功能 | 指南 |
|---|---|
| 从 Azure AD 对用户进行身份验证 | 以前，Azure AD 不支持 SharePoint 进行身份验证所需的 SAML 1.1 令牌，并将 ACS 用作中介，使 SharePoint 能够与 Azure AD 令牌格式兼容。 现在，可以使用 Azure AD 应用库 SharePoint 本地应用将 SharePoint 直接连接到 Azure AD。 |
| 本地 SharePoint 中的应用身份验证和服务器到服务器身份验证 | 不受 ACS 停用的影响；无需更改。 |
| SharePoint 加载项的低信任授权（提供程序托管和 SharePoint 托管） | 不受 ACS 停用的影响；无需更改。 |
| SharePoint 云混合搜索 | 不受 ACS 停用的影响；无需更改。 |
使用被动身份验证的 Web 应用程序
对于使用访问控制进行用户身份验证的 Web 应用程序，访问控制为 Web 应用程序开发人员和架构师提供以下特性和功能：
- 与 Windows Identity Foundation (WIF) 深度集成。
- 与 Google、Facebook、Yahoo、Azure Active Directory 和 ADFS 帐户，以及 Microsoft 帐户联合。
- 支持以下身份验证协议：OAuth 2.0 草案 13、WS-Trust 和 Web Services 联合身份验证（WS 联合身份验证）。
- 支持以下令牌格式：JSON Web 令牌 (JWT)、SAML 1.1、SAML 2.0 和简单 Web 令牌 (SWT)。
- WIF 中集成了主页领域发现体验，方便用户选取用于登录的帐户类型。 这种体验由 Web 应用程序托管，可完全自定义。
- 令牌转换，方便对 Web 应用程序从访问控制收到的声明进行丰富自定义，具体包括：
- 传递标识提供者提供的声明。
- 添加其他自定义声明。
- 用于在特定情况下颁发声明的简单 if-then 逻辑。
遗憾的是，尚无一项服务可以等效提供所有这些功能。 应评估所需的访问控制功能，然后在使用Microsoft Entra ID、Azure Active Directory B2C (Azure AD B2C) 或其他云身份验证服务之间进行选择。
迁移到 Microsoft Entra ID
要考虑的一个途径是将应用和服务直接与Microsoft Entra ID 集成。 Microsoft Entra ID 是 Microsoft 工作或学校帐户的基于云的标识提供者。 Microsoft Entra ID 是 Microsoft 365、Azure 等的标识提供者。 它提供与访问控制类似的联合身份验证功能，但并不支持所有访问控制功能。
一个主要的例子是与社交标识提供者（如 Facebook、Google 和 Yahoo）联合。 如果用户使用这些类型的凭据登录，则Microsoft Entra ID 不是适合你的解决方案。
Microsoft Entra ID 也不一定支持与 访问控制 完全相同的身份验证协议。 例如，尽管 访问控制 和 Microsoft Entra ID 都支持 OAuth，但每个实现之间存在细微的差异。 不同的实现要求在迁移过程中修改代码。
但是，Microsoft Entra ID 确实为访问控制客户提供一些潜在优势。 它本身支持云中托管的 Microsoft 工作或学校帐户，而访问控制客户常常使用这些帐户。
Microsoft Entra租户还可以通过 AD FS 联合到一个或多个本地 Active Directory实例。 这样，应用便可对基于云的用户和本地托管的用户进行身份验证。 它还支持 WS 联合身份验证协议，这样可以相对简单地使用 WIF 与 Web 应用程序进行集成。
下表比较了与 Web 应用程序相关的访问控制功能与Microsoft Entra ID 中可用的功能。
概括而言，如果你允许用户仅使用其 Microsoft 工作或学校帐户登录，则Microsoft Entra ID 可能是迁移的最佳选择。
| 功能 | 访问控制支持 | Microsoft Entra ID 支持 |
|---|---|---|
| 帐户类型 | ||
| Microsoft 工作或学校帐户 | 支持 | 支持 |
| Windows Server Active Directory 和 ADFS 帐户 | - 通过与Microsoft Entra租户联合支持 - 支持（通过与 AD FS 直接联合） |
仅通过与Microsoft Entra租户联合支持 |
| 其他企业标识管理系统帐户 | - 可以通过与Microsoft Entra租户联合实现 - 支持（通过直接联合） |
可以通过与Microsoft Entra租户联合实现 |
| 供个人使用的 Microsoft 帐户 | 支持 | 通过 Microsoft Entra v2.0 OAuth 协议提供支持，但不支持任何其他协议 |
| Facebook、Google、Yahoo 帐户 | 支持 | 都不支持 |
| 协议和 SDK 兼容性 | ||
| WIF | 支持 | 支持，但说明有限 |
| WS-Federation | 支持 | 支持 |
| OAuth 2.0 | 支持草案 13 | 支持最新规范 RFC 6749 |
| WS-Trust | 支持 | 不支持 |
| 令牌格式 | ||
| JWT | 支持 beta 版本 | 支持 |
| SAML 1.1 | 支持 | 预览 |
| SAML 2.0 | 支持 | 支持 |
| SWT | 支持 | 不支持 |
| 自定义 | ||
| 可自定义的主页领域发现/帐户选取 UI | 可以合并到应用的可下载代码 | 不支持 |
| 上传自定义令牌签名证书 | 支持 | 支持 |
| 自定义令牌中的声明 | - 传递标识提供者提供的输入声明 - 以声明形式获取标识提供者提供的访问令牌 - 根据输入声明值颁发输出声明 - 颁发含常数值的输出声明 |
- 无法传递联合标识提供者提供的声明 - 无法以声明形式获取标识提供者提供的访问令牌 - 无法根据输入声明值颁发输出声明 - 可以颁发含常数值的输出声明 - 可以基于同步到Microsoft Entra ID 的用户的属性发出输出声明 |
| 自动化 | ||
| 自动执行配置和管理任务 | 支持（通过访问控制管理服务） | 使用 Microsoft Graph API 实现支持 |
如果确定Microsoft Entra ID 是应用程序和服务的最佳迁移路径，则应注意将应用与Microsoft Entra ID 集成的两种方法。
若要使用 WS-Federation 或 WIF 与Microsoft Entra ID 集成，建议遵循为非库应用程序配置联合单一登录中所述的方法。 本文涉及为基于 SAML 的单一登录配置Microsoft Entra ID，但也适用于配置 WS 联合身份验证。 遵循此方法需要Microsoft Entra ID P1 或 P2 许可证。 这种方法具有两个优势：
- 可以完全灵活地Microsoft Entra令牌自定义。 可以自定义Microsoft Entra ID 颁发的声明，以匹配访问控制颁发的声明。 尤其是用户 ID 或名称标识符声明。 若要在更改技术后继续为用户接收一致的用户 IDentifier，请确保Microsoft Entra ID 颁发的用户 ID 与 访问控制 颁发的用户 ID 匹配。
- 可以配置应用程序专属令牌签名证书，且由自己控制其生存期。
注意
此方法需要Microsoft Entra ID P1 或 P2 许可证。 如果你是访问控制客户，并且需要 Premium 许可证来设置应用程序的单一登录，请与我们联系。 我们很乐意为你提供开发人员许可证。
另一种方法是遵循此代码示例，其中有关如何设置 WS 联合身份验证的说明略有不同。 此代码示例不使用 WIF，而是使用 ASP.NET 4.5 OWIN 中间件。 但是，应用注册的说明对于使用 WIF 的应用有效，不需要Microsoft Entra ID P1 或 P2 许可证。
如果选择此方法，则需要了解Microsoft Entra ID 中的签名密钥滚动更新。 此方法使用全局签名密钥Microsoft Entra颁发令牌。 默认情况下，WIF 不会自动刷新签名密钥。 当Microsoft Entra ID 轮换其全局签名密钥时，WIF 实现需要准备好接受更改。 有关详细信息，请参阅有关在 Microsoft Entra ID 中签名密钥滚动更新的重要信息。
如果可以通过 OpenID Connect 或 OAuth 协议与 Microsoft Entra ID 集成，我们建议这样做。 我们在Microsoft Entra开发人员指南中提供了有关如何将 Microsoft Entra ID 集成到 Web 应用程序中的大量文档和指南。
迁移到 Azure Active Directory B2C
可以考虑的另一种途径是迁移到 Azure AD B2C。 Azure AD B2C 是类似于访问控制的云身份验证服务，可方便开发人员将身份验证和标识管理逻辑外包到云服务。 它是一项专为面向使用者的应用程序（最多有数百万名活跃用户）设计的付费服务（包含免费层和高级层）。
类似于访问控制，Azure AD B2C 最具吸引力的功能之一是，支持许多不同类型的帐户。 Azure AD B2C 允许用户使用其 Microsoft 帐户或 Facebook、Google、LinkedIn、GitHub、Yahoo 等帐户登录。 Azure AD B2C 还支持用户专门为应用程序创建的“本地帐户”或用户名和密码。 Azure AD B2C 还提供丰富扩展性，可用于自定义登录流。
但是，Azure AD B2C 支持的身份验证协议和令牌格式范围无法满足访问控制客户的全部需求。 也不能使用 Azure AD B2C 从标识提供者、Microsoft 或其他地方获取令牌和查询附加用户信息。
下表对与 Web 应用程序相关的访问控制功能和 Azure AD B2C 中提供的功能进行了比较。 粗略来看，如果应用面向使用者或支持许多不同类型的帐户，那么正确选择可能是迁移到 Azure AD B2C。
| 功能 | 访问控制支持 | Azure AD B2C 支持 |
|---|---|---|
| 帐户类型 | ||
| Microsoft 工作或学校帐户 | 支持 | 支持（通过自定义策略） |
| Windows Server Active Directory 和 ADFS 帐户 | 支持（通过使用 AD FS 进行直接联合） | 支持（通过使用自定义策略实现 SAML 联合） |
| 其他企业标识管理系统帐户 | 支持（通过使用 WS 联合身份验证进行直接联合） | 支持（通过使用自定义策略实现 SAML 联合） |
| 供个人使用的 Microsoft 帐户 | 支持 | 支持 |
| Facebook、Google、Yahoo 帐户 | 支持 | 本身支持 Facebook 和 Google，使用自定义策略通过 OpenID Connect 联合支持 Yahoo |
| 协议和 SDK 兼容性 | ||
| Windows Identity Foundation (WIF) | 支持 | 不支持 |
| WS-Federation | 支持 | 不支持 |
| OAuth 2.0 | 支持草案 13 | 支持最新规范 RFC 6749 |
| WS-Trust | 支持 | 不支持 |
| 令牌格式 | ||
| JWT | 支持 beta 版本 | 支持 |
| SAML 1.1 | 支持 | 不支持 |
| SAML 2.0 | 支持 | 不支持 |
| SWT | 支持 | 不支持 |
| 自定义 | ||
| 可自定义的主页领域发现/帐户选取 UI | 可以合并到应用的可下载代码 | 完全可自定义 UI（通过自定义 CSS） |
| 上传自定义令牌签名证书 | 支持 | 自定义签名密钥（而不是证书），支持（通过自定义策略） |
| 自定义令牌中的声明 | - 传递标识提供者提供的输入声明 - 以声明形式获取标识提供者提供的访问令牌 - 根据输入声明值颁发输出声明 - 颁发含常数值的输出声明 |
- 可传递标识提供者提供的声明；某些声明要求自定义政策 - 无法以声明形式获取标识提供者提供的访问令牌 - 可以通过自定义策略根据输入声明值颁发输出声明 - 可以通过自定义策略颁发含常数值的输出声明 |
| 自动化 | ||
| 自动执行配置和管理任务 | 支持（通过访问控制管理服务） | - 使拥 Microsoft Graph API 创建允许的用户 - 无法以编程方式创建 B2C 租户、应用程序或策略 |
如果确定 Azure AD B2C 是应用程序和服务的最佳迁移途径，请从以下资源着手：
迁移到 Ping 标识或 Auth0
在某些情况下，你可能会发现，Microsoft Entra ID 和 Azure AD B2C 不足以替换 Web 应用程序中访问控制而不进行重大代码更改。 一些常见示例可能包括：
- 通过结合利用 WIF 或 WS 联合身份验证和社交标识提供者（如 Google 或 Facebook）实现登录的 Web 应用程序。
- 通过 WS 联合身份验证协议执行与企业标识提供者的直接联合的 Web 应用程序。
- 需要将社交标识提供者（如 Google 或 Facebook）颁发的访问令牌用作访问控制颁发的令牌中的声明的 Web 应用程序。
- 具有Microsoft Entra ID 或 Azure AD B2C 的复杂令牌转换规则的 Web 应用程序无法重现。
- 具有后列特点的多租户 Web 应用程序：使用 ACS 集中管理与多种不同标识提供者的联合
在这些情况下，可能需要考虑将 Web 应用程序迁移到另一个云身份验证服务。 建议了解以下选项。 以下每个选项都提供了与访问控制类似的功能：
Auth0 是一种灵活的云标识服务，该服务创建了针对访问控制客户的高级迁移指南，并且几乎支持 ACS 所支持的所有功能。
Ping 标识提供两种类似于 ACS 的解决方案。 PingOne 是一种云标识服务，支持多种与 ACS 相同的功能，PingFederate 是一个类似的本地标识产品，可提供更大的灵活性。 若要深入了解如何使用这些产品，请参阅 Ping 的 ACS 停用指南。
使用 Ping 标识和 Auth0 是为了确保所有访问控制客户都拥有适用于其应用和服务的迁移途径，从而最大限度地减少从访问控制迁移所需的工作量。
使用主动身份验证的 Web 服务
对于通过访问控制颁发的令牌保护的 Web 服务，访问控制提供以下特性和功能：
- 可以在访问控制命名空间中注册一个或多个服务标识。 服务标识可用于请求令牌。
- 通过使用以下类型凭据，支持 OAuth WRAP 和 OAuth 2.0 草案 13 协议请求令牌：
- 为服务标识创建的简单密码
- 使用对称密钥或 X509 证书的签名 SWT
- 受信任的标识提供者（通常为 AD FS 实例）颁发的 SAML 令牌
- 支持以下令牌格式：JWT、SAML 1.1、SAML 2.0 和 SWT。
- 简单令牌转换规则。
访问控制中的服务标识通常用于实现服务器间身份验证。
迁移到 Microsoft Entra ID
对于此类身份验证流，建议迁移到Microsoft Entra ID。 Microsoft Entra ID 是 Microsoft 工作或学校帐户的基于云的标识提供者。 Microsoft Entra ID 是 Microsoft 365、Azure 等的标识提供者。
还可以使用 OAuth 客户端凭据授予Microsoft Entra实现Microsoft Entra ID 进行服务器到服务器身份验证。 下表将服务器到服务器身份验证中的访问控制功能与Microsoft Entra ID 中可用的功能进行比较。
| 功能 | 访问控制支持 | Microsoft Entra ID 支持 |
|---|---|---|
| 如何注册 Web 服务 | 在访问控制管理门户中创建信赖方 | 在Azure 门户中创建Microsoft Entra Web 应用程序 |
| 如何注册客户端 | 在访问控制管理门户中创建服务标识 | 在Azure 门户中创建另一个Microsoft Entra Web 应用程序 |
| 使用的协议 | - OAuth WRAP 协议 - OAuth 2.0 草案 13 客户端凭据授予 |
OAuth 2.0 客户端凭据授予 |
| 客户端身份验证方法 | - 简单密码 - 签名 SWT - 联合标识提供者提供的 SAML 令牌 |
- 简单密码 - 签名 JWT |
| 令牌格式 | - JWT - SAML 1.1 - SAML 2.0 - SWT |
仅 JWT |
| 令牌转换 | - 添加自定义声明 - 简单 if-then 声明颁发逻辑 |
添加自定义声明 |
| 自动执行配置和管理任务 | 支持（通过访问控制管理服务） | 使用 Microsoft Graph API 实现支持 |
若要了解如何实现服务器间方案，请参阅以下资源：
迁移到 Ping 标识或 Auth0
在某些情况下，你可能会发现，Microsoft Entra客户端凭据和 OAuth 授权实现不足以替换体系结构中的访问控制，而无需进行重大代码更改。 一些常见示例可能包括：
- 使用非 JWT 令牌格式的服务器间身份验证。
- 使用外部标识提供者提供的输入令牌的服务器间身份验证。
- 使用令牌转换规则的服务器到服务器身份验证，Microsoft Entra ID 无法重现。
在这些情况下，可能要考虑将 Web 应用程序迁移到另一个云身份验证服务。 建议了解以下选项。 以下每个选项都提供了与访问控制类似的功能：
Auth0 是一种灵活的云标识服务，该服务创建了针对访问控制客户的高级迁移指南，并且几乎支持 ACS 所支持的所有功能。
Ping Identity 提供了两种解决方案，这两种解决方案类似于 ACS。 PingOne 是一种云标识服务，支持多种与 ACS 相同的功能，PingFederate 是一个类似的本地标识产品，可提供更大的灵活性。 若要深入了解如何使用这些产品，请参阅 Ping 的 ACS 停用指南。
使用 Ping 标识和 Auth0 是为了确保所有访问控制客户都拥有适用于其应用和服务的迁移途径，从而最大限度地减少从访问控制迁移所需的工作量。
直通身份验证
对于使用任意令牌转换的直通身份验证，没有与 ACS 等价的 Microsoft 技术。 如果你的客户需要此身份验证，Auth0 可能是提供最接近的近似解决方案的服务。
问题、疑虑和反馈
许多访问控制客户在阅读本文后可能仍然无法确定出合适的迁移途径。 这些客户可能会需要一些帮助或指导，以便确定出合适的计划。 若要讨论迁移方案和相关问题，请在此页上发表评论。