转载

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/
正文到此结束
Loading...