服务结构有状态服务-扩展而不分区？

Question

我计划通过三个步骤将现有的云整体式Restful Web API服务迁移到Service Fabric。 内存缓存（正在处理）已在我的云服务中大量使用。

步骤1）将云服务迁移到具有1个副本和单个分区的SF状态服务。 缓存代码保持原样。 不使用可靠收集。

步骤2） SF整体状态服务的水平扩展到5个副本和单个分区。 缓存代码已修改为使用可靠收集。

步骤3）将SF整体服务分解为微服务（无状态/有状态）

以上方法更清洁吗？ 有什么建议吗？ 有什么缺点吗？

有关步骤2）SF状态服务的水平扩展的更多信息

• 我不打算使用SF分区策略，因为我无法想到应用程序中的统一数据分布。
• 通过添加更多副本并且不使用SF状态服务进行分区，我只是使我的服务更加可靠（可用性）。 我的理解正确吗？
• 我将修改缓存代码以使用“可靠集合-字典”。 相同状态数据将在所有副本中可用。
• 我了解GET可以在任何副本上执行，但是需要在主副本上执行更新/写入吗？
• 如何在不分区的情况下扩展SF状态服务？

• 包括secondory在内的所有副本都可以侦听我的客户请求并响应吗？ GET将能够执行，PUT＆POST调用如何工作？

• 我是否应该在此步骤中使用外部缓存存储（Redis）而不是可靠的收集？ 使用无状态服务？

Answer 1

本文档很好地概述了用于扩展Service Fabric中特定工作负载的选项，以及一些有关何时使用它们的示例。

选项2（动态或预先创建更多服务实例）听起来像可以很好地映射到您的工作负载。 您决定使用自定义状态服务作为缓存还是使用外部存储取决于以下几件事：

• 主计算机中是否有足够的空间来存储缓存的数据
• 您的服务是否可以通过简单的缓存摆脱困境，还是需要其他缓存服务提供的更高级功能？
• 您的服务是否需要提高与Web层相同的一组节点中的缓存的性能，或者是否可以承受延迟方面的对远程服务的调用
• 您是否可以负担得起缓存服务的费用，或者是否要使用已经通过虚拟机付费的内存，计算和本地存储来赚钱。
• 是否真的要构建并运行自己的缓存

要回答您的其他一些问题：

• 是的，添加更多副本将增加可用性/可靠性，而不是规模。 实际上，这可能会对性能（写入）产生负面影响，因为必须将更改写入更多副本。
• 不能保证所有副本中的状态数据都是相同的，只是其中大部分是相同的。 某些中学甚至可以领先，这就是为什么不鼓励从中学读书的原因。
• 因此，对于您的下一个问题，建议始终对主数据库执行所有读写操作，以便您看到一致的仲裁提交数据。