我有一个可以分解为多个通信服务的应用程序。我目前的实现是单一的，我想重新组织它，以便单个组件可以独立部署、迭代和扩展。我看到有两种方法可以在Azure中做到这一点:
- 服务由一组通信微服务(无状态、web-api等)组成的Fabric服务
- 在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上的应用程序平台层，而Cloud Services是一个用于部署带有负载的azure管理虚拟机的系统。Service Fabric应用程序模型有很多优点:
- 快速部署。创建虚拟机实例比较耗时。在Service Fabric中，虚拟机只部署一次，组成一个集群，用于承载Service Fabric应用平台。从那时起，应用程序包可以非常快速地部署到集群中。
- 高密度托管。在云服务中，一个Worker Role VM承载一个工作负载。在Service Fabric中，应用程序与运行它们的vm是分开的，这意味着您可以将大量应用程序部署到少量vm上，这可以降低大型部署的总体成本。
- Service Fabric平台可以在任何有Windows Server或Linux机器的地方运行，无论是Azure还是本地。该平台在底层基础设施之上提供了一个抽象层，因此您的应用程序可以在不同的环境中运行。
- 分布式应用程序管理。Service Fabric是一个平台，不仅可以托管分布式应用程序，还可以帮助管理它们独立于托管VM或机器生命周期的生命周期。
Peter做了一个很好的总结。以下是我的附加观点:
-
Cloud Service不是为微服务模式设计的，而Service Fabric是。如果你想享受微服务带来的好处，service Fabric是你最好的选择。使用云服务，如果你想把你的应用程序分离成自治的服务，你可以
- 创建多个云服务。这很难监控和管理，因为一组云服务没有统一的接口，云服务不是为这种模式设计的。
- 或者将多个角色添加到单个云服务中，这将导致a)云服务配置文件的膨胀，因为所有服务配置都在单个配置文件中;b)升级单个角色，最终需要重新部署整个云服务!
-
Cloud Service不支持跨区域/数据中心部署，而Service Fabric支持。这意味着您可以将数据中心级别的灾难恢复转换为正常的故障转移，由Service Fabric自动处理，参见此。