Darkstar项目的工作原理

游戏客户端与运行在Darkstar平台上的服务器端应用程序(拷贝)进行数据交互. 负载均衡和错误恢复均由Darkstar服务管理.

Darkstar是Sun实验室的一个开源在线游戏平台项目, 本文主要介绍Darkstar的工作原理.

Darkstar集群服务器中的每一个节点都运行一份游戏逻辑代码的拷贝, 这些游戏逻辑代码都位于Darkstar协议栈之上(见下图). 我们从下图可以看到游戏服务器以服务的方式提供给客户:

任务服务: 调度和运行任务.
数据服务: 确保游戏具有稳定的状态.
通道和会话服务: 建立和管理游戏和游戏之间, 游戏和玩家之间的数据通信.

Client: 客户端
Game Server: 游戏服务器
Project Darkstar Stack: Darkstar项目协议栈
Darkstar meta: Darkstar元服务

在Darkstar模型中, 任务总是以传输方式运行, 对游戏开发者而言任务是透明的, 开发者可以对任务进行并行控制. 比如当某项任务需要访问某个已被其它任务锁定的对象资源时, 处于传输中的任务将被包装且放弃运行, 稍后会进行重新调度运行. 任务的传输机制也确保了相关任务可以建立串行的执行序列.

我们还可以通 过使用多个线程来扩展单个节点, 这些线程是由任务服务程序来管理的. 额外的扩展能力可以使多个节点(可能是一台实际的机器或者是一个虚拟机)协作运行同一个游戏. 这项功能是由数据服务和通道服务程序共同提供的, 它们能够确保运行在Darkstar环境中的任务都可以运行在任意一台机器上, 而任务的执行结果是相同的. 现在开源版本的Darkstar服务器不提供多个节点的能力, 我们的目标是在下一个版本提供此项功能.

任何游戏目标资源的存在时间都会比 单个被创建的任务和保存在数据仓库中的时间要长. 在任务确定它们需要的资源的最新状态后, 任务必须能够从任何这些目标资源中读取数据. 数据仓库实际上就是一个数据库. 当前Darkstar项目的服务器使用的是Berkeley DB数据库. 两个原因, 一是性能, 二是Berkeley DB是开源软件. 不过, 数据服务和数据库之间接口也可以使用其它的数据库, 比如Postgres或者SQL.

服 务器和客户端之间的通信使用了会话服务. 会话服务向游戏客户端和游戏服务器之间提供了一个低延持的直接通信方式. 当一个客户(游戏用户)登陆到游戏中, 会话被建立起来, 会话在用户退出游戏之前一直都是客观存在的. 客户端和其它客户端之间的通信是通过通道服务来实现的. 通道服务提供了一个发布/订阅形式的通信机制. 客户端加入到一个通道中, 通道中的任何成员都会收到所有发到该通道的信息. 会话和通道都是基于基本通信机制的抽象概念, 由底层操作系统提供, 允许一个通道被移动到另外一台机器, 而且不会影响到用户的使用.

Darkstar服务器由Java语言编写, 使用Java语言使在运行时插入代码和通过延迟绑定(类似动态链接库或者更加复杂的DLL)无缝集成到进程当中变为可能. 这也使Darkstar项目小组能够创建一个平台, 在任何层次上都是可插入的而且不用去求助于多个进程和IPC通信机制. 另外, 广泛使用的Java技术能够帮助开发者创建真正的跨平台和而且有广大市场潜力的游戏.

及时提供负载均衡能力

使用数据仓库和可移动通道意味着任何任务都可以运行在任何机器上, 而且不会改变任务的属性. 这同时也意味着负载能够从一台机器转移到另外一台机器上. 而且我们还可以及时通过简单增加更多的机器到多个节点当中来提高游戏网络的处理能力.

另外, Darkstar服务器提供了元服务, 它能够动态地移动任务, 从而能够确保数据存取和通信的可靠性.

第 三方的厂商也可以来提高Darkstar服务器提供的基本服务. 新的第三方服务可以无缝的集成到任务当中. 这些服务可以与传输机制进行交互和观察使用元服务的整个系统. 例如. 我们可以通过增加访问一个完整的关系数据库来跟踪游戏的实时统计信息, 而且允许查询这些统计信息, 并扩展游戏的管理能力, 我们将不需要把这些信息都存储到在单个数据仓库中. 然后我们可以随时对游戏需要访问的数据仓库进行优化.