响应式架构：消息模式Actor实现与Scala、Akka应用集成下载 mobi epub pdf 电子书 2024

☆☆☆☆☆
简体网页||繁体网页

[美] Vaughn Vernon（沃恩弗农）著，苏宝龙译

下载链接在页面底部

点击这里下载

facebook linkedin mastodon messenger pinterest reddit telegram twitter viber vkontakte whatsapp 复制链接

想要找书就要到图书大百科

book.teaonline.club

立刻按 ctrl+D收藏本页

你会得到大惊喜!!

发表于2024-11-22

类似图书点击查看全场最低价

图书介绍

出版社：电子工业出版社

ISBN：9787121291135

版次：1

商品编码：11972978

包装：平装

开本：16开

出版时间：2016-06-01

用纸：胶版纸

页数：440

字数：555000

正文语种：中文

图书描述

编辑推荐

适读人群：在企业中任职的软件架构师和开发者，以及任何对Actor模型感兴趣并渴望提高自身技术和价值的软件开发者均适合阅读本书。

√ 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 模型和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 的实践。

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