分布式异步消息框架构建笔记 1—— 设想

前几天在查看关于 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还是比较轻松的.

对两者的结合表现还是比较期待的.