阅读笔记二

一般情况下,处理拥塞的解决方案:
1. 基于地理位置来实现。游戏设计包含不同的游戏区域,每个虚拟区域运行一台服务器,每个区域拥有自我限制功能,当人数过多时,服务拥塞,游戏变慢,趣味性下降,用户就转向更有趣的区域,响应时间就会得到改进。(对于棋牌类游戏,每个房间或区域有人数限制,满的房间可以限制进入)
这种开发方法的问题:游戏设计时,需要决定哪些区域放在一台服务器上,而添加新的区域时比较容易,若改动原来的区域,可能需要改动代码,这些都是开发的工作量。

2. 分区sharding。一个分区是一个区域的副本,运行在自己的服务器上,独立于其他分区,不同的玩家进入同一个区域的不同副本(分区)。这样的缺点时,不允许不同副本的玩家彼此进行交互。

3. Darkstar架构就是克服以上缺点,支持随时伸缩,同时又不要求游戏逻辑受到伸缩影响。支持动态响应负载,而不是放在游戏设计中完成。


Darkstar的架构

DarkStar是由一组服务组成。每个服务定义为一个小的编程接口。这些接口很像经典操作系统的服务,支持对服务端的访问持久存储、调度并执行任务、与游戏的客户端进行通信。
这些服务的程序不会受低层实现变更的影响,因为每个服务由一个接口来描述。当接口不变时,一个服务的变更,不会影响其他服务的实现。这是一个"分治"的过程。
另外,将基础设施设计为一组服务,可以将这些服务在不同场景下进行不同的组合,更加灵活,复用性强。一组服务可以组成一个Darkstar栈,Darkstar栈中具体包含哪些服务可以由一个配置文件来设置。

从宏观结构上来看

(分层、模块化、通信机制)

每个Darkstar栈运行在一个服务器上,Darkstar栈就是服务的副本和游戏逻辑的副本。客户端连接到其中一个服务器,与该世界的抽象表示进行交互。

每个副本可以与客户端独立的交互,不需要处理相同事件。复制主要是用于支持伸缩性。游戏逻辑也不知道其他服务器上的副本。而不同服务器上的副本协作是由Darkstar项目的基础设施完成的。
游戏客户端与服务端的通信机制包含两种,一种是直接通信,另外一种是"发布-订阅"模式。
Darkstar栈由一组元服务来协调,这是一组网络访问服务,对游戏程序员是不可见的。这些服务支持在线的副本相互协作,共同运营整个游戏。而且副本间相互独立,某副本失效,会发起失效恢复操作。
此外,这些Darkstar元服务会跟踪各副本

 

posted @ 2017-02-12 19:27  Huangliping  阅读(81)  评论(0编辑  收藏  举报