編輯推薦

√ 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 的實踐。

——豌豆莢資深程序員　鄧草原

前言/序言

【京東超市】雅詩蘭黛（Estee

不錯的書，必讀，活動價給力

還沒來得及看，大神的書肯定好！

得好好研究下

好像很有意思的樣子，以後有時間瞭看

感覺Actor在之後的開發中會廣泛應用，書不錯

好，很快到貨，服務好，繼續支持！

好用

書是正品，包裝密封完好，正在學習中。