问题描述
我有一个可以分解为多种通信服务的应用程序.我当前的实现是整体的,我想对其进行重组,以便可以部署,迭代,独立缩放各个组件.我看到两种使用Azure的方法:
I have a application that can be broken down into multiple communicating services. My current implementation is monolithic and I want to reorganize it so that individual components can be deployed,iterated upon, scaled independently. I see two ways to do this with Azure:
- 由一组通信微服务(无状态,web-api等)组成的Service Fabric服务
- 在http端点处相互调用的单个Azure Web Apps/云服务的集合.
1比2有明显的优势吗?选择任何一个的经验法则也将非常有帮助.
Are there any obvious advantages of 1 over 2? Any rule of thumb to chose one over the other would also be very helpful.
推荐答案
我认为此页可以很好地进行比较:"> https://docs.microsoft.com/zh-cn/azure/service-fabric/service-fabric-cloud-services-migration-differences /
I think this page compares it well: https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-cloud-services-migration-differences/
我无法比这更好地说明问题.
I can't tell it better than this.
实际上没有经验法则. Service Fabric似乎更复杂,但提供了Cloud Services/Web Apps无法提供的功能.
There is not really a rule of thumb. Service Fabric might seem more complex but offers some things that Cloud Services / Web Apps don't.
快速摘要(摘自提供的链接):
A quick summary (taken from the link provided):
Service Fabric本身是在Windows或Linux上运行的应用程序平台层,而Cloud Services是用于部署带有工作负载的Azure托管VM的系统. Service Fabric应用程序模型具有许多优点:
Service Fabric itself is an application platform layer that runs on Windows or Linux, whereas Cloud Services is a system for deploying Azure-managed VMs with workloads attached. The Service Fabric application model has a number of advantages:
- 快速部署时间.创建VM实例可能很耗时.在Service Fabric中,VM仅部署一次即可形成一个托管Service Fabric应用程序平台的群集.从那时起,可以非常快速地将应用程序包部署到群集中.
- 高密度托管.在Cloud Services中,辅助角色VM承载一个工作负载.在Service Fabric中,应用程序与运行它们的VM是分开的,这意味着您可以将大量应用程序部署到少量VM中,这可以降低大型部署的总体成本.
- Service Fabric平台可以在装有Windows Server或Linux计算机的任何地方运行,无论是Azure还是本地.该平台在基础架构上提供了一个抽象层,因此您的应用程序可以在不同的环境中运行.
- 分布式应用程序管理. Service Fabric是一个平台,不仅可以承载分布式应用程序,而且还可以独立于托管VM或计算机生命周期来帮助管理其生命周期.
这篇关于Service Fabric微服务的优势与Azure云服务/Web应用程序的集合的优势的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!