君临天下服务端架构调研

最新推荐文章于 2020-11-09 14:17:34 发布

偶像罗斯福

最新推荐文章于 2020-11-09 14:17:34 发布

阅读量1.1k

点赞数

原文 http://blog.csdn.net/damacheng/article/details/48245689

1、游戏说明

玩法跟COC基本没区别，只不过除了普通的兵，多了一些武将，并且社交系统比COC加强了不少，但总体来说交互性和实时性还是比较弱的。阅读以下文档之前最好对此款游戏有一些基本了解。此文档目的在于理清使用云平台架构全球大服的思路，若以后有类似的需求，可以进行一些参考。

2、机房架构及说明

首先看看全局的架构图：

首先，各种渠道的客户端限制了玩家连接的机房，比如大陆的包只能连到阿里云，跟其他因素无关，即使IP是美国、香港也是如此，这样可以尽可能的靠近玩家，不会让网络连接过慢影响体验。游戏在检测到新玩家的时候就给玩家加一个标识，比如大陆玩家标识为CN，香港玩家标识为HK，这一点跟COC是一样的。

另外看到在大陆地区使用了阿里云，其他地区都使用了亚马逊，同样的一套东西使用2个服务，多多少少有些别扭，这是因为亚马逊当时在大陆没有机房，但最近在北京开设了机房，如果以后要使用云服务，最好就统一使用同一个服务商提供的服务了。（阿里云在9月初又出故障，你还敢用吗？）

每个机房构成了一个区域服，属于这个区域的玩家的一些私有数据存储在各自的区域服中，比如在线奖励、任务、背包、邮件、本地副本、好友列表等一些玩家私有数据，因为这些数据跟其他的玩家不会发生交互，所以存放在各自的区域服即可。

另外一些可能跟其他区域玩家交互的数据，如公众聊天、军团数据、LBS，则统一放在一个机房，在图中则假设放在新加坡机房，另外还会处理一些全局的事务，如军团战的倒计时等。

具体把公共数据和公共服务放在哪个机房需要具体分体具体分析，其中一个因素是根据各机房之间的网络时延，由于需要在服务器之间传输数据，需要找到一个与各个机房传输网络最好的机房。

当各机房之间需要发生一些交互时，通过远程RPC的方式来进行交互。

3、机房内部架构图

再看看内部的架构图：

下面来分块讲解，由于看不到君临天下的具体实现，所以以下部分把所有可能的方案都列举了出来，仅供参考。

负载均衡器

使用它的目的是为了防止区域同时在线玩家过多。

阿里云方面提供的产品是：负载均衡SLB。

亚马逊方面提供的产品是：Elastic Load Balancing。

另外也可以自行搭建，如最新的Nginx版本就可以提供这些功能。

游戏逻辑服和全局后台任务

这里的服务是跑在阿里云或者亚马逊的虚拟主机中，具体的业余由于逻辑开发人员制定，但要保证不能存储状态数据，要保证一个玩家连接到任何一台逻辑服上都是一样的，逻辑服中也包含远程RPC的服务，如果使用Apache的Thrift来做远程RPC可减轻开发工作。

分布式缓存集群

缓存一些使用频繁的数据。

阿里云方面提供的产品是：开放缓存服务OCS，支持Memcached协议。

还有：键值存储KVStore for Redis，支持Redis协议。

亚马逊方面提供的服务是：Amazon ElastiCache，同时支持Memcached协议和Redis协议。

相关地址为：https://aws.amazon.com/cn/elasticache/

另外也可以自行搭建一套，个人建议使用Redis 3.0的集群版本。

分布式数据库集群

阿里云和亚马逊都提供了MySQL的服务，但都是单机的主从架构，存在单机瓶颈，无法横向扩展，虽然阿里云提供了一个解决方案，就是引入了一个中间件来自动分表分库，相关地址为：http://www.aliyun.com/product/drds/?spm=5176.7630237.3.32.y4m8wM

但因为在亚马逊上没有这种服务，所以不推荐使用，故下面主要介绍NoSQL的产品，它的好处就是不需要关注可扩展性的问题。

另外如果实在需要MySQL，也可以自行搭建，如使用一些相对比较成熟的开源方案。

如阿里开源的Cobar：https://github.com/alibaba/cobar

和OneProxy：http://www.onexsoft.com/?page_id=3383

优势是可以自动的分库分表，对应用层开发透明，缺点是会损失一部分功能，如无法使用存储过程，无法跨库进行JOIN操作，不过这点对互联网以及游戏业务来说影响不大。

阿里云提供的NoSQL产品为：开放结构化数据服务OTS。

亚马逊提供的NoSQL产品为：Amazon DynamoDB

相关地址为：https://aws.amazon.com/cn/dynamodb/

若自行搭建可选用Mongo、HBase等，这方面的候选方案比较丰富，可酌情选择。

