每个 Service Fabric 实例的配置答案

【问题标题】：Configuration per Service Fabric Instance每个 Service Fabric 实例的配置
【发布时间】：2017-10-16 19:35:09
【问题描述】：

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

使用ServiceProxy.Create 随机访问分区（在我上面的尝试中）。

以下不涉及分区的解决方案：

基于每个实例的配置。 This post 在提出解决方案时没有提供太多帮助。每个实例独有的配置部分将是最理想的解决方案。
创建命名实例，并使用名称作为用户名（基本上将字符串附加到非分区实例）
按索引获取实例，并使用索引对共享只读字典获取用户名。
不知何故使用 InitializationData（参见 this post）来获取用户名字符串（如果 InitializationData 可以在每个实例中是唯一的）。

以上所有将解决我的问题。这些方法中的任何一种都可能吗？

编辑：我正在尝试创建的服务示例：

假设我们有一个 stackoverflow 问题服务（简称 SOQS）。为了这个例子，假设一个用户可以在任何时候连接到 stackoverflow 的 websocket。 SOQS 内部方法（发布到我的服务结构）有一种方法：GetQuestions()。每个 SOQS 都需要使用唯一的用户名/密码连接到 stackoverflow，当新问题通过 websocket 推送时，它们会添加到内部问题列表中。 SOQS 的GetQuestions() 方法（从我的服务结构内部调用）会给出相同的问题列表。然后我可以通过添加更多实例来进行负载平衡（只要我有更多的用户名/密码），然后可以分配我的结构内部的负载。我可以调用ServiceProxy.Create<SOQS>() 连接到随机实例以获取我的问题列表。

【问题讨论】：

标签： c# azure azure-service-fabric

【解决方案1】：

听起来您正在寻找一种服务类型，该服务类型具有多个参与者，每个参与者都有自己的配置。它们不会是具有唯一配置的同一服务的多个副本，而是作为单例的服务的一个（当然是副本）实例，以及每个实例的单独参与者。

作为一个例子，你可以让用户服务（猜测它是什么，因为你提到了用户名字符串）从一些外部存储机制中读取用户名列表和 longs，例如每个用于内部跟踪的实例 id。然后，该服务将为每个参与者创建一个具有自己的配置信息的参与者。然后，用户服务将成为与各个参与者进行消息传递的路由器。

【讨论】：

服务需要建立出站连续连接（连接到我无法控制的外部托管的另一个服务），每个连接都需要唯一的用户名/密码。然后每个服务将管理一个内部状态（无状态，如果实例崩溃它可以重建它的状态），但每个服务将提供相同的确切数据。我已经用服务应该如何工作的示例编辑了我的帖子。
这有帮助。我仍然认为它可能是连接到外部服务的参与者，有自己的配置，服务的单例实例仍然可能是传入 + 出站之间的代理。您将失去的可扩展性当然是拥有单例外部服务，但无论如何您最终都会陷入这种情况，不是吗？我的意思是，一些连接到您的服务的外部程序必须知道它们的索引、分区等才能获得端点，否则它们每个都必须有单独的预定端点。我会考虑的，我有个主意
我相信actor生命周期阻止通过actor的传出连接是一个可行的选择。如果需要不断 ping 演员以保持他们的生命。这似乎不是正确的方法。
好吧，Service Fabric 会自己创建和垃圾处理 Actor 的活动实例。演员的状态在服务结构中维护，即使演员被垃圾收集。所以激活一个已经被垃圾收集的actor让它恢复到它之前的状态。你会从你的持久性提供者那里为每个actor分配一个id（可以使用那个唯一的用户名），在服务中跟踪哪些是在使用。
greatwhitenorth 的回答也很好，但需要注意的是，您仍然需要一个单独的服务来处理要创建的其他服务的实例数量，直到您的持久性中的用户名总数。无论使用情况如何，这些服务都将始终处于活动状态，这与演员的工作方式相反。我想这部分取决于传入连接是否需要具有使用具有相同用户 ID 的相同实例的亲和力。

【解决方案2】：

我不完全确定这就是您要寻找的东西，但一种替代方法可能是创建一个额外的配置服务来为每个实例提供唯一的配置。在启动无状态服务时，您只需请求一个随机（或非随机）配置对象，例如 json 字符串，并在初始化期间引导服务。这样，您就不必弄乱分区，因为每个无状态实例都会触发它自己的 Startup.cs（或等效文件）。

【讨论】：