编辑推荐

√ AKKA项目创始人为原书作序，国内Scala倡导者和践行者邓草原为译著作序，可见本书地位之显赫。

√ 用先进的ACTOR模型，能创建更简单、性能及可伸缩性更高的系统。

√ 函数响应式编程(Functional Reactive Programming)具前景，本书首度剖析其架构理念与实践思路。

√ 本书作者前作《实现领域驱动设计》畅销至今，对DDD理解深刻，目前更是AKKA模型屈指可数的专家。

使用响应式结构通过全方位简化编程工作的各个层面，消除编程复杂性的方式

Actor系统和Actor对象的特点，以及通过Akka框架使它们拥有更强大功能的方式

怎样创建可以在一个或多个计算节点中自由伸缩的系统

创建通道机制的方式，以及怎样选择适当的通道解决应用程序的开发和整合难题

应使消息拥有怎样的结构，才能将消息发送者的意图清晰地告知消息接收者

由领域驱动的应用程序实现处理过程管理器的方式。

降低消息源和消息目的地之间的耦合性，和将适当的业务逻辑整合到消息路由器中的方式

在应用程序开发和整合环境中会用到的各种消息转换方式

使用事件溯源模式和符合CQRS原则的响应式视图，实现持久化Actor对象的方式

内容简介

通过Actor模型使用响应式消息传输模式，可编写出具有高性能、高响应性、高可伸缩性和高韧性的并发应用程序。本书由10章构成，详细介绍了使用Actor模型中响应式消息传输模式的理论和实用技巧。其中包括：Actor模型和响应式软件的主要概念、Scala语言的基础知识、Akka框架与Akka集群功能、Actor模型中的通道机制和技术、降低消息源与消息目的地之间耦合性的方式、持久化Actor对象和幂等接收者。附录A中还介绍了通过.NET平台和C#语言使用Actor模型的方式。

作者简介

　　Vaughn Vernon 是一位资深的软件开发者，并且是一位简化软件设计和实现思想的领袖人物。他是畅销书Implementing Domain-Driven Design 的作者，这本书也是由Addison-Wesley 出版社出版的。他还为来自世界各地的数百位软件开发者教授IDDD Workshop 课程。Vaughn Vernon 经常在计算机行业大会上发表演讲。他擅长的领域包括分布式计算和消息传输，而且尤为擅长Actor 模型。在2012 年，他在一个GIS 系统中*一次使用了Akka 框架。此后，他就一直专门研究通过由领域驱动的设计模式应用Actor 模型的技术。通过关注Vaughn Vernon 的博客（www.VaughnVernon.co）和微博（Twitter 网站的@VaughnVernon 用户），可以了解他的*新著作。

目录

第１章　Actor模型和企业级软件概述 1

为什么企业级软件难以开发1

响应式应用程序简介4

响应性 5

韧性 6

灵活性 6

消息驱动 7

企业级应用程序8

Actor模型 9

Actor模型的起源 10

了解 Actor模型 11

Actor模型的明晰性 20

下章提要21

第２章　使用Scala语言和Akka框架实现Actor模型 22

怎样获取Scala语言和Akka框架 23

使用 Typesafe Activator编辑器 23

使用 sbt 23

使用 Maven 24

使用 Gradle 25

使用Scala语言编写程序 26

Scala概要教程 27

使用Akka框架编写程序39

Actor系统 40

实现 Actor对象 46

监督 52

远程处理 55

集群功能 68

测试 Actor对象 94

CompletableApp类 98

小结100

第３章　性能情结 101

晶体管101

时钟频率103

核心和高速缓存104

可伸缩性106

多线程技术的难点109

Actor模型的作用 114

处理伪共享 116

设计模式 117

第４章　通过Actor对象传递消息 119

消息通道120

消息121

管道和过滤器126

消息路由器131

消息译码器134

消息端点135

小结137

第５章　消息通道 138

点对点通道140

发布―订阅通道143

本地事件流 143

分布式发布―订阅通道 149

数据类型通道157

非法消息通道159

死信通道161

确保送达机制164

通道适配器172

消息桥174

消息总线180

小结189

第６章　消息结构 190

命令消息191

文档消息192

管理处理流程和处理过程 194

事件消息195

请求―回复模式197

返回地址199

相关标识符203

消息序列204

消息有效期206

格式标识符209

小结213

第７章　消息路由 214

基于内容的路由器215

消息过滤器219

动态路由器223

接收者列表232

分离器241

聚合器245

重新定序器252

组合消息处理器259

