分区分服游戏框架设计

单服框架的特点
分区分服游戏框架是目前游戏行业使用最多的一种框架，这个框架的优点是：

1. 框架简单，不需要太复杂的设计，可以快速开发
2. 框架的维护成本比较低
3. 框架对于新手来说上手快，学习成本也比较低
4. 框架容易管理，开发方便，可以减少业务的bug量
5. 测试功能也比较简单，容易在测试中发现问题
6. 开发周期短，上线快，节省成本，快速变现

所以分区分服的框架很适合创业公司及小团队使用。在这里，对这个框架进行一下总结，并提供一个可运行的游戏代码例子，比较适合想进入游戏行业的新手及所在公司使用的也是单服框架的同志，可以取长补短。

分区分服的开发框架大致如下所示，不同的公司可能略有不同：

一般是分成WEB服务集群和游戏服务集群，一个是短连接，一个是长连接。为什么要分种不同的服务集群呢？主要是和他们负责的业务类型来区分的。针对上面所述的模块，下面我们单独拆解说明一下：

WEB服务集群

Web服务相信大家都不陌生，也有很多游戏开发者起初都是做Web服务开发的，是后来转做游戏开发的。在Web服务中，主要是负责管理一些全局服务类型的接口，且Web服务一般是做成无状态的，它可以随意部署N多台服务实例，每个实例处理的业务都是对等的，由ngix负责负载均衡。一般管理的功能有：

1. 用户账号管理

用户账号代表的是一个用户的身份，是用户进入游戏的凭证。主要的方式是让用户自己注册然后登陆，或者是接入第三方的用户SDK，比如微信，QQ，华为等。用户管理就是一个全局性的功能，一个用户只需要注册一个账号，就可以进入任何一个游戏分区玩游戏。另外，把用户管理单独放在Web服务的另一个考虑是减少游戏服务中线程的阻塞。因为用户注册或登陆，都需要访问数据库或第三方的服务，这时候就会产生网络IO，导致线程阻塞，如果放在游戏服务之中，会严重影响游戏服务消息处理的效率及吞吐量，直接影响用户的体验。

2. 游戏分区管理

因为是分区分服的框架，所以一般一个区就是一台固定的服务器，那么对于客户端来说，就需要有一个统一的游戏分区选择列表，这个列表是全局性的，放在游戏服务器上面明显不太合适，而且，只有在进入游戏的时候才会访问，其它时间内基本上不会再访问了。

3. 游戏公告管理

游戏公告一般只是一个简单的html页面，让客户端直接展示即可，或者把公告的信息封装成结构化的数据，让客户端自己拼接显示的页面。这个功能也是和游戏基本没有任何关系的，所以可以放在web服务里面。和后台管理系统使用同一个数据库，或者在服务内部调用后台管理的数据库。

4. 充值管理

充值服务是需要和第三方公司的服务通信的，客户端支付一般是调用第三方的sdk接口,一般是运营商的sdk,充值成功的钱是先到第三方公司的，第三方收到充值成功之后，会请求游戏服务器这边的接口，通知某个用户充值成功了，把充值的信息也会一起携带过来。而第三方公司通知只需要一个服务地址，所以可以在web服务对外提供一个统一的充值成功回调接口，收到充值成功之后，根据用户id和所在的zoneId，就可以找到这个用户所在的游戏服务器，然后向这个区的游戏服务器发送充值成功即可。

5. 后台管理服务

后台管理是游戏服务中最重要的一个辅助服务，它可以查看游戏服务中的数据，给游戏服务发送某些指令，可以帮忙运营人员修改数据，添加配置，发布公告，查看用户信息等，如果没有一个完善的后台管理服务，那么整个游戏的运营效率都是低下的。

6. 其它服务

因为不同公司的业务场景不一样，所以web服务也没有统一的标准功能，需要根据自己的业务功能来确定是否应该放在web服务中管理 。这个就是经验与需求决定的了。

游戏服务

游戏服务主要是为客户端提供流畅的游戏功能服务，游戏的特点是用户操作频繁，需要响应快，不像看网页那样，点击一下可以等待十几秒。所以游戏服务的标准要求就是吞吐量大，响应速度快，请求响应延迟低，要不然玩游戏的时候卡顿太厉害，用户是无法忍受的。单服架构的游戏服务一般是一个区对应一个物理服务器，也有做成集群，在逻辑上划分区的，这个技术要求就比较高了，暂时不在这说了，后面在说分布式游戏服务时再讨论。

在运行部署上，也可以多个区放在同一台物理服务器上面，但是进程是分离的，比如一区和二区，虽然在同一台服务器上面，但是是启动的两个进程，它们之间的数据是隔离的，不能相互访问。但是可以共用数据库服务，数据库名字可以根据区号划分，比如game_10001,game_10002等。
如果使用了redis缓存，需要注意，在存储数据时，redis key一定要拼接上zoneId，这样可以防止不同区之间的数据混乱，要不然可能会相互覆盖。
一般在游戏服务开发的时候，也会设计一个服务器开发的框架，把公共业务抽象出来，让开发人员专注于业务开发，主要有：

1. 网络层管理，包括网络的连接，网络数据的读取，网络读取的响应
2. 与客户端交互的数据序列化与反序列化。因为网络传输的都是二进制数据，从socket中读取出来或写到socket中的都是byte[]，但是在开发游戏业务的时候，不能直接使用byte[]。在接收客户端请求的数据之后，将byte[]转化为具体的参数对象，叫反序列化，在响应给客户端数据时，将具体的参数对象转成byte[]叫序列化。
3. 角色数据的统一加载与存储，更新
4. 角色连接管理，需要实现根据用户id获取这个用户当前的连接，或根据连接获取当前的用户信息，是一个双向绑定
5. 内部数据管理。因为服务器为了追求高吞吐，低延迟，在用户登陆之后就会把数据加载到内存之中，但是内存的空间是有限的，而且用户也不是一直在游戏中活跃，所以不能无限制的往内存中放置用户数据，需要有一个良好的清理策略，保证内存空间的循环利用。如果没有清理策略，有可能内存很快就会溢出，导致游戏服务进程宕机。

上面的几点，我在这个单服框架中都有实现：https://gitee.com/wgslucky/xinyue-alone-game-server