关于Service Fabric可以做什么以及如何使用，存在许多常见问题。 本文档包含其中的许多常见问题及其解答。
注意
建议使用 Azure Az PowerShell 模块与Azure交互。 若要开始，请参阅 Install Azure PowerShell。 若要了解如何迁移到 Az PowerShell 模块，请参阅 Migrate Azure PowerShell从 AzureRM 迁移到 Az。
群集设置和管理
如何回滚Service Fabric 集群证书？
在将任何升级回滚到您的应用程序之前，需要进行健康故障检测，以确保服务Fabric群集仲裁尚未提交更改；一旦提交，更改只能前滚。 如果因未监控到的破坏性证书更改导致问题，可能需要通过客户支持服务中的升级工程师来恢复群集。 Service Fabric的应用程序升级 应用应用程序升级参数，并提供零停机时间升级承诺。 按照建议的应用程序升级监视模式，更新域上的自动更新进度基于运行状况检查是否通过，如果更新默认服务失败，将自动回退。
如果群集仍在Resource Manager模板中使用经典证书指纹属性，建议将群集从证书指纹更改为公用名，以应用新式机密管理功能。
是否可以创建跨多个Azure区域或自己的数据中心的群集？
是的。
核心服务Fabric群集技术可用于合并世界上任何地方运行的计算机，只要它们相互建立网络连接。 然而，生成并运行这样的群集可能很复杂。
如果对此方案感兴趣，建议通过 Service Fabric GitHub 问题列表或支持代表联系以获取其他指导。 Service Fabric团队正在努力为此场景提供更多的明确性、指导和建议。
应考虑的一些事项：
- Azure中的Service Fabric群集资源和其所构建的虚拟机规模集都是区域性的。 这意味着在发生区域性故障时，可能会失去通过Azure Resource Manager或Azure门户管理群集的能力。 即使群集仍在运行，且你能够直接与其交互，也可能发生此情况。 此外，Azure目前不提供跨区域使用的单个虚拟网络的功能。 这意味着 Azure 中的多区域群集需要虚拟机规模集中每个 VM 的公共 IP 地址，或 Azure VPN 网关。 这些网络选择对成本、性能以及某种程度上的应用程序设计都有不同的影响，因此需要在选择此类环境前仔细分析和规划。
- 这些计算机的维护、管理和监视可能会变得复杂，尤其是在跨类型环境时，例如在不同云提供商之间或本地资源和Azure之间。 必须格外小心，确保在此类环境中运行生产工作负荷前，已了解群集和应用程序的升级、监视、管理和诊断。 如果已在Azure或自己的数据中心内解决这些问题，那么在构建或运行服务Fabric群集时，可能会应用这些相同的解决方案。
服务Fabric节点是否会自动接收 OS 更新？
现在，您可以使用虚拟机规模集自动 OS 映像更新这项正式推出的功能。
对于未在 Azure 中运行的群集，我们提供了一个应用程序来修补您 Service Fabric 节点下的操作系统。
是否可以在我的 SF 群集中使用大型虚拟机规模集？
简短解答 - 否。
详细解答 - 虽然大型虚拟机规模集允许将虚拟机规模集扩展到最多 1000 个 VM 实例，但这是通过使用放置组 (PG) 来实现的。 在 Service Fabric 中，容错域 (FD) 和升级域 (UD) 仅在放置组内是一致的，因为 Service Fabric 使用 FD 和 UD 来为您的服务副本/服务实例做出放置决策。 由于 FD 和 UD 仅在同一个放置组内可比较，因此 SF 无法使用它。 例如，如果 PG1 中的 VM1 具有一个 FD=0 的拓扑，并且 PG2 中的 VM9 具有一个 FD=4 的拓扑，这并不意味着 VM1 和 VM2 在两个不同的硬件机架上，因此在这种情况下 SF 无法使用 FD 值做出放置决策。
当前，大型虚拟机规模集还存在其他问题，例如缺少 level-4 负载均衡支持。 请参考有关大型规模集的详细信息
Service Fabric 群集的最小大小是多少？ 为何不能更小一点？
运行生产工作负荷的服务Fabric群集支持的最低大小为五个节点。 对于开发方案，我们支持一个节点（针对 Visual Studio 中的快速开发体验进行优化）和五个节点群集。
由于以下三个原因，我们要求生产群集至少包含五个节点：
- 即使没有用户服务正在运行，服务Fabric群集也会运行一组有状态系统服务，包括命名服务和故障转移管理器服务。 这些系统服务对于群集的正常运行至关重要。
- 我们始终为每个节点保留一个服务副本，因此，群集大小是某个服务（实际上是分区）可以包含的副本数上限。
- 由于群集升级至少会关闭一个节点，所以我们希望至少有一个额外的节点作为缓冲。因此，一个生产群集在满足最低要求外，最好至少多包含两个节点。 最低限度是如下面所述的系统服务法定人数大小。
我们希望该群集在两个节点同时发生故障时保持可用。 要使服务Fabric群集可用，系统服务必须可用。 跟踪哪些服务已部署到群集及其当前托管位置的有状态系统服务（如命名服务和故障转移管理器服务）依赖于强一致性。 这种强一致性反过来又取决于是否能够获得一个法定人数来更新这些服务的状态，其中，法定人数表示某个给定服务的严格多数副本 (N/2 + 1)。 因此，如果我们希望能够弹性应对两个节点同时丢失（系统服务的两个副本也会同时丢失）的情况，必须保证 ClusterSize - QuorumSize >= 2，这会将最小大小强制为 5。
请注意，在上面的论述中，我们假设每个节点有一个系统服务的副本，因此，法定人数的大小是根据群集中的节点数计算的。 但是，我们可以通过更改 TargetReplicaSetSize 来使仲裁大小小于 (N/2+1)，这可能会让人以为群集可以小于 5 个节点，并且仍然有 2 个节点超过仲裁大小。 例如，在 4 节点群集中，如果将 TargetReplicaSetSize 设置为 3，则基于 TargetReplicaSetSize 的仲裁大小为 (3/2 + 1) 或 2，因此 ClusterSize - QuorumSize = 4-2 >= 2。 但是，如果我们同时丢失了两个节点，无法保证系统服务会达到或超过仲裁。因为丢失的两个节点可能托管了两个副本，因此系统服务将发生仲裁丢失状态（只保留一个副本），这将导致系统不可用。
在了解这种背景的前提下，让我们探讨一些可能的群集配置：
单节点：此选项无法提供高可用性，因为出于任何原因丢失单个节点就意味着丢失整个群集。
双节点：在两个节点 (N = 2) 上部署的服务需要仲裁票数为 2 (2/2 + 1 = 2)。 丢失单个副本时，无法达成仲裁。 由于执行服务升级要求暂时关闭副本，因此这不是一个有用的配置。
三节点：使用三个节点 (N = 3)，创建仲裁的要求仍然是使用两个节点 (3/2 + 1 = 2)。 这意味着，即使丢失一个节点，也能继续保持仲裁，但若两个节点同时发生故障，将驱动系统服务进入仲裁丢失状态，并导致群集不可用。
四个节点：当有四个节点时 (N = 4)，创建仲裁所需的最少节点数量是三个 (4/2 + 1 = 3)。 这意味着，即使丢失一个节点，也能继续保持仲裁，但若两个节点同时发生故障，将驱动系统服务进入仲裁丢失状态，并导致群集不可用。
五个节点：在包含五个节点的情况下 (N = 5)，创建仲裁仍需要三个节点 (5/2 + 1 = 3)。 这意味着，您可以同时丢失两个节点，但仍能维持系统服务的仲裁。
对于生产工作负荷，必须能够弹性应对至少两个节点同时发生故障的情况（例如，群集升级导致一个节点发生故障，其他原因导致一个节点发生故障），因此需要五个节点。
是否可以在夜间或周末关闭集群以节省成本？
一般来说，不。 服务Fabric将状态存储在本地临时磁盘上，这意味着如果虚拟机移动到其他主机，则数据不会随该主机一起移动。 在正常操作中，这是没有问题的，因为其他节点可使新节点保持最新状态。 但是，如果停止所有节点，又将它们重新启动，则很有可能大多数节点在新主机上启动，使得系统无法恢复。
如果你在部署应用程序之前想要创建群集来测试应用程序，我们建议将这些群集动态创建为持续集成/持续部署管道的一部分。
如何将操作系统（例如从 Windows Server 2012 升级到 Windows Server 2016）？
我们致力于改善体验，但现在升级由你负责。 必须升级群集虚拟机上的操作系统映像，一次升级一个 VM。
是否可以对群集节点类型（虚拟机规模集）中的附加数据磁盘进行加密？
是的。 有关详细信息，请参阅 创建包含附加数据磁盘的群集和用于虚拟机规模集的 Azure 磁盘加密。
在群集中运行防病毒程序时需要排除哪些目录和进程？
| 防病毒软件排除目录 |
|---|
| Program Files\Microsoft Service Fabric |
| FabricDataRoot（来自群集配置） |
| FabricLogRoot（从群集配置中） |
| 排除的防病毒进程 |
|---|
| Fabric.exe |
| FabricHost.exe |
| FabricInstallerService.exe |
| FabricSetup.exe |
| FabricDeployer.exe |
| ImageBuilder.exe |
| FabricGateway.exe |
| FabricDCA.exe |
| FabricFAS.exe |
| FabricUOS.exe |
| FabricRM.exe |
| FileStoreService.exe |
应用程序如何进行身份验证以访问 Key Vault 中的机密？
应用程序获取凭据以与 Key Vault 进行身份验证的方法如下：
A. 在应用程序生成/打包作业期间，可以将证书拉取到 SF 应用的数据包中，并使用它对Key Vault进行身份验证。 B. 对于启用了虚拟机规模集 MSI 的主机，您可以为 SF 应用开发一个简单的 PowerShell SetupEntryPoint，以便从 MSI 终结点获取访问令牌，然后从 Key Vault 检索机密。
是否可以将订阅转让给其他Microsoft Entra租户？
否。 在此情况下，您需要在订阅转移到其他 Microsoft Entra 租户后创建新的 Service Fabric 群集资源。
我是否可以在 Microsoft Entra 租户之间移动或迁移集群？
否。 此时，你需要在新的租户下创建一个新的服务结构群集资源。
我可以在订阅之间移动/迁移群集吗？
否。 此时，需要在新订阅下创建新的服务Fabric群集资源。
是否可以将我的群集或群集资源移动/迁移到其他资源组，或将它们重命名？
否。 此时，需要在新的资源组/名称下创建新的服务Fabric群集资源。
应用程序设计
跨 Reliable Collection 分区查询数据的最佳方法是什么？
Reliable Collections 通常已分区以支持扩展并提高性能和吞吐量。 这意味着，给定服务的状态可以分散在数十甚至数百台计算机上。 要针对整个数据集执行操作，可采用以下几种做法：
- 创建一个服务用于查询另一服务的所有分区，提取所需的数据。
- 创建一个可从另一服务的所有分区接收数据的服务。
- 定期将每个服务中的数据推送到外部存储。 此方法仅适用于要执行的查询不属于核心业务逻辑的情况，因为外部存储的数据会过时。
- 或者，将需要支持跨所有记录查询的数据直接存储在数据存储中，而不是可靠集合中。 这消除了过时数据带来的问题，但无法利用可靠集合的优势。
在我的参与者之间查询数据的最佳方法是什么？
执行组件在设计上是独立的状态和计算单元，因此不建议在运行时针对执行组件执行广泛查询。 如果需要跨整个参与者状态集进行查询，应考虑：
- 将您的 Actor 服务替换为有状态的可靠服务，使得收集所有数据的网络请求数量从演员（Actor）的数量变为您服务中的分区数量。
- 将执行组件设计为定期向外部存储推送其状态，以方便查询。 如前所述，仅当运行时行为不需要所执行的查询时，此方法才可行。
在 Reliable Collection 中可以存储多少数据？
Reliable Services 通常已分区，因此，可存储的数据量受到群集中计算机数目以及这些计算机上的可用内存量的限制。
例如，某个服务中的 Reliable Collection 包含 100 个分区和 3 个副本，存储平均大小为 1 KB 的对象。 现在，假设创建了一个由 10 台计算机构成的群集，其中每台计算机有 16GB 内存。 为简单起见，并保持保守，假设操作系统和系统服务、Service Fabric服务框架以及您的服务总共使用6gb，这样每台计算机剩余10gb可用，整个群集则有100gb可用。
请记住，每个对象必须存储三次（一个主体和两个副本），因此，在运转整个容量时，需要为集合中大约 3500 万个对象留出足够的内存。 但是，我们建议在故障域和升级域同时丢失的情况下保持弹性恢复能力（这会减少大约 1/3 的容量），并将对象数目减少到大约 2300 万个。
此计算还假设：
数据在各个分区中的分布大致均匀，或者您正在向集群资源管理器报告负载指标。 默认情况下，服务Fabric基于副本计数进行负载均衡。 在前面的示例中，群集中的每个节点上会放置 10 个主副本和 20 个辅助副本。 对于均匀分布在分区之间的负载而言，这是没有问题的。 如果负载不是偶数，则必须报告负载，以便Resource Manager可以将较小的副本打包在一起，并允许较大的副本在单个节点上占用更多内存。
在群集中，只有该可靠服务存储状态。 由于可将多个服务部署到群集，因此你需要知道每个服务运行时以及管理其状态时所需的资源。
群集本身没有扩大或缩小。 如果添加更多计算机，Service Fabric 会自动重新平衡副本实例，从而利用额外的容量，直到计算机数量超过服务中的分区数量，因为单个副本实例无法跨多个计算机。 相比之下，如果通过移除机器来减小群集大小，那么集群中的实例将被更紧密地部署，整体容量会减少。
在执行组件中可以存储多少数据？
与 Reliable Services 一样，在执行组件服务中可以存储的数据量仅受群集中节点上的总磁盘空间和可用内存量的限制。 但是，如果使用单个执行组件来封装少量的状态和关联的业务逻辑，则它们可以发挥最大的效率。 通常情况下，个体参与者的状态数据应该以千字节为单位进行测量。
Azure Service Fabric资源提供程序在何处存储客户数据？
Azure Service Fabric资源提供程序不会将客户数据移出其部署的区域。
其他问题
Service Fabric 与容器有何关联？
容器提供打包服务及其依赖项的简单方法，以便它们能够在所有环境中一致地运行并且可在单台计算机上以隔离方式运行。 Service Fabric 提供了一种用于部署和管理服务的方法，包括那些已打包在容器中的服务。
是否计划开放源代码服务Fabric？
我们已经在GitHub上开源了Service Fabric的部分组件（可靠的服务框架、可靠的Actors框架、ASP.NET Core集成库、Service Fabric Explorer 和 Service Fabric CLI），并接受社区为这些项目作出的贡献。
我们最近宣布我们计划开源Service Fabric运行时。 此时，我们使用 Linux 生成和测试工具在 GitHub 上拥有 Service Fabric 存储库，这意味着你可以克隆存储库、生成适用于 Linux 的服务Fabric、运行基本测试、打开问题和提交拉取请求。 我们正在努力将 Windows 构建环境迁移过去，与此同时还要迁移完整的 CI 环境。
关注 Service Fabric 博客以获取更多已公布的详细信息。