适合C# Actor的消息执行方式（4）：阶段性总结

核心提示：这个系列原本打算写3篇，也就是说在上一篇文章中已经把老赵认为较合适的方法展现出来了，适合C# Actor的消息执行方式（4）：阶段性总结，但事实上这个系列的计划已经扩展为8篇了——没错，翻了一倍不止，合适的容错机制，老赵正在为此努力），而最终是几篇现在我也无法断言，其实这也是我写不了书的原因之一

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

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

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

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