关于架构（续）
source link: https://www.zenlife.tk/architecture1.md
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
关于架构（续）
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实现。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK