本文提供了一个决策矩阵,可帮助评估当前基于云服务构建的 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 应用的易于使用和自动缩放功能得到很好的服务。
后续步骤
评估工作负荷:
确定解决方案的哪些组件最适合每个体系结构,请考虑计算绑定组件和有状态组件。
原型迁移:
考虑为前两个或三个选项构建概念证明。 这有助于发现不可预见的挑战,并更好地估计迁移复杂性。
成本效益分析:
不仅包括迁移工作量和运营开销,还包括长期优势,例如轻松更新、复原能力和可伸缩性。
利益干系人评审:
与团队和其他利益干系人共享决策矩阵,以获取反馈,并符合优先级。
查看迁移指南:
- 全面的迁移指南 - 从 Azure 云服务迁移到 Service Fabric 的详细步骤和最佳做法
- Web 角色迁移示例 - 将 ASP.NET Web 角色迁移到 Service Fabric 无状态服务的完整示例
- 辅助角色迁移示例 - 将辅助角色后台处理转换为 Service Fabric 的详细指南
- 状态管理迁移示例 - 将应用程序状态管理迁移到 Service Fabric 的技术指南