问题标签 [service-fabric-on-premises]

有没有办法根本不告诉服务有关设置而只在应用程序级别提供它们？

我仍然对 servicefabric 配置的工作方式不满意。

据我所知，我必须在服务的 settings.xml 中指定所有可能的配置值。然后我可以覆盖应用程序的 ApplicationParameters 中的那些。根据文档，这看起来也适用于环境变量。

造成的复杂情况是，我们的配置在许多情况下用于对数组进行水合选项。

例如考虑json：

有2个数组；这是必要和有用的。为了在服务结构配置中表达这一点，它转换为：

虽然与结构化对象相比，翻译并不令人愉快，但它是完全可用的。

但是，如果我没有在服务中指定部分和参数，我似乎无法在应用程序中覆盖它们。因此，在这种情况下，我必须定义服务中每个策略的确切策略和组数，并且应用程序可以修改策略名称或组值，但不能修改策略总数或组总数。

有没有办法根本不告诉服务有关设置而只在应用程序级别提供它们？

如果不是，存在哪些替代方案可以使服务在我可能希望用于以不同方式提供这种类型的动态配置的应用程序中可重用？

可能有助于回答这个问题的难题的最后一部分是我正在使用一些预发布代码将服务结构设置转换为 Microsoft.Extensions.Configuration.IConfiguration。但是，这只是采用它找到的设置；这不是我遇到的覆盖问题的原因。

示例服务 Settings.xml：

示例应用程序 ApplicationManifest.xml：

示例应用程序 ApplicationParameters (Local.1Node.xml)：

示例应用程序 PublishProfiles (Local.1Node.xml)：

应该是不相关的，但是设置的示例消费：

从那时起，一切都按预期在 IConfiguration 对象中。

我收到了一条警告说有新版本的 Service Fabric 可用，但是当我尝试升级它时，该过程卡在节点 Rep_247 上的 PreUpgradeSafetyCheck。我试过 -Force 和 -ForceRestart 但没有帮助。

聚类图

我在我的微服务的前提下使用服务结构，我采用了使用动态端口的策略，但显然我认为我已经缩小了端口的范围，因为我已经达到了 25 个应用程序的限制，大约 340 个微服务在无形中. 并且在尝试上传新应用程序时，几乎所有服务都会出错。例如，如果您删除旧的应用程序，则出现错误的应用程序会上升并保持稳定。我已经在参数中增加了clustermanifest中的端口范围：ApplicationEndpoints但没有效果...

在构建服务结构时，package 命令在本地机器上运行文件，但在 TFS/VSTS 中作为构建步骤添加时会失败。我们正在使用 onPrem 构建代理。

dotnet msbuild DependentServices.sfproj /t:Package

它抛出错误：

该进程无法访问文件“D:\TFS BuildAgent\BuildAgent4_work\4\s\CommonLibraries\Model.dll”，因为它正被另一个进程使用。

我有一个由 18 个节点（9 个是种子节点）组成的本地 Service Fabric - 通过 gMSA Windows 安全性进行保护。集群代码版本 6.4.622.9590

不幸的是，我必须重建其中的 6 个节点（3 个种子节点）。他们都住在一个数据中心（集群跨越 3 个数据中心）。因此，我希望删除这 6 个节点，重建它们，然后重新添加它们。

根据MSDOC，添加/删除节点是通过配置升级执行的。注意：我最近已经使用这个过程来添加 12 个节点，所以很好地理解 SF 配置升级的概念。

不幸的是，在删除节点之前，我无法在此集群上进行任何配置升级 - 这是由于Start-ServiceFabricClusterConfigurationUpgradepowershell 命令报告的 ValidationExceptions：

• 如果我不将 6 个节点添加到“NodesToBeRemoved”部分，我会收到验证错误，即并非所有已删除的节点都在此字段中
• 如果我确实添加了 6 个节点，则会收到以下验证错误：

所以，我们被困住了！我也已经删除了节点状态，因此所有 6 个节点都处于“无效状态”。Get-ServiceFabricClusterConfiguration不返回这 6 个节点，但它们仍显示在 SF Explorer 中并列在集群清单 XML 文件中。

就可靠性水平而言——我很确定在 SF 中无法再改变这一点；即旧版本的 SF 允许您在配置文件中配置青铜/银/金，但在最近的版本中（+6.0？？） - 这是一个计算字段，由 SF 内部管理。无论如何 - 因为种子节点将从 9 个减少到 6 个，我怀疑内部计算的可靠性水平会下降（大概从黄金到白银）。

