有状态应用 VS 无状态应用

应用（或其他任何事物）的状态是指它在特定时间的状况或品质，即它的存在状态。一个应用是有状态还是无状态，取决于记录其交互状态的时间长短，以及需要如何存储这些信息。有状态应用会保留应用与用户、系统或组件交互的状态或上下文。这些状态始终保存在持久的存储解决方案中，因此应用在重新启动后仍能保持其状态。有状态应用和无状态应用的主要区别在于，有状态应用会保存过去和现在的信息，而无状态应用不会保存。

利用红帽 OpenShift 服务开启应用转型之旅

有状态应用和进程会通过互联网存储、记录以及返回到已建立的信息和进程，从而保留其状态。在有状态应用中，服务器会跟踪每个会话或交互的状态，并根据用户过去的请求维护这些信息。用户可以反复回到之前的会话状态，比如在网上银行查看之前的交易记录或在电子邮件中回到草稿继续编辑邮件。这些应用会在之前事务的上下文中执行操作，并且当前事务可能会受到之前事务中所发生情况的影响。因此，有状态应用每次处理用户请求时都会使用相同的服务器。 

如果某个有状态事务出现中断，由于上下文和历史记录已存储，所以可以从中断位置继续进行。有状态应用会跟踪窗口位置、设置偏好和最近活动等内容。您可以将有状态事务看作是与同一个人的持续周期性对话。

有状态应用的用例

• 以用户为中心的应用：以用户为中心的应用（比如社交媒体应用和电子商务网站）会跟踪已登录用户的会话，包括他们的偏好设置或购物车中的商品。
• 物联网系统：物联网（IoT）系统要维持正常工作，就要在反馈回路中不断发送、接收和分析数据。根据历史数据或实时数据，设备会随着时间的推移响应不断变化的状态，比如您家中的恒温器就是这么调节室温的。
• AI/ML 模型训练：人工智能和机器学习（AI/ML）训练模型可以从数据中学习并记住这些数据。维持这种学习和记忆状态有助于模型最大限度地发挥其能力。

了解有状态应用与采用 RAG 的 ML 模型有何关联

无状态应用或进程不会保留用户先前的交互信息。它们没有存储或引用过去事务的信息。每次事务都像是第一次从头开始进行的。无状态应用会提供一项服务或功能，并使用内容分发网络（CDN）、Web 或打印服务器来处理这些短期请求。

无状态事务的典型示例是执行在线搜索，寻找您想要的答案。您会在搜索引擎中输入问题并按下 Enter 键。如果事务中断或意外关闭，您只需开始一个新的事务。您可以将无状态事务想象成自动售货机：一个请求对应一个响应，它不用记住您之前买过什么。

无状态应用的用例

• REST API：REST 应用编程接口（API）会将资源状态的表述形式传递给请求者或端点。每个 API 请求都是独立的，服务器不会存储先前的请求信息。
• 微服务：微服务允许应用内的每项核心功能都独立存在。因此，无论是无状态应用还是有状态应用，都非常适合采用微服务。
• 无服务器架构：无服务器架构旨在孤立地响应事件，不会保留先前操作的上下文，因此无需维护状态。对于能够瞬时启动的异步、无状态应用，无服务器架构是十分理想的选择。

了解 API 如何助力实现应用

有状态应用是保留用户交互的当前状态信息，无状态则是将每个请求视为独立、孤立的事务，这就是二者的主要区别。此外，还有一些具体的不同之处，包括：

状态保留

有状态应用会存储交互信息，通常保存在数据库或分布式内存中。无状态应用则不会存储交互信息，因此每个事务都需要从头开始进行。

会话依赖性

在有状态应用中，每个请求都依赖先前交互和事务中的数据或上下文进行处理。无状态应用的会话更加独立，因为每个请求都会被视为新请求，但这意味着应用必须具备所有必要的信息才能处理请求。

存储依赖性

有状态应用需要使用持久存储，比如数据库和分布式文件系统。有状态应用则必须依赖底层存储解决方案，并且需要采用在实例之间同步数据的方案。

资源利用率

无状态应用通常具有较低的资源利用率，因为不需要存储和管理会话数据。有状态应用更加依赖于存储，因此可能需要更多的内存和处理能力来处理和维护会话信息。

可扩展性

无状态应用通常更具可扩展性，因为每个请求都是独立的，可以使用负载平衡技术由任何可用的服务器处理。有状态应用的实例紧密耦合，因此更难以扩展。它们可能需要使用 Kubernetes 中更具体的实例或容器集来管理状态、负载平衡和会话。

容错能力

无状态应用的容错能力更强，因为即使某个服务器发生故障，也不会影响用户会话。在有状态应用中，除非采取会话复制或集群化等额外措施，否则服务器出现问题就会导致会话数据丢失。

开发难度

无状态应用通常更易于开发和维护，因为无需管理多个请求的状态。相对而言，有状态应用需要仔细处理会话数据和状态管理，这就增加了复杂性。

我们日常使用的大多数应用都是有状态的，但随着技术的进步，微服务和容器使得在云中构建和部署应用（无论是有状态还是无状态）变得更加容易。

随着云计算和微服务日益普及，应用的容器化（无论是有状态还是无状态）也变得越来越流行。容器将应用的代码和相关的库和依赖项一起打包在一个单元内，因此容器化应用能够轻松移动并在任何环境中运行，无论是在桌面、传统的 IT 基础架构还是云端。

最初，容器采用无状态设计，因为这符合它们便携、灵活的特性。但随着容器的广泛使用，人们开始对现有的有状态应用进行容器化（重新设计和重新打包以便在容器中运行）。这使他们能够在享受容器带来的灵活性和速度的同时，保留有状态性所需的存储和上下文信息。

因此，有状态应用与无状态应用的界限开始变得很模糊。例如，您可能会有一个无状态应用，它不需要具备长期存储，但可以通过使用 Cookie 让服务器跟踪来自同一个客户端的请求。

随着容器的普及，出现了一些使用数据存储、Kubernetes 和 StatefulSets 来管理无状态和有状态容器的方法。有状态性现已成为容器存储的重要组成部分，如今的问题不在于是否使用有状态容器，而是何时使用。

无论是有状态应用还是无状态应用，红帽都可以满足您的要求。无论是在我们的混合云应用平台（红帽® OpenShift®）上编排有状态容器，还是通过红帽应用基础为应用开发打造统一的环境，您都可以享受到我们一流的支持服务以及合作伙伴生态系统的保障。

红帽 OpenShift 提供了一个安全至上的统一混合云应用平台，能够帮助企业组织实现应用开发和部署以及运维流程的现代化改造，从而加快创新。红帽 OpenShift 提供出色的功能（比如 Kubernetes StatefulSets ）来支持有状态应用。借助红帽 OpenShift 数据基础，您可以使用提供软件定义存储并帮助置备持久卷的存储解决方案，轻松管理有状态数据。红帽 OpenShift 还将有状态应用集成到了 DevOps 工作流中。红帽 OpenShift Pipelines 旨在运行 CI/CD 管道的每个步骤，可支持有状态工作负载和无状态工作负载的测试与部署。

红帽应用基础可提供服务组合与编排、应用连接与数据转换、实时消息流、变更数据采集与 API 管理——所有这些功能都能结合云原生平台和工具链，从而支持全方位的现代应用开发。

若能结合使用红帽 OpenShift 和红帽应用基础，可以为开发和交付云原生应用提供理想的平台。无论您有怎样的需求，我们的产品都能帮助您构建解决方案、提高开发人员生产力并促进创新——认识我们的开源之道。

了解红帽 OpenShift 如何为应用提供支持