Darkstar的架构
DarkStar是由一组服务组成。每个服务定义为一个小的编程接口。这些接口很像经典操作系统的服务，支持对服务端的访问持久存储、调度并执行任务、与游戏的客户端进行通信。
这些服务的程序不会受低层实现变更的影响，因为每个服务由一个接口来描述。当接口不变时，一个服务的变更，不会影响其他服务的实现。这是一个"分治"的过程。
另外，将基础设施设计为一组服务，可以将这些服务在不同场景下进行不同的组合，更加灵活，复用性强。一组服务可以组成一个Darkstar栈，Darkstar栈中具体包含哪些服务可以由一个配置文件来设置。
从宏观结构上来看
（分层、模块化、通信机制）
每个Darkstar栈运行在一个服务器上，Darkstar栈就是服务的副本和游戏逻辑的副本。客户端连接到其中一个服务器，与该世界的抽象表示进行交互。
每个副本可以与客户端独立的交互，不需要处理相同事件。复制主要是用于支持伸缩性。游戏逻辑也不知道其他服务器上的副本。而不同服务器上的副本协作是由Darkstar项目的基础设施完成的。
游戏客户端与服务端的通信机制包含两种，一种是直接通信，另外一种是"发布-订阅"模式。
Darkstar栈由一组元服务来协调，这是一组网络访问服务，对游戏程序员是不可见的。这些服务支持在线的副本相互协作，共同运营整个游戏。而且副本间相互独立，某副本失效，会发起失效恢复操作。
此外，这些Darkstar元服务会跟踪各副本的负载，在需要的时间重新分配负载，或随时添加服务器，增加总体容量。
基本的组件/服务
对于游戏程序员而言，可见的架构就是栈中包含了一组服务，而4个基本服务是必须的。数据服务、通道服务、客户端会话服务、任务服务。
数据服务
数据存储、数据读取、数据操作。
特征：大部分都是持久化数据、数据间静态关系少、很少有复杂查询、需要对延迟进行优化、需要修改的数据多
选型：与标准数据库的使用方式有区别、数据库简单的命名策略，编程语言上对对象的引用
任务服务
用于调度、执行任务。
任务来源：响应某个事件、或游戏内部逻辑触发的。常见任务的操作包括：从数据服务中读取、修改一些数据，可能会有一些通信、或者生成其他的任务。
时间限制：执行任务的时间必须很短。配置中可以设置，默认值是100ms。
底层特征：Darkstar的底层在尽量的调度最多的任务。但对游戏程序员，因事件只响应一个任务。
并行性：客户端产生的任务、服务端响应逻辑的任务是并行执行的。
数据竞争：由并行性带来的数据竞争，同步、事务性操作（一个操作要么全部成功，要么回退）
通信机制：若任务包含事务操作，通信机制也必须支持事务
通信服务、会话服务：
登录、认证后建立会话，监听客户端消息，并响应生成任务。会话也负责维持消息的顺序，前一消息未处理完，后一消息就先不提交。这样也让"任务服务"得到了简化。因为任务服务假定其任何时候触发的任务都是并发的。
通道服务：
一对多的通信机制。客户端之间可以交互，这种方式不能采取让客户端直接通信的方式，虽然这样会减轻服务端的负载，但容易产生作弊行为。所有通道信息都必须经过服务器。
这些抽象层不会暴露客户端或服务端的真实端点，这样Darkstar系统能将服务端的通信端点从一个服务器上移到另外一个机器上，同时又不改变客户对通信的感觉。底层的基础设施可以根据需要进行动态调整。