架构之美 -- 第3章 伸缩性架构设计

对服务端应用而言，系统的伸缩性是最基本的需求。这就意味着系统应该是分布式的，并发的。一个理想的可伸缩性架构应该将分布式，并发的特征对上层应用隐藏，尽管完全隐藏这些特征不现实，而且需要上层应用的开发者遵循一定的编程模型(例如反应式的)，但开发者无需将较多的精力放在伸缩性架构的具体实现，而是遵守这样的架构并重点关注应用逻辑的实现方面。

作者以游戏项目为例介绍了两种伸缩性架构方案，一种是将游戏基于地理位置分不同区域实现的，每个区域彼此独立，限定地理区域的大小，这样服务器就不会因为太多用户进入这个区域而拥塞，但这种方案需在开发/部署的时候决定哪些区域应该放在一台服务器上；另一种方法是分区。一个分区是该区域的一份副本，运行在它自己的服务器上，独立于其他的分区。这样增加副本就增加了该区域允许的用户数，但这种方案的缺点是不同分区彼此独立，导致不同分区间的玩家彼此之间不能交互。

对于一个复杂的系统，用一组相互联系的服务来构建，“分而治之”是最基本的方法。每种服务都可以用一个接口来描述，这让使用该服务的程序不会受到底层实现变更的影响，同时也支持这些实现可以独立地完成。常见的几个核心服务：数据服务、任务服务、会话服务、通道服务

数据服务应该是分布式系统最基本的服务和难点。一个分布式系统中往往又需要保持数据的一致性，这就需要提供集中式的数据服务，也就带来数据资源访问和操作的竞争问题，从而可能导致系统的性能瓶颈。对数据服务的设计需要充分考虑数据的特点，例如数据的读写频度，更新频度，生命周期等，只有把这些数据特点分析清楚后才可能设计出合适的数据服务。

任务服务用于调度或执行任务。这些任务要么是响应从客户端收到的某个事件，要么是服务器本身的内部逻辑发起的。

会话服务是在登录和认证后，客户端与服务器之间建立的一种联系。通过会话机制向应用层隐藏了客户端和服务器的真实端点，同时会话服务也需要负责确保维持消息的顺序。如果来自某个客户端的前一条消息所引发的任务还没有完成，后一条消息就不会提交，从而大大简化了任务服务

通道服务在作者的项目中是一种一对多的通信机制。在概念上，通道可以由任何数目的客户端加入，任何发往该通道的消息都会送达所有与通道相关的客户端。

除了这些核心的服务，分布式系统还需要负载均衡机制，将系统的服务请求根据一定策略分发/转移到系统中各个节点