问题、品质需求
1. 系统的伸缩性需求。如大型在线游戏，需要满足大量用户。在线用户数量短时间内可能有很大的变化。
这其中隐含的需求是：
多用户
并行
分布式系统，系统运行在多台机器上
高可扩展性（用于加入新的故事情节，意味着新的代码）
高稳定性、可靠性（一个用户崩溃，不影响其他用户）
数据一致性（多个用户看到同一个东西的状态应该是一样的）
2. 架构设计目标
即另外一个需求，对其他开发者部署出一个简单的编程模型，程序员可以将系统视为一个单机开发环境。
隐藏分布式和并发是一件困难的事。需要一种严格限制的编程模型。
典型的游戏服务器开发模型：反应式
客户端（游戏机）（生成事件） - 服务端的事件监听器（监听事件，并生成任务） - 此任务可与多个客户端进行交互
或者是服务端自己周期性生成任务。
这是一种典型的胖客户端机制，适用于游戏和虚拟世界，也适用于J2EE和Web服务的应用。
区别另外一种经典的企业级架构：
瘦客户端 - 胖客户端 - 更胖的数据库服务器。服务器保存客户端的绝大部分信息，绝大多数真正的工作在服务器上完成。
在游戏的软件架构中。不被修改的数据都被放在客户端完成，只有共享的数据才放在服务器，服务器尽量保持简单，减少计算。保持共享事实的最终来源，防止玩家作弊。客户端只访问少量的状态数据，但访问的数据大部分会被改写。
而另外一种架构是90%的数据都是只读的，大多数任务会读取大量数据，再修改少量数据。
3. 延迟的需求
游戏架构要求用户体验好，大的延迟不被接受，甚至牺牲吞吐量换取少的延迟。
而企业环境的架构重在吞吐量，管理业务。有一点延迟可以接受。
一般情况下，处理拥塞的解决方案：
1. 基于地理位置来实现。游戏设计包含不同的游戏区域，每个虚拟区域运行一台服务器，每个区域拥有自我限制功能，当人数过多时，服务拥塞，游戏变慢，趣味性下降，用户就转向更有趣的区域，响应时间就会得到改进。（对于棋牌类游戏，每个房间或区域有人数限制，满的房间可以限制进入）
这种开发方法的问题：游戏设计时，需要决定哪些区域放在一台服务器上，而添加新的区域时比较容易，若改动原来的区域，可能需要改动代码，这些都是开发的工作量。
2. 分区sharding。一个分区是一个区域的副本，运行在自己的服务器上，独立于其他分区，不同的玩家进入同一个区域的不同副本（分区）。这样的缺点时，不允许不同副本的玩家彼此进行交互。
3. Darkstar架构就是克服以上缺点，支持随时伸缩，同时又不要求游戏逻辑受到伸缩影响。支持动态响应负载，而不是放在游戏设计中完成。
Darkstar的架构
DarkStar是由一组服务组成。每个服务定义为一个小的编程接口。这些接口很像经典操作系统的服务，支持对服务端的访问持久存储、调度并执行任务、与游戏的客户端进行通信。
这些服务的程序不会受低层实现变更的影响，因为每个服务由一个接口来描述。当接口不变时，一个服务的变更，不会影响其他服务的实现。这是一个"分治"的过程。
另外，将基础设施设计为一组服务，可以将这些服务在不同场景下进行不同的组合，更加灵活，复用性强。一组服务可以组成一个Darkstar栈，Darkstar栈中具体包含哪些服务可以由一个配置文件来设置。
从宏观结构上来看
（分层、模块化、通信机制）
每个Darkstar栈运行在一个服务器上，Darkstar栈就是服务的副本和游戏逻辑的副本。客户端连接到其中一个服务器，与该世界的抽象表示进行交互。
每个副本可以与客户端独立的交互，不需要处理相同事件。复制主要是用于支持伸缩性。游戏逻辑也不知道其他服务器上的副本。而不同服务器上的副本协作是由Darkstar项目的基础设施完成的。
游戏客户端与服务端的通信机制包含两种，一种是直接通信，另外一种是"发布-订阅"模式。
Darkstar栈由一组元服务来协调，这是一组网络访问服务，对游戏程序员是不可见的。这些服务支持在线的副本相互协作，共同运营整个游戏。而且副本间相互独立，某副本失效，会发起失效恢复操作。
此外，这些Darkstar元服务会跟踪各副本的负载，在需要的时间重新分配负载，或随时添加服务器，增加总体容量。