问题标签 [service-fabric-stateful]

我对 Service Fabric 很陌生。

如果我打开状态管理器事务，并且在其中进行网络 I/O（非服务结构 Web 服务调用），则提交事务。想知道出现的问题，是否有更好的方法来使用 Service Fabric Reliable 服务？

我有一个有状态的服务，它将东西存储在一个 IReliableDictionary 中。部署到本地集群后，我重新启动了主节点以测试故障转移，但是，在我这样做之后，代码 StateManager.GetOrAddAsync>("MyDictionary") 会抛出 FabricNotPrimaryException，然后在以后的试验中会抛出 FabricObjectClosedException。我可以检查哪些内容来解决此问题？

每当我尝试为无状态服务解析端点时，我似乎不断收到“未找到服务”。我曾尝试使用服务分区解析器和服务代理，但它们都产生相同的结果。对 Service Fabric 是否有限制，或者我是否误解了应该如何使用无状态服务？我找不到任何说明任何一种方式的文件。

更详细地说明我正在尝试做的事情。我正在构建一个 Api 网关。Api Gateway 由 RegistryService 和 RoutingService 组成。

我有多个服务结构应用程序，其中一些具有使用 WebApi 和 Owin 的“前端”无状态服务。在启动时，这些服务将它们的路由注册到 RegistryService。

网关使用 Registryservices 来确定将请求定向到的服务。此时我正在尝试解决所述服务的端点，但没有这样做。但是，如果我将路由更改为有状态的后端服务，它可以正常工作。

任何想法都会很有帮助

从 Service Fabric SDK 2.0.135 升级到 2.3.301 后，我们开始遇到无法访问 Service Fabric 参与者或服务（尽管在 Service Fabric Explorer 中显示为正常）的情况。一旦处于此状态，任何通过 ActorProxy 或 ServiceProxy 对参与者或服务的调用都将挂起 5 分钟，然后最终给出 TimeoutException。一旦处于这种状态，actor 或服务永远不会自行恢复——即使离开一个小时也是如此。唯一的解决方案是重置参与者或服务所在的节点，重新部署参与者或服务（完全相同的 EXE），重置整个集群或重新启动所有集群机器。

它通常在部署或重新部署 SF 应用程序后进入此状态。

在使用 Service Fabric 的最后一年（自 SDK v1.3 起），我们从未遇到过这个问题。它只是在移动到 2.3.301 后才开始。

它似乎随机且不一致地发生。我们的解决方案中的 13 个 SF 应用程序中的哪一个受到影响也是随机的。

有人对我们如何解决这个问题有任何想法吗？这似乎是最新版本的 Service Fabric 中的一个错误，但也许我们做错了什么。

任何帮助表示赞赏。

下面是很多额外的信息，我希望它们有助于理解我们在这个问题上所面临的问题。

非常感谢

脚步

我真的没有步骤来始终如一地重现该问题。这只是我有时观察到的。

1. 我从 Visual Studio 编译然后重新部署了我的 SF 项目（调试-> 不调试就开始）
2. Visual Studio 表示已成功部署项目
3. Service Fabric Explorer 将我的所有服务都显示为运行状况良好，包括数据绑定
4. 有问题的 SF 项目有 2 个演员，它们是单个 EXE 的一部分。Service Fabric Explorer 显示了在不同节点上运行的每个参与者。
5. Windows 任务管理器显示 EXE 的两个运行副本，这是有道理的，因为有两个节点运行 EXE。

同样，我们的 QA 在直接使用 PowerShell 部署到 Azure 后遇到了这个问题。（他没有从 Visual Studio 部署。）

回顾一下

• Visual Studio 说部署成功
• Service Fabric Explorer 显示一切正常
• 任务管理器显示 EXE 的两个运行副本

当我看到失败

我有一个 SF 服务使用 ServiceProxy 或 ActorProxy 类调用另一个 SF 服务。我们在整个解决方案中结合了 13 个不同的应用程序和大约 25 个不同的服务和参与者来做到这一点。自 2015 年 11 月我们开始使用 Service Fabric SDK v1.3 以来，它一直运行良好。

现在，在升级到 2.3.301 之后，我们会周期性地出现随机 Actor 或 Service 进入无法响应从 ServiceProxy 或 ActorProxy 调用的方法的状态。挂起 5 分钟后，我们收到带有以下消息的 System.Timeout 异常：

如果在服务繁忙或其长时间运行的操作并且花费的时间超过配置的操作超时时丢弃消息，则可能会发生这种情况。

