战魂小筑

讨论群:309800774 知乎关注:http://zhihu.com/people/sunicdavy 开源项目:https://github.com/davyxu
   :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  257 随笔 :: 0 文章 :: 506 评论 :: 0 Trackbacks
大服务器架构讨论

最近参加了一个大服务器架构讨论活动, 记录下心得

概述

游戏客户端采用Cocos2dx-Lua的纯Lua编写逻辑, 服务器采用Golang作为开发语言

游戏类型类似于COC,因此无需选服. 需要使用大服务器架构进行处理

数据库

采用Mongodb做持久存储, redis做跨服通信数据交换

使用UCloud的云技术, 省去了烦人的运维工作

通信及协议

客户端和服务器通讯使用HTTP短连接, 基于json的数据封包协议

服务器间大量使用Golang自带的json+rpc进行通信

服务器类型

服务器类型大致分为逻辑服务器,战斗服务器, 中心服务器

逻辑服务器

逻辑服务器负责日常逻辑及公共逻辑处理(好友, 公会)

1个逻辑服务器对应一个区, n个区均使用Ucloud云Mongodb进行数据存储

战斗服务器

战斗服务器是一个集群, 集群会返回一个负载最低的服务器返回使用

战斗服务器通过cgo技术与客户端C++/lua的战斗逻辑进行逻辑复用, 在此技术上进行

战斗逻辑的校验

中心服务器

客户端登陆前, 在中心服务器这里获得可登陆的逻辑服务器地址, 同时做一个负载均衡

短连接

评价

由于操作系统的技术趋于稳定, 同时, 手游的弱交互型导致的游戏架构趋于简单. 因此网络负载不再是游戏服务器技术的瓶颈. 从经验看来, 游戏服务器技术, 更重要的是还是看数据库的选型及处理方式. 

虽然Mongodb的性能上不如内存数据库. 但是从存储安全性上要比个人搭建的内存数据库简单, 安全

外加上云技术的引用, 性能的瓶颈和运维的技术复杂度迎刃而解

Redis用于跨服数据交互那是再好不过的数据中介了, 保证速度和稳定性, 绝对不是造轮子能比拟的

短连接在手游上处理起来比长连接简单一些, 无需做断线重连. 服务器的底层也是由Golang的框架库保证质量的. 因此负载毫无问题. 服务器对内及对外均使用json进行数据交换, 简化了协议处理. 也方便了调试

json rpc的性能损耗对于整个逻辑的处理来说均可以忽略不计

posted on 2015-07-21 10:30 战魂小筑 阅读(5123) 评论(8)  编辑 收藏 引用 所属分类: 网络 服务器技术 、Golang

评论

# re: 大服务器架构讨论 2015-07-21 10:43 小强哥
各个逻辑服务器之间的玩家有数据交互吗？如果有，那么只是通过redis之间从mongo里把数据取出来，中间没有一个统一的数据服务来做一些同步操作嘛？  回复  更多评论
  

# re: 大服务器架构讨论 2015-07-21 10:44 战魂小筑
@小强哥
每个区之间会有跨服逻辑, 跨服通过redis交互数据
同步操作都是服务器之间自己完成, 无需中间服务器进行同步  回复  更多评论
  

# re: 大服务器架构讨论 2015-07-22 14:52 QQ:79039039-8
请问对于全局状态，也是redis来缓存？
应该需要全局锁操作吧，数据是否有多份呢？

否则，这个架构本身还是存在单点故障/瓶颈吧。（当然要分析目标玩家数量）。

我也在成都，下次有讨论叫上我啊~  回复  更多评论
  

# re: 大服务器架构讨论 2015-07-22 14:53 战魂小筑
@QQ:79039039-8
加我的群讨论吧

redis只是两个服务器间某种逻辑的数据交换. 其实一般这种交换对数据的时效性要求不是那么及时. 锁没必要的  回复  更多评论
  

# re: 大服务器架构讨论 2015-08-31 09:49 freeeyes
服务器开发实际上有两种模式。
一种是你说的Actor模式，实际上，这种模式的关键是极度信赖内部网络，虽然逻辑可以分散，但是在设计上，你必须做到数据消息状态的解耦，否则，会给未来调试和测试带来很多的问题。
无状态数据，一般选择http类似协议（因为现成，简单高效，可以和脚本语言方便整合，适合移动网络），一般情况下，Gate模式是比较受欢迎的。数据在入口验证，所有的逻辑依靠后面负载的各种服务器（一般的情况可以选择部分中间件作为消息传递手段，比如thrift,ice,tao等）。这种分布的基础在于数据的流向并不确定，你不知道数据的下一个命中点在哪个服务器，所以对于持久化的数据（比如用户信息，玩家数据等）必须支付更多的IO成本去做维护统一。那么，在这样的模式下，服务器架构的稳定性，就被压在IO上了。在排错过程中，你必须确认数据在IO上的流动，从而需要支出部分维护架构的开发成本。并且最大的保证内部IO的稳定，当模块变多和设计上的耦合需要，随着功能的复杂，模块间交互的增加，未来维护成本会较高。
一种是面向数据状态的负载，这种相对比较好理解，比如前几年的一些MMO游戏，这种模式开发的依赖不是IO，同样可以支持Gate模式，但是，数据流的方向是指定的，也就是说，服务器的处理不以单独一个功能模块划分，而是以一组的形式存在。一组服务在一台主机上，这种模式依赖的是内存的效率。一般是采用共享内存节省数据交换的成本。这种状态的模式，很难做到精确的负载均衡，而更加考验的是，你的驾驭逻辑的能力，这里必须强调的前期的数据组织和开发能力。
两种模式的比较，实际是你信任IO还是信任内存。你把维护放在需求开发后还是需求开发前的问题。
在实际开发过程中，没有万能药，最关键的是，如何利用已有的资源去解决需求提出的问题。开发的关键，是把复杂变简单。
最关键的是，架构是为人服务的，关键是要做到隔离性，独立性，可维护性以及可替换性。  回复  更多评论
  

# re: 大服务器架构讨论 2015-08-31 09:56 战魂小筑
@freeeyes
非常给力的评论!  回复  更多评论
  

# re: 大服务器架构讨论 2015-08-31 14:21 freeeyes
有兴趣可以一起研究可服用的服务器架构？  回复  更多评论
  

# re: 大服务器架构讨论 2015-12-01 17:04 mmocake
Actor模式非常赞  回复  更多评论
  


只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   博问   Chat2DB   管理