Azure 应用服务和 Azure 服务 Fabric 的区别

Question

Azure 应用服务和 Azure 服务 Fabric 的区别

azureazure-service-fabricazure-app-service-envrmnt

54

有没有什么资料可以帮我解释何时应创建 Azure Service Fabric 应用程序，何时应创建 Azure App Service 应用程序？我想构建一个应用程序，但无法确定是否应使用 Azure Service Fabric 还是 Azure App Service。

- StewartArmbrecht

我认为没有一个权威的指南 - 这取决于你想要构建什么以及你拥有什么样的团队。也许你可以分享一些这方面的信息？ - charisk

1

这是一个定制的企业项目管理应用程序，可以扩展为内容管理系统等更多功能。它可以使用标准API和Web应用程序轻松构建，但我不确定会失去什么。我喜欢Service Fabric的可扩展性，无论是从性能还是开发角度来看。然而，如果采用App Service方法，我不知道会失去什么。我希望有人能够概述每种方法的优缺点。你如何在两者之间做出决定？ - StewartArmbrecht

2

您可能会发现这篇文章对比Azure应用服务、虚拟机、服务织物和云服务非常有用-https://learn.microsoft.com/en-us/azure/app-service-web/choose-web-site-cloud-service-vm - mvark

5个回答

35

微软已经创建了这份文档，用于比较Azure应用服务、虚拟机、服务织物和云服务。此外，您可能会发现这个决策树很有帮助。

- ivamax9

我想知道价格差异有多大？以这个例子为例：我将一个单实例的Hello World网页部署到App Service上。然后，我比较在Service Fabric上执行相同操作的价格。 - Post Impatica

4

应用服务是一个更加管理的服务，而服务网格则更多需要你自己来管理并可以在本地运行。服务网格在非微软技术栈开发（如原生应用等）方面支持更好。

正如文档所述：“如果您正在创建新应用程序或重新编写现有应用程序以使用微服务体系结构，则服务网格是一个不错的选择。”

如果您只是托管几个应用程序，则无需考虑服务网格；但另一方面，如果您要部署超过10个服务，则服务网格会成为更好的解决方案。

同时，请注意服务网格具有包含在服务中的数据存储机制。它擅长于以下三个方面： 1）海量数据集群； 2）简单数据，通常在微服务数据库中，每个服务都应该有自己的数据，像SQL这样的东西对于只有1-3张表的情况有点大材小用； 3）Actor编程模型的状态存储。

我认为，在未来，服务网格和Web应用将分割“云服务”的用户群。

- user1496062

2

如果（应用程序可能在未来需要扩展或希望构建微服务架构的应用程序），请使用Azure Service Fabric。否则，Azure App Service就可以了。最初的回答：如果您的应用程序需要扩展或者希望构建微服务架构，请选择Azure Service Fabric。否则，可以选择Azure App Service。

- sameer prabhu

0

当您需要更多控制或直接访问基础架构时，请使用Service Fabric。

当您需要一个完全托管的托管平台来托管您的Web应用程序时，请使用App Service。

-根据文档

- Srinath

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- charisk · Accepted Answer

很遗憾没有官方指南说明何时使用哪种平台。它们是两个独立的平台，遵循不同的开发范例。

应用服务将为您提供 Service Fabric 不提供的功能。例如自动缩放、认证、速率限制、与 SaaS 应用程序集成等等。这些功能中的一些或全部可能会逐步引入到 Service Fabric 中，但我认为，目前它们面向的是不同的受众群体——一个经验不足的团队可能会发现使用应用服务更容易。

另一方面，Service Fabric 使部件组合更加容易。例如，在“传统”方法中，如果您有一个 API，可以访问数据存储并具有缓存以避免对数据存储造成压力，那么您必须处理各种容错方案。而在 Service Fabric 中，您的缓存可以位于可靠集合的 API 进程中，您无需处理外部缓存组件。数据与服务共存（检索/编辑更快！）并且可靠，因为它分布在服务部署到的所有节点上。队列也是类似的情况。如果考虑工作流类型系统，其中有一个 API、一个作业服务和一个队列位于它们之间，并允许它们进行通信，那么您必须管理 3 个不同的组件和它们之间的通信。而在 Service Fabric 中，队列进入应用程序。这还只是其中的一半 :) 您还可以使用 actor 模型进行分布式计算，无需处理通常有的并发问题。最后，在 Service Fabric 中，您可以获得在本地环境中更完整的开发环境的好处，您无需处理在 Azure 开发帐户或类似账户上创建队列等问题。

值得注意的是，没有什么阻止您同时使用这两种范例——想象两个应用程序，其中至少一个是 Service Fabric 应用程序，它们提供 API，以及一个位于其上的逻辑应用程序。

你的决策应该基于你想要构建什么，需要多长时间完成，何时发布（Service Fabric目前仅处于私人预览阶段，因此他们距离GA还有一段时间），以及你的团队类型。我想，即使你没有一个经验丰富的团队，使用App Service会很容易上手，但是Service Fabric将为你提供更多的动力，灵活性和控制。