每个 Service Fabric 实例的配置

3
我正在设计一个服务织物无状态服务,每个实例都需要配置数据。我的初始想法是创建命名分区,并使用PartitionInfo获取命名键,使用共享的只读字典来加载每个实例的设置。问题是,现在从内部访问这个实例(从其他服务)需要一个分区键。由于所有使用这种方法的分区在内部提供相同的数据,连接到哪个分区并不重要(我希望它是随机的)。因此,这给了我很多解决这个问题的可能方式:

以下解决方案不涉及分区:

  • 每个实例都有一个基于配置的设置。这篇文章没有太多帮助来提出一个解决方案。对于每个实例唯一的配置部分将是最理想的解决方案。
  • 创建命名实例,并使用名称作为用户名(基本上将字符串附加到未分区的实例)。
  • 通过索引获取实例,并使用该索引针对共享只读字典获取用户名。
  • 以某种方式使用InitializationData(请参见此贴文)来获取用户名字符串(如果InitializationData可以对每个实例进行唯一设置)。

以上所有方法都可以解决我的问题。这些方法中是否有任何可行的方法?

编辑:我正在尝试创建一个服务的示例:

假设我们有一个名为stackoverflow问题服务(简称SOQS)。为了举例说明,假设每个用户一次只能连接到stackoverflow的websocket。SOQS内部方法(发布到我的服务fabric)有一个方法:GetQuestions()。每个SOQS都需要使用唯一的用户名/密码连接到stackoverflow,并且当新问题通过websocket推送时,它们将添加到问题的内部列表中。 SOQS的GetQuestions()方法(从我的服务fabric内部调用)将提供相同的问题列表。然后我可以通过添加更多实例(只要我有更多的用户名/密码)来进行负载平衡,并且在我的fabric内部分配负载。我可以调用ServiceProxy.Create<SOQS>()来连接到随机实例以获取我的问题列表。

2个回答

2

我不确定这是否是你要找的,但另一种选择可能是创建一个额外的配置服务来为每个实例提供唯一的配置。在无状态服务启动时,您只需请求随机(或非随机)配置对象,例如JSON字符串,并在初始化期间引导服务即可。这样,您就不必处理分区,因为每个无状态实例都将启动自己的Startup.cs(或等效文件)。


2
似乎您需要的是具有多个演员且每个演员都有自己配置的服务类型。它们不会是具有唯一配置的相同服务的多个副本,而是作为单例的服务实例(当然有副本),以及每个实例的独立演员。
例如,您可以让用户服务(根据您提到的用户名字符串猜测)从某些外部存储机制中读取用户名和长整型实例ID列表,用于内部跟踪。然后该服务将为每个演员创建一个具有其自己配置信息的演员。然后用户服务将成为与各个演员之间的消息路由器。

服务需要建立连续的出站连接(到另一个托管在我控制范围之外的外部服务),每个连接都需要唯一的用户名/密码。然后,每个服务将管理内部状态(无状态,如果实例崩溃,则可以重建其状态),但每个服务将提供完全相同的数据。我已经编辑了我的帖子,并提供了服务应该如何工作的示例。 - Blue
那很有帮助。我仍然认为它可能是连接到外部服务的演员,拥有自己的配置,而服务的单例实例仍然可以是入站+出站之间的代理。当然,你会失去可扩展性,因为单例外部服务,但你几乎无论如何都会陷入那种情况,不是吗?我的意思是,连接到你的服务的某些外部程序必须知道它们的索引、分区等以获取端点,否则它们将必须具有单独的预定端点。我会考虑一下,我有一个想法。 - Eric Lizotte
我认为演员生命周期阻止了通过演员作为可行选项的外向连接。如果需要不断地ping演员以保持它们的活跃状态,这似乎不是正确的方法。 - Blue
服务布局自行创建和处理活动对象的实例。即使Actor被垃圾回收,其状态也仍在服务布局中保持。因此,激活一个已被垃圾回收的Actor会使其以先前的状态重新启动。您需要为每个Actor分配一个ID(可以使用唯一的用户名),并跟踪哪些ID正在使用。 - Eric Lizotte
greatwhitenorth的回答也很好,但需要注意的是,您仍然需要一个单独的服务来处理创建其他服务实例的数量,以达到持久性中用户名总数的要求。这些服务将始终处于活动状态,无论使用情况如何,有点类似于演员的工作方式的反向。我想这部分取决于传入连接是否需要具有使用相同用户ID的相同实例的亲和力。 - Eric Lizotte

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接