转载

Actor模型以及网络程序架构

在去年实现我的Raft实现，考察过一些Raft算法的实现，包括Golang的一些实现。基于Golang的实现给人的第一感觉是，不知道有哪些协程是“持续”运行的，比如说监听网络请求，快照生成等等。而且由于CSP模型不关注发送者和接受者导致数据追踪比较困难，在没有IDE的情况下你可能几眼都看不出数据到了哪个模块的哪行代码。个人不确实是不是开发者的问题，导致这个网络程序架构那么松散，还是说CSP模型下的程序都那么松散。

由于个人长期在Web后端开发，对于MVC模型以及处理复杂业务逻辑的分层架构、组件化和依赖注入都比较熟悉，但是在开发一个传统意义上的网络程序时，还不确定什么是最佳架构。

假如用类似Web容器的做法，即每过来一个请求，开启一个thread或者使用线程池的话，程序逻辑可以采用分层架构。即使请求入口采用非阻塞IO的做法，比如说用Netty，程序逻辑也可以做在Netty的pipeline或者单独开线程处理复杂任务。但是，网络程序与很多没有额外线程的Web后端不同，会有定时任务，会有比较复杂的异步处理，所以可能一开始做成类似事件驱动模型可能更好。

个人在实现xraft时，用类似事件驱动的方式处理定时任务，各种外部的请求，把接受和发送等IO操作交给了Netty。整体上类似JavaScript，但是我把耗时的快照生成与应用发在主事件线程外，严格来说有一些区别。使用事件驱动除了理解起来简单之外，一些多线程下的数据访问问题利用单线程的线程封闭解决掉了。

如果问这种架构是否有改进空间，个人认为是有的。但是多线程下数据访问是一个难点，比起全局锁，个人更看好STM（软件事务内存）。除了数据访问，逻辑的封装也需要考虑，还有比较棘手的组件间双向访问问题。

在进一步找寻解决方案的时候，个人先找到了Cassandra所使用的SEGA，一种基于Stage驱动的架构模式。一个Stage绑定一个queue和相关处理逻辑。复杂逻辑被拆分成多个Stage，从第一个Stage执行到最后一个Stage。类似逻辑可以复用Stage。

老实说，这和Actor模型很像。Actor有一个Mailbox，Actor的内部根据收到的消息进行不同的处理。Actor同时其他一些特点，比如说树一样的管理结构，失败处理，热部署等等。类似组件间双向访问问题，Actor可以通过名字访问来解决。

整体来说，Actor符合我的要求。把Actor作为逻辑单位，有助于松耦合组件，但不是像我看到的CSP代码那么散。Actor除了“无法超过的前辈”Erlang之外（Actor+协程+函数式，理论上最好的并发编程语言），Scala和Java中可以使用Akka。BTW，Akka有针对STM的实现。

为了学习，个人选择了另一个Java下的Actor实现：Vert.x。严格来说，Vert.x并没有完全实现Actor模型，但是Vert.x作者把涉及到的绝大部分IO操作都异步化了，比如网络（基于Netty），文件，数据库（扩展形式）等等。之前个人也撰文分析过，协程的本质是异步编程，假如你把所有操作都异步化了，剩下的你可以用JavaScript的callback方式，或者更直观的ReactiveX。

Vert.x还有一个特点是把Actor的queue统一到一个eventBus中去，这样做的一个效果是用queue的名字代替了Actor。考虑到Actor在失败时以及多个Actor时的处理时，这么做并没有太大问题。

在使用过Vert.x+ReactiveX之后，个人觉得这可能是现代网络编程的一种比较好的组合。当然同时理解这两者会比较难，特别是ReactiveX。好在Vert.x不需要ReactiveX也可以使用，就像JavaScript没有async/await也可以使用。

个人不确定这是不是面向复杂网络程序的最佳架构方案，如果有更好的方案，欢迎留言。

原文 http://blog.gssxgss.me/actor-model-and-network-program-architecture-1/

正文到此结束