服务结构有状态服务 - 无需分区进行扩展？

Question

我打算通过三个步骤将现有的云单片Restful Web API服务迁移到Service Fabric。 内存缓存（正在进行中）已在我的云服务中大量使用。

步骤1）使用1个副本和单个分区将云服务迁移到SF状态服务。缓存代码就是这样。没有使用可靠的集合。

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

步骤3）将SF单片服务细分为微服务（无状态/有状态）

上述方法是否更清洁？任何建议。？有什么缺点吗？

有关步骤2的详细信息）SF状态服务的水平缩放

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

• 包括secondory在内的所有副本都可以收听我的客户端请求并回复相同的内容吗？ GET应该能够执行，如何PUT＆amp; POST通话有效吗？

• 我是否更喜欢在此步骤中使用外部缓存存储（Redis）而不是Reliable集合？使用无状态服务？

Answer 1

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

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

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

回答其他一些问题：

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