服务端架构的一些思考

前言

自从做了服务端开发之后，也算是把自己的一块空白补全了。之前对服务端的了解，主要是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