关于架构(续)

2014-01-27

关于架构(续)

上一篇中,谈了一下我所理解的架构。其中提到了一条基本原则:Don't communicate by share memory, share memory by communicate instead。并说了一下关于对归属的理解。这一篇中谈谈另一个基本原则:移动计算而不是移动数据。

最早接触到这个概念应该是在近来炒得很火的大数据中,mapreduce就是典型代表。数据是分布存储在各个机器上的,为了使用这些数据进行计算,并不是移动数据去适配计算,而是移动计算,map过程实质就是移动计算。因为这种条件下移动计算的成本是比较低的。

mapreduce是受lisp语言启发的,说到lisp,还有另一种形式的移动计算的魔力,这个应该归功于它的代码即数据。就是RPC只需要把代码发过去在另一端运行就可以实现了,想远程那边跑什么计算,就发送什么样的代码过去。其实这种能力也不仅仅限于lisp,应该说带虚拟机的脚本语言都可以实现这种性质。

将这一点使用到极致,令我感触最深的,应该是剑三中的插件系统(魔兽世界没玩过)。剑三中的做法,应该跟云风博客描述得着不多:每个玩家在服务器端都对应了一个lua虚拟机的agent。插件是用lua语言写的,有了agent,那么插件系统就顺理成章了,客户端直接把lua代码发送给agent,agent执行这些代码,把结果告诉客户端--瞧,这就属于典型的移动计算而不是移动数据。

按照移动数据的做法,就是一个一个的封包的交互,客户端想要某东西的计算结果,而计算依赖于数据(状态是在服务端),数据不在本地,所以发消息包的方式就像是把输入数据发过去,计算原本就在另一边(不景移动过去的),然后再把输出数据发回来。用这种方式显然无法实现也剑三那样的插件系统的。

而使用移动计算的做法,我需要对数据进行计算的结果,那么我把要执行的代码发到另一端就行了,计算自然是跟着代码过去的。


PS,在我接下来想做的东西中,用goroutine实现的agent,没有lua虚拟机,不能接受计算。但是我又想要类似这种插件系统的能力,因为这样客户端写起来会方便很多。我初步打算这一块用RPC实现。

架构编程感悟