2 actor系統
Actor是封裝狀態和行爲的對象，他們的唯一通訊方式是交換消息，交換的消息存放在接收方的郵箱裏。從某種意義上來說，actor是面向對象的最嚴格的形式，但是最後把它們看成一些人：在使用actor來對解決方案建模時，把actor想象成一羣人，把子任務分配給他們，將他們的功能整理成一個有組織的結構，考慮如何將失敗逐級上傳（好在我們並不需要真正跟人打交道，這樣我們就不需要關心他們的情緒狀態和道德問題）。這樣的結果就可以在腦中形成進行軟件實現的框架。
2.1樹形結構
像一個經濟學組織一樣，actor自然會形成樹形結構。程序中負責某一個功能的actor可能需要把它的任務分拆成更小的、更易管理的部分。爲此它啓動子Actor並監管它們。雖然監督機制的細節將在這裏解釋，我們在這一節裏將集中講述其中的基礎概念，唯一的前提是要知道每個actor有且僅有一個監管者，就是創建它的那個actor.
Actor系統的精髓在於任務被分拆開來並進行委託，直到任務小到可以被完整地進行處理。這樣做不僅使任務本身被清晰地劃分出結構，而且最終的actor也能按照它們“應該處理的消息類型”，“如何完成正常流程的處理”以及“失敗流程應如何處理”來進行解析。如果一個actor對某種狀況無法進行處理，它會發送相應的失敗消息給它的監管者請求幫助。這樣的遞歸結構使得失敗能夠在正確的層次進行處理。
可以將這與分層的設計方法進行比較。分層的設計方法最終很容易形成防護性編程，以防止任何失敗被泄露出來。把問題交由正確的人處理會是比將所有的事情“藏在深處”更好的解決方案。
現在，設計這種系統的難度在於如何決定誰應該監管什麼。這當然沒有一個唯一的最佳方案，但是有一些可能會有幫助的原則：
如果一個actor管理另一個actor所做的工作，如分配一個子任務，那麼父actor應該監督子actor，原因是父actor知道可能會出現哪些失敗情況，
知道如何處理它們。
如果一個actor攜帶着重要數據（i.e. 它的狀態要儘可能地不被丟失），這個actor應該將任何可能的危險子任務分配給它所監管的子actor，並酌情處理子任務的失敗。視請求的性質，可能最好是爲每一個請求創建一個子actor，這樣能簡化收集迴應時的狀態管理。這在Erlang中被稱爲“Error Kernel Pattern”。
如果actor A需要依賴actor B才能完成它的任務，A應該觀測B的存活狀態並對收到B的終止提醒消息進行響應。這與監管機制不同，因爲觀測方
對監管機制沒有影響，需要指出的是，僅僅是功能上的依賴並不足以用來決定是否在樹形監管體系中添加子actor.
當然以上的規則都會有例外，但是無論你遵循這些規則或者打破它們，都需要有足夠的理由。
2.2配置容器
多個actor協作的actor系統是管理如日程計劃服務、配置文件、日誌等共享設施的自然單元。使用不同的配置的多個actor系統可以在同一個jvm中共存。Akka自身沒有全局共享的狀態。將這與actor系統之間的透明通訊（在同一節點上或者跨網絡連接的多個節點）結合，可以看到actor系統本身可以被作爲
功能層次中的積木構件。
2.3Actor最佳實踐
- Actor們應該被視爲非常友好的同事：高效地完成他們的工作而不會無必要地打擾其它人，也不會爭搶資源。轉換到編程裏這意味着以事件驅動的方式來處理事件並生成響應（或更多的請求）。Actor不應該因爲某一個外部實體而阻塞（i.e.佔據一個線程又被動等待），這個外部實體可能是一個鎖、一個網絡socket等等。阻塞操作應該在某些特殊的線程裏完成，這個線程發送消息給可處理這些消息的actor們。
- 不要在actor之間傳遞可變對象。爲了保證這一點，儘量使用不變量消息。如果actor將他們的可變狀態暴露給外界，打破了封裝，你又回到了普通的Java併發領域並遭遇所有其缺點。
- Actor是行爲和狀態的容器，接受這一點意味着不要在消息中傳遞行爲（例如在消息中使用scala閉包）。有一個風險是意外地在actor之間共享了可變狀態，
而與actor模型的這種衝突將破壞使actor編程成爲良好體驗的所有屬性。
2.4 你不應該擔心的事
一個actor系統管理它所配置使用的資源，運行它所包含的actor. 在一個系統中可能有上百萬個actor，不用擔心，內存一定是夠用的，因爲每個actor實例僅佔差不多300個字節。自然地，一個大系統中消息的處理順序是不受應用的開發者控制的，但這並不是有意爲之。放鬆些，讓Akka去做幕後的繁重事務吧。