游戏服务器架构设计
自工作以来一直致力于游戏服务器的开发，看过很多游戏服务器的架构，心中也无数次构建自己所想的游戏服务器的架构模型。这篇文章会分析一下常见的游戏服务器架构，以及其中会遇到的问题，然后分享我想设计的一种游戏服务器的架构。如你看到疑惑或者文中不正确的地方，希望能够指正。
首先我们来看页游时代一种页游服务器的结构
首先我们来分析一下这个结构的服务器的优缺点。
优点:
1. 结构简单，易于开发部署。
2. 线上出现bug时只影响本服，不会波及其他服务器。
缺点：
1. 跨服逻辑难以实现
2. 需要不定时合并服务器
这种服务器的架构实际满足的是整个游戏分多个区，各个区之间的玩家不能互通数据，也不能同时在一起玩，必须通过跨服服务器来进行简单的跨服玩法的实现。当游戏玩家数量逐渐增加是通过开新服的方式引导玩家进入新的游戏服务器中来减少单个服务器的压力。
服务器的架构总是随着技术的变革而不断演化，在进入手游时代之后，游戏服务器的架构又有什么变化呢。我们下面来看看一款手游时代的爆款游戏(具体游戏不提名了 但是该游戏同时在线人数达到百万以上)的服务器架构设计，首先看看简易架构图。
上图所示的服务器同样我们来分析一下优缺点
优点：
1. 几乎可以在逻辑上实现全球单服(游戏只有一个入口)
2. 分布式架构可是实现横向扩展，当服务器压力过大时可以扩展机器来增加服务器的抗压能力
缺点：
1. login服务器不应该处理业务(我了解的实际情况是login服务器中做了大量的游戏业务逻辑)
2. db服务器压力可能过大
3. 对外开发的服务器有直接操作redis的权限，可能会带来安全问题
该游戏服务器整体架构逻辑是客户端通过http请求login服务器获取承载最小的gateway服务器地址，可以通过gateway服务器当作一个中转服务器进行跨服的相关逻辑。
客户端通过http请求获取当前承载最小的roomserver地址，然后tcp直连room服务器进行对局逻辑实现。所有游戏数据存储于Redis，此处Redis直接作为数据库使用，据说Redis消耗近10T的内存（我听到这个数据的时候是这个表情 
）。
近期一直在思考自己想要设计的服务器架构，今天整理了一下，将架构图画了出来，后续将在空闲时间完成开发，完成相关的工具开发。先看看架构图，后续会发布在github上开源的项目地址，敬请期待。
主要分析一下我想要设计的这种架构的服务器的逻辑。整个服务器对外提供一个统一的入口gateway，gateway是一组服务器集群，视服务器承载情况进行动态扩展，支持动态添加、删除节点。游戏主逻辑由logic服务器实现，gateway将游戏请求转发至logic服务器，logic处理完请求再将数据由gateway返回给玩家。
当游戏需要处理即时性较强的逻辑时，将这部分逻辑分担至一组新的服务器，由客户端直连。这部分逻辑需要logic服务器从center服务器（管理一组battle服务器）中获取最佳承载的battle服务器返回给客户端。
整个游戏服务器个部分之间需要向register服务器进行注册，注册的作用在于当服务器节点发生增加、删除操作时其他服务器能够即时感知，可以理解为一种服务发现，并且register服务器也担负这配置中心的作用。
通过上图我们可以看到有两处使用Redis，第一处logic服务器连接的Redis为游戏的数据中心(或当缓存)，同时这组Redis集群可以由center服务器操作，完成battle服务器的结算。还有一处为battle服务器直连的Redis，这一组Redis的作用是缓存对局数据，用于故障恢复（服务器完全无状态，故障回复或者玩家重连逻辑都是直接从Redis恢复数据）。
每种游戏服务器的架构设计都有当时设计时的局限性，不能说哪种设计好，哪种设计不好，都局限于当时的资源情况，但整体来说服务器架构设计的最终目标应该是以更小的资源消耗服务更多的人并且利于扩展、开发
我正在实践的路上，期待对服务器架构有所思考的人能够分享你的想法以利于更多的人。