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