问题标签 [service-fabric-stateful]

我有一个ReliableQueue<MyTask>被排入不同范围的队列，并且我正在将事务中的任务出列，然后想对每个任务运行一些长时间运行的计算。

这里的问题是，如果我的队列事务被中止，我不想丢失长计算的实例。它将继续在后台独立运行，我只想在我重试处理任务后检查它是否完成。

代码段：

我的担忧：我正在使用嵌套事务，不建议这样做。

如果我仅将事务用于ReliableQueue或ReliableDictionary单独使用，这里是否真的存在死锁的风险？

对于我想要实现的目标，是否有更好的设计？

是否可以在 Windows 10 计算机上运行 Service Fabric 应用程序的发布/生产版本？

我目前有一个由多个服务组成的 Service Fabric 应用程序。我想要实现的是一种排队机制，因此一个服务可以将消息发布到队列，而另一个服务可以从同一个队列接收消息。

以下不起作用（对于侦听器服务，没有什么可出队的）：

PublisherService：

ListenerService：

看起来队列的范围仅限于单个 Service。这似乎不是文档中指定的限制。

所以我的问题是：

• 这实际上是一些未记录的限制吗？
• 还是上面的代码有问题？
• 我怎样才能实现上述场景（一个服务将消息添加到队列中，另一个服务从同一个队列中检索消息）？

显然我可以使用 Azure 服务总线，但由于以下几个原因我不能：

• 在我实际的真实场景中，我将有几个队列（可变数量），因此需要按需创建服务总线队列（这并不是一个快速操作）
• 将依赖项添加到另一个 Azure 服务（因此增加了整个系统的故障概率）
• 花费更多
• 更复杂的部署
• 等等

我使用以下示例为我的 配置通信侦听器Stateful Service：

https://github.com/Microsoft/azure-docs/blob/master/articles/service-fabric/service-fabric-reliable-services-communication-webapi.md

相关片段：

服务清单片段：

现在，当部署我的应用程序时，我可以通过各种 guid 在 URL 上获得服务：

http://localhost:8090/ba794109-bba3-4cdf-8434-d718be264087/131407811483781446/614de30b-14a7-4172-a03d-4e28d23cf28d

如果我尝试http://localhost:8090/自行访问，则会收到错误503

有什么方法可以将通用 URL 映射到主分区和副本？或者在有状态服务中是不可能的？在 Stateless 中，您将开箱即用。

我正在用 C# 在 Service Fabric 之上实现 GRPC。GRPC 服务器需要一个 ServerPort（负责将 ssl 凭据绑定到端口）和一个服务定义（负责将路径上的请求映射到方法委托）。我创建了一个通信侦听器，它报告分区和副本 ID 以及 FQDN：端口。这允许客户端正确地确保其与正确的分区/副本通信。我在服务 mainifest 中声明了一个 Endpoint 资源，并将端口留空以表示我希望服务结构分配一个随机端口。我在本地开发中的问题（我还没有将它推送到天蓝色的集群中）是副本似乎死了，因为它们被分配了相同的端口。我还应该注意，我是在告诉侦听器侦听辅助副本。

我的问题是：

1. 服务结构如何选择一个端口来托管服务副本？
2. 次要副本的端口共享问题是否只是我物理上在同一台机器上的本地开发问题？（我假设真实集群中的副本将放置在不同的故障/升级域中）

当使用 VS2017 创建有状态解决方案时，生成标准样板代码，由此产生的两个项目具有两个不同的 MSBuild 版本。该应用程序使用 MSBuild 1.5.0 版。该服务使用 MSBuild 版本 1.6.0（当前的“最新”）。

如果我以这种方式运行解决方案，它在我的本地 Service Fabric 群集上运行良好。

但是当我使用 NuGet 将应用程序的 MSBuild 更新到 1.6.0 后（因此应用程序和服务器项目使用相同），就会出现以下错误。

Repair-ServiceFabricPartition 命令用于强制使分区脱离仲裁丢失。为了完成此任务，该命令究竟做了什么？

如果我有一个包含一个主副本和两个辅助副本的分区，并且该分区正在存储一堆状态。显然，辅助副本具有所有这些状态的副本。如果两个辅助副本由于某种原因出现故障，则我的分区处于仲裁丢失状态，并且不会执行写入。如果我使用此命令修复分区并使其摆脱仲裁损失，这会做什么？

Service Fabric 是否会启动两个全新的副本，然后将状态复制到它们？我假设如果是这种情况，那么在两个副本都启动并且该分区中的所有状态都已复制到至少一个辅助节点之前，它不会摆脱仲裁损失？

我想创建一个使用 Azure Service Fabric 和 ASP.NET Core 作为前端托管的服务。

如果我正确阅读了文档，那么这里似乎只有两个真正的选项来处理我的会话数据......

1 - 创建一个无状态服务，该服务使用 Azure SQL 等外部数据库来存储会话信息。然后我可以通过简单地增加实例数量来扩展，并让更多的服务跨节点运行。只要 Azure SQL 数据库能够应对负载，那么一切都很好。这很有吸引力，因为它易于理解和实施。但它有外部数据库的额外成本。

2 - 创建一个使用可靠集合（字典）来存储会话信息的有状态服务。我不想将我的会话拆分到多个分区上，因为这会带来额外的复杂性。但是对于单个分区，我只能拥有一个主服务器实例。这降低了拥有外部数据库的成本。但不能扩展到两个或更多服务器实例。

我对文档的阅读意味着您只能将一个主服务器用于有状态的服务分区。我说对了吗？如果我可以有更多的初选，那么有 100 个初选会很好吗？

我目前正在学习如何限制 Azure 服务的 CPU 负载。我基本上制造了一个分叉炸弹，并以限制 CPU 使用率为目标，为系统的其余部分留出一小部分。

我在资源治理策略中找到了“CpuPercent”值，但是我发布到集群后还没有看到效果。应用了同一行中的内存限制，但 CPU 使用率仍然飙升。我也可以将程序限制在一定数量的内核上，但这几乎不是我想要的，因为这会使处理器在正常运行期间有很大一部分空闲。

这是我的项目的 ApplicationManifest.xml：

这个“CpuPercent”打算如何使用？有文件吗？

我正在考虑在 Service Fabric 中存储新生成的 orderID。

• 要求：一秒通过1000个订单。

I. 如果需要性能，我应该存储这个可靠的字典吗？

二、有哪些性能注意事项？

三、什么是 Service Fabric 可靠收集容量

参考

可靠的服务可靠的集合

https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-services-reliable-collections

服务结构 dotnet 性能（无结果页面）

https://github.com/Azure-Samples/service-fabric-dotnet-performance/tree/master/ServiceLoadTest