Load Balancer粘性会话和非常旧的Web服务

Question

使用硬件LoadBalancer，您可以配置粘性会话，以确保相同的会话将始终转到同一服务器。

但是这也适用于webservices（而不是web服务器）吗？

即。我将WebServices托管在Load Balancer后面。

来自不同本地客户端（而不是浏览器客户端）的Webservice呼叫是否会始终转到同一个Web服务服务器？

这些是非常旧的样式Webservices - 使用RPC / Encoding - 本机客户端程序使用Axis 1.4作为客户端存根。

Answer 1

来自不同本地客户端（不是浏览器客户端）的Webservice调用总是可以转到同一个Web服务器。

为了保持会话粘性，主要是负载均衡在cookie中注入服务器标识符，同时响应客户端（请注意cookie不是浏览器功能，它是由this specification定义的HTTP功能）并且应该由下面是Axis 1.4使用的HTTP客户端。

我建议您分析负载均衡的工作原理，并根据您的需要改变您的客户需求。如果您的负载均衡使用基于Cookie的方法，this answer您可能会觉得有用。

希望这有帮助。

Answer 2

如果您可以保持您的应用程序无状态，那么使其在性能和可伸缩性方面都很好。

无国籍的好处：

• 可扩展性。您可以拥有任意数量的服务器，而无需共享用户会话。他们每个人都可以处理请求（例如通过循环进行负载平衡）。

• 保存服务器资源。我们不需要在服务器端分配内存（再次 - 可伸缩性）。

• 服务器重启后无需恢复。

会议粘性可能很难实现。例如，如果您的Web服务器在多核计算机上运行，​​并且您有多个进程处理Web流量，那么您需要一种方法来粘贴特定计算机和该计算机上的单个进程。因此，在粘性无法正常工作的情况下，请确保系统性能下降。

您可以在此处找到很好的讨论：Sticky and NON-Sticky sessions

粘性会议的利弊： Pros and Cons of Sticky Session / Session Affinity load blancing strategy?

现在回答你的问题：

  

Webservice呼叫来自不同的本地客户端（不是   浏览器客户端）总是去同一个webservice服务器？

在粘性会话中是。

  

这些是非常古老的Webservices - 使用RPC / Encoding - 本机   客户端程序使用Axis 1.4作为客户端存根。

会话配置您需要负载均衡器/服务器，它可以处理任何旧的或新的应用程序类型

  

这项工作也与webservices（而非网络服务器）有关吗？

您无需在服务器级别进行配置。

Answer 3

只要您的本机客户端正确管理会话，它就会起作用。为每个请求设置正确的http标头。

通常，粘性会话由负载均衡器通过修改会话cookie来添加服务器标识来管理。

HA-proxy example

您的负载均衡器必须有专门的文档。