我正在尝试将AKKA集成到在框架net46上使用ASP.NET Core构建的IoT应用程序中。我正在尝试寻找最佳方法，希望对这个问题提出任何意见，尽管时间太长了。基于Java和AKKA.NET的AKKA经验的两个评论都将是相关的。
简而言之，我需要AKKA.NET来从远程设备接收IoT消息并执行相当复杂的处理逻辑。
对于IoT通信，我们使用Azure IoT中心。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创建一个新的控制台应用程序，并使用AKKA.Remoting与ASP.NET应用程序和IoT消费者应用程序进行通信。这意味着所有参与者逻辑都将封装在一个隔离的控制台应用程序中。当然，AKKA.NET也将在ASP.NET应用程序和IoT消费者应用程序中被引用和利用，但仅用于发送远程消息。
解决方案2：直接在ASP.NET应用程序中使用AKKA.NET，并使用AKKA.Remoting与Iot使用者应用程序进行通信。这意味着ASP.NET应用程序将与Actor逻辑与基于控制器，await / asynch等的现有传统ASP.NET逻辑并排扩展。
解决方案3：与解决方案2相反，即在IoT消费者应用程序中直接使用AKKA.NET，并使用AKKA.Remoting与ASP.NET应用程序进行通信。
可能会有更多的变化，例如将AKKA.NET逻辑集成到ASP.NET和IoT消费者应用程序中，但是我不喜欢让参与者在不同的应用程序中运行的想法，至少在我所处的早期阶段不是如此。试图建立一个全新的基于参与者的全新实现。
这是我对解决方案1的论点：
我被告知，如果配置正确，AKKA.NET可以以最佳方式利用所有内核，而无需上下文切换。为了能够分析和优化配置，我更喜欢为AKKA.NET应用程序逻辑提供最简单的运行时环境。使AKKA.NET在Web容器中或已经使用线程和锁的控制台应用程序中运行，与运行除我的AKKA.NET actor之外的其他原始控制台应用程序相比，这看起来并不简单。
由于C＃中基于actor的逻辑与普通的过程/函数编程在根本上是不同的（并且更加费解），因此我希望将其封装在使用现有应用程序项目作为依赖项的单独项目中。通过这种方式，我希望以后的代码会更容易理解。
我计划运行计划的参与者来接管基于cron的处理。在我的ASP.NET应用程序内部执行此操作似乎很脆弱，因为基础结构可能会将应用程序置于睡眠状态。
如果某个时候我想扩大基于actor的处理，使用纯运行控制台的纯控制台应用程序进行扩展似乎比扩展ASP.NET应用程序节点或IoT消费者应用程序（这更简单，更透明）更透明。如果不引入细微的错误，甚至是不可能的。
我的首选始终是选择1之类的东西-使actor系统在ASP.NET内运行得非常稀薄，因此该Web应用程序仍然大部分只是“只是”一个Web应用程序。让您的实际角色在Topshelf服务中运行，该服务通过Akka.Remote从ASP.NET应用程序接收输入。
我已经在大规模生产中使用了此设置，并在移动分析和营销自动化SaaS应用程序中取得了巨大成功：http：//www.aaronstannard.com/markedup-akkadotnet/
我为什么喜欢这个？我可以将更改彼此独立地部署到任一服务，并且可以调整Topshelf服务以处理Chron作业之类的事情，而无需将其耦合到ASP.NET部署。这是松散耦合事物的好方法。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句