任务的可移动性
要实现负载的动态均衡能力，就应该实现任务的可移动性，从一台机器移到另外一台机器上。这是系统伸缩性的要求和目标。
技术要求：
1. 任务是由java写成，这样物理机器上运行JVM，任务就可以运行
2. 任务数据来源。任务的数据都来自数据服务。而数据服务是所有游戏实例和Darkstar栈所共享的。
3. 通信由"会话服务"或"通道"来实现中介。其抽象能力，使得特定的会话由一个服务器移向另外一个服务器。
4. 负载的监控。Darkstar元服务的工作，这是网络层面的服务，对程序员不可见，但对Darkstar栈中的服务是可见的。不会影响游戏的逻辑性，而能实现系统的伸缩性。
5. 利用伸缩机制来实现系统的高容错能力。由于任务和通信机制是与具体机器无关的，且任务本身也是持久对象，保存在"数据服务"中。若任务中断，等同于事务中断，系统会重新调度不同的机器运行。这样的后果是延迟有点长，但系统的正确性不变。
游戏架构的思考、改进
游戏与虚拟架构的特点：
1. 由于此行业的保密性，专用性， 其性能测试，数据指标比较难获取，另外很多偶然性的因素，使得无法对不同的基础设施做比较，对通用基础设施的测试更加困难。
2. 很多服务器的架构都是定制的，很少有可复用的基础设施假设，不注重这方面的积累。
Darkstar架构是围绕服务器性能做出了很多关键决定。
1. Darkstar拒绝在服务器中存放任何重要信息。
所有生存周期超过一个任务的数据都需要放入"数据服务"中统一管理。这是Darkstar的核心。为什么？因为它能检测数据的并发问题，对游戏程序员隐藏这些细节，让服务器能利用多核架构，并实现整体是伸缩性。
2. 延迟的分析。
以上对并行性的处理，会引发一些延迟。将数据放入内存，才能将延迟最小化，是主流观点。
而采用"数据服务"的方式会影响性能，访问数据会引入一定延迟。但比其他方法会更有竞争力：1）持久化存储可以利用数据库缓存和一致性，尽量减少数据访问延迟。2）将相关联的玩家放到一个服务器上去，也可以利用数据库的标准缓存技术，减少访问和保存持久数据的延迟。（与基于地理位置的技术不同，这部分工作无需放入游戏开发工作中，而是根据运行时进行优化,（类似于编译优化与运行优化））
3. 可靠性更高。
利用高并发来弥补持久化存储的延迟损失，方案总体上是更有优势，也更符合未来芯片基础架构发展的方向。另外，持久化"数据服务"将服务器失效而导致的数据丢失减少到了最小。
4. 简化游戏程序员工作。
当同时要求支持伸缩性和减少延迟的开发目标，那么开发者需要编写自己的分布式和多线程基础架构和代码，这对开发者的要求更高，且工作量更大。而Darkstar将所有任务封装到事务中，并在"数据服务"中检测数据冲突，开发者就能享受多线程的好处，又不必在他们的代码中引入锁协议、同步和信号量。 Darkstar提供透明的负载平衡。
但是开发者还是需要了解Darkstar的底层并发和分布式实质，需要遵循一定编程模型，尽量利用数据服务的并发性，提升游戏的整体性能。