David Fowler :actor框架为什么没能流行起来?

19-10-31 banq
                   

众说纷纭:

如果您正在寻找更好的方法,并且已经找到了CQRS/ES,那么它们是多余的。

如果actor用作聚合或事件投射,可以很好地与CQRS/ES一起工作,我过去曾在奥尔良做过。

因为这与人们被教导为Web应用程序的好东西(无状态计算)的模型相反?如果一个人的背景全是关于将状态问题推送到数据库的,那么可能很难理解Actor为什么有用。

抽象得过于复杂。构建一次性或一次性应用程序并不容易。这需要大量的学习投入。

我正在使用Actor系统。血腥的很难调试。为什么状态更改发生或没有发生。为什么一条消息从未得到答复。DI不能很好地工作。特别是对于MS DI或EF。由于没有作用域(我们将作用域定义为消息),因此必须为EF进行复杂的操作。

大多数应用都是CRUD。人们编写应用程序将数据扔到数据库中,并让它照顾并发性(无论是天真还是乐观)

而且仍然大多数人会弄错它并导致数据不一致。我都代码逻辑推理没有问题,但还是不确定,不如将数据扔到数据库中并假定它将解决所有并发问题。

在我的经验(非常有限)中:它调试困难,可组合性有限

因为云原生工具赢了。云产品中存在创建群集,服务发现,pub sub,监视,PaaS托管等功能。Actor框架中存在零退出策略。

难以引导(前期设计成本高,而“我将开始在此Web应用程序中抛出端点”要简单得多)和调试困难是两个主要原因。

如果在水平扩展时创建状态服务,则会变得非常复杂。

在大约4年使用.NET(fw和Core)中的actor框架构建各种应用程序后,我的个人感觉是:由于缺少调用栈,并且仅通过调用固有的清晰接口/类型安全性,很难调试应用程序发送消息。

与传统应用程序(DDD,洋葱架构)相比,其优势尚不清楚。难以推断整个系统状态。强制执行特定的编程方式。模型并非每个人都喜欢或适合。想想如何将所有现有领域模型重构到一组Actors?

强烈推荐 http://nact.io

这是编程思考的范式转变。以我的经验,大多数人对OOP并不完全精通,因此范式转换会带来额外的提升。

定义一个类专门来传送数据,这有点设计过头,这是一种思考问题的方法,这是大多数人不习惯的另一种方式。但是,如果您的解决方案很复杂并且需要可伸缩性,那就太好了。

我们不需要Actor带来的额外框架复杂性。我认为,只有在复杂性和并发性达到一定程度时,它们才能带来收益,而收益要超过模型的成本。在90%的情况下,crud很好。

actor的组合不及函数。如果将事情解耦得太多,则可能会失去类型安全性的许多好处。

 

                   

3