Vaughn Vernon在他的新书《 Addison-Wesley 的Actor Model中的Reactive Messaging Patterns with Actor Model》一开始就声称，企业软件开发非常困难。 他强调说，他的声明并非专门针对多线程或并发，而是他认为是正确的一般性声明。 企业软件开发困难的原因是所需的所有框架，模式，软件层，消息传递系统，应用程序服务器和数据库。 Vernon提到了他在较早的《 实现域驱动的设计》一书中描述的端口和适配器 （又称六边形）体系结构，他在其中解释了为何简化了企业解决方案。 他指出，即使对于高级架构师和开发人员来说，理解这种架构也需要花费数月的时间。 考虑到所有涉及的事物以及游戏中的意外复杂性，他将其称为复杂性堆栈。
相反，我们在应用程序中真正想要实现的是提交表达用户意图的命令到域模型，并存储由于命令而创建的域事件。 这是一个简单而强大的模型，Vernon称之为简单堆栈，这也将他带入了他的书的主题，即Actor模型 ，他在第一章中介绍了React式软件的宗旨。
Vernon在其示例中使用了Scala和Akka ，在第二章中，他提供了一个有关Scala基础知识的简单教程，作为本书后面代码示例的准备。 在同一章中，他还详细介绍了Akka以及角色的监督，远程处理，聚类和测试的基础知识。
在第3章中，Vernon讨论了性能以及在过去的几十年中如何将性能提高到当今的64位大型高速缓存多核处理器中。 他认为Actor模型是在企业中实现性能和可伸缩性的重要方法，并且Actor可以帮助减轻多线程的复杂性并利用这些现代多核处理器的使用。
Vernon本书的主要部分是第4章至第10章，是一个模式目录，该模式目录描述了Gregor Hohpe和Bobby Woolf在《 企业集成模式 》一书中的大多数模式，但是从Actor模型的角度。 这些章节涵盖了基本消息传递模式，基本通道机制以及消息构建，路由和转换等内容。 为了简化制作和理解角色模型图，Vernon与Typesafe合作创建了一组标准的角色模型元素。 该书的代码示例可供下载。
Vernon在接受InfoQ采访时分享了他对Actor模型，领域驱动设计，微服务和CQRS的看法。
InfoQ：目标读者是谁？他们希望学到什么？
沃恩·弗农（Vaughn Vernon） ：我写这本书的目的是为各级软件开发人员提供入门和高级指导，以指导他们如何创建下一代软件，这些软件不仅具有并发性，并行性，可扩展性和性能，而且还具有弹性，具有低延迟和高吞吐量。 它教了如何创建一个贯穿始终的多线程和消息驱动的软件，团队可以对此进行推理。 我认为这本书大声喊着说，使用Akka的Actor模型是一种相对简单的方法，可以在日常IT企业中大规模并发地实现并发性，并行性。 它以其单独的模式详细显示了如何使用构建块将团队引导至此类高级应用程序和系统。 以大多数企业架构师和开发人员都会欣赏的方式来表示，这是正确进行SOA的方式。
InfoQ：既然您的上一本书是关于DDD的，那么您能告诉我们您从DDD过渡到Actor模型的过程吗？
Vernon ：在我看来，这不是从DDD转换为Actor模型的问题，而是将两者拥抱在一起。 我认为Actor模型是在现代企业中实施DDD的自然方法，这是我在新书中力求强调的一点。 实际上，我在全文中的适当时候讨论了DDD，有时我认为读者可以从有关DDD各个主题的更多知识中受益时，经常参考我的IDDD书。 我要强调的DDD主题之一是DDD是关于业务领域的显式表示，而具有Akka的Actor模型是表达域模型的最佳方式之一，这种表达具有明确性且没有不必要的体系结构开销和意外（或故意！）。 ）的复杂性。 对我而言，这段旅程是短暂而甜蜜的，我发现Actor模型是DDD在实践中的完美伴侣。
InfoQ：Alan Kay和Actor模型最初的面向对象的想法有多近？
弗农（Vernon） ：根据艾伦·凯（Alan Kay）的观点，演员模型保留了他打算面向对象的工作方式的大部分重要方面。 他指出，对象之间的消息发送比对象内部实现的方式更为重要。 好吧，这基本上就是Actor模型。 我的印象是，如果艾伦·凯（Alan Kay）有机会全面贯彻他的愿景，那么Smalltalk语言和环境最终将成为整个活动的参与者。 那将是一个引人注目的平台，我认为该平台将经受数十年的考验。 我喜欢Smalltalk的开发。 我只能想象Smalltalk-actor环境会为编程做些什么。 但是，我想当Smalltalk在1990年代初到中期达到顶峰时，我们仍然没有价格合理/普及的硬件来真正实现这一目标。 从目前的情况来看，Scala和Akka形成了一个高效的环境来实现几乎相同的目标，尤其是因为Scala既面向对象，并且比Smalltalk支持更多的功能编程概念。 这是一个令人难以置信的高效环境，它使我想起了Smalltalk的许多过去，Smalltalk是一种纯粹的面向对象的编程语言和开发平台。
InfoQ：CQRS（包括事件源）和Actor模型之间有什么关系？
弗农（Vernon） ：演员制作了完美的DDD聚合，因为它们是形成理想交易边界的原子处理单元。 因此，至少在战术上，将Actor模型与DDD结合使用会带来很大的好处。 另一个要点是，Actor模型是消息驱动的，这意味着Actor自然适合于事件驱动的体系结构。 通过事件驱动，参与者可以轻松地支持事件源，其中参与者产生的事件消息用于产生其持久状态。 但是，除非将事件投影到查询模型中，否则实际上无法真正查询事件日志。 因此，在使用事件源时，这意味着您需要使用CQRS，以便可以查询由于发送actor命令消息而产生的数据。 一切都可以很好地协同工作，并且随着Akka的成熟，对事件源的支持以及CQRS变得越来越先进。 今天，您可以从Akka项目的一部分中选择诸如Akka Persistence，Akka Query之类的工具，以及名为Eventuate的较新工具。 Eventuate展示了很多希望，并且在某些方面比Akka Persistence和Akka Query更先进。 我目前在Scala-Akka项目上使用Eventuate，对此我感到非常满意。 无论哪种方式，使用这两种工具集都将为您提供很好的服务。
InfoQ：从DDD（聚合）或微服务的角度来看，参与者有多大？
弗农（Vernon） ：就像我之前提到的，演员可以制作完美的DDD聚合。 我真的不只想回答有关Actor模型和微服务的问题，因为微服务具有许多概念上的定义。 不过，我将根据自己的经验尝试提供答案。 我认为有时微服务会非常小，因为它倾向于仅提供一些功能，您可能会认为它们是服务端点。 （您可能还认为微服务通过有限数量的URI模式仅提供几种REST资源。）在这种情况下，在此微服务级别中，您仍然可能有十几个或更少的参与者类型，因为它需要支持的几件事。 我们只是在讨论CQRS，以我的经验，您将拥有支持以下各项的参与者：一种聚合类型，一种流程管理器，View投影仪（对新事件做出React以使查询模型保持最新状态的参与者）和查询服务。 这甚至没有考虑如何支持服务/资源控制器。 对于一个非常集中的微服务，这可能会导致6-10个参与者类型，并且可能会产生数百万个将个体聚合实现为域对象的参与者实例。
另一方面，我认为有时微服务更接近于DDD有界上下文。 我将在这里补充说，我之前所说的非常专注的微服务可能并没有描述整个有限的上下文，它可能只支持较大的逻辑有限上下文的有限部分。 但是，我还创建了比这个更大的微服务，并且实际上是一个完整的绑定上下文，其中可能有5-10个聚合类型。 即使如此，微服务也绝不是一个整体，因为可能总共有20-25个参与者类型支持聚合，流程管理器，View投影仪和查询服务。
InfoQ：您认为Actor模型有一天会成为开发人员的主流吗？
Vernon ：我当然希望如此，因为如果不这样做，那么这意味着各地的开发人员都没有意识到他们必须从以前的企业服务器技术继续前进，而这些技术在接下来的几十年中将无法扩展和运行。 我还要补充一点，我认为Akka正在成为主流，从Akka用户组上支持Q＆A论坛帖子的数量可以看出。 不断有Akka的新开发人员问一些基本问题，这显示了很多吸收，并且显然吸引了我的新书。 Microsoft还为Project Orleans提供了可用的Actor模型工具，并且还为.NET平台提供了Akka.NET。 我还要补充一点，“ Akka Typed”是一个即将到来的项目，它使设计类型化演员成为可能（如Microsoft的奥尔良提供的那样），并且可能使采用Akka的人对那些强类型支持者更具吸引力。
扫一扫
2639
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
