Question

我有三个当前作为Windows服务运行的.net程序。我们正在迁移到Service Fabric，我有几个问题。我们的目的是将服务迁移到StateFul服务，因为我们需要跟踪当前存储在app.config文件中的文件的位置，批处理大小等。因此，我们可以将代码从onTimer事件“提升并转移”到RunAsync，如以下stackoverflow问题中所述： How to Migrate Windows Service in Azure Service Fabric

但是我对这些服务有一些疑问。当然，使用SF的一部分是使应用程序处于可靠的环境中，以使这些应用程序尽可能保持可用，因此第一个问题是：

Should we only deploy the service to one node and use the reliable 
collection to maintain the state of the process should the node go down and 
have to be brought back up?  

Or, should we deploy the application to say 3 nodes and just have each 
application on their node check the reliable collection to see if another 
application is processing files and to wait? 
files?

应用程序将按确定的时间间隔“唤醒”并查看文件夹，如果文件夹中有任何文件，它将对其进行处理。这可能需要几秒钟到几分钟的时间。因此，如果其中的应用程序在三个节点上，则它们节点上的其他两个应用程序完全有可能醒来以处理文件。如果他们可以检查可靠的词典以查看应用程序的其他实例是否正在运行文件处理，则他们将等到下一次需要它们时使用。

我知道这很模糊，我正在寻找有关在多个节点还是在单个节点上启动应用程序的信息？

Answer 1

简而言之：全状态服务具有partitioned data。因此，您将至少有一个分区，并且可能有多个分区。对于每个分区，主要实例将启动并运行服务请求或进行工作。然后，对于每个主要实例，将有一些次要实例在原始事件失败时接管。更多信息here。

在服务的配置中，您指定分区数和副本数：

<Service Name="Processing">
<StatefulService ServiceTypeName="ProcessingType" TargetReplicaSetSize="[Processing_TargetReplicaSetSize]" MinReplicaSetSize="[Processing_MinReplicaSetSize]">
    <UniformInt64Partition PartitionCount="[Processing_PartitionCount]" LowKey="0" HighKey="25" />
</StatefulService>
</Service>

primairy和secundairy实例（副本）将分布在群集节点上，因此，例如，当运行primairy实例的节点发生故障时，另一个节点上的副本将接管。

除了我所描述的内容之外，还有更多其他内容，但这是所有内容的基本思想。

所以要回答您的问题：您应该在其他节点上指定足够的副本，以确保高可用性。

在Service Fabric中将Windows Service作为全状态服务运行

1 个答案: