复制的负载均衡服务

在本章中，我们将更进一步接近分布式系统的实际应用场景。我们将讨论一些在世界各地真实系统中广泛采用并实际实现的架构模式。这将帮助学习者更好地理解分布式系统在实践中的运作方式。

我们将在本课中讨论的第一个模式是复制的负载均衡服务。从名称就可以大致了解其核心思想。

无状态服务

复制的负载均衡服务模式的第一种类型是无状态服务。

无状态服务是指那些无需保存状态即可正确运行的服务。

《设计分布式系统》，布伦丹·伯恩斯

在无状态服务中，节点不需要预先加载额外的数据来处理请求。当请求到达时，无状态服务可以检查请求内容，从数据库获取所需数据，并返回结果。它不会依赖任何先前请求所携带的预加载数据，也不会在自身中存储任何状态。整个过程非常简单：收到请求后触发服务，处理请求，完成后即忘记该请求。

设想一个应用程序。为了向用户交付应用，我们会将其部署在一个节点上。随着用户数量的增长，单个节点将无法满足不断增长的访问需求。

为了支持更多用户，我们将应用部署到多个节点上。此时，任意一个节点都可以独立地为用户提供服务。用户的请求可能被分发到任意一个节点，但响应结果仍符合预期。

在无状态服务中，各个节点之间没有与状态相关的上下文。它们接收请求，可能查询数据库，然后返回响应。它们不负责管理任何状态信息。

无状态服务的一个典型例子是静态内容服务器（如 CSS、HTML 或 JavaScript 文件）。

上图是一个无状态服务的简要示意图。我们的应用被复制到 N 个节点上，每个节点都能独立地处理来自客户端的请求。所有副本均可访问同一个数据库，同时前端还配备了一个负载均衡器，用于在各副本之间分配流量。

会话跟踪服务

在某些场景下，仅靠无状态服务并不足够。我们来看一个简单的例子。

假设我们正在网上订购杂货。我们浏览商品列表，并将商品添加到购物车中。每次添加商品时，都会向在线杂货服务的后端发送一次请求。这意味着购物车的状态必须被持久化存储。每当用户添加新商品时，购物车状态都必须更新。

一种实现购物车功能的方式是将特定用户的购物车数据存储在某个节点的内存中。每次用户添加商品时，请求必须始终发送到同一个节点。换句话说，每个用户的会话状态被绑定在某个节点上，只要会话仍在使用，用户就会被持续重定向到该节点。

在会话跟踪服务中，所有用户请求都会被导向特定节点，在该节点上缓存了用户会话的部分状态。

其他类似的会话跟踪场景还包括长时间运行的操作，例如用户注册流程或在线表单填写。

会话跟踪服务在外观上与无状态服务几乎相同，唯一的区别在于：在特定节点上，用户的会话状态是保持的。一旦该节点发生故障，缓存的状态数据将丢失。用户需要重新连接应用并重新发起请求。

需要注意的是，用户会话跟踪并非总是通过将状态缓存在服务节点中来实现。有些系统会将会话数据转移到高性能的键值数据库中，例如 DynamoDB。这样一来，无论哪个节点接收到请求，都可以在同一个会话中正常响应。即使某台机器崩溃，也不会造成状态丢失。

核心要点

• 复制的负载均衡服务是最基础的分布式系统模式。
• 在无状态复制服务中，每个客户端请求可由任意副本独立处理。
• 在会话跟踪服务中，必须保留用户会话状态。因此，会话数据会被缓存在某个节点上，后续的用户请求也必须路由到同一节点。