这个系列慢慢变成先设想后完成的模式了,上篇我们测试了以Yield当多任务处理.
楼主写了个小Demo也完成了类似功能,并且支持中途等待,直接等到完成回调后,继续处理下一阶段.

这个功能可以完成类似逻辑事件流,比如C需要等待A,B完成后再执行,而且写法也比较简单.直接上代码:

            //创建事件,把Handle丢入Yield队列,
            //执行当发现有等待Handle状态为YieldWating
            //放入YieldWating队列
            //回调时检查YieldWating队列,重新激活
            Context.Wating(WatingResultSubCall, (r) =>
            {
                myvalue = http://www.mamicode.com/r;>
这是上一篇的总结吧.

 今天要解决的是关于多个模块和数据之间的交互,众所周知框架尝试使用单线程来避免所有的锁和开销.
但是并不是所有任务都可以在一个线程中解决,我们需要更多独立的模块和更多独立的线程.
但是又不期望开发者在开发时明确区分这些模块.
最好类似正常的函数直接使用,那么才是一个"优雅"的使用方式.
常规的切片一般基于2种:
1.逻辑切片,独立的功能放在独立的线程或者独立的服务器中运行.比如一个单独的聊天模块,或者拍卖行模块.
2.数据切片,切分若干个大小的地图,用于分开负载,或者简单的分多个区,分散玩家.
但是经常会混合起来,若干个区域的玩家,使用若干个独立的功能.
但是对于框架来说并不关心"切片方式",仅关心"调用位置",既:
是否在当前线程中运行?
1.是,则丢入当前线程
2.否,则丢入路由模块,由路由模块寻找所在线程并丢入执行.
那么路由模块承担什么角色?
1.管理所有模块,它需要知道所有模块所在的线程或者服务器节点?
2.管理所有对象,面向对象的过程,我喜欢把方法集成在对象内,当然你也可以不用这么做.路由模块需要知道所有对象所在线程.
3.负责中转所有消息,不管是基于什么传输/跨线程/跨AppDomain/跨服务器,只要完成中转.

从以上分析可以看出,在这样的机制下,实现分布式是一个非常简单的逻辑,无需修改任何代码,只要路由支持转发消息.那么可以部署到任何位置.
唯一要做的只要指定初始化位置即可.
当然所有的编写规则必须经过所谓的代理逻辑,有点像AOP么,确实比较像,只要符合规范的编写过程,那么一切都不是问题.



分布式异步消息框架构件3 —— 自动消息路由