有状态的Web服务有多好和/或必要?

理想情况下,Web服务(和网站)应该是无状态的。

不幸的是,这需要经过深思熟虑的问题域,以及清晰的关注分离。

我在实践中发现 最 真实世界 网站 依赖于状态,即使这限制了它们的可伸缩性。

我也发现了 许多的 真实世界 Web服务 也依赖于国家。

最终,“正确”的决定是针对特定问题的决定,所以编写一个依赖状态的WebService,并在可伸缩性成为问题时稍后重构它可能是可以的。

虽然这只是一个小小的区别,但仍应提及:

它不是 Web服务中的状态 这会破坏可扩展性,相反, 应用服务器上的状态 它承载的Web服务会破坏可伸缩性。当您说这个用户需要访问这个服务器时(就像在粘性会话中那样),您实际上限制了您的可伸缩性选项。你想要达到的一点是,“任何一个自由负载平衡的应用服务器”都可以处理这个Web服务请求,如果我 再添加一个应用服务器,我应该能够处理更多的用户 .

如果您希望保持状态以传递身份验证令牌,并且在每次请求时都让服务从数据存储中检索您的“状态”(最好是冗余和分区的状态,例如分布式+复制的键/值数据存储),那么这完全可以(并且个人推荐)。这就是亚马逊使用SimpleDB和Google使用Bigtable的方式。

eBay采用了一种稍有不同的方法,将大多数客户的状态存储在一个cookie中,这样它就可以在每次请求时都得到传递。尽管它产生了更多的流量,但是它仍然可以扩展,因为他们的任何服务器都可以处理请求。

如果您想要一个可扩展的数据存储,我建议您查看 redis 它的速度和功能在密钥/值数据存储中是无法超越的。

你也应该退房 highscalability.com 如果你想获得关于如何建立快速和可扩展的服务的好资料。

高度依赖于服务是单事务导向的(例如获取股票报价),还是来自服务的输出依赖于跨多个事务从特定客户机提供的数据(在这种情况下,必须保持状态)。

就可伸缩性问题而言,在数据库中存储状态实际上并不是一个糟糕的方法(事实上,如果您在服务器场中负载平衡服务,那么这可能是唯一的方法。)

我认为,对于Flex客户机,状态将从服务转移到客户机层。使服务保持无状态,并让客户机维护所需的状态。服务保持简单,客户可以随意将它们混合在一起。

你似乎把国家和认证等同起来了。也许您习惯于在会话状态下存储用户名和密码?

这是不必要的,即使旧的ASMX Web服务也是如此。只需将您需要的任何信息传递给您的“登录”操作即可。此操作将被定义为返回“身份验证票证”头。

所有其他需要身份验证的操作都需要这个“身份验证票据”头。他们将检查每个头,看看它是否代表一个有效的、经过身份验证的用户。如果是这样,他们将执行他们的任务。如果没有,那么它们将返回一个SOAP错误,指示需要进行身份验证。

不需要状态。只需确保在您的服务运行的任何服务器上(例如,在Web场中)都可以验证身份验证票证,您就可以了。