技术开发 频道

C# Actor消息执行:阶段性总结

    【IT168技术文档】

转载自Jeff Zhao的博客

    这个系列原本打算写3篇,也就是说在上一篇文章中已经把老赵认为较合适的方法展现出来了,但事实上这个系列的计划已经扩展为8篇了——没错,翻了一倍不止,而最终是几篇现在我也无法断言。其实这也是我写不了书的原因之一。虽说唯一不变的就是变化,但是我变的太离谱了。不断写,不断出现新想法,不断变化。作为这个系列的第4篇,我们现在来对之前3篇文章进行一番阶段性总结。

    阶段性总结本不在计划之内,不过似乎Actor模型这方面内容还不太受人关注,因此有的朋友也误解这系列文章想要解决的问题是什么。除了这方面的解释之外,我还会对之前提出的几种做法进行综合的对比,可以进一步了解整个演变过程的思路,为接下去的改变做铺垫——因为下次改变就涉及到多个方向,每个方向都是在一定程度上真正可用的方式。

    我们究竟是要解决什么问题

    Actor模型的本质已经被强调了无数遍:万物皆Actor。Actor之间只有发送消息这一种通信方式,例如,无论是管理员让工作者干活,还是工作者把成果交还给管理员,它们之间也要通过发送消息的方式来传递信息。这么做看似不如直接方法调用来的直接,但是由于大量的消息可以同时执行。同样,消息让Actor之间解耦,消息发出之后执行成功还是失败,需要耗费多少时间,只要没有消息传递回来,这一切都和发送方无关。Actor模型的消息传递形式简化了并行程序的开发,使开发人员无需在共享内存(确切地说,其实是共享“写”)环境中与“锁”、“互斥体”等常用基础元素打交道。不过,使用Actor模型编写应用程序,需要开发人员使用一种与以往不同的设计思路,这样的思路说难倒不难,说简单也不简单。等我们有了成熟、稳固的Actor模型之后(例如高效的调度,合适的容错机制,老赵正在为此努力),再回头来探究这种特殊的架构方式。

    由于Actor执行的唯一“事件”便是接受到了一个消息,而一个Actor很可能会做多件事情,因此我们一定需要一种机制,可以把消息“分派”到不同的“逻辑段”中去,并为不同的逻辑指定各自所需要的参数。例如,Person是一个Actor类型,它有三种任务,不同的任务会带有不同参数:

聊天(Chat):指定另一个Person对象(聊天的另一方),以及一个Topic对象(聊天的话题)。
吃饭(Eat):指定一个Restaurant对象(餐馆)。
干活(Work):指定一个Person对象(工作完成后的汇报人),以及一个Job对象(任务)。
  当Person对象获得一条消息时,它需要将其识别为聊天、吃饭或干活中的一种,再从中获取到这个行动所需要的数据。如果用一幅示意图来表示,它可能是这样的:
 

    如何在C#中把一条消息转化为一段逻辑的执行,并且尽可能确保一些优势(如易于编写,静态检查,代码提示,重构,单元测试……),这便是这系列文章唯一的目的。正如文章的标题,我们关注的是“消息执行方式”,而不是:

“消息传递”与“共享内存”两种并行方式的比较
讲述Actor模型的应用程序设计方式。
提出消息传递时的解耦方式。
……
  文章使用Actor模型作为示例,是因为我编写的ActorLite组件易于说明问题,并且是典型的“消息传递”场景。事实上,文章所表达的内容,适合任何基于消息传递的C#场景,例如内存中的消息队列、生产者/消费者模式、消息总线……它并没有限制Actor模型这一种架构方式。

0
相关文章