本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 基于 SOAP 的 ASP.NET 网络服务 (ASMX)
当你将传统的 ASP.NET Web 服务 (ASMX) 现代化为 REST API 时 AWS，它可能有依赖的使用者无法同时升级，而且由于相关的风险，很可能不应该同时升级。下图描绘了一个 ASMX Web 服务，该服务有三个依赖的使用者。
由于这些使用者使用 SOAP 协议调用 ASMX 服务，因此用 REST API 替换 ASMX 服务会导致这些使用者中断。此外，在将系统从整体架构转换为微服务的同时，将 ASMX 服务重构为 REST API 很可能涉及重塑系统行为和域模型。这可能会给消费者带来额外的突破性变化。
为了保持与旧服务的向后兼容性，从而使系统可以逐步实现现代化，你可以实施strangler fig方法的指导。在 strangler fig 方法中，与重要遗留系统现代化相关的风险在一定程度上是通过用新系统逐步取代旧系统来管理的。
抽象分支是马丁·福勒（Martin Fowler）引入的另一种方法，它是实现勒死者无花果模式的有效技术。与 strangler fig 方法一样，抽象分支可以帮助工程师在必须更换主要功能或对其进行现代化改造时对系统进行渐进和渐进的更改。在这种方法中，在实现特定功能的代码和使用该功能的代码（即客户端代码）之间引入了一个抽象层。这个抽象层不一定是可以由具体类继承的抽象类型。相反，它可以是任何捕获消费者和提供者之间功能契约的实现。
对于基于 SOAP 的旧版 ASP.NET Web 服务，您可以通过一种受抽象技术分支启发的方法，通过保持兼容性，实现服务使用者从旧到新的逐步迁移。但是，基于 SOAP 的 ASP.NET Web 服务的方法使用委托而不是继承。通过重构传统的 ASMX 服务，将其实现委托给新的 REST API，可以实现与 ASMX 使用者的兼容。下图描述了将其实现委托给新的 REST API 的旧版 ASMX 服务。此委派允许服务使用者 3 升级到新的 REST API，而服务使用者 1 和 2 则独立升级。
ASMX 服务重构的性质取决于该服务的功能和非功能（跨功能）要求。在某些情况下，重构可能涉及从旧的身份验证和授权机制转换为新的身份验证和授权机制，将服务 ASMX 有效负载从 XML 转换为 JSON，然后使用转换后的有效负载调用 REST API。在更复杂的场景中，重构后的 ASMX 服务可能需要编排对多个 REST 的调用并保持状态。 APIs
将服务使用者从传统的 ASMX 服务迁移到现代化的 REST API 的过程会逐步进行，直到所有服务使用者都已更新为引用新 API 为止。下图描绘了完全现代化的状态，即所有服务使用者都引用 REST API，而 ASMX 服务由于不再需要而已停用。
## 示例架构
基于 SOAP 的 ASMX 服务的最终状态架构显示了所有使用现代化的 REST API 的服务使用者，从而导致了传统 ASMX Web 服务的停用。但是，这种模式的重点不是最终状态架构，而是在消费者升级期间迁移期间所需的临时状态架构。下图说明了这种临时状态。在这个临时架构中，服务使用者 1 和 2 仍在使用传统的 ASMX 服务，该服务已经过重构，将其实现委托给现代化的 REST API。重构后的 Windows 服务作为 Windows 容器部署在 Amazon ECS 中，跨三个可用区进行配置以实现高可用性，并通过应用程序负载均衡器进行访问。服务使用者 3 已更新，可以直接通过 API Gateway 使用新的 REST API。
