本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
其他考虑因素
到目前为止,我们已经讨论了使用 API Gateway 和 Windows 容器对旧版 ASP.NET 网络服务进行 AWS现代化改造。以下是需要考虑的其他一些注意事项:
-
安全性
-
重塑服务域
-
当有许多服务需要现代化时,排序 Web 服务升级
以下各节将讨论这些内容。
身份验证和授权
现代网络服务 APIs 通常使用基于令牌(JSON Web Token 或 JWT)的身份验证和授权标准,例如 2.0 OAuth 和 OpenID Connect,而传统的 ASP.NET 网络服务传统上依赖于 Windows Active Directory 域的基本身份验证或 Windows 集成的身份验证。作为最佳实践,如果新旧身份验证和授权方法不兼容,我们建议您在对 Web 服务进行现代化改造之前,先升级这些安全机制 AWS。尝试映射身份或尝试在新旧系统之间安全地传输安全状态可能不是一件容易的事,但可能会带来安全漏洞。
领域驱动型设计
在将整体分解为单个服务时,域驱动设计 (DDD) 是一种最佳实践,通常用于将系统建模为有凝聚力的业务领域。DDD 是一种通过将实现与不断演变的核心业务概念模型联系起来来开发满足复杂需求的软件的方法。其前提是将项目的主要重点放在核心领域和领域逻辑上,并将系统设计建立在反映业务的模型之上。如果您在对现有的单体应用程序进行现代化改造时使用 DDD,则需要从整体式应用程序的功能和用户流程向后推进。您可以将 DDD 与 Strangler 模式结合使用,以指导打破整体结构并确定要扼杀哪些服务的过程,因此被称为 “域驱动设计”。
临时州和目标州
在对多个 ASP.NET Web 服务进行现代化改造时 AWS,最好先定义所有服务现代化后的目标状态架构。但是,目标状态架构不一定是最终状态或最终状态,因为业务环境经常变化,系统目标状态应根据需要进行更新,以与业务目标保持一致。定义目标状态后,您可以从那里向后移动,定义逐步实现目标状态愿景的临时状态架构。你可以把这些临时状态架构想象成扼杀无花果树在遇到宿主树的大部分并吞没宿主树的大部分时向树上移动。临时状态架构通常会引入临时或重叠的结构,这些结构不会成为最终状态架构的一部分,以促进向目标状态的演变。基于 SOAP 的 ASP.NET Web 服务的现代化就是一个例子:暂时引入了基于 Windows 的容器,以弥合依赖传统服务的调用系统之间的差距,直到它们可以升级到新的 REST API。