服务结构有状态服务 - 无需分区即可扩展？

Question

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

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

第 2 步） SF Monolithic 有状态服务水平扩展至 5 个副本和单个分区。缓存代码修改为使用可靠集合。

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

上述方法更干净吗？有什么推荐吗。？有什么缺点吗？

更多关于第 2 步）SF 有状态服务的水平扩展

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

• 所有副本（包括辅助副本）都可以监听我的客户端请求并做出相同的响应吗？ GET 应该能够执行，PUT 和 POST 调用如何工作？

• 在这一步我是否应该更喜欢使用外部缓存存储 (Redis) 而不是 Reliable 收集？使用无状态服务？

Answer 1

This document 很好地概述了在 Service Fabric 中扩展特定工作负载的选项以及您希望何时使用每个选项的一些示例。

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

• 您的主计算机中是否有空间来存储缓存数据
• 您的服务是否可以摆脱简单的缓存，或者它是否需要其他缓存服务提供的更高级功能
• 您的服务是否需要在与 Web 层相同的一组节点中提高缓存的性能，或者它是否有能力在延迟方面调用远程服务
• 您是否有能力为缓存服务付费，或者您是否希望使用已经为虚拟机付费的内存、计算和本地存储。
• 您是否真的想要构建和运行自己的缓存

回答您的其他一些问题：

• 是的，添加更多副本会提高可用性/可靠性，而不是扩展。事实上，它会对性能（写入）产生负面影响，因为必须将更改写入更多副本。
• 不能保证所有副本中的状态数据都相同，只是大多数副本。一些辅助节点甚至可能领先，这就是不鼓励从辅助节点读取数据的原因。
• 因此，对于您的下一个问题，建议始终针对主节点执行所有读取和写入操作，以便您看到一致的仲裁提交数据。