使用硬件 LoadBalancer，您可以配置粘性会话，以确保同一会话始终转到同一台服务器。
但这是否也适用于网络服务（而不是网络服务器）？
即我在负载均衡器后面托管了 Web 服务。
来自不同本地客户端（不是浏览器客户端）的 Web 服务调用是否总是会转到同一个 Web 服务服务器？
这些是非常老式的 Web 服务 - 使用 RPC/编码 - 本机客户端程序使用 Axis 1.4 作为客户端存根。
【问题讨论】：
标签： web-services session load-balancing
如果您可以让您的应用程序保持无状态，那么让它在性能和可扩展性方面都很好。
无国籍的好处：
可扩展性。您可以拥有任意数量的服务器，而无需共享用户会话。他们每个人都可以处理请求（例如通过循环进行负载平衡）。
节省服务器资源。我们不需要在服务器端分配内存（同样——可扩展性）。
服务器重启后无需恢复。
会话粘性很难正确处理。例如，如果您的 Web 服务器在多核机器上运行，并且您有多个处理 Web 流量的进程，那么您将需要一种方法来粘住特定机器和该机器上的单个进程。因此，请确保您的系统在粘性无法正常工作的情况下能够很好地降级。
你可以在这里找到很好的讨论：Sticky and NON-Sticky sessions
粘性会话的优缺点： Pros and Cons of Sticky Session / Session Affinity load blancing strategy?
现在来回答你的问题：
Webservice 调用是否来自不同的本地客户端（不是 浏览器客户端）总是去同一个网络服务服务器？
在粘性会话中是。
这些是非常老式的 Web 服务 - 使用 RPC/Encoding - 本机 客户端程序使用 Axis 1.4 作为客户端存根。
您需要负载均衡器/服务器的会话配置，它可以处理任何新旧类型的应用程序
这也适用于网络服务（而不是网络服务器）？
您无需在服务器级别进行配置。
【讨论】：
Session configuration you need load balancer - 这是什么意思？
只要您的本地客户端正确管理会话，它就会工作，即。为每个请求设置正确的 http 标头。
通常粘性会话由负载均衡器通过修改会话 cookie 以添加服务器身份来管理。
您的负载均衡器必须有专门的文档。
【讨论】：
来自不同本地客户端（不是浏览器客户端）的 Web 服务调用总是会转到同一个 Web 服务服务器。
为了保持会话粘性，主要是负载平衡在响应客户端时在 cookie 中注入服务器标识符（请注意 cookie 不是浏览器功能，它是由this specification 定义的 HTTP 功能）并且应该由 HTTP 支持Axis 1.4 下面使用的客户端）。
我建议您分析负载平衡的工作原理，并在此基础上更改您的需求以更改您的客户端。如果您的负载平衡使用基于 cookie 的方法，this answer 您可能会发现它很有用。
希望这会有所帮助。
【讨论】：