空中换心

最近一周在做一件非常刺激的事情，刺激到不想再干第二遍了 T_T。。。还有一个月就要内测的时候，换掉服务器架构，而且还要同时做需求，无异于对空中的飞机换引擎啊

8 月末的时候，老大开了个会，服务器架构要重构一下，将以前的逻辑分服改成物理分服。之前的架构里，开新服很简单，但因为是大服结构，任何一个逻辑服挂了，都会影响其他服的玩家，隔离性不够高。同时，做单服的服务时，处理逻辑需要考虑不同服的影响，添加了额外的心智负担，不容易做对。于是，架构决定改成这样：

每个 game 是一个进程，这样任意 game 挂掉都不会影响其他服务器了，适合策划们大量开新服，每周清理关停老服的洗量玩法。设计的时候，希望各个进程之间是松散的结合到一起的，甚至 center 都没有直接 call 到 game 的接口。取而代之的，是一个消息队列。game 上线之后，就在 center 上创建一个消息队列，center 需要发消息给 game，就丢一个消息到队列里。最终的目标是，center 即使短暂挂掉，也能快速重启，只造成短时间新玩家无法登录，已经登录游戏的玩家应该能继续游戏。同时，center 的结构足够简单，几乎不会挂掉。

上周老大和另外一位同事做了一周，这周就决定切换到新架构来了。因为我的工作主要是写逻辑，基本都是在玩家身上，挂在 agent 上的玩法，所以改动的地方不多，修好聊天和邮箱服务即可。于是，一边消化策划的新需求，一边参与迁移新架构。实际结果喜忧参半，喜的是新写的逻辑因为都在 agent 上，可以完全复用；忧的是时间非常紧迫，然后还要处理一些迁移架构带来的 bug。幸而最后还是活过来了 XD

关于这次架构的变动，也跟其他组的同事讨论过，不过被吐槽说跟 skynet 的 master-slave 架构没什么区别 ^_^ 回来仔细想了一下，感觉还是可以辩护一下的。第一点，之前用的 master-slave，没有指定 slave 具体负责的逻辑服 id，每个 slave 都是相同的，都有可能被不同服的客户端连上。当然，这个问题可以改掉，改成跟现在架构类似的。第二点，之前的 master 挂掉之后，slave 虽然不会马上挂掉，但是公会之类的服务是放在特殊的 slave 上的，也会立即失效，而新架构都在一个进程内，还能继续工作。归根结底，是因为 master-slave 被认为是一个稳定的整体，skynet 不会处理内部的网络连接断开的。如果换成 cluster，用消息队列来连接，相对来说容错性就更高了

策划们最近学聪明了，也要搞隔离式设计了。出了十几二十种资源，基本都不互通，很多资源都是某个功能专有的，比如这种资源专用于升装备指定属性，那种资源用来升英雄特定属性。每种资源的投放到回收都隔离开来，不会相互影响。做设计的时候就可以不怎么动脑了，做错了大不了直接关掉这个系统，不需要为之前挖的坑埋单。对于这种快餐式设计，只能无奈叹气。程序做起来没什么难度啊，多一种资源不就多记一个变量。只不过这种水平扩展的系统，能不能给玩家带去更有层次感的游戏体验，个人对此表示怀疑。