7

我有一个可以分解为多个通信服务的应用程序。我当前的实现是单片的，我想重新组织它，以便可以独立部署、迭代和扩展各个组件。我看到了两种使用 Azure 的方法：

  1. Service Fabric 服务由一组通信微服务（无状态、web-api 等）组成
  2. 在 http 端点相互调用的单个 Azure Web 应用程序/云服务的集合。

1比2有什么明显的优势吗？任何选择一个而不是另一个的经验法则也将非常有帮助。

4

2 回答 2

18

我认为这个页面比较好：https ://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-cloud-services-migration-differences/

我不能说比这更好了。

没有真正的经验法则。Service Fabric 可能看起来更复杂，但它提供了一些云服务/Web 应用程序没有的东西。

快速总结（取自提供的链接）：

Service Fabric 本身是一个在 Windows 或 Linux 上运行的应用程序平台层，而云服务是一个用于部署 Azure 管理的带有工作负载的 VM 的系统。Service Fabric 应用程序模型具有许多优点：

  • 快速部署时间。创建 VM 实例可能非常耗时。在 Service Fabric 中，仅部署一次 VM 即可形成托管 Service Fabric 应用程序平台的群集。从那时起，应用程序包可以非常快速地部署到集群中。
  • 高密度托管。在云服务中，工作角色 VM 承载一个工作负载。在 Service Fabric 中，应用程序与运行它们的 VM 是分开的，这意味着您可以将大量应用程序部署到少量 VM，这可以降低大型部署的总体成本。
  • Service Fabric 平台可以在任何拥有 Windows Server 或 Linux 计算机的地方运行，无论是 Azure 还是本地。该平台在底层基础架构上提供了一个抽象层，因此您的应用程序可以在不同的环境中运行。
  • 分布式应用管理。Service Fabric 是一个平台，它不仅可以托管分布式应用程序，还可以帮助管理其生命周期，而与托管 VM 或机器生命周期无关。
于 2016-10-19T18:54:55.640 回答
4

彼得做了一个很好的总结。以下是我的补充观点：

  1. 云服务不是为微服务模式设计的，而 Service Fabric 是。如果您想享受微服务带来的好处，Service Fabric 是您的最佳选择。使用云服务，如果您想将您的应用程序分离为自治服务，您要么

    • 创建多个云服务。由于一组云服务没有统一的接口，因此难以监控和管理，云服务不是为这种模式设计的。
    • 或者将多个角色添加到单个云服务中，这将导致 a) 云服务配置文件膨胀，因为所有服务配置都在单个配置文件中；b) 要升级单个角色，您最终会重新部署整个云服务！

  2. Cloud Service 不支持跨区域/DC 部署，而 Service Fabric 支持。这意味着您可以将 DC 级别的灾难恢复转变为由 Service Fabric 自动处理的正常故障转移，请参阅此。

于 2018-05-19T19:47:47.307 回答