分散―聚集路由器260

传送名单274

处理过程管理器282

消息经纪人路由器298

小结301

第８章　消息转换 302

封装器303

内容丰富器305

不可变的 DoctorVisitCompleted消息309

是否应在本地系统中创建 AccountingEnricherDispatcher对象 309

内容过滤器310

存放证313

标准化器321

规范化消息模型322

Actor系统需要标准 323

小结324

第９章　消息端点 325

消息传输网关326

消息传输映射332

事务型客户端/ Actor对象 339

事务型客户端 341

事务型 Actor对象 342

轮询消费者350

资源轮询 354

由事件驱动的消费者358

具有竞争性的消费者359

消息调度器361

选择性消费者364

持久订阅者367

幂等接收者370

避免处理消息副本 370

使消息具有相同的效果 371

使状态切换操作不受收到消息副本的影响 372

服务激活剂378

小结379

第10章　系统管理和基础结构 380

控制总线380

改道器382

窃听器384

消息元数据/历史记录 385

消息日志/存储器 389

智能代理392

测试消息397

通道净化器399

小结401

附录A　NET平台上的Akka工具集：Dotsero 402

Dotsero的Actor系统 402

通过C#和NET使用Actor对象 405

Dotsero实现 410

小结413

参考资料 414

精彩书摘

推荐序

终于有一本围绕企业应用和架构来讲解Actor 模型和Akka 的书了。很期待这类书的出现，希望能引领Actor 模型开始向企业应用的“回归”。

本书作者Vaughn Vernon 恰好也是《实现领域驱动设计》（ImplementingDomain Driven Design）一书的作者，这在某种程度上印证了，近十来年的“领域驱动设计（DDD）”理想在Actor 模型和Akka 上终于找到了现实的技术实现。

DDD 希望能在业务领域层面就把模型和逻辑设计清楚（业务模型和逻辑是最稳定的），并一一对应到实现中。或者说，领域有什么，实现中才应该有，也应该有。但由于计算机性能限制、语言实现难度等方面的原因，这一理想在现实中一直没能得到很大程度的实现。

而近二十年来，Java 及其生态一直占据着企业应用领域的主导地位。尤其从20 世纪90 年代末以来，J2EE 规范（现在叫Java EE）也试图围绕业务领域，为企业应用提供从建模到分层，涵盖事务、持久化、分布式的整套解决方案，并提出Entity Bean、Session Bean 及Message Bean 等试图对应到业务领域的模型。

遗憾的是，基于当时的技术，Java EE 也并没有很好地实现初衷，这在我看来至少有以下几方面的原因：

? EJB 规范起初的一个主要价值——对分布式应用进行事务管理，在实践中几乎很少被使用，反倒引入了整个架构的复杂性。

? Entity Bean 不能在集群中分片部署，而这本应是分布式系统最需要解决的问题之一。

? 只有Message Bean 是异步的，但它却不是Entity Bean。这意味着系统很难在时间维度解耦。

2005 年前后，Hibernate、Spring 等技术逐渐兴起，以轻量化的角度切入了企业应用领域，并在互联网领域异军突起。

对于Spring + Hibernate 的方案，保存在持久层的业务实体的数据/ 状态需要反复被业务逻辑存取。为了解决这个性能瓶颈，不得不引入Ehcache、Memcached、Redis 等中间缓存。这样，在数据扩张时，为了解决这些缓存数据的分片（sharding）问题，这些缓存方案还需要进一步引入和实现集群分片的支持，这带来了复杂性。可即便如此，它解决的是缓存数据的分布，而并没有解决Beans 本身的分布。Beans 仍然受限于Bean 容器的缓存大小，而不得不经常去中间缓存甚至持久层要数据。

那么，在企业应用领域，Actor 模型能带来更合适的解决范式吗？

Carl Hewitt 在1973 年对Actor 模型进行了如下定义：“Actor 模型是一个把‘Actor’作为‘并发数字计算的通用原语’的数学理论。”。这个定义跟我常说的“Actor 是最适合并行计算的最小颗粒”是相通的。

Actor 是异步驱动、可以并行和分布式部署及运行的最小颗粒。也即，它可以被分配、分布、调度到不同的CPU、不同的节点，乃至不同的时间片上运行，而不影响最终的结果。因此，Actor 是在空间（分布式）和时间（异步驱动）上解耦的。

