《通過Actor模型實現響應式消息處理模式》書評及與Vaughn Vernon的問答

jopen 8年前發布 | 30K 次閱讀 Scala

在由Addison-Wesley所出版的新作 《通過Actor模型實現響應式消息處理模式》 (通過Actor模型實現響應式消息處理模式)中,作者Vaughn Vernon在全書的開篇部分表述了一個觀點:企業級軟件開發是一件艱難的工作。他同時強調,這一點并非特指多線程或并發而言,而是一種他所深信的、具有普遍性的觀點。之所以企業級軟件開發如此困難,是源于開發中所需的所有框架、模式、軟件分層、消息系統、應用服務器以及數據庫。Vernon還提到了在他的前一本著作 《實現領域驅動設計》 (Implementing Domain-Driven Design)中描述過的 端口與適配器架構 (Ports and Adapters)(又名多邊形架構),他在書中闡述了這種架構能夠簡化企業級解決方案的原因。但他也表示,即便是對于高級架構師與開發者來說,要充分理解這種架構也需要耗費長達幾個月的精力。整個過程中需要考慮到各種因素,并且會出現各種出乎意料的復雜性,他將此稱為復雜性棧(complexity stack)。

而與這種復雜性相反,我們在應用程序中真正想要實現的功能無非是將能夠表達出用戶意圖的命令提交至某個領域模型中,并將作為這些命令的結果所創建的領域事件保存起來而已。這是一種簡單而強大的模型,Vernon將其稱為簡單性棧(simplicity stack)。隨后,Vernon切入了本書的主題 Actor模型 ,他在本書的第一章結合響應式軟件的原則對Actor模型進行了介紹。

Vernon使用 ScalaAkka 代碼編寫本書的示例,在第二章中,他通過一個簡單的指南介紹了Scala的基礎知識,為本書接下來的示例做好了準備。同樣在第二章中,Vernon也對Akka進行了詳細的介紹,包括Actor的監管、遠程調用、集群以及測試,作為進一步學習的基礎。

在第三章中,Vernon著重講解了性能方面的問題,以及近幾十年來出現的64位系統、大容量緩存以及多核處理器等技術是怎樣使得性能不斷提高的。他相信,Actor模型是一種在企業系統中實現高性能與可伸縮性的重要方法,而Actor將幫助開發者克服多線程開發的復雜性,并充分利用先進的多核處理器。

第四章至第十章是全書的重點所在,Vernon列舉了一份包含多種模式的目錄,從Actor模型的角度描述了在Gregor Hohpe與Bobby Woolf共同撰寫的著作 《企業集成模式》 (Enterprise Integration Patterns)中所描述的大多數模式。這些章節也涵蓋了其他一些相關知識點,包括基本的消息處理模式、基礎的通道機制,以及消息的創建、路由和轉換。為了簡化對Actor模型圖的構建與理解,Vernon與 Typesafe 合作創建了一系列標準的Actor模型元素。讀者還可以隨意下載本書中的 代碼示例

在與InfoQ進行的一次訪談中,Vernon分享了他對于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:Actor模型與Alan Kay所提出的面向對象的最初想法有多接近?

Vernon:按照Alan Kay對于面向對象所預期的工作方式來看,Actor模型保持了其中大部分的重要元素。他曾表示,與對象內部如何實現相比,對象之間的消息傳遞是一種更重要得多的關注點。好吧,這基本上就是Actor模型的功能了。我有一種感覺:如果Alan Kay有機會將他的思想貫徹到底,那么Smalltalk語言及環境最終就將完全成為Actor。這將是一個非常具有競爭力的平臺,我認為它將能夠承受住幾十年的考驗。當然,我熱愛Smalltalk開發原本的形式,我現在也只能夠在腦中想象一個結合了Actor的Smalltalk環境進行編程時的情況。不過,我認為當Smalltalk在上世紀90年代中葉達到巔峰時,當時的硬件價格以及普及性對于實現這一構想來說仍是無法實現的。而正如當前的現狀所見,Scala與Akka構建了一個具備高度生產力的環境,它基本實現了這一構想。尤其是Scala,它既支持面向對象,并且與Smalltalk相比支持更多的函數式編程概念。這是一個具備了令人難以置信的生產力的環境,它令我回想起昔日還在使用Smalltalk的美好時光,那是一個純粹的面向對象編程語言以及開發平臺。

InfoQ:CQRS、包括事件溯源在內,他們與Actor模型之間存在怎樣的關系?

