actors模式的問題
原標題：The Problem with Actors
基於actor模式的設計十分的吸引人並且有很大的潛能。
- 由於基於消息，讓其看上去十分的適合做分佈式橫向擴展的應用
- 由於在多線程環境操作時候，actor方法確認是安全，基於actor的設計看上去，可以成爲EJB輕量級的替代品。
- 使用actor的時候垂直擴展來的要自然些，並且比使用線程和鎖方式實現的代碼要更加具有可維護性。
剛開始接觸基於actor設計的開發者，很快就會被迷住。它是基於事件設計的，卻具有線程安全和模塊化。代碼十分的簡潔，當我們一直讓actor保持小的規模和聚焦在簡單的關係上，代碼將十分的容易編寫。但是當你開始處理性能的問題的時候，麻煩就來了。
你試着寫一個簡單的性能檢測時候，你惱火於數個out of memory的異常。 不！actor使用單一的消息，沒有任何流程控制。當你增加ACK消息到你的actor上時候。突然所有的事情都有點不太清楚，並且應用的代碼更加難寫了。
現在你開始了自己的性能檢測工作，並看着那些數字。天哪！actor通過線程傳遞所有的消息，引起了大量的延遲。你向那些具有基於actor設計經驗的開發人員請教時候，你只會被告知你用錯了方式。
一個好的基於actor的應用，會最小化actor之間的消息數，至少在注重性能的地方應該這樣。當你停止使用只有簡單關係的小的actor，你放棄了模塊化和清晰性，actor變的像一大碗麪條一樣，基於actor的設計就不那麼有趣了。
另一方面，我們可以改變actor的工作方式，實現些真的基於actor的設計。我們在後續應用中引入雙向消息，最小化線程間傳遞的消息，然後使用小的、關注點固定的actor，在不放棄性能的前提下，去保持代碼的清晰和可讀性。
Bill