《架构之美》阅读笔记三

　　今天阅读了《架构之美》第三章，主要利用游戏软件开发作为例子，向我们展示了在设计一些系统架构时，确保系统的伸缩性的重要性。对于一款运行在网络上或互联网上的系统，如果你希望在设计之初就将系统的适用范围的误差控制在几个数量级以内的想法是荒谬的。因为我们无法确定设计出的系统在将来的运用时将会有多少客户会同时使用它，且不同时间使用量也会有不同，此时我们要做的就是让我们的体统具有很强的伸缩性，以适应不断变换的需求，主要使用胖客户端瘦服务器的方式，同时配备并行连接服务器的方式。

　　书中以Darkstar项目作为例子，讲述了它的架构。游戏架构要求用户体验好，大的延迟不被接受，甚至牺牲吞吐量换取少的延迟。而企业环境的架构重在吞吐量，管理业务。有一点延迟可以接受。

　　一般情况下，处理拥塞的解决方案：
　　1. 基于地理位置来实现。游戏设计包含不同的游戏区域，每个虚拟区域运行一台服务器，每个区域拥有自我限制功能，当人数过多时，服务拥塞，游戏变慢，趣味性下降，用户就转向更有趣的区域，响应时间就会得到改进。（对于棋牌类游戏，每个房间或区域有人数限制，满的房间可以限制进入）
　　这种开发方法的问题：游戏设计时，需要决定哪些区域放在一台服务器上，而添加新的区域时比较容易，若改动原来的区域，可能需要改动代码，这些都是开发的工作量。

　　2. 分区sharding。一个分区是一个区域的副本，运行在自己的服务器上，独立于其他分区，不同的玩家进入同一个区域的不同副本（分区）。这样的缺点时，不允许不同副本的玩家彼此进行交互。

　　3. Darkstar架构就是克服以上缺点，支持随时伸缩，同时又不要求游戏逻辑受到伸缩影响。支持动态响应负载，而不是放在游戏设计中完成。　　

　　DarkStar是由一组服务组成。每个服务定义为一个小的编程接口。这些接口很像经典操作系统的服务，支持对服务端的访问持久存储、调度并执行任务、与游戏的客户端进行通信。这些服务的程序不会受低层实现变更的影响，因为每个服务由一个接口来描述。当接口不变时，一个服务的变更，不会影响其他服务的实现。这是一个"分治"的过程。另外，将基础设施设计为一组服务，可以将这些服务在不同场景下进行不同的组合，更加灵活，复用性强。一组服务可以组成一个Darkstar栈，Darkstar栈中具体包含哪些服务可以由一个配置文件来设置。

　　DarkStar架构利用一些创新的方法解决了，伸缩性，延迟和通信的要求，这种架构在之后是非常可以借鉴的。