Azure App Service 与 Azure Service Fabric [关闭]答案

【问题标题】：Azure App Service vs Azure Service Fabric [closed]Azure App Service 与 Azure Service Fabric [关闭]
【发布时间】：2015-09-17 09:39:18
【问题描述】：

谁能告诉我什么时候应该创建 Azure Service Fabric 应用程序和 Azure App Service 应用程序？我有一个想要构建的应用程序，但无法确定是应该使用 Azure Service Fabric 还是 Azure App Service 来构建它。

【问题讨论】：

我认为没有明确的指南 - 这取决于您要建立什么以及您拥有什么样的团队。也许您可以分享其中的一些信息？
这是一个定制的企业项目管理应用程序，可以扩展到内容管理系统等等。它可以使用标准 API 和 Web 应用程序轻松构建，但我不确定我会放弃什么。从性能和开发的角度来看，我喜欢 Service Fabric 的可伸缩性。但是，如果我采用这种方法而不是应用服务方法，我不知道我会放弃什么。我所希望的是能够概述每种方法的优缺点的东西。你如何在两者之间做出选择？
您可能会发现这篇比较 Azure 应用服务、虚拟机、Service Fabric 和云服务的文章很有用 - docs.microsoft.com/en-us/azure/app-service-web/…

标签： azure azure-service-fabric azure-app-service-envrmnt

【解决方案1】：

很遗憾，没有关于何时使用什么的官方指导。它们是两个独立的平台，遵循不同的开发范式。

应用服务将为您提供 Service Fabric 未提供的现成功能。诸如自动缩放、身份验证、速率限制、与 SaaS 应用程序集成等内容。其中一些或所有这些东西可能会逐渐出现在 Service Fabric 中，但我想说的是，目前它们针对的是不同的受众——a经验不足的团队可能会发现使用应用服务更容易。

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

另外值得注意的是，没有什么能阻止您同时使用这两种范式 - 想象两个应用，其中至少一个是服务结构应用，它公开 API 和位于其之上的逻辑应用。

您的决定应基于您尝试构建的内容、要在多长时间内发布（Service Fabric 目前仅提供私人预览版，因此需要一段时间才能正式发布）和你有什么样的团队。我想，即使您没有经验丰富的团队，使用 App Service 也可以轻松上手，但 Service Fabric 将为您提供更多功能、灵活性和控制力。

【讨论】：

谢谢 Charisk，这绝对有帮助。我认为混合模式很有吸引力。我想为我的 Web 和 API 应用程序利用应用程序服务的简单性和附加功能，但我想使用服务结构构建系统的后端。我将深入了解如何做到这一点。希望有一种方法可以两全其美。 :)
这应该是首选答案。有趣的是，在很多情况下，第二个答案通常更好:-)
@Sardaukar 请注意，这个答案比接受的答案早 2 年。在那个时候，微软发布了这个问题的“官方”答案。虽然我不喜欢只是一个链接的答案，但接受的答案可能是最新和最相关的。感谢 OP 回来并接受它。

【解决方案2】：

Microsoft 创建了document，并与 Azure 应用服务、虚拟机、Service Fabric 和云服务进行了比较。此外，this decision tree 可能对您有所帮助。

【讨论】：

【解决方案3】：

App 服务是一种更托管的服务，SF 更多的是您自己管理，您也可以在自己的场所运行。 SF 更好地支持非 MS 堆栈开发，例如原生应用等。

正如该文档所述，“如果您要创建新应用或重写现有应用以使用微服务架构，Service Fabric 是一个不错的选择。”

如果您托管一些应用程序，您不应该关注 SF，另一方面，如果您部署超过 10 个服务，那么它会成为一个更好的解决方案。

另请注意，SF 具有包含在服务中的数据存储机制。擅长3件事 1）海量数据集群 2）简单的数据，通常在 Micros 服务中，数据库成为一个沉重的负担，因为每个服务都应该有自己的数据，而当你只有 1-3 个表时，像 SQL 这样的东西有点矫枉过正。 3) Actor 编程模型的状态存储。

我认为 SF 和 Web 应用程序将在未来分割“云服务”用户群。

【讨论】：

【解决方案4】：

如果（未来可能需要扩展应用程序 || 想要构建具有微服务架构的应用程序）选择 Azure Service Fabric

否则 Azure 应用服务还可以

【讨论】：

【解决方案5】：

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

当您需要一个完全托管的 Web 应用托管平台时，请使用应用服务。

-根据文档

【讨论】：