归档 2016年6月

最后更新于 .

一. 前言

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来实现分布式锁 ...

最后更新于 .

一. 部署自己的git服务器

之前一直是在用bitbucket来做代码托管,因为它的服务器在国外,所以客户端提交大文件的时候慢的跟蜗牛一样。而我们服务器是直接使用tag来进行部署,有时候代码拉不下来也非常痛苦。

正好这次bitbucket提示我们客户端代码已经超过1G,一旦超过2G就无法再push新代码,所以就狠心自己来搭建了。

代码肯定是用的gitlab,版本是7.9。一开始用的7.8,好像对中文支持有bug,后来又升级的。
8.x系列好像部署起来更简单些,也尝试了一下,感觉太傻瓜了导致各种配置路径都不知道在哪,所以还是决定使用7.9。

因为git本身的特性,迁移代码也没费多少力气。

小伙伴们用了新的git服务器之后,普遍反馈速度快的都不习惯了,哈哈。

其实之所以把这件事情单独拿出来说,是因为我觉得这个事情是有着超过其本身的意义的。
那就是:公司已经成长到可以投入一些成本到一些原本第三方能够解决的服务上了。

这其实是一个很大的进步,当公司处于生死边缘挣扎时,是不会去理会这种事情的。

同样的,我们的统计服务也越来越完善,而之前常用的友盟基本已经抛弃不看了。

二. 支持IPv6

我昨天在朋友圈发了个状态:

苹果说:要有光,于是世界有了光。

说实话,也只有苹果敢这么强势了。说是6月1号之后必须支持IPv6,我们版本6月2号就因为这个原因被打回。

而因为我们的网络底层是直接操作的原生socket,所以没法直接使用ios提供的封装库。不过这个最后还好,https://tools.ietf.org ...

每日归档

上个月

2016年5月

下个月

2016年7月

归档