目前使用硬件负载均衡器作为Exchange 的部署场景中，采用硬件负载均衡器一个很好的好处就是应用的负载能够更均衡的分布到各台后端的服务器上，目前硬件负载均衡器存在两种不同的工作模式，一种方式是转发，另一种是代理模式。
转发采用的工作模式很类似于微软的NLB，采用一种无状态的方式进行转发，当服务请求过来，我通过网络检测来判断这台服务器没有出现宕机的情况下就会将这段报文直接转发到相应的机器，而不关心这台机器上相应的进程能够提供服务，这种模式毫无疑问存在一定的缺点。同时他们的网关采用了当前网络的网关，不需要将网关设置到真正的负载均衡设备上。
基于转发的缺点是因为他工作在网络层，不关心具体的应用数据相应的服务器是否能够接收，基于存在这样的问题，就出现了7层负载均衡设备，也就是关心应用层数据是否能够正常的接受和处理，7层负载均衡设备多工作在代理模式。所以基于这种模式我们能够对于服务器健康状态进行检测。同时根据端口及服务状态来判断服务器是否符合提供相应的服务标准来确定将服务是否转发到相应的服务器上。所以他的工作模式基本上如下图：
相对来说，基于应用检测的代理模式是非常适合企业中相应的部署的，但是如果相应的算法不正确或者相关的设置不OK，我们在监控服务器的指标的时候发现美誉实现该有的负载均衡。如下图，我们当初采用的访问模式是Cylic，基于这样一种模式我们的访问是有负载均衡器将相应的访问按照一定的顺序直接转发到每台服务器上。我们在监控计数器指标的时候发现用户连接的不均衡，我们主要监控的是Exchange 服务器的三个指标，是基于RPC CLIENT ACCESS的指标：
1. active user count 活动用户连接
2. connection count 连接数统计
3. User Count 用户数统计
在设置Cylic的时候我们发现连接数和相应的活动用户数在某一情况下没有办法达到很好的负载均衡，因此我们需要对算法进行调整。在应用负载均衡器中有一种算法死基于HASH值进行相应调整的算法，我们采用Hash同时在断开连接后不再保留缓存调整之后我们就能发现我们能够很好的实现真正的负载均衡。
所以在一般的情况下我们处理设置负载均衡器可能还要在某种程度上保证应用负载均衡设备能够很好的运作的话我们就需要持续的对于客户端连接状况进行连接，最后这张图片是我们对应用负载均衡器调整后的结果，各位可以根据这个结果来调整相应的参数。这里我提出了一些注意的事情和想法，大家可以根据这些路径去真正寻找你所需要的解决问题的方法，希望对大家排错能够有所帮助：
