第三章伸缩性架构设计，书中采用了Darkstar的项目为例，这是一个虚拟游戏项目，所以该项目的服务器必须拥有较强的伸缩性，它受在线人数、时间、热度等多方面的影响，在它负载的时候应该适时进行变化服务器的数量和连接方式以应对不同的需要。游戏的架构和实现直接影响到游戏的性能和游戏玩家的体验，所以对整体架构的优化是提高游戏性能的关键步骤，也是不可缺少的。通过多线程和多机器来提高整体的游戏效率，以使得整个游戏项目得到质的提升，这就是伸缩性架构设计。
系统的伸缩性需求
如大型在线游戏，需要满足大量用户。在线用户数量短时间内可能有很大的变化。
这其中隐含的需求是： 多用户 、并行 、分布式系统，系统运行在多台机器上 、高可扩展性（用于加入新的故事情节，意味着新的代码） 、高稳定性、可靠性（一个用户崩溃，不影响其他用户） 、数据一致性（多个用户看到同一个东西的状态应该是一样的）
架构设计目标
即另外一个需求，对其他开发者部署出一个简单的编程模型，程序员可以将系统视为一个单机开发环境。
隐藏分布式和并发是一件困难的事。需要一种严格限制的编程模型。
延迟的需求
游戏架构要求用户体验好，大的延迟不被接受，甚至牺牲吞吐量换取少的延迟。
而企业环境的架构重在吞吐量，管理业务。有一点延迟可以接受。
一般情况下，处理拥塞的解决方案：
1. 基于地理位置来实现。游戏设计包含不同的游戏区域，每个虚拟区域运行一台服务器，每个区域拥有自我限制功能，当人数过多时，服务拥塞，游戏变慢，趣味性下降，用户就转向更有趣的区域，响应时间就会得到改进。（对于棋牌类游戏，每个房间或区域有人数限制，满的房间可以限制进入）
这种开发方法的问题：游戏设计时，需要决定哪些区域放在一台服务器上，而添加新的区域时比较容易，若改动原来的区域，可能需要改动代码，这些都是开发的工作量。
2. 分区sharding。一个分区是一个区域的副本，运行在自己的服务器上，独立于其他分区，不同的玩家进入同一个区域的不同副本（分区）。这样的缺点时，不允许不同副本的玩家彼此进行交互。
3. Darkstar架构就是克服以上缺点，支持随时伸缩，同时又不要求游戏逻辑受到伸缩影响。支持动态响应负载，而不是放在游戏设计中完成。
游戏架构的思考、改进
游戏与虚拟架构的特点：
1. 由于此行业的保密性，专用性， 其性能测试，数据指标比较难获取，另外很多偶然性的因素，使得无法对不同的基础设施做比较，对通用基础设施的测试更加困难。
2. 很多服务器的架构都是定制的，很少有可复用的基础设施假设，不注重这方面的积累。
Darkstar架构是围绕服务器性能做出了很多关键决定。
1. Darkstar拒绝在服务器中存放任何重要信息。
所有生存周期超过一个任务的数据都需要放入"数据服务"中统一管理。这是Darkstar的核心。为什么？因为它能检测数据的并发问题，对游戏程序员隐藏这些细节，让服务器能利用多核架构，并实现整体是伸缩性。
2. 延迟的分析。
以上对并行性的处理，会引发一些延迟。将数据放入内存，才能将延迟最小化，是主流观点。
而采用"数据服务"的方式会影响性能，访问数据会引入一定延迟。但比其他方法会更有竞争力：1）持久化存储可以利用数据库缓存和一致性，尽量减少数据访问延迟。2）将相关联的玩家放到一个服务器上去，也可以利用数据库的标准缓存技术，减少访问和保存持久数据的延迟。（与基于地理位置的技术不同，这部分工作无需放入游戏开发工作中，而是根据运行时进行优化,（类似于编译优化与运行优化））
3. 可靠性更高。
利用高并发来弥补持久化存储的延迟损失，方案总体上是更有优势，也更符合未来芯片基础架构发展的方向。另外，持久化"数据服务"将服务器失效而导致的数据丢失减少到了最小。
4. 简化游戏程序员工作。
当同时要求支持伸缩性和减少延迟的开发目标，那么开发者需要编写自己的分布式和多线程基础架构和代码，这对开发者的要求更高，且工作量更大。而Darkstar将所有任务封装到事务中，并在"数据服务"中检测数据冲突，开发者就能享受多线程的好处，又不必在他们的代码中引入锁协议、同步和信号量。 Darkstar提供透明的负载平衡。
但是开发者还是需要了解Darkstar的底层并发和分布式实质，需要遵循一定编程模型，尽量利用数据服务的并发性，提升游戏的整体性能。
