azure-service-fabric - Azure 服务结构是否为每个服务创建单独的进程

Question

假设有一个命名的应用程序在 Azure 服务结构集群上运行。这个命名的应用程序有 5 种不同的服务。

这些服务是在不同的进程中运行还是在同一个进程中运行？如果这些服务不是 .net 服务并且是可执行的呢？

Answer 1

guest EXE 始终拥有自己的进程。

否则，有两种托管模式可用:

Exclusive Process - 这个非常简单，所以让我们从这里开始。在这种模式下，一切 都有自己的进程。每个应用程序的每个服务实例的每个分区的每个副本都有自己的独占主机进程。这是我推荐的托管模式，因为它最简单，而且通常会带来更高的稳定性和更容易调试的服务。

Shared Process - 这变得有点复杂。在一个应用程序实例 中，所有相同服务类型 都共享一个主机进程。因此，例如，假设您有一个应用程序:

fabric:/myapp

在该应用程序中，您有两种服务类型:

service-type-1 (stateful)
service-type-2 (stateless)

现在假设您创建了一个 service-type-1 实例，每个分区有 5 个分区和 3 个副本:

fabric:/myapp/mystateFULservice1    (service-type-1)

这为您提供了 15 个副本。对于 5 节点集群，Service Fabric 默认会均匀分布，因此您会在每个节点上看到 3 个副本。在共享主机进程模型中，每个节点上的 3 个副本将共享一个主机进程。在该宿主进程中，每个副本都是派生自 StatefulService 的类的一个实例。马上，您就会明白这会变得多么复杂。我们使用 C# 构造来表示副本 - 每个副本都是一个 C# 对象。这意味着它们共享一个进程、地址空间，以及一切。如果其中一个副本抛出未处理的异常并导致进程崩溃，则其他副本也会随之崩溃。忘记使用静态变量吧!

现在假设您创建了一个实例数 = -1 的 service-type-2 实例:

fabric:/myapp/mystateLESSservice1

因为这是一种不同的服务类型，它将获得自己的宿主进程，与我们创建的第一个服务分开——它必须这样做，因为它确实运行不同的代码/DLL。这是无状态的，因此对于该服务实例 (fabric:/myapp/mystateLESSservice1)，每个节点只能获得一个副本。

现在，如果您创建 service-type-2 的另一个实例，实例数也为 -1:

fabric:/myapp/mystateLESSservice2

这是相同的服务类型，因此该服务实例将使用已经为该类型的前一个实例启动的主机进程，因为它们运行相同的代码/DLL。这类似于我们在有状态示例中看到的情况 - 每个服务实例实际上只是派生自 StatelessService 的类的一个实例，这当然有所有相同的问题。

最后，如果您创建一个全新的应用程序实例:

fabric:/myapp2

您会为该应用程序中的所有内容获得一套全新的流程。所以应用程序实例总是进程边界。

tl;dr:使用独占流程。