服务端架构的一些思考

前言

自从做了服务端开发之后,也算是把自己的一块空白补全了。之前对服务端的了解,主要是Socket通讯这一块,毕竟游戏客户端和服务端的通讯接口是类似的(之前做的是Socket长连接的手游)。虽然自己也看过项目组服务端的代码,但终归没有机会专心的去做服务端的开发。
目前做服务端开发已经有3个多月了,结合自己之前的理解,差不多把这几年的所学、所用的东西都贯穿了起来。几年前比较模糊的概念、架构,现在都看的比较特彻了。

关于目前

目前在开发的产品的一些功能和微信比较接近,用的是Nodejs的Express来开发,采用http来通讯,mongodb作为数据库。


服务端的架构

之前所开发的手游服务端架构

当时采用的是socket长连接来通讯,因为没有用第三方现有的服务端框架,所以底层socket的封装,以及协议内容的定义都是从0开始写。比如通讯协议定的数据格式是最原始二进制,每个协议发的二进制内容大体由“数据长度+操作码+具体内容”组成。服务端结构如下:

  • 一台登入服务器
  • 多台逻辑服务器(一个区一个服务器)

客户端通过连接登入服务器验证账户,再连接具体的游戏逻辑服务器。现在许多游戏都是这种登入服务器与逻辑服务器分开的架构:

英雄联盟:如果长时间在选区界面不动,就会被踢下线。
炉石传说:记得当时暗黑3刚开放的那天晚上,炉石传说都挤得无法登入了。估计他们两游戏用的是同一台登入服务器。

当前NodeJS服务端的架构

因为是http通讯,所以服务端对于手机客户端来说,差不多就是提供一套RESTful API。这里之所以只说手机客户端,是因为目前的服务端还负责网页这一块的显示,其实也是可以完全把网页端当作一个客户端来开发,服务端只负责提供通讯接口。比如借助一些MVVM的框架,把前端的显示和数据,完全分离开来。我试着用过avalon来写一个网页工具,来调试服务端的通讯协议,效果还是蛮不错的。服务端结构如下:

  • 登入服务器
  • 逻辑服务器
  • 文件服务器

负载均衡

以上两种架构,都会遇到性能上的瓶颈。

  • 手游服务端:当时的负载量差不多是同时在线1000人,压力就比较大了(不过当时的服务器配置也不算太高)。

    解决方案就是开新服,一是技术实现上比较简单,二是,开新服可以获得更多的新用户。

  • NodeJS服务端:因为所有用户是算在一个区,所以总用户量会非常大,目前遇到的主要瓶颈是带宽不够用。

    Http通讯协议的确是比较费流量,多余的报头、再加上是用json作为协议格式、以及post传参格式的多种多样,这和用纯socket传二进制数据流是完全不能比的。
    不过http也有它的优势:无状态
    所以对http结构做负载均衡比较方便,只需要多开几台逻辑服务器,这些服务器通过连接同一个数据库,再加上一个管理服务器来把请求分发给各个逻辑服务器就可以了。

数据库的压力

以上的负载均衡主要是针对带宽,CPU之类的性能瓶颈。对于不分区的App应用来说,还有一个比较大的瓶颈就是数据库这块。这一块内容之后再专门写一篇文章! (更新: 《技术正变得不再是门槛》

Pomelo!!!

前段时间,看了下网易的开源引擎Pomelo,的确是开阔了下思路。它的实现机制有点把前面两种服务端架构结合了起来的味道。

Gate

相当于之前手游服务端里面的登入服务器

Connector和具体的逻辑服务器

类似http服务端里面的那个负载均衡的管理服务器和具体的逻辑服务器。

当你在用手机QQ语音的时候,可以无缝切换到用iPad上进行语音聊天。通过这种先连接connector,再通过connector来连接具体的逻辑服务器的机制,可以很方便的实现这种效果。

其它

还有路由系统,channel机制,rpc机制等等…都很有亮点!有点相见恨晚的感觉,有空的时候,一定好好看下!

转载本站文章请注明作者(xtutu)和出处 xtutu.me