无状态与有状态微服务

Posted 2023-02-23

【中文标题】无状态与有状态微服务

【英文标题】：Stateless vs Stateful Microservices

【发布时间】：2020-02-29 23:04:56

【问题描述】：

我正在阅读一些关于无状态微服务的信息。我的问题很简单。如果一个微服务有一些持久性存储，这是否真的是有状态的微服务。总是这样吗？任何意见将不胜感激。

【问题讨论】：

看来你还不明白state是什么。

State 是User 使用服务的情况，stateless 和 statefull 是关于 - 如果你需要用户的状态给他发送响应 - 记忆的状态在哪里用户。

好的，如果在数据库中我有类似的东西：user1-processing，user2-final;在微服务的代码中，我正在检查是否处理 do1()，如果最终 do2() - 是否使微服务有状态？

没有。用户的状态是会话（id、组、权限、以前的操作等）。

通常 REST 无状态应用程序在数据库上执行读取以加载满足请求所需的数据，处理它并回复用户查询。术语无状态也主要是指缺少服务器实体来保持数据从一个请求到另一个请求而无需读取/写入数据库。

【参考方案1】：

“如果一个微服务 [has] 一些持久化 [t] 存储，这是否会使其成为 [a] 有状态的微服务 [？]

不，这不是真的。如果这是真的，那么几乎所有微服务都是有状态的，因为几乎所有微服务都使用某种形式的持久存储。

如果您稍停片刻，从用户的角度以某种距离和不可知论的方式看待 Web 应用程序，任何 Web 应用程序，您会注意到它绝对不是无状态的。 （如果是，那么它就毫无用处了。）至少，它为您提供了一些注册和登录的方式，因此它会记住您，这就是持久状态，它保存在持久存储中。但是，这个 Web 应用程序可能是由无状态微服务构建的。这些微服务可以访问应用程序的持久状态，但这并不能使它们成为有状态的。

如果微服务维护自己的某种状态，并在服务请求中利用该状态，则该微服务称为有状态。

这种状态是否持续是无关紧要的。 （虽然最好是这样，否则微服务将面临无法扩展和弹性的危险，这将使其不值得被称为“微服务”，但这是另一回事。）

因此，有状态微服务会在您登录时查询应用程序的主要持久存储以获取有关您的信息，然后在您保持登录状态时记住该信息，以便继续为请求提供服务无需在每次请求时查询应用程序的主持久存储以获取此信息。

从可用性的角度来看，有状态和无状态微服务的主要区别在于：

使用无状态微服务，任何微服务实例都可以处理来自任何客户端的任何请求。没有“会话”的概念，因此进入农场的任何请求都可以路由到任何服务器，以及该服务器内该微服务的任何实例。

使用有状态微服务，您必须在客户端和在特定服务器上运行的特定微服务实例之间建立会话。进入场并属于该会话的所有服务请求都必须路由到该特定服务器以及该服务器内的该特定微服务实例。

【参考方案2】：

有状态和无状态通常与数据库持久性无关。另外，有不同级别的状态（完整）（更少），我将尝试列出一些示例：

如果微服务在其内部存储中不保存对服务客户至关重要的信息，而是在外部存储中保存数据（可以是有状态的），我们可以说微服务是无状态的。一个好的思想实验是想象您的服务在每个请求之间在不同的节点上重新启动。如果服务可以通过这种方式实现其目的，通常可以认为它是无状态的。另一个例子是负载平衡器可以随机平衡请求，而无需为无状态服务使用粘性会话。也就是说，如果您的服务将数据保存在本地存储（文件系统等）中，然后在另一个节点中重新启动，并且这些数据对于正常运行至关重要，那么它就不是无状态的。因此，无状态并不严格限制为不在内存中保存数据。

有状态服务可以是任何在客户端访问之间保持状态的东西，如果这个状态被破坏，一些请求将会失败。

对于内部有状态但外部具有无状态 API 的应用程序，事情会变得复杂。例如，基于actor的系统可以称为有状态的（服务彼此了解），但如果与持久的actor状态存储配对，自动故障转移（从死节点迁移到活动节点）可以保证可靠性。如您所见，整个服务是有状态的，但通过 API 进行的交互是无状态的。

比这些流行语更重要的是您的应用程序在某些边缘条件下的行为方式：

在扩展期间处理现有进程/会话/请求（添加节点） 处理服务或节点的意外重启或终止 在网络分区期间处理请求 还有更多类似...

如果您的服务在这些情况下能够保持一致和高效，那么您一切都好。