Vernon:Actor本身就是完美的DDD聚合,因為他們本身就是具備原子性的處理單元,可以構成理解的事務邊界。因此,至少從戰術方法的角度來說,這一特點對于Actor模型與DDD的結合使用是一個很大的促進。另一個關鍵點在于Actor模型是由消息驅動的,這意味著Actor能夠很自然地適用于事件驅動的架構。通過事件驅動架構,Actor能夠非常方便地支持事件溯源,某個Actor所產生的事件消息將用于構建它的持久狀態。不過,對某個事件記錄進行查詢的做法不太實際,除非你能夠將事件投射至某個查詢模型中。因此,一旦你使用了事件溯源,這也意味著你需要使用CQRS技術,使你能夠查詢那些向Actor發送命令消息后所產生的結果數據。他們之間的結合使用能夠產生很好的效果,隨著Akka的不斷成熟,它對于事件溯源和CQRS的支持也變得越來越優秀。現如今,可供你選擇的工具包括Akka Persistence和Akka Query(這兩者都屬于Akka項目),以及一個名為 Eventuate 的新工具。Eventuate向使用者做出了許多承諾,而且在短短時間內,它的功能就超越了Akka Persistence和Akka Query。我目前就在一個基于Scala和Akka的項目中使用了Eventuate,并且對于它的表現感到相當滿意。不管怎樣,無論你選擇了哪一套工具集,你都會得到足夠的功能。

InfoQ:從DDD的聚合,或是從微服務的角度來看,Actor的概念有多大?

Vernon:正如我之前所建議的,一個Actor能夠完美地扮演DDD聚合的角色。我其實很不愿意回答Actor模型和微服務的相關問題,因為微服務的概念定義實在是太多了。不過,我還是愿意基于我個人的經驗來回答一下這個問題。我認為,微服務在某些情況下可能是一種非常小的概念,因為它傾向于僅提供少量的特性,你可以將其設想為服務端點。(你也可以認為微服務的功能是通過數量有限的URI模式提供一定數量的REST資源。)在這種情況下,你可能依然需要一打或稍少一些的Actor類型去匹配這種級別的微服務,因為這種微服務仍然有一些需要支持的功能。我們剛才已經談論了CQRS,從我的經驗來看,你需要通過Actor支持以下特性:一種聚合類型、一個流程管理器(Process Manager)、視圖映射器(View projector,即對新的事件進行響應的Actor,以保持查詢模型的更新)、以及查詢服務。這還不包括服務或資源控制器的支持。即使對于某個具備高度關注性的微服務來說,這也將產生6-10種Actor類型,乃至產生上百萬個Actor的實例,以領域對象的形式實現各種不同的聚合。

不過從另一方面來看,我認為在某些情況下微服務更接近于DDD中的邊界上下文的概念。這里我得多說一句,之前我所描述的那種具備極高關注性的微服務或許并不能表述一個完整的邊界上下文,它或許僅僅支持某個較大的邏輯邊界上下文中有限的一部分內容。不過,我也曾創建過比這更大型的微服務,這些微服務確實能夠描述一個完整的邊界上下文,在其中可能會包含5至10種聚合類型。即便如此,微服務也不是一種一體化的架構,因為對于這種級別的微服務,可能需要多達20至25種Actor類型以支持所需的聚合、流程管理器、視圖映射器以及查詢服務等等。

</div>

InfoQ:你認為Actor模型有朝一日會成為開發者的主流工具嗎?

Vernon:我當然是這樣希望的,如若不然,則意味著開發者們還沒有理解這一點:他們不能繼續停留在以往的那種不具備高伸縮性的企業服務器技術中裹足不前,在今后的幾十年中他們必須不斷前進。我還想補充一點,我認為Akka正在成為主流的技術,從Akka用戶組中的Q&A論壇帖子中的數目就可以看出這一點。總有一些剛接觸Akka的開發者在詢問一些基礎的總是,這也說明Akka的接收度已經很高。很明顯,對于我的新作來說,他們是很好的讀者群體。微軟也在為 Orleans項目 這個可用的Actor模型工具貢獻自己的力量,同時在.NET平臺上也出現了Akka.NET這樣的工具。此外,我還想提一下Akka Typed,這是一個即將發布的項目,通過它能夠設計類型化的Actor(微軟的Orleans工具也提供了此類功能),對于那些強類型的支持者來說,該項目將使Akka更具吸引力。

關于作者

Vaughn Vernon 是人們所公認的軟件開發方面的思想領袖,他致力于簡化軟件的設計與實現,并出版了兩本著作 《實現領域驅動設計》 以及 《通過Actor模型實現響應式消息模式》 。他從上世紀80年代起就開始通過面向對象語言進行編程,從90年代早期,他在通過Smalltalk進行領域建模時就大量應用了領域驅動設計中的概念。Vernon對于分布式計算、消息處理、尤其是Actor模型非常感興趣。近幾年來,他一直致力于通過領域驅動設計方法應用Actor模型。

查看英文原文: Reactive Messaging Patterns with the Actor Model Book Review and Q&A with Vaughn Vernon

來自: http://www.infoq.com/cn/articles/reactive-messaging-patterns-with-actor-model-book-review

 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!