Akka 是Lightbend（前身是Typesafe）公司在JVM 上的Actor 模型实现，它同时是一个可扩展、引入了多种分布式范式的框架。而且，Akka 2.3.0 开始支持带状态的Actors 的分片集群，以及根据journal/snapshot 形式对事件流和状态快照实施持久化和回放。

Akka 的Actor 模式本身可以保证在单个Actor 实例中每个行为的原子性，并行的粒度可以细化到单个Actor 实例。也即，当行为被封装在一个Actor 实例中时，该行为不会阻塞其他Actors 实例的行为，从而很难出现整个系统被阻塞的情况。

从EJB 角度看，Akka Actor 提供了什么对应的角色呢？

首先，从各类Bean 的角色看。Akka Actor 支持持久化，所以有一类Actor 可以设成“Entity Bean”；Actor 实例可以维护自己的状态，所以它也可以是“StatefulSession Bean”；而不需要关心其状态的Actor，自然可以担当“Stateless SessionBean”；最后，对Actor 的存取、调用，都是通过异步的消息传递来实现的，因此，它们都是“Message Bean”。

其次，从架构层面看。Actor 能同时担当实体Beans 和中间缓存的角色，并且是异步驱动的，且具备分片集群下的水平扩展能力。而akka-persistent 进一步将持久化、HA 一并细粒度地实现了。与SSH/Java EE 相比，Actor 减少了数据反复在各种形态（数据库、缓存、业务层中的实体对象实例）间转化的消耗，减少了线程阻塞的消耗，并提供了一致的并行和分布式机制。

再次，从业务领域看。Actor 可以非常自然地直接对应到业务实体。某类Actor 的一个实例可以是一个人、一个物品、一部设备，等等。这些实体Actor 都是通过接收命令或者事件，来驱动完成一次状态的变化或者完成一次任务会话。Akka 的每个Actor 仍由自己的scheduler 来完成各类定时任务，也可以理解为它们同时可以由时钟事件来驱动。而一次任务会话也可以抽象为一个会话Actor 的实例，它跟踪会话的进度、事务状态、发送事件等。

最后，就像前面提到的，对Actor 实例的存取、调用是通过异步的消息传递来实现的，这带来一种担心：性能代价会不会很高？

这确实是很多年前，采用异步消息驱动来设计、实现系统的架构师、程序员的最大障碍，因为那时的机器不仅性能有限，多核的物理机制也少见且昂贵，而且多线程的切换代价高昂。

但对于现在的计算机而言，多核处处可见，CPU 的计算能力、线程的调度和切换能力也有了极大的提高，上面这些问题已经不再是障碍。比如，Akka 在单核的CPU 上，每秒可以处理的异步消息数是5000 万以上。尤其是，现代JVM的线程切换时间已经在微秒级，线程切换的代价变得非常小。小到在大量场景下，采用异步处理所带来的整体性能和效率的提升已经足够将其代价忽略。

还有一种担心来自：用Akka 会引入复杂的架构吗？

从DDD 的理念和实践来看，恰恰相反，因为处处都是同样的模型（Actor、Async Message Driven、Event Streaming），系统实际上更具一致性和弹性（包括对需求的弹性）。

这些年，我本人一直在尝试将Actor 模式及Akka 用于企业应用，包括证券交易及计算领域，以及在豌豆荚实现的若干实时系统。实际上最近十年做来做去无非是同一件事：将现实（直接）映射到计算机体系的Actor 模型。而实践效果充分验证了，采用异步消息驱动以及小粒度的并行和持久化机制，在性能和内存的使用上都不是问题。更重要的是，模型及架构与领域的自然对应大大降低了系统进化和维护的成本。而得益于Akka 的集群、高可用及事件溯源（Event-Souring）的持久化机制，这几个系统也几乎都能无故障地持续运行。运行时间最长的一个，超过了两年没有重启。

本书的内容是基于Akka 2.3.4 版本的，这个版本包含了Akka 框架主要的功能和实现（包括sharding 和persistent），非常新且全面。而且作为一个长期从事企业应用领域的设计和实现的专家，作者非常熟悉在企业业务领域需要用到的知识和术语以及思维方式，并很好地融入了Akka 的实践。

——豌豆荚资深程序员　邓草原

前言/序言

好不错哦

学习之路开启 加油加油

能带来不少启发，还成

还不错 有空看看

5分给快递小哥的

还不错，虽然看不太懂，慢慢学

上面都是托儿吗，我看了一下写的不怎么样啊，没什么逻辑可言，也可能是翻译太差了吧，词不达意而且语句不通顺啊，也没有操作性可言，还卖这么贵，真的是...

还不错

还行了