Azure Service Fabric 是不是与 Docker 做同样的事情？

Posted 2023-03-27

【中文标题】Azure Service Fabric 是不是与 Docker 做同样的事情？

【英文标题】：Does Azure Service Fabric do the same thing as Docker?Azure Service Fabric 是否与 Docker 做同样的事情？

【发布时间】：2017-01-10 05:20:55

【问题描述】：

我的想法是，人们使用 Docker 是为了确保本地环境与生产环境相同，并且我可以不再考虑他们的应用程序在哪里物理运行，而平衡机制应该只是在那一刻将应用程序分配到最佳位置。

我 100% 是基于 Web 的，我将与我们的数据库一起迁移到云中，无法迁移的部分将无缝桥接，因此企业资源和云将成为一个子网。

所以我想知道，也许 Service Fabric 已经做了与 Docker 相同的事情，而且它提供了地址转换服务（fabric://，它对结构空间中的进程有点像 DNS）加上（对于一些）鼓励按需分配工人 - 巨大的可扩展性。

Service Fabric 能否成功替代 Docker？ 它是否获得了观众和接受？因为否则即使是最伟大的发明也会失败。

【参考方案1】：

这很令人困惑，因为 Docker（该公司）正试图在所有云中提出主张。

Docker Engine（大多数人称之为“Docker”）

是一种容器化技术。它可以给你 进程隔离 网络隔离 一致的应用环境

Docker Hub

是一个镜像注册表。它存储 Docker 映像，因此您可以将它们作为部署的一部分下载。

Docker Cloud

是 Docker 的编排系统。它可以给你 向上和向下扩展您的应用程序 将您的应用程序相互连接 CI 测试，与 Docker Hub 集成（这不是编排的一部分，只是它做的另一件事）

Service Fabric 是一个编排系统。它可以编排 Docker 容器，但如果您专门为 Fabric 构建，它也可以与您的服务更紧密地集成。 （Docker 完全不知道容器内运行的内容。）

因此，Service Fabric大部分可与 Docker Cloud 相媲美，但并不完全匹配。还有其他一些基于 Docker 的编排解决方案（Kubernetes 可能是最大的），还有其他基于云的微服务解决方案（Heroku 可能是最著名的）。

Service Fabric 的主要缺点是它是一项 Microsoft 技术，因此与运行 Docker 相比，您与 Azure 的关联程度更高。另一个是 Docker 有更广泛的选择来构建你的堆栈：我上面列出的所有三个 Docker 事物都至少有一个开源替代方案（这也是 Docker 的一大缺点，因为没有人会为您制定一份最佳实践文档）。

如果您喜欢 Microsoft，并且如果将系统拼凑在一起对您来说并不重要，那么 Service Fabric 应该是 Docker 生态系统的一个很好的替代品。 （而且你仍然可以在它下面运行 Docker 容器。）

【讨论】：

澄清几点：首先，Service Fabric 与底层托管服务提供商无关。你可以在 Azure 上运行它，你可以在 AWS 上运行它，你可以在 5 台笔记本电脑上运行它——没关系。有可用的 Azure 集成，但它始终是可选的。

@NathanielWaisbrot 我正在阅读有关 App Service Fabric 的信息，并且与 Azure 无关，您可以在 PREM、Amazon 或 Azure 上拥有集群，因此该说法不正确。

@Vaclav-Turecek Nathaniel 的评论帮助我深入了解了不同 Service Fabric 变体的命名，我希望官方文档能更好地解释它。我希望“Azure Service Fabric for Windows Server”（参考 azure.microsoft.com/en-in/updates/…）和 PaaS 平台 Azure Service Fabric 有更多不同的名称

与讨论相关，***.com/q/41756276/397817 询问有关在 Azure 以外的云平台上运行 Service Fabric

RE：“Service Fabric 的主要缺点是它是 Microsoft 技术，因此您将与 Azure 绑定”。这是不正确的：尽管它的名称中有 Azure，但 ServiceFabric 绝不与 Azure 绑定。我们正在将 ServiceFabric 部署到我们的 Windows 机器集群，甚至没有 Azure 帐户。

【参考方案2】：

Service Fabric 和 Docker 容器化的主要相似之处：

Docker 和 SF 都能够在 Linux 和 Windows 两种平台上从您的微服务实施中创建不可变的映像。 Docker 和 SF 都能够在 VM 集群中编排您的容器化应用程序。这些虚拟机可以在任何地方——公共云、私有云或您自己的数据中心。请注意，它们都与云平台无关，这意味着它们对任何云服务都没有很强的亲和力。因此，只要您不在微服务中使用任何特定于云的功能，就可以了。 Docker 和 SF 都能够展示编排平台的基本功能：服务发现、服务级别负载平衡、服务之间的网络级别隔离、故障转移处理和复制控制等。

Service Fabric 和 Docker 容器化的主要区别：

Docker 容器本质上是一个部署/打包结构。也就是说，作为服务实现的一部分，docker 并没有规定您在容器中打包的内容。它也不提供任何编程结构来实现您的服务类型。然而，Service Fabric 以基本类型/接口的形式提供编程构造，您的服务实现可以从它们开始以声明的特定种类的服务 - 有状态服务、无状态服务、虚拟参与者。 在 Docker 世界中，一切都是容器，即您的最小部署/编排单元是容器。因此，它不识别或支持单个进程。而在 SF 中，我们有一项规定，其中您从无状态/有状态服务派生的微服务可以作为一个流程进行编排和治理。但是，SF 也像 Docker 一样支持容器编排。此外，最新版本的 SF 允许将您的有状态/无状态服务打包在一个容器中。

考虑到上述事实，请注意，SF 与任何云提供商没有任何密切的关系。只要您能够创建具有所需平台的虚拟机，它就可以在任何公共云（Azure、AWS 或 GCP）上同样运行。

【参考方案3】：

根本没有可比性。使用服务结构，您可以获得运行状况监控、与结构的代码集成、日志记录、监控、负载平衡和其他智能功能。您的应用程序甚至可以执行关闭代码。 Service Fabric 不仅适用于 Microsoft 技术，甚至 docker 也可以驻留在 SF 中，rkt 或 Unix OS 也是如此。安全和网络功能（与网络应用程序一致）是另一个优势。可靠的收藏简直太棒了。并且为采用它的公司保证了更好的应用程序构建和性能的路线图（历史如此）。

这个问题非常支持“最伟大的发明”Docker。这种比较对 Docker 营销有好处，但没有人会取代 Docker 的 SF。 Docker 只是一个微小的操作系统副本（与服务、应用程序或智能无关）。 Docker 甚至与应用程序开发无关，这不是本意。只是人们开始发现需要隔离和分享。这就是 Docker 的全部意义所在。

【讨论】：

很遗憾看到这么少的人了解 Service Fabric“本机”的真正力量。如果您的应用程序全部基于 .Net 或 Java，您可以使用 Service Fabric SDK 构建功能极其强大的（微）服务环境，全面支持服务编排、负载平衡、健康探测甚至非常聪明的全状态服务，例如 Actors 和分布式集合。所以没有容器化和 Kubernetes/插件配置学习曲线。

@TedvanderVeen 我完全同意。在我看来，如果您是一家已经拥有“面向服务”架构的软件商店，并且想进入微服务/编排领域，那么 Service Fabric 是一个不错的选择。