Azure App Service 与 Azure Service Fabric [关闭]

Posted 2023-03-27

【中文标题】Azure App Service 与 Azure Service Fabric [关闭]

【英文标题】：Azure App Service vs Azure Service Fabric [closed]

【发布时间】：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/…

【参考方案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 应用托管平台时，请使用应用服务。

-根据文档