我有一个可以分解为多个通信服务的应用程序。我当前的实现是整体的，我想重新组织它，以便可以独立地部署、迭代和扩展各个组件。我发现使用 Azure 有两种方法可以实现此目的：
- Service Fabric 服务由一组通信微服务（无状态、Web-API 等）组成
- 在 http 端点相互调用的各个 Azure Web 应用程序/云服务的集合。
1比2有什么明显的优势吗？选择其中之一的任何经验法则也会非常有帮助。
我认为这个页面比较得很好：https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cloud-services-migration-differences/
我无法说得比这更好了。
确实没有经验法则。 Service Fabric 可能看起来更复杂，但提供了一些云服务/Web 应用程序不提供的功能。
快速摘要（取自提供的链接）：
Service Fabric 本身是一个在 Windows 或 Linux 上运行的应用程序平台层，而云服务是一个用于部署 Azure 托管 VM 并附加工作负载的系统。 Service Fabric 应用程序模型具有许多优点：
- 快速部署时间。创建虚拟机实例可能非常耗时。在 Service Fabric 中，VM 仅部署一次即可形成托管 Service Fabric 应用程序平台的集群。从那时起，应用程序包可以非常快速地部署到集群中。
- 高密度托管。在云服务中，辅助角色 VM 托管一个工作负载。在 Service Fabric 中，应用程序与运行它们的 VM 是分开的，这意味着您可以将大量应用程序部署到少量 VM，这可以降低大型部署的总体成本。
- Service Fabric 平台可以在拥有 Windows Server 或 Linux 计算机的任何地方运行，无论是 Azure 还是本地。该平台在底层基础设施上提供了一个抽象层，以便您的应用程序可以在不同的环境中运行。
- 分布式应用程序管理。 Service Fabric 是一个平台，不仅可以托管分布式应用程序，还可以独立于托管 VM 或计算机生命周期来帮助管理其生命周期。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
