应采用哪些方法来确定 Azure Service Fabric 有状态 Actor 系统的正确 Actor 大小？
极端情况下，我可以理论上拥有恰好 1 个拥有所有状态的 actor，或者相反，使用一个 actor 来存储恰好 1 个字符串。显然这两种说法都是错误的。
对于单个参与者，如果测量数据的序列化大小，多少千字节会被视为小，多少兆字节会被视为大？比如10KB小，10MB大吗？
根据上述答案，假设 Actor 网络由“小” Actor 组成。小型网络与大型网络的构成是什么？再举个例子，100万是小还是10亿大？
我强烈希望对这些测量结果应用某种引用。但是，我无法从 Azure 文档中获取任何特定信息。如果尚未发布具体信息，我会接受处理与 ASF 不同的参与者网络实现的来源。
最佳答案
一般来说，参与者状态的原始大小不如其范围和访问模式更有趣。如果您将 Actor 用作其他组件需要访问各个部分的大量状态的“管理器”，那么当多个调用者尝试时，您很可能会被 Actor 模型的单线程性质所困扰。并行发出请求。另一方面，如果您有一个自然封装的参与者，需要利用大量状态来执行其任务，那么将所有状态存储在本地而不是发出一组网络请求可能会更有利。
如果您正在寻找非常粗略的经验法则，我希望大多数 Actor 状态以千字节为单位。如果您正在跨越兆字节阈值，则值得重新检查您的设计并确保您的参与者没有扮演经理或小型数据库角色，如果有可靠的服务/可靠的字典，这会更好。
关于Azure Service Fabric 如何调整参与者和网络的大小，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/38210307/