我还遇到过有人用来删除集群中的节点的黑客行为......但在我的场景中，节点仍然列在清单文件中......尽管如此，黑客和生产这两个词永远不应该相遇！

那么，如何让我们的生产集群摆脱这种情况呢？重建集群不是一种选择（这就是集群的全部原因......高可用性！）。

我们最近决定开始使用本地 Service Fabric，但遇到了“依赖”问题。

我们有几个来宾可执行文件，它们之间存在依赖关系，并且如果不重新启动它们所依赖的服务，则无法从它们所依赖的服务重新启动中恢复。

一个清楚的例子：

在下图中，服务 B 依赖于服务 A。如果服务 A 遇到意外错误并重新启动，服务 B 将进入“错误”状态（不会报告给结构）。这意味着服务 B 将报告一个正常的健康状态，尽管它处于错误状态。

我们正在考虑围绕这些方面的解决方案：

提出一个独立的服务来监控集群中所有副本/分区/应用程序的健康状态事件，并包含整个依赖树。

当一个服务的健康状态发生变化时，它会重新启动它的直接依赖关系，这将导致事件的多米诺骨牌效应->重新启动，直到整个子树被重置（如下面的事件->动作流程图所示）。

问题是 healthReport 事件不会在很短的时间间隔内发送（这意味着我的整个系统无法工作，我几分钟内都不知道）。我会监控健康状态，但我确实需要知道历史（即使状态现在是健康的，这并不意味着它之前没有处于错误状态）。

另一个问题是事件可以在任何服务级别（副本/分区）弹出，并且需要我汇总所有事件。

我真的很感激任何关于此事的帮助。我也完全愿意接受任何其他关于这个问题的建议，即使它完全是另一个方向。

我们有一些作为 Service Fabric 参与者创建的长期运行的作业。除了提醒之外，演员没有其他数据。当这些服务部署在本地集群中时，它们似乎可以毫无问题地激活。当我们将它们部署到运行 3 节点集群的服务器时，一些服务无法激活。我们没有看到节点中的内存利用率超过 50% 。但是，当我们添加 2 个节点并在 5 个节点上运行时，激活似乎工作正常。我们只使用 1 个分区和 1 个副本计数；所以想知道是否有一些设置会停止结构以激活更多服务。我们还增加了应用程序端口范围，但没有运气。

还需要注意的是，一个服务激活失败后；其他有状态的服务也变得不稳定。它们显示不健康分区的错误。集群还运行一些无状态服务，运行起来就像一个魅力。任何线索为什么演员的激活失败？

我正在建立一个集群。也许 2 取决于我能在这里得到什么样的答案。基本上我有 5 台服务器，我计划在每台服务器上设置 8 个节点，总共 40 个节点。我计划为外部 API 调用负载平衡其中的 5 个。这样做我需要控制该应用程序，使其仅在这 5 个节点上运行，并且我希望其他应用程序根据需要使用所有这些节点。那么我可以控制应用程序坚持到集群上的哪些特定节点吗？

我目前正在使用服务结构运行本地 3 节点集群。

我有一个有状态的服务，它有一个 .csv 文件，其中包含我的服务的复杂配置，我想打开一个 REST 端点来动态更新这个配置。

因此，为了同步状态，我可以使用可靠的字典序列化我的 csv 配置并保存它。

我不知道该怎么做是确保即使在电源短缺（定义为不可靠的操作）之后，配置也将被保存（因为 CSV 保存在工作目录中而不是图像中店铺）。

我考虑过在每次更新 CSV 时升级服务，但它似乎真的过分了，并且会导致提供多个应用程序版本。有没有标准的方法来支持这一点？

我正在寻找在本地托管的 ServiceFabric 中托管现有 ASP.NET Framework（不是.NET Core，也不是 ASP.NET Core）应用程序的选项。

我们在 IIS 中托管此类遗留应用程序，这是我认为的常见做法，我们正在考虑将它们迁移到本地 ServiceFabric 集群，而无需（或至少尽可能少地）修改。

我看到 Visual Studio 2017 SF 项目模板没有“旧 ASP.NET”，这让我认为如果完全支持的话，使用旧 ASP.NET 不是首选。我可以理解。

我知道可以将应用程序部署在带有 IIS 的容器中，例如使用 Windows IIS。

还有其他可能性吗？