SGS 提供的主要功能 :
服务器端的扩展 : 传统的扩展方法是将整个游戏区域分成多个区 , 不同的区运行在不同的游戏服务器上 . 这带来两个问题 , 一个是处于不同区的玩家不能互相交互 , 另外一个是如果某个区发生的动作较少时 , 会出现服务器资源未被充分利用的情况 . 而在 sgs 的处理方式下 , 所有的处理被分割成为一个个小的执行单元 ( 称为 task), 这些 task 可以在组成网络的任何 sgs 服务器上执行 , 当用户增加时 , 系统自动增加处理线程 , 不再需要为了扩展而将不同的区分配到不同的服务器上面 . 这样既提高了资源利用率 , 又可以让所有的玩家进行交互 .
数据完整性 : sgs 提供了一个分布式的数据存储 , 一个 task 需要访问数据时 , 通过数据存储 api 进行访问 , 数据访问具有事务支持 , 当两个 task 发生冲突时 ,sgs 会自动协调 , 较年轻的 task 重新调度等待执行 , 而年老的 task 将会执行并直到结束 . 当前版本中的 sgs 数据存储未使用关系数据库 , 而是使用了 berkeley db. 任何 java 对象 , 只要实现了 ManagedObject 标志接口 和 Serializable 接口后即可自动透明存储 .(sgs 的存储机制好像是可扩展的 , 论坛上已经看到有人在讨论 mysql 的存储插件 )
简单的编程模型 : 从应用开发的角度来看 ,sgs 提供了 api 屏蔽了多数的底层复杂性 , 例如线程调度 , 事务处理 , 等等 , 应用程序只需要开发并装配自己的对象 , 监听响应客户端事件 , 自己管理持久化的 ManagedObject 对象生命周期即可 .
两种通信模型 : 一种是 client/server 的通信 , 即每个 client 只和 server 通信 , 由 server 来负责数据的处理和转发 . 另外一种是 channel 机制 ( 类似一对多的广播 ),channel 由 server 创建并维护 , 每个 channel 可以添加多个 client,server 可以监听 channel 中的所有通信或者具体某个 client 的通信 . 也可以给 channel 中的全部或者部分 client 发送消息 . 加入 channel 的 client 可以收到其它任何 client 发送的消息 .channel 下面 client 之间的通信不需要 server 端的介入 . 由于所有通信的数据格式都是字节数组 , 所以应用程序需要开发自己的应用层协议 .
可扩展的机制 : sgs 应用程序访问数据 , 使用 channel, 创建 task 都是通过 ”Manager” 来进行的 . 目前一共有三种缺省的 ”Manager” ,DataManager,ChannelManager,Taskmanager. 但可以扩展开发自己的 Manager, 例如在 sgs 中要求 task 应该是尽量快的执行 (task 允许执行的时间上限可以配置 ) , 所以如果出现调用可能导致阻塞的系统方法时 , 就需要开发一个扩展的 Manager.
Darkstar 项目为游戏开发者提供了一个开发环境。在该环境中，开发者只需通过使用虚拟环境的固有并行性就可以扩展该环境，而不需要学习分布式计算或多线程编程。 Darkstar 项目实现了开发者的梦想，服务器端应用程序代码可以运行在单机器单线程上。事实上，服务器执行的任务可以分布运行在许多机器和线程上，在某种程度上增大了 扩展和容差能力。系统优化了游戏应用程序需要的低延迟时间。Darkstar 项目集群的每一个节点都运行了一份游戏服务器代码（由游戏开发者编写，包含游戏逻辑）的拷贝，这些代码都位于 Darkstar 项目协议栈之上。协议栈以一组服务的方式显示给游戏服务器。这些服务控制游戏的持久状态、通信通道，以及任务的创建和调用。任务，游戏服务器的工作单元， 响应玩家或一些内部触发器发出的消息，在一次事务处理中隐式地执行。并行控制对游戏开发者而言是透明的，当一个任务需要访问某个已被另一个任务锁定的对象 时，处于事务处理中的任务将被包装且放弃运行，稍后会被重新调度运行。任务的事务性质也确保了相关任务可以建立串行的执行序列。
可以通过 使用多个线程来扩展单个节点，这些线程是由任务调度程序控制的。更进一步的扩展允许多个节点(可能是一台实际机器或者是一台虚拟机)协作运行同一个游戏。 这项功能是由 Darkstar 项目的服务结构提供的，应用程序运行在基础结构上，确保了系统执行的任何任务都可以从一台机器迁移到另一台机器，以平衡负载和增强可靠性。
所 有游戏对象存在的时间都比单个任务存在的时间长，在数据服务中需要创建它们并将将其保存在数据库中。任务在操作任何对象之前，必须先读取它们，确保它们在 以最新的状态工作。数据服务由数据库支持。当前数据库服务器使用的是 Berkeley DB，一方面因为其性能，另一方面因为它是开源软件。然而，数据服务间的接口和后台数据库也可以是其他数据库，比如 Postgres 或者 mySQL。
Darkstar 项目通过会话服务和通道服务协调通信。会话服务提供游戏客户端和游戏服务器的直接通信。通道服务提供了一个发布/订阅通信机制，通道上的消息可以被传送给 在该通道上的所有订阅者；此机制提供客户端和客户端谈话服务。这两种通信形式都是基于由底层操作系统提供的基本通信机制的抽象概念，可以在 Darkstar 项目集群的任何特殊节点中释放通信端点。这样，服务器端集群中的任何特殊中间节点的通信都是自由的。这些通道可以从一个服务器移到另一个服务器，以优化性 能或进行故障恢复。
如果将数据服务的用途和通信通道的可移植性结合使用，那么各个任务就可以运行在任意机器上，且不会改变任务的执行功 能。也就是说，负载可以从一个机器移到另一个机器，在移动过程中，通过简单地增加更多机器到运行游戏的节点集上，就可以增加或减少负载容量。此 外，Darkstar 项目基础结构内的元服务将参与动态移动任务，确保数据访问和通信的位置。这些服务，对游戏开发者来说是不可见的，他们可以观测 Darkstar 项目基础结构中的基本服务来决定系统节点的最佳负载，检测故障并且恢复到初始状态，检测新的资源以便在将来需要使可以增加到整个系统。
第 三方的厂商可以提高 Darkstar 项目的基本服务。新服务可以被引进并参加任务的执行活动。这些服务可以与事务机制进行交互，并观测使用元服务的整个系统。例如，它将可以访问完整的关系型 数据库，跟踪游戏统计信息，且允许查询这些统计信息，以及在不需要游戏数据服务存储信息的情况下扩大游戏管理能力，优化许多游戏需要的低访问延迟性。
项目优点总结
Darkstar 项目架构具有许多重要优点，包括：
- 一个简单的开发模型
虽 然 Darkstar 项目基础结构提供的是可扩展的多线程多节点环境，但是游戏服务器开发者却如同在单机器和单线程的环境中编写代码。该模型最小化或消除了数据存取竞争、线程 调度和工作负载分布问题，使得开发者可以集中精力编写游戏，而不必关注可伸缩的系统机制。众所周知，编写一个复杂、多线程的游戏应用程序是一件困难且辛苦 的事情，而拥有成功开发此类应用程序经验和技能的程序员又少之又少。使用 Darkstar 项目基础结构，开发复杂性将会极大地减小，且程序员需要的技能仅仅与游戏有关而与环境无关。 - 通过动态负载均衡改进的可伸缩性
架 构允许系统以一种线性的方式扩展来满足计算资源日益增长的需求。额外的需求通常是由于同时在线玩家数量的增加、应用程序复杂性的增加或者两者同时发生引起 的。无论哪种方式引起的，考虑到游戏运行时的动态行为，面对增加的任务负载，该架构都自动地执行负载平衡来给与响应。当需要更多的容量时，简单地增加更多 的计算节点到可用的服务器池中。多个游戏甚至可以共享计算中心的服务器。在当今的游戏行业，现存架构是不可能完全实现这种资源共享和可伸缩性的。 - 为今后的计算技术而设计
各主要芯片设计使用并行性技术，拥有性能改善功能。单芯片多线程虽然保存了能量，增大了吞吐量，扩展了摩尔定律，但是如果那些程序要想在硬件新阶段受益，就需要以不同的方式来编写。Darkstar 项目基础结构拥有性能改善功能，且不需要改变游戏代码本身。 - 健壮的游戏运作能力
Darkstar 项目系统基础结构的设计方便了大型多玩家在线游戏的开发，而且该游戏将比迄今为止该行业中的任何游戏都健壮。游戏服务器崩溃、数据库破坏和编程错误是很常 见的，为此，公司需要组织大型的内部开发者团队、网络专家和操作人员来维护游戏。这已经在需要绝对可靠性的金融和企业领域得到证实，我们相信由 Darkstar 项目创建的游戏将会更加健壮，维护和增强也更加简单，且不以牺牲交互游戏需要的性能为代价。这样，将会缩短开发周期（对于新游戏和新特性，从构思到市场所 需时间变得更短），减少开发成本，以及减少支持和运作成本。 - 有效利用计算资源
Darkstar 项目是一个完整的游戏架构，也就是说其运作模型不需要将特定的硬件分配在特定的游戏区域。当游戏需要时，可用的服务器资源可以动态的进行再分配。使用 Darkstar 模型，您不会遇到碎片架构存在的限制，如在 Second Life 和多数其他 MMO 这样的碎片架构中，一些服务器过载，而另一些服务器处于闲置状态。例如，公开的有用数据显示：Second Life 的特点在于当孤岛容量受到严重限制时，整个服务器仅仅使用了5% 或者更少。然而，他们却仍然一直在增加许多机器到他们的基础结构中，试图去跟上订阅者数量的增长。启用的 Darkstar 项目架构有更高的服务器利用率，这样节约了机器成本，同时也节约了支持基础结构和运作的成本。所以，成本完全减少了，这些成本可以有效地分配到跨单个游戏 或多个游戏的多协议栈上。在当今的游戏行业中，您还发现不了这种部署的灵活性和计算机资源的重用性。