我浏览了这个博客Azure SF vs Docker，但它并没有完全回答我的疑问。 我有本地 Docker 数据中心，我想将 Azure SF 推送到其中。但我觉得 DDC 做的事情和 Service Fabric 完全一样。 我的想法很少。
它不提供的一些项目：
有人能告诉我什么时候应该选择 DDC 不提供的 SF。
【问题讨论】：
标签： azure azure-service-fabric docker-swarm service-fabric-on-premises docker-datacenter
如果您的应用程序环境由容器组成并且不打算改变它，那么您可能应该坚持使用 DDC。
Service Fabric (ASF) 提供的不仅仅是对容器的支持。事实上，在早期它甚至不支持容器。
AFS 的重点是提供一个平台，用于使用无状态服务、有状态服务和参与者构建基于微服务的应用程序。
DDC 不提供的东西：
有状态服务：有状态服务的好处是数据位于代码所在的位置，因此不再需要像 NoSQL 或关系数据库那样单独的数据存储。一个很大的好处是减少了延迟。所以换句话说，如果你有一个运行在一个容器中的前端，它连接到一个包含 MySQL 服务器的容器，你可以使用无状态和有状态服务的混合来替换它。
Actor 模型：Actor 模式是一种用于并发或分布式系统的计算模型，其中大量的 Actor 可以同时且彼此独立地执行。
在某些情况下，在 ASF 中使用容器只是暂时的，用于提升和转移现有软件并将其与 ASF 自己的服务模型相结合。在后期阶段，容器可以被 ASF 服务替换。
official docs 确实列出了一些场景，例如何时在 ASF 上运行容器：
IIS 提升和转移：如果您有想要继续使用的现有 ASP.NET MVC 应用程序，请将它们放在容器中，而不是将它们迁移到 ASP.NET Core。这些 ASP.NET MVC 应用程序依赖于 Internet 信息服务 (IIS)。您可以将这些应用程序从预先创建的 IIS 映像打包到容器映像中，并使用 Service Fabric 部署它们。有关 Windows 容器的信息，请参阅 Windows Server 上的容器映像。
混合容器和 Service Fabric 微服务：将现有容器映像用于部分应用程序。例如，您可以将 NGINX 容器用于应用程序的 Web 前端，将有状态服务用于更密集的后端计算。
减少“嘈杂邻居”服务的影响：您可以使用容器的资源治理能力来限制服务在主机上使用的资源。如果服务可能会消耗大量资源并影响其他服务的性能（例如长时间运行的类似查询的操作），请考虑将这些服务放入具有资源治理的容器中。
顺便说一句，在您引用的问答中，作为 Microsoft 产品的事实被认为是一个可能的劣势。对某些人来说可能仍然是，但微软已经宣布它将open source ASF。
【讨论】：