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