我只是想找一些关于如何解决这个问题的标题的建议。
我目前有一个asp.net核心应用程序，它使用DDD模式支持实体框架，我们希望将其迁移到带有服务结构的微服务架构。
我知道演员可以持久化到磁盘和内存，但有没有人有任何经验将演员持久保存到外部存储器，如MSSQL？
之所以出现这种情况，是因为目前我们遇到了实体框架的并发问题，而且演员似乎很适合这种情况，因为它们是单线程和分布式的，但我似乎无法找到任何材料来暗示演员应该或可能由数据库持久性支持。
我们需要数据库（而不是有状态的actor）的唯一原因是SSRS链接到数据库以提供报告。
所以问题确实如此
任何帮助，指导或建议都非常感谢。
您可以通过编写IActorStateManager的自定义实现（不推荐，非常困难）将SQL用作后备存储，但您也可以从Actor访问数据库。您可以像在任何其他.NET（核心）项目中一样使用EFx（核心）。
不确定它是否会帮助解决你的并发问题，因为你可能会有很多Actors使用相同的数据库。仅使用单个Actor访问数据库可能会起作用，但它会成为系统中的瓶颈。
我建议您使用retry design pattern处理数据库中的并发问题。 （例如，通过使用像Polly这样的包），locking and row versioning。
您没有找到有关此方法的示例，因为Service Fabric中的actor的主要思想是使用平台的状态管理功能来为您处理。
该框架可以灵活地编写您自己的提供程序，但是比在另一个不像SF这样的平台上构建的像Akka.Net或Orleans这样的actor框架上工作会更难。
SF Actors有一个来自奥尔良的DNA，这是一个SF Actor被移植到的框架。
Orleans不提供数据平台，并且需要Storage Providers来处理持久性，对于SQL存储，您可以创建custom provider并将其注册到运行时并完成所有操作。他们已经有一个用于Azure表存储。
如果您仍然计划将状态存储在DB上，则可以选择其中一个解决方案，或者按照Loek的建议创建自定义提供程序，并将其基于从其他框架中获取的想法。
关于主要问题，您不必实际使用actor状态管理来解决并发问题，您可以使用它的隔离和通信方面来防止针对单个Item的并发操作（每个项目都是actor）和对项目数据的所有操作都应由actor本身处理。
但是，因为您正在使用外部持久性，所以没有什么能阻止其他actor，服务或外部系统更改actor状态，从技术上讲，它再次对并发性开放。如果您可以保证只有actor可以更改它，那么可能不是问题，例如Azure Azure您可以租用blob，只有租赁持有者可以更改它。
这是actor应该由actor封装和管理的原因之一，否则管理它的复杂性将泄漏到actor之外。