分布式文件系统

主要是存储一些日志、战报等文件。

阿里云提供的服务为：开放存储服务OSS

亚马逊这一块服务分得比较细，可根据实际需求使用，如图：

自行搭建的话，若量不大，可存本地文件系统，如有必要可搭建分布式文件系统，如HDFS等等。

队列系统

引入的目的是会使用到一些Pub/Sub、异步计算等场景。

阿里云相关服务为：开放消息服务ONS

值得一提的是此服务支持延时消息。

亚马逊相关服务为：Amazon SQS

相关地址为：https://aws.amazon.com/cn/sqs/

不过功能略为简单，不能满足一些场景，不推荐使用。

也可以自行搭建，如RabbitMQ，RocketMQ等，若要支持延时队列，建议使用Beanstalkd，总而言之根据具体的场景来选择。

关于CDN、DNS、推送等一些技术方案此处先略过。

4、某些功能服务端方面的流程的分析

这里对一些需要涉及跨区域交互的游戏功能的服务端流程进行一些分析，仅是自己的主观分析。

场景1 世界排行榜

各个区域都维护一份自己的前200名的排行榜，定时再去其他区域拉取指定的前200名的排行榜，合并成一份世界前200名的排行榜即可。

场景2 攻城略池

就是找其他一些玩家攻击，其实搜到的玩家都是本区域的，如果实在要搜别的区域的玩家，可以定时去拉取一批玩家数据过来，再随机返回一个即可。战斗结束后，向双方的攻击/防守日志中插入一条记录，对于非本区域的玩家，则进行远程RPC调用一下即可。

场景3 群雄争霸

类似于竞技场，从一个时间段开始，比如上午7点开始，随机抽取全世界的一些玩家到一个小组里，你可以攻击小组里的其他玩家，到了规定的时间后结算排名，可以领取排名奖励。

可以在区域服的公共定时任务中来做，同样也是从其他区域服中拉取其他玩家的数据来生成小组。

场景4 公众聊天

对于公众聊天，游戏对语言进行区分，分为中文、英语、韩语、日语做了区分，华语渠道的玩家只能进中文聊天室，日本渠道玩家只能进日语聊天室，韩国渠道玩家只能进韩语聊天室，其他渠道玩家只能进英文聊天室。

这是因为游戏没有像COK那样做翻译功能，只能做这样的限制，让说同一种语言的人在一起聊天。

另外处于性能考虑，公众聊天切分成了数个聊天室，如下图：

这样做可以降低聊天消息的广播，这也是出于对网络延迟和性能的考虑。当某个聊天室的玩家发言后，就把该消息发向本区域和其他区域的处于同一个聊天室中的其他玩家。当玩家退出，再次登录进入聊天室时，并不能获取之前的聊天记录，可见不会存储公众聊天。

场景5 好友系统

搜索好友的功能，应该是交给全局服务区域来完成的，这里假设是在新加坡完成的，新加坡定时把其他区域的玩家基础表（只包含头像ID、等级等基础数据）异步增量同步一次。依据是对于刚注册的用户，无论是在本区域还是其他区域，都无法搜索到，而对于随机一个高等级的玩家来说，在本区域后者其他区域都可以搜到。这样做降低了实时性，降低了开发难度。

搜到好友之后可以查看玩家更具体的资料，如拥有的武将，阵形等等，可以通过国家来判断在哪个区域，远程RPC来获取资料。

然后可以申请添加对方为好友，也是利用远程RPC的方式通知对方，把自己添加到对方的好友申请列表中。对于玩家留言也是如此。

最后是LBS，应该也是全局处理的。

场景6 军团系统

军团是各个区域的玩家都能够随意加入或者离开的，军团没有国家的概念，故军团的数据应该是在全局区域存储的，这里是存储在新加坡，数据包括军团成员、军团科技等等，玩家获取或修改军团数据通过远程RPC操作。

对于军团搜索，刚创建的军团是可以马上搜索到的，这也印证了军团的数据是全局存储的。

对于军团聊天，跟公众聊天的处理方式是类似的，区别是会存储聊天记录。

对于军团援兵，就是广播给其他的在线的军团成员请求援兵，对方收到通知后则回馈，否则不做处理。

军团战的逻辑也基本没什么新意，不赘述。

偶像罗斯福

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
君临天下服务端架构调研

原文 http://blog.csdn.net/damacheng/article/details/482456891、游戏说明玩法跟COC基本没区别，只不过除了普通的兵，多了一些武将，并且社交系统比COC加强了不少，但总体来说交互性和实时性还是比较弱的。阅读以下文档之前最好对此款游戏有一些基本了解。此文档目的在于理清使用云平台架构全球大服的思路，若以后有类似的需求，可以进行一些参
复制链接

扫一扫