Akka系統《sixteen》譯

Actor是一個封裝狀態(state)和行爲(behavior)的對象，它們只經過交換消息通訊(放入收件人郵箱的郵件)。從某種意義上說，Actor是最嚴格的面向對象編程形式，但它更適合將他們視爲人：在與Actor建模解決方案時，設想一羣人併爲他們分配子任務，將他們的功能安排到一個組織結構，並思考如何處理失敗。

ActorSystem是一個重量級結構，它將分配1 ... N個線程，所以每一個邏輯程序建立一個。

層次結構

就像在經濟組織中同樣，Actor天然造成等級制度。程序中某個功能的一個Actor可能但願將其任務分解爲更小，更易於管理的部分。爲此目的，它啓動它監督的子Actor。

雖然解釋了監督的細節，但咱們將集中討論一些基本概念。惟一的先決條件是要知道每一個Actor都有一個主管，即建立它的Actor。

Actor系統的典型特徵是任務被分割和委派，直到它們變得足夠小以便一體化處理。在這樣作的過程當中，不只任務自己結構清晰，並且能夠根據他們應該處理哪些消息，他們應該如何正常反應以及如何處理失敗。若是一個Actor沒有處理某種狀況的手段，它會向其主管發送相應的失敗消息，尋求幫助，遞歸結構容許在高的級別處理失敗。

相比之下，分層軟件設計很容易轉化爲防護性編程，目的是不泄漏任何故障。若是問題傳達給合適的人，能夠找到一個更好的解決方案，而不是試圖保持一切「在地毯下」。

如今，設計這樣一個系統的困難在於如何決定誰應該監督什麼。沒有單一的最佳解決方案，但有一些指南可能會有所幫助：

• 若是一個Actor管理另外一個Actor正在作的工做，例如經過傳遞子任務，父級別應該監督子級別。緣由是父級別知道預期會出現哪一種故障以及如何處理故障。
• 若是一個Actor攜帶很是重要的數據（其狀態不能丟失），該Actor應該向其監督的子Actor提供任何可能危險的子任務時，並在適當時處理這些子的失敗。根據請求的性質，最好爲每一個請求建立一個新子項，這樣能夠簡化收集回覆的狀態管理。這被稱爲Erlang的「Error Kernel Pattern」。
• 若是一個Acot依賴另外一個Actor履行其職責，它應該觀察其餘Actor的活動並在收到終止通知時採起行動。這與監督不一樣，由於觀看方對主管策略沒有影響。

這些規則老是有例外，但不管你是遵照規則仍是違反規則，都應該有理由。

配置容器

Actor系統做爲互相協做Actor集合，Actpr管理共享設施（如調度服務，配置，日誌記錄等）的天然單元。具備不一樣配置的幾個actor系統能夠在同一JVM中共存而沒有問題，沒有全局共享狀態在Akka自己。將此與Actor系統之間的透明通訊（在一個節點內或經過網絡鏈接）相結合，以查看Actor系統自己能夠用做功能層次結構中的構建塊。

Actor Best Practices

1. Actos應該像好夥伴同樣：高效地完成工做而沒必要費心地打擾其餘人，避免佔用資源。轉換爲編程這意味着以事件驅動的方式處理事件並生成響應（或更多請求）。參與者不該該阻止（即在佔用線程時被動地等待）， 多是鎖，網絡套接字等 ，除非它是不可避免的;在後一種狀況下見下文。
2. 不要在Actor之間傳遞可變對象。爲了確保，更喜歡不可變的消息。若是經過將其可變狀態暴露給外部來破壞actor的封裝，那麼您將回到正常的Java併發領域，並具備全部缺點。
3. 使Actor成爲行爲和狀態的容器，這意味着不要常常在消息中發送行爲（使用Scala閉包可能很誘人）。其中一個風險是意外地在Actor之間共享可變狀態，而且這種對Actor模型的違反不幸地破壞了使Actor在編程中進行編程的全部屬性。
4. 頂級Actor是你的Error Kernel的最內層部分，所以請謹慎建立它們而且更應用真正的分層系統。這有利於故障處理（既考慮配置的粒度和性能），也減小了監護人的壓力，若是過分使用，這是一個單一的爭用點。

你不該該關心的是什麼

actor系統管理她所配置的資源，以便運行它包含的actor。在一個這樣的系統中可能有數百萬的Actor，固然，應用程序做者沒法控制在大型系統中處理消息的確切順序，這也不是能夠預期的。退後一步，放鬆，讓Akka在引擎蓋下進行繁重的操做。

中止ActorSystem

當您知道應用程序的全部內容都已完成時，您能夠調用ActorSystem的terminate方法。這將阻止監護Actor，又會遞歸地中止其全部的子Actor 。

若是要在終止ActorSystem時執行某些操做，請查看CoordinatedShutdown。

下節再續！

原文：https://doc.akka.io/docs/akka/2.5/guide/tutorial_5.html