Akka（0）：聊聊對Akka的初步瞭解和想法

   前一段時間一直沉浸在函數式編程模式裏，主要目的之一是掌握一套安全可靠的併發程序編程方法（concurrent programming），最終經過開源項目FunDA實現了單機多核CPU上程序的並行運算。可是，雖然經過在終端實現並行運算能充分利用多核CPU的計算能力把數據處理運算分佈到前臺能夠大大減輕後臺服務器的壓力，提升系統總體效率，對現今大數據廣泛盛行的系統計算要求仍是遠遠不足的，只有經過硬件平行拓展（scale-out）造成機羣並在之上實現分佈式運算才能正真符合新環境對軟件程序的要求。那麼，下一個階段目標應該是分佈式運算了。衆所周知，Akka應該是目前最著名和通用的分佈式軟件開發工具了，加上是scala語言的開源項目。因爲Akka已是一個在現實中被大量使用的成熟軟件工具，網上各方面的參考資料比較豐富，感受應該是一個比較理想的選擇。

花了幾天時間研究了一下Akka官方網站上的資料，先在這裏把了解的狀況在下面作個小結：

Akka程序是由多個Actor組成的。它的工做原理是把一項大運算分割成許多小任務而後把這些任務託付給多個Actor去運算。Actor不單能夠在當前JVM中運行，也能夠跨JVM在任何機器上運行，這基本上就是Akka程序實現分佈式運算的關鍵了。固然，這也有賴於Akka提供的包括監管、監視各類Actor角色，各式運算管理策略和方式包括容錯機制、內置線程管理、遠程運行管理（remoting）等，以及一套分佈式的消息系統來協調、控制總體運算的安全進行。

Actor是Akka系統中的最小運算單元。每一個Actor只允許單一線程，這樣來講Actor就是一種更細小單位的線程。Akka的編程模式和其內置的線程管理功能使用戶能比較天然地實現多線程併發編程。Actor的主要功能就是在單一線程裏運算維護它的內部狀態，那麼它的內部狀態確定是可變的（mutable state），但由於每一個Actor都是獨立的單一線程運算單元，加上運算是消息驅動的（message-driven），只允許線性流程，Actor之間運算結果互不影響，因此從Akka總體上來說Actor又好像是純函數不可變性的（pure immutable）。Actor的內部狀態（internal state）與函數式編程不可變集合（immutable collection）的元素差很少，都是包嵌在一個類型內，即F[A] >>> Actor[A]從類型款式來說很相像，那麼咱們能否對Actor進行函數組合（functional composition），而後實現函數式編程模式的Akka編程呢？應該是不可能的，由於咱們沒法對Actor的運算結果進行固定。一是咱們沒法防止Actor的運算產生反作用，再就是Actor的運算結果是沒法預料的，例如它可能把結果發送給任何其它Actor，這樣對一樣的輸入就能夠產生不一樣的結果。咱們能夠把Actor視做不純函數（impure function），對一樣的輸入可能會產生不一樣的輸出結果，如此就沒法把對Actor的編程歸類爲函數式編程了，但Actor編程的確是一種有別於其它編程模式、別具風格的編程模式，並且Akka還有一套領域特定語言DSL，是一種獨立的編程模式，即Actor編程模式了。這是一種須要掌握的嶄新編程模式。

Akka程序具有了如下的優勢：

一、Responsive 快速響應

   以最快時間對用戶請求進行回覆（響應）

二、Resilient 高容錯性

   能夠經過對Actor的：

   複製（replication)、

   封閉（containment）、

   分離（isolation）、

   託管（delegation）來應對解決Actor產生的任何程度的錯誤和異常

三、Elastic 可伸縮性

   經過提高計算機配置的垂直擴展（scale-up）、添加網絡中計算機數量的水平擴展（scale-out）等系統拓展能力

   實如今任何負載壓力狀況下的快速響應

四、Message-driven 消息驅動

   - 異步通訊（asynchronous communication）

   - 鬆散耦合（loosely coupled）

   - 位置透明的Actor定位方式

   - 負載均衡（load management）、流程控制（flow control）、back-pressure

上面所述特色之一的消息驅動模式中提供了位置透明的Actor定位方式，能夠簡單的經過設定消息接收方地址來實現程序的分佈式運算。這點卻是頗有趣。

除了普通功能的Actor以外，Akka還提供了幾種具備特殊功能的Actor，包括：路由（routingActer）、有限狀態機（FSMActor）、持久式（persistenceActor）。其中persistenceActor頗有吸引力，它能夠經過CQRS模式幫助實現新的數據庫操做模式ES（Event-Sourcing）。CQRS模式的基本原理是對數據庫的讀和寫進行分離操做，目的是提升大數據類型網絡應用程序的響應。固然，從另外一個方面來說，Event-Sourcing做爲一種新的數據庫操做模式，應該能解決任何數據庫應用軟件所廣泛面對的數據重演功能缺失，以及數據庫使用壓力等問題。

初步打算下面的主攻方向是基於persistenceActor的ES模式數據庫應用和基於Actor-http的Microservice工具庫。固然，但願經過各類努力最終實現讓那些不精通Akka的朋友們能方便的編寫Actor模式的分佈式應用程序。這可能會涉及到對Akka功能的再組合，搭建新的更高層次的抽象框架、提供API等。固然，這些仍是須要對Akka進行詳細的研究學習後纔能有所定論。

恰好，發如今網上的基於scala的Akka討論示範並很少，那在下面一段時間的討論裏咱們就開始從頭學習Akka吧。。。