游戏云间之五：游戏架构

说起架构，分为两块，一个是软件层次的代码架构，另外一个是硬件层次的系统架构。软件层次的，模块划分、代码重构及业务层的架构为主。系统层次的，以网络、部署、服务器集群为主。软件层次的架构，在于前期代码研发。硬件层次的系统架构，在于后期的服务器部署上线。今天的内容主要偏向于游戏领域的系统架构。

谈起系统架构，无外乎就那些技术，什么负载均衡啊，什么数据库垂直、水平分区啊、前端/后端缓存、nosql什么什么的。几乎任何行业里面的架构，都离不开这些技术。今天要说的是游戏架构，我不想再费劲的介绍那些传统的架构技术，也没什么新鲜感。要说某个领域的架构，我觉得这个领域相比其他领域的架构有什么鲜明特点，这才是最有价值的部分。

游戏架构相比传统b/s、c/s应用架构，鲜明特点在于：
游戏架构特有的“分区”概念。

为了解决玩家的延时，传统IDC机房的游戏架构，一般分为电信和联通两个大的分区。然后在两个大分区中，又分类似“北京分区”“上海分区”“江苏分区”等等。这种逻辑层次的按照地域的分区，其实在物理层次，是把服务器对应部署在不同地域的机房中。这样部署，也主要是为了解决游戏玩家的延迟性。打个比方，北京电信的玩家登陆上海电信的服务器，延时肯定是很高的。

游戏分区的架构特性，决定了游戏的架构一般不是分布式集群的架构（以下简称为集群架构）。身为玩家的你们都知道，比如我是北京电信的玩家，然后登陆上海电信的游戏服务器，这个时候，一般你都会发现你的游戏角色的属性都会回归你刚注册的时候（针对绝大数游戏，当然有些游戏也不是这样设计的，这里就不做过多介绍）。从这点我们可以判断出，不同地域的游戏部署，应用层和