举一个简单的例子：我有一个拥有1000000用户的服务，每个用户都有一些配置文件信息。我想使用actor来管理此配置文件信息上的CRUD操作。
在Project Orlean中，我的理解是每个用户有一个粒度，因此1000000个相同参与者类型的虚拟粒度（只有在使用时才会创建），每个粒度将管理存储在其状态中的单个用户的配置文件信息。随着我的用户数量的增长，谷物的数量也在增长。
在ServiceFabric中，如果我正确解释文档，它的工作方式会略有不同。我会有一个有状态的actor类型，它管理所有用户上的CRUD操作，为了可伸缩性，我会对actor进行分区，让每个分区负责用户数据的子集。考虑到分区选项，我看不出有什么明显的方法可以像Project Orleans那样细粒度地实现它。
我真的很喜欢奥尔良计划的方法。actor只是为单个用户处理数据，可伸缩性是显而易见的（更多的用户等于更多的粒度）。记忆模型也很简单：单个参与者通过其少量的状态按需获得水分。
服务结构的实现似乎会稍微复杂一些。每个参与者都要处理一组用户，为了实现可伸缩性，我必须提前决定应该制作多少个分区，因为以后无法修改。至于内存模型，每个参与者管理的数据量都会随着用户数量的增长而增长。
所以我的问题是：我的理解是否正确，即Service Fabric中的参与者只是比Project Orleans更粗糙？
更新
谢谢你的回答。我的错误是认为分区包含一个单独的参与者实例，该实例将包含并管理分区内所有参与者ID的状态。这是完全错误的。Michiel指出，一个分区包含多个参与者实例，每个参与者ID一个。因此，参与者可以用与Project Orleans中相同的方式实现。这现在更有意义了，谢谢。
使用API，您可以获得Actor实例（不必显式创建实例）：
var actor = ActorProxy.Create<IActorType>(new ActorId("some id"), "fabric:/application");
在奥尔良，你的谷物被分散在筒仓上，而不是把它们捆在隔板里。因此，如果奥尔良愿意，它可以将一个实例移动到不同的思洛。在服务结构中，这一切都是在分区级别上完成的。因此，分区中的所有实例都会一起移动。
我对Project Orleans了解不多，但我认为您可能混淆了Service Fabric中actor和actor类型的概念。
actor是actor类型的实例，这种关系类似于面向对象语言中的类和对象。
在您的情况下，用户只有一个actor类型，例如UserActor，但随后会有许多该类型的actor实例。这些actor实例是保持状态并进行分区和分布的实例。