Vaughn Vernon在此描述使用Actors作为DDD聚合: Vaughn Vernon on the Actor Model and Domain-Driven Design
考虑发票汇总: 是否使用Azure Service Fabric Actor的生命周期,以便1个Actor可用于保存仅1个Invoice的状态(例如标识为“ABC”),可靠存储表示该Invoice的状态。或者是某种Flyweight实现需要选择一个可用的Actor实例并在调用期间加载Invoice“ABC”的状态?
第一个选项似乎符合Actor的想法,但这意味着Fabric基础设施需要在设计时考虑到这一点,系统中的每个发票都有1个Actor(一个无限且毫无疑问非常大的数字)
答案 0 :(得分:1)
Service Fabric绝对是针对这种情况而设计的。您需要聪明地分区您的状态,以便可以容纳大量的参与者 - 您必须考虑数据的潜在大小,参与者的数量和节点的大小。
Service Fabric不支持(还有?)是一种自动重新分区服务的方法。因此,如果您从3个分区开始,并且在某些时候您意识到您需要更多分区,那么您需要自己处理。你需要做一些试验才能看到你需要多少个分区,但一般来说,建议你从大量分区开始。
值得阅读此https://azure.microsoft.com/en-gb/documentation/articles/service-fabric-concepts-partitioning/并查看评论。