actor - 在功能即服务环境中使用面向参与者/代理的编程是否有意义？

Question

我想知道，是否可以在功能即服务环境（OpenWhisk、AWS Lambda）中应用代理/演员库（Akka、Orbit、Quasar、JADE、Reactors.io）？

是否有意义？

如果是的话，什么是最小示例帽子提供附加值（当我们仅使用 FaaS 或仅使用参与者/代理库时缺少）？

如果不是，那么我们是否能够构建决策图，这可以帮助我们决定，对于我们的问题，我们应该使用 actor/agent 库还是 FaaS（或其他东西）？

Answer 1

这是更多基于意见的问题，但我认为，在目前的情况下，将参与者放入 FaaS 是没有意义的——相反的工作实际上非常好：OpenWhisk 实际上是在 Akka 之上实现的。

有几个原因：

1. FaaS 当前的形式本质上是无状态的，这极大地简化了请求路由之类的事情。演员本质上是有状态的。
2. 根据我的经验，FaaS 功能通常是脱节的——你需要一些外部资源，但这是心智模型：通用资源和功能。在参与者模型中，我们倾向于将特定实体的类别视为参与者，即用户 Max，而不是用户表。我在这里没有涵盖仅将参与者用作并发单元的范围。
3. FaaS 应用程序的生命周期很短——这是它们背后的基石之一。由于更复杂的参与者的创建、放置和状态恢复可能需要一段时间，而且您通常需要很多参与者来执行单个任务，因此您最终可能会遇到恢复系统状态所花费的时间比实际执行任务，需要该状态。

话虽如此，在未来，这两种方法有可能最终会合，但需要在思维模型和基础设施模型（即参与者生活在运行时，FaaS 必须意识到这一点）方面发生变化。目前，IMO 在现有 FaaS 提供商之上建立现有参与者框架是不可行的。