Azure 云服务迁移决策矩阵

本文提供了一个决策矩阵,可帮助评估当前基于云服务构建的 Azure 解决方案的迁移选项。 该矩阵比较了各种 Azure 平台技术,以帮助指导重新架构决策。

决策矩阵

条件/选项 Service Fabric Azure Functions Azure Web 应用 Azure 应用服务(容器应用、逻辑应用等) Azure Kubernetes 服务 (AKS) 虚拟机规模集 Azure 虚拟机
迁移复杂性 中等到高。 要求将角色的架构重构为有状态/无状态服务。 通常,状态管理和编排方面会有一个学习曲线。 低到中等。 最适合事件驱动的轻型任务。 如果应用程序不是为无服务器架构设计的,则需要进行大规模的返工。 低到中等。 通常类似于当前的 Web 角色结构。 几乎不需要返工。 低到中等。 迁移复杂性因服务而异,但迁移工具支持良好。 高。 容器化应用需要深入了解微服务和业务流程。 适中。 与云服务模型更趋相近,具有自动缩放功能,提供更轻松的迁移提升。 高。 迁移和转移可能更简单,但不会利用云原生带来的优势。
可伸缩性和性能 高。 专为复杂微服务设计,能够有效扩展有状态/无状态负载。 高。 基于事件的自动缩放,但可能会受到冷启动的影响。 中等到高。 内置缩放功能,但可能需要为高级方案手动配置。 高。 使用各种触发器(HTTP 请求、基于事件的计划)进行自动缩放。 非常高。 容器编排允许精细扩展和复原能力。 高。 基于指标的自动缩放,并具有预测性自动扩展能力。 有限。 可伸缩性取决于手动缩放和 VM 大小/配置。
控件和自定义 高。 完全控制服务业务流程和状态管理。 有限。 具有受限运行时环境和执行限制的托管服务。 适中。 具有某些配置选项的托管平台;对底层基础结构的控制更少。 适中。 与容器支持的 Web 应用相比,更具灵活性,但仍存在 PaaS 约束。 高。 对容器业务流程和运行时环境的最大控制。 高。 使用自动缩放策略控制 VM 配置、网络和负载均衡。 非常高。 完全控制 OS、中间件和运行时。
运营开销 适中。 需要管理群集运行状况、升级和有状态服务。 低。 托管服务抽象化基础结构,从而减少运营开销。 低。 Microsoft管理平台,尽管仍有一些特定于应用的问题。 低。 托管服务,所需的基础架构管理最少。 高。 需要深入的操作专业知识(监控、更新、网络等)。 适中。 自动处理实例缩放,但需要 VM 映像维护和更新。 高。 完全负责维护、修补和安全性。
生态系统集成 要点。 与 Azure 面向服务的生态系统很好地集成,但可能需要进一步配置。 要点。 与 Azure 的事件网格、逻辑应用和其他无服务器服务本地集成。 要点。 与 CI/CD、监控及其他 Azure 服务的顶级集成。 非常强大。 设计为与其他 Azure 服务协同工作,配置最少。 要点。 与现代 DevOps 工具配合使用,尽管集成复杂性随微服务的增加而增加。 要点。 与 Azure 负载均衡器、应用程序网关和 Azure Monitor 集成。 变量。 虽然集成是可能的,但通常需要进行更多的自定义开发。
用例适用性 特别适合需要精细化管理微服务的应用程序,包括状态服务。 最适合事件驱动的工作负载、批处理以及对延迟要求不高的情况。 非常适合采用标准请求/响应模型的 Web 应用和 API。 适用于将 Web、移动后端、集成逻辑和 API 方案组合在一起的混合工作负荷。 非常适合需要高可用性和可伸缩性的微服务和容器化工作负载。 非常适合具有可变负载模式和 IaaS 要求的无状态应用程序。 适用于需要最少更改但云优化较少的旧版应用程序。

其他注意事项

  • 传统系统与重构:
    如果您希望不仅仅是简单的迁移和重置,来实现架构现代化,选择如 Service Fabric、AKS,甚至是以 Functions 这种无服务器方法可能提供更好的长期收益,尽管初始架构重构的成本较高。

  • 技能集和团队专业知识:
    评估团队对微服务(Service Fabric、AKS)与无服务器或 PaaS(Web 应用、Functions)的熟悉程度。 培训和采用曲线可能会影响你的决定。

  • 成本影响:
    与管理自己的容器群集(AKS)或 VM 相比,托管服务(Functions,Web 应用)可能会降低运营成本,但定价模型(消耗实例与预留实例)可能会有很大差异。

  • 未来防护:
    考虑每个选项如何与长期产品策略保持一致。 例如,AKS 和容器化体系结构以其可移植性和轻松与 CI/CD 管道集成而广受欢迎。

  • 性能和延迟要求:
    某些工作负荷可能受益于 Service Fabric 或 AKS 提供的精细控制,而其他工作负载则可通过 Functions 或 Web 应用的易于使用和自动缩放功能得到很好的服务。


后续步骤

评估工作负荷:
确定解决方案的哪些组件最适合每个体系结构,请考虑计算绑定组件和有状态组件。

原型迁移:
考虑为前两个或三个选项构建概念证明。 这有助于发现不可预见的挑战,并更好地估计迁移复杂性。

成本效益分析:
不仅包括迁移工作量和运营开销,还包括长期优势,例如轻松更新、复原能力和可伸缩性。

利益干系人评审:
与团队和其他利益干系人共享决策矩阵,以获取反馈,并符合优先级。

查看迁移指南: