前几天在查看关于 Actor模式的一些资料,包括Erlang在游戏中一些资料,虽然本人不会Erlang但是稍微看了下编写方式.觉得还是有可借鉴的地方的.因为实在不熟悉不枉加评论了.这里说下自己的一些理解．
从这几年Erlang和函数式编程的崛起，引发OOP编程的一些不足，但是OOP并不妨碍获得相关的优点，只不过需要一些有效的框架和规范支持。
首先这里有几个简单的问题：
1.OOP方式面临多线程，跨进程访问问题，那么就有所谓的锁问题。
2.函数式编程的优点，不可变数据，并发时无需关心对象状态是否会被别的改变。
3.Nodejs异步编程，在IO上有着高效的吞吐，因为没有所谓的等待，但是，回调嵌套。
4.如果采用单线程OOP的编程方式，那么是否可以达到所期望的要求，但是如何处理多任务？
设想:
1.以完整的消息模式作为传递，但是我们并不抛弃OOP，所以并不是以函数式的方式传递，而是以完整对象方式传递。
2.单线程的模式，所有逻辑都使用模块的方式 封装，单个模块运行在一个线程中，跨模块不可直接访问。
3.多任务问题，使用运算时间片模式，手动控制中断以及切割，在单线程分割类似Lua Coroutine，达到切换任务的结果。
4.脱离回调，因为是异步的方式，所以很多逻辑都有回调，采用同步模式来编写，使用Coroutine来进行中断等待返回，并继续执行。
5.跨模块访问检测，将默认访问转换为代理模式。
6.因为基于消息的模块间访问方式，那么只要消息可序列化，那么分布式也就理所应当了。
7.如果模块隔离，那么模块热更新也是可以有效支持的。
测试和基础框架选型：
从技术选型和测试上Disruptor 是应该能胜任的消息队列，单线程达到百万级别ops的处理能力.而且并不是所有函数都需要消息传递的.用于处理多任务切割和单线程逻辑.
然后是ZeroMQ,因为采用异步回调模式,所以只要单向数据流的测试,达到十万以上ops还是比较轻松的.
对两者的结合表现还是比较期待的.