游戏架构 云游戏(5)-游戏架构

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


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


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


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


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


游戏分区的架构特性，决定了游戏架构的扩展性非常好。 所谓的数据库垂直分区、水平分区，又比如mysql的主从读写分离，这种数据库层次的扩展，是很繁琐的，一般都是应用于我们的集群架构中。而我们的游戏架构呢，简单点的话，我们只需要一台服务器部署应用，一台服务器部署数据库即可。如果用户量增加，比如上海电信的用户量增加，一台服务器和一台数据库扛不住的时候。这个时候，我们简单增加一个区即可，再独立部署一台应用和一台数据库即可。因而就有了上海电信一区，上海电信二区这样的区分了。


传统IDC  机房部署游戏，地域之间访问的延时性，因而就形成了这种很强的地域性分区。如果我们通过云来部署，这种分区上有什么区别呢？我们知道，云主机网络都是BGP（多家运营商接入），从而就有效解决了传统机房部署遇到的问题——不同地域不同运营商的玩家访问的延时问题。所以我们通过云来部署的游戏应用的分区，就没有北京电信分区、上海电信分区之说了。我们就可以简单的叫为一区、二区、三区等，然后我们还可以为不同区取个好听的别名。比如一区之风云再起，二区之逐鹿中原，三区之雄霸天下。


分区只是游戏行业一个很突出的特点，几乎所有类型的游戏都具有这个特点。 但不同游戏的类型，在架构及技术上是有所区别的。游戏按照应用划分，主要分为页游、手游和端游。但页游、手游和端游具体在架构及技术上有什么区别呢？


页游与手游、端游的架构区别：
页游是网页游戏的简称，这类web游戏应用，都是属于B/S架构的范畴。需要注意的是，这里我说的网页游戏，以及本文所介绍的游戏架构，并不包括单机游戏的。如果是单机游戏的话，根本不用跟服务端进行通信，那就谈不上什么架构不架构的了。
手游是手机游戏的简称，端游也就是客户端游戏的简称，手游和端游的特点，需要在手机、电脑上安装客户端。所以手游和端游就是典型的C/S架构了。
页游是B/S架构，手游和端游是C/S架构，说到这里，可能不需要我再多说。做过技术的，可能比我还要了解B/S与C/S有什么区别吧。B/S的架构基于浏览器，所以用户不用关心我们程序的升级。当我们程序升级，我们只需要在我们服务器端更新一下，客户下次浏览器访问，会自动把最新的数据返回。而我们C/S的架构，每次我们程序升级，可能都需要客户手动在手机或者电脑上下载最新的客户端或者升级包进行更新。


页游、手游、端游的技术区别：
页游、手游、端游后端的技术的话，可能都相差不多，主要技术区别在于前端。页游的话，采用html5、flash等前端技术。而手游，如果是Android系统的话，采用java技术。如果是IOS，主要采用object c。那端游呢，当然C++是首先了。