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

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