A Look Into Stateless Design#

无状态设计是一种强大的模型，它促进产生了简单但高度可扩展且高效的应用程序的开发。

“状态”是指系统用于处理请求的存储信息。当用户与应用程序交互或系统事件发生时，此信息可能会随着时间而变化。

在我们深入研究无状态设计的细节之前，让我们先看一下替代方案——有状态应用程序。

什么是有状态应用程序？

对于有状态应用程序，可以存储用户 ID、会话信息、配置和首选项等客户端数据，以帮助处理给定用户的请求。根据应用程序的功能和要求，可能会保存其他数据，例如在线商店的购物车信息或金融科技服务的交易历史记录。

有状态设计允许应用程序为其用户提供个性化体验，同时消除在多个请求之间共享数据的需要。因此，对于流媒体服务和在线游戏等具有用户偏好的应用程序来说，这是一种流行的方法。

无状态设计的诞生

随着应用程序变得越来越复杂并收到越来越多的流量，有状态设计的局限性变得显而易见。管理和维护会话数据会显着增加系统的性能开销和复杂性。这种复杂性使得系统难以水平扩展，因为跨多个实例共享状态成为一个挑战。

对可扩展性和效率的快速需求推动了无状态设计的流行。请求没有包含状态管理机制，而是包含处理它所需的所有信息。这使得系统能够处理高水平的请求，同时增加系统扩展的灵活性，从而提高资源效率。

无状态设计的用例

无状态设计由于符合无服务器架构和微服务等现代计算趋势而越来越受欢迎。微服务背后的关键原则之一是每个服务都是无状态的。这使得微服务能够独立扩展并确保资源消耗保持高效。无服务器计算遵循相同的概念——每个函数都是独立调用的。

即使是需要会话管理的应用程序也可以从在其系统组件中实现无状态设计中受益。例如，大多数 RESTful API 都是无状态的，其中每个 API 调用都包含所有必要的信息。内容分发网络 (CDN) 还遵循无状态设计，以便网络中的任何服务器都可以满足每个请求，而无需在所有服务器之间同步会话数据或查询单个会话管理存储。

无状态设计的缺点

在无状态设计中，请求的大小可能会大得多。此外，跨多个请求发送数据可能会导致明显的低效率，其效率远远高于从中央存储系统管理和查询该数据的替代方案。

值得注意的是，无状态设计只能针对真正无状态的用例来实现。尽管有状态设计有其缺点，但解决方法可能会增加更多的复杂性和脆弱性。

最后的想法

大多数应用程序根据每个组件的需求和约束选择有状态和无状态设计之间的混合方法。设计良好的系统的关键是平衡。它应该是可扩展的、简单的、快速的，并且不牺牲功能。