我正在尝试将 AKKA 集成到使用框架 net46 上的 ASP.NET Core 构建的 IoT 应用程序中。我正在尝试找到最佳方法，并希望对这个问题发表任何评论，尽管它有点长。基于在 Java 和 AKKA.NET 中使用 AKKA 的经验的两条评论都将是相关的。
简而言之，我需要 AKKA.NET 从远程设备接收 IoT 消息并执行相当复杂的处理逻辑。
对于 IoT 通信，我们使用 Azure IoT-hub。IoT 消息由多线程控制台应用程序使用，遵循 Microsoft 此处的指南：
https://azure.microsoft.com/da-dk/documentation/articles/iot-hub-csharp-csharp-process-d2c/
同时，我们正在使用依赖注入和所有最新的最佳实践运行标准的 ASP.NET Core（框架 net46）应用程序。
我需要 AKKA.NET 来接管 IOT 消费者应用程序内部进行的部分处理，以及 ASP.NET 应用程序内部进行的部分处理。
我看到以下三个解决方案，我很好奇更有经验的 AKKA 开发人员会推荐这些解决方案。我自己的直觉是解决方案 1 是首选，请参阅下面的我自己的论点：
解决方案 1：基于 AKKA.NET 创建一个新的 Console 应用程序，并使用 AKKA.Remoting 与 ASP.NET 应用程序和 IoT 消费者应用程序进行通信。这意味着所有参与者逻辑都将封装在一个隔离的控制台应用程序中。当然，AKKA.NET 也将在 ASP.NET 应用程序和 IoT 消费者应用程序中被引用和使用，但仅用于发送远程消息。
解决方案 2：直接在 ASP.NET 应用程序中使用 AKKA.NET，并使用 AKKA.Remoting 与物联网消费者应用程序进行通信。这意味着 ASP.NET 应用程序将通过 Actor 逻辑与现有的基于控制器、等待/异步等的传统 ASP.NET 逻辑并排扩展。
解决方案 3：与解决方案 2 相反，即在 IoT 消费者应用程序中直接使用 AKKA.NET，并使用 AKKA.Remoting 与 ASP.NET 应用程序进行通信。
可能会有更多变化，例如在 ASP.NET 和 IoT 消费者应用程序中集成 AKKA.NET 逻辑，但我不喜欢让参与者在不同的应用程序中运行的想法，至少在我所处的早期阶段不喜欢试图建立一个干净的新的基于actor的实现。
以下是我对解决方案 1 的论点：
有人告诉我，如果配置正确，AKKA.NET 能够以最佳方式利用所有内核，而无需上下文切换。为了能够分析和优化配置，我更喜欢为 AKKA.NET 应用程序逻辑提供最简单的运行时环境。让 AKKA.NET 在 Web 容器内或已经使用线程和锁的控制台应用程序内运行，与只运行我的 AKKA.NET 演员的原始控制台应用程序相比，这似乎并不简单。
由于 C# 中基于 actor 的逻辑与普通的过程/函数式编程有根本的不同（而且稍微复杂一些），我喜欢将其封装在一个单独的项目中，使用现有的应用程序项目作为依赖项。通过这种方式，我希望以后代码会更容易理解。
我计划运行预定的演员来接管基于 cron 的处理。在我的 ASP.NET 应用程序中执行此操作似乎很脆弱，因为该应用程序可能会被基础结构带入睡眠状态。
如果在某些时候我想扩展基于actor的处理，使用仅运行actor的纯控制台应用程序进行扩展似乎比扩展ASP.NET应用程序节点或扩展我的物联网消费者应用程序（其中如果不引入细微的错误，甚至可能是不可能的）。