发现想抽时间写博客实在是太难了，不过我觉得今天这一篇还是很值得写一下的。

熟悉我的同学应该都知道，我之前做了一款《矩阵危机》的产品，使用的是帧同步的技术。

简单画一下V1架构图：

• Gateway

  网关服务器。

  负责客户端连接的接入，使用协议TCP。

  使用C++编写。

• KcpProxy

  Kcp协议的代理服务器。

  客户端默认使用Kcp连接服务器，如果失败会自动回退到Tcp。

  使用C++编写。

• RoomServer

  房间服务器。运行战斗逻辑，每个房间同时仅能运行一场战斗，帧率为15帧/秒。

  房间服务器与Gateway间通过Tcp连接，每个房间建立一个一条独立的连接。

  使用Python编写。

整个架构还是比较清晰的，但是里面有个极大的问题：性能

因为python的性能实在是太差了，对于RoomServer每秒15帧这种cpu密集型的业务场景完全不适合。

至于python的性能有多差，我当时做过一个简单的测试，同样的业务代码，c++是python性能的10倍左右。

可能直接说这个数字大家也没什么感觉，但是要知道换算成服务器的话，那就是10倍的服务器量，10倍的成本。

所以这也是要做架构升级的原因。

而升级的方案也有多种，其中一个方案如下：

其核心逻辑是将CPU密集的RoomServer放到Gateway中去，而额外多出来一组RoomController负责对Gateway和Room进行控制。

RoomController可以继续使用python实现。

这样的方案虽然解决了性能问题，但是却导致gateway的功能过于耦合，不是好的设计方案。

还有一个方案就是将RoomServer直接使用C++重写，每个Room开一个线程 ...

一. 前言

2016年6月17日凌晨5点钟，我们完成了服务器端V3版本的重构，切换的过程十分平滑且没有对线上用户产生任何影响。

这也正式标志着，我们的游戏服务器进入了一个全新的阶段。

我们上一次的重构是在 2014年12月23日，现在看看，时间过的真快啊。

而熟悉我的人应该知道，我特意为上一次重构写过一篇《游戏服务器端架构升级之路》，其中详细的讲述了我们游戏服务器从农业时代跨越到工业时代的历程。

而这次V3版本的重构，我将其定义为第二次工业革命。也许它没有那么的强大和完美，但是他切实的解决了现存的大部分问题。

二. 背景

之前的文章已经说过，V2版本的服务器的几个优点：

1. 支持服务器代码热更新而不影响外网服务
2. 架构模式足够简单：push-pull

但是，其简单的架构也存在一些缺点：

1. 业务模块之间容易互相影响

   比如两个游戏玩法 A 和 B，内部使用的逻辑、存储服务器都完全不同，但是在worker层却是共用的。

   所以一旦玩法A的服务器出现问题导致处理变慢，那么worker就会被堵住，而玩法B也会跟着遭殃。

   同时，即时在一个业务模块内，也存在请求处理优先级的问题，比如拉取牌局记录和跟注，要尽量避免跟注这种核心逻辑受到影响。

2. 限制了游戏逻辑的实现方式

   V2的多worker的模式，导致worker必须限制为无状态的，因为worker可能处理任何一个请求，而一个请求也可能被分配到任何一个worker上。

   这一点是之前解决服务器热重启的关键，但同时也限制了我们代码逻辑多样性的实现。

   比如我们的游戏桌子数据是存储在redis中，所有人对桌子的写操作可能同时分配到多个worker上，而为了避免写冲突，我们不得不通过redis来实现分布式锁 ...