请注意，该服务不忙，也没有执行长时间运行的操作。作为参与者，该服务根本不做任何持续的操作。它只是公开了其他服务可以使用的公共方法。它从第一次调用就失败了。

事实上，跟踪告诉我们，即使是actor中方法的第一行也永远不会被调用。就好像 Service Fabric 通信基础结构无法传递消息一样。

什么时候开始

在过去的 12 个月里，我们从未见过这个问题。

现在，自上周升级 Service Fabric 以来，我们经常在各种情况下看到此问题。

我们升级到 Service Fabric SDK 2.3.301.9590 和 Service Fabric 5.3.301.9590。

起初，团队中的每个开发人员都独立遇到了这个问题，并且每个人都认为这只是我们机器的暂时性问题。Service Fabric 确实存在一些问题，因此我们只是接受这一点并继续前进。但后来我们开始互相抱怨，并意识到我们都看到了。甚至我们的质量保证人员也在我们即将投入生产的环境中的云中看到它。

同样，这只是在我们上周升级到最新版本的 Service Fabric 时才开始的。

以前，我们运行的是 Service Fabric SDK 2.0.135。

我们通过安装 SDK v 2.3.301 升级了我们的代码库，打开了我们的每个解决方案并允许 Visual Studio 进行升级。

环境

我在具有 16 GB RAM 的 i7 上运行全新安装的 Windows 10 Enterprise（不到 2 周前安装）。我全新安装了 Visual Studio 2015 Update 3 和 SF 2.3.301.9590。我把所有东西都安装干净了。没有升级。

这也发生在我所有同事的机器上（不同年龄、配置和“新鲜度”）。它偶尔发生在我们每个人身上。

最关键的是，这也发生在 Azure 上的 Service Fabric VM 上。这些是我们的 QA 大约一个月前使用 Azure 上的 Service Fabric VM 的标准模板创建的机器。它预装了 5.3.301.9590。他没有手动安装任何 Service Fabric 更新。直到开发人员升级到新版本之后，我们基于 SF 的应用程序才在 Azure（或我们自己的开发机器）上遇到这个问题。

这不是我的机器，也不是孤立于开发环境。对我们所有人来说，唯一一致的变化是 SF 版本的更新。

原因

我们不知道是什么原因造成的。

它通常在部署新的 SF 应用程序后立即发生。是的，我们确实会等待 SF 在部署后“自行解决”通常需要 2 或 3 分钟。我们已经离开了一个小时或更长时间，但它永远不会起作用。

有趣的是，我认为我有一个运行良好的 SF 服务，然后突然停止工作，但这是在我们意识到存在问题之前，所以我没有在寻找它。我不能确定。

变通办法

一旦我们的 SF 服务处于“不可访问”状态，Service Fabric 将不会再次退出该状态。该应用程序完全无法使用。随着不同程度的成功，我们做了以下工作：

• 重新部署无法访问的 SF 应用程序
• 重新启动托管不可访问的 SF 服务和参与者的节点（通过 Service Fabric Explorer 转到节点，单击省略号按钮并单击“重新启动”选项）
• 重新启动整个 SF 集群（停止然后启动）
• 重启所有运行 SF 节点的机器
• 重置整个集群并重新部署所有东西（最后的手段，但有必要几次）

有趣的是，使用任务管理器杀死有问题的进程也无济于事。如果我终止了有问题的进程，Service Fabric 会重新启动它（如预期的那样），但它仍然不会响应消息。

因此，问题似乎出在 Service Fabric 本身，而不是 EXE。

当然，这些根本不是“解决方案”，因为它们使我们的整个应用程序无法访问，直到 SF 可以重新启动/重新平衡。即使重新启动一些节点也会使一堆东西脱机。

从本质上讲，这对我们来说是一个阻碍。我们不可能将我们的应用程序投入生产（甚至是测试版），因为 Service Fabric 的行为是这样的。

使用 Service Proxy 或 Actor Proxy 时的 C# 异常：

ActorProxy 或 ServicePRoxy 抛出的异常的 JSON 渲染

这是 Service Fabric 信息的 JSON 呈现：

重新部署时的事件查看器日志

Windows 事件查看器确实在“应用程序和服务日志 -> Microsoft-Service Fabric -> 管理员”下显示了一些值得注意的日志。

以下日志在我重新部署应用程序的更新版本时发生（请注意，DataBinding.exe 是包含我的两个 SF 演员的 EXE 的名称）：

事件查看器超时时记录

一旦服务处于不可访问状态，尝试调用它会在每个请求上产生以下日志（等待 5 分钟后）：

