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

您在实际项目中看到什么样的服务器？

1)Web服务必须是无状态的:基本上你必须为每个请求发送用户名/密码,每个请求必须使用HTTPS,我将在每次需要时验证并加载User对象.

2)Web服务会话:就像在Web容器中一样,因此我至少可以保存经过身份验证的User对象并具有类似于会话ID的内容,因此我不需要在每个请求上对User进行身份验证,加载和检查.

3)粘性服务(跨请求的持久服务):https://jax-ws.dev.java.net/nonav/2.1/docs/statefulWebservice.html

我理解有状态服务(以及Web应用程序会话)的可伸缩性问题,但有时您必须具有某种状态,例如购物车.但是你也可以将这个状态放在数据库中(使用后端作为一种会话argh)或将整个状态传递给客户端(客户端负责重新发送整个购物车).

事实是,至少对于Web应用程序,会话在许多情况下都有很大帮助.如果您的系统接受"如果他的Web服务器发生故障,用户必须重新开始做任何事情",或者您可以尝试使用会话群集(如果这是不可接受的),则可以忽略可伸缩性问题.

它是如何用于Web服务的？我倾向于得出结论,Web服务与Web应用程序非常不同,并且接受选项1)(总是无状态),但是根据实际项目经验听取其他意见会很好.

虽然这只是一个小差异,但仍应提及:

它不是Web服务中破坏可伸缩性的状态,而是它在托管Web服务的App Server上的状态会破坏可伸缩性.当您说该用户需要访问此服务器时(就像在粘性会话中一样),您实际上限制了您的可伸缩性选项.您想要达到的目的是"任何免费的负载平衡App服务器"都可以处理此Web服务请求,如果我再添加1个App Server,我应该能够处理更多用户.

如果你想保持状态传递一个身份验证令牌并在每个请求上获得服务从数据存储中检索你的'状态'(最好是冗余和分区的,例如分布式+复制的密钥),这是完全正常的(并且是个人推荐的)/value数据存储).这就是亚马逊用SimpleDb和谷歌与BigTable一起做的事情.

Ebay采用了稍微不同的方法,并将大多数客户端状态存储在cookie中,因此每次请求都会传入它.虽然它可以产生更多的流量,但它仍然可以扩展,因为它们的任何服务器仍然可以处理请求.

如果你想要一个可扩展的数据存储,我建议你看一下redis它具有的速度和功能是在键/值数据存储中无法击败的.

如果您想获得有关如何构建快速和可扩展服务的良好材料,您还应该查看highscalability.com.

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

不幸的是,这需要经过深思熟虑的问题领域,以及明确的关注点分离.

我发现在实践中,大多数现实世界的网站都依赖于状态,即使这限制了它们的可扩展性.

我还发现许多现实世界的网络服务也依赖于州.

最终,"正确"的决策是针对特定问题的决策,因此编写依赖于状态的Web服务可能是可以的,如果可伸缩性成为问题则稍后重构它.