我正在编写一个托管在 Service Fabric 中的有状态服务。该服务的工作是使用来自外部队列的消息，转换它们并将它们放置到我们自己的消息传递系统中。根据供应商文档，吞吐量可以达到 6k 消息/秒。

我已将服务配置为多个分区以分散消息负载，每个分区都有最少 2/最多 3 个副本。为了从故障中恢复，我可以订阅供应商队列并传入我希望接收消息的时间戳。为此，我将存储在服务状态下处理的最后一条消息的时间戳。由于消息量很大，我决定在计时器上“保存”（并允许下游消息的潜在重复）

这是时间调用的代码：

每次尝试持久化时，我都会在每个分区上收到“System.Fabric.FabricNotPrimaryException”错误。

我已经包含了重试策略（由 Polly Retry 提供），因为在类似的问题上有评论建议这样做。这没有任何效果，只是延长了报告错误之前的时间。

我是否误解了应该如何使用 SF 的一些基本内容？这对我来说似乎是一个简单的用例。

我在无状态服务中正确使用了 Asp.net 核心 DI，因为它基本上是一个带有控制器的普通 WebApi 应用程序。

我不知道如何在有状态服务中使用依赖注入。这是有状态服务的默认构造函数：

并在 Program.cs 中由

我想在有状态服务中使用这样的东西：

我已经在有状态服务的配置部分注册了它，但是如果我尝试使用上面的代码，我会遇到错误：

StatefulService 不包含采用 0 个参数的构造函数

如何让它发挥作用？

场景：有状态的 SF 服务将其状态存储在几个可靠的集合中。Statefull SF 可通过远程处理获得。

我是否需要在第一次使用之前“初始化”集合（通过调用 StateManager.GetOrAddAsync）？是否有助于降低对可靠集合的首次访问或不需要执行此步骤？

如果建议做这个初始化，什么时候做它合适的时间和地点？最合理的位置是在 RunAsync 中的无限循环之前，但是如果在集合初始化之前调用通过远程处理调用的方法怎么办？第一次远程调用（当集合将被初始化时）的性能是否会下降？

最后一件事->使用可靠集合时，可以在类中保存对集合的引用（例如，在某些实例启动期间，我将使用 StateManager.GetOrAddAsync 获取引用）并仅使用此引用，或者最好调用 StateManager.GetOrAddAsync在每次调用收集之前？

感谢您的回答！

尝试在服务结构集群中运行我的服务时，输出窗口显示

“应用程序 URL 未设置或不是 HTTP/HTTPS URL，因此浏览器不会对应用程序打开”。

我是否缺少配置步骤？

在可靠集合（特别是 IReliableDictionary）中，实现“常见”查询的一种方法是更新二级字典，该字典以特定方式在枚举中对键进行排序。对于大型数据集，我想避免在.

为了实现这一点，我想实现某种延续令牌，调用者可以在请求数据时提供给我。我目前正在通过首先生成一个有序枚举并返回前 n 个项目来实现这一点，其中 n = MAX_PAGE 大小。 延续本质上是 n 个项目列表中的最后一个键。下次调用者传入 continuation 令牌时，我会使用 filter 函数生成有序可枚举，指定 key 应该大于 continuation。

这有两个问题（我可以看到）：

1. 集合可能会在调用者第一次请求页面和后续请求之间发生变化。这一点，我不确定我是否可以避免，因为无论谁试图翻阅数据，都需要能够随时更新集合。
2. 我不确定如何使用过滤器功能。我假设由于开发人员可以过滤任何内容，因此GetEnumerableAsync() 方法必须在返回 enumerable 之前提供字典中的所有键。对于足够大的数据集，这似乎很慢。

有没有规定的方法来分页这样的数据？ 我开始觉得我可能会在我的一些用例中使用 Reliable Collections 找出错误的树。

我计划将 Service Fabric 用作我的 Web 应用程序的缓存工具。

在 Service Fabric 中，我有：

• 一个有状态的应用程序来存储我的缓存对象
• 一个无状态 WebAPI 应用程序，充当其他应用程序与有状态应用程序对话的端点。WebAPI 使用 OWIN 自托管。（见截图）

两者都在同一个集群中。无状态 WebAPI 将充当公开的端点。这个想法是让我的外部应用程序将 API 用于 GET/POST/DELETE 缓存到有状态应用程序。

我正在尝试使用 Windows 身份验证来保护 WebAPI（参见屏幕截图），因此只有我域中的用户才能调用 API。因为我没有使用 IIS，所以在 Service Fabric 中甚至可以使用此功能吗？我应该在 App.config 中包含其他内容吗？