负载均衡，这个词对现在的IT工程师来说已经不陌生了，随着各类大型网站的访问量节节高升，各种数据存放越来越集中，对服务器性能的要求也越来越高，这个时候，一个完善的应用负载均衡就显得尤为重要。也许很多IT工程师都已经配置过类似的设备，但是在配置过程中往往对一些细节不甚了了，所以也就不能很好的分析解决碰到的问题，这篇文章将从本质上分析一下应用负载的过程细节以及应用负载的重要组成部分及常见的一些问题。
在谈应用负载之前，我们先来看下未使用负载分担的常规应用流程：
在上图中，源IP为172.16.0.1的client去访问目标IP为10.0.0.1，目标端口为80的server，整个应用流程分2个部分：
第一部分：1,2为请求从client到达server的部分，在常规流程中，请求经过三层交换机到达server，1,2中源IP，源端口，目的IP，目的端口均未发生改变。
第二部分：3,4为应答从server返回clienet的部分，在常规流程中，应答经过三层交换机到达client，3,4中源IP，源端口，目的IP，目的端口均未发生变化。
在了解了常规应用流程以后，让我们假设一个场景，在该场景中，我们采用单臂方式旁路部署应用负载均衡设备，这个时候应用流程会如何改变呢？
在上图中，172.16.0.1和172.16.0.2两台client仍旧去访问10.0.0.1，但是这个时候的10.0.0.1只是一个虚拟IP，而其后面有10.0.0.2和10.0.0.3两台真实的server。上图所示的应用负载分担流程中，和常规应用流程不同的是，分为了4个部分：
第一部分：1,2为请求从client发到应用负载分担设备上的过程，这个过程中源IP，源端口，目标IP，目标端口无变化
第二部分：3为请求达到应用负载分担设备以后被进行目标地址转换和源地址转换以后发往选择的server的过程，这个过程中，源IP，源端口，目标IP均发生了变化（在该场景中，目标端口未发生变化，但是在实际场景中，是否发生变化视应用需求而定）
第三部分：4为应答从server返回应用负载设备的过程
第四部分：5,6为应答达到应用负载设备以后，将3步骤中被修改的源IP，源端口，目标IP改回来以后，返回到client的过程，这个过程中，源IP，源端口，目标IP均发生了变化。
我们注意一下上图中3对应的过程，请求的源IP已经发生改变，从172.16.0.1（或者172.16.0.2）变为了10.0.0.100，该改变是在旁路模式下应用正常工作的需要。如果不进行源IP的改变会怎么样呢？
我们来看下面的图：
在上图中我们可以发现，如果只进行目标IP和目标端口的转换，而不进行源IP的转换，那当上图中3步骤中请求到达真实server 10.0.0.2:80的时候，源IP还是172.16.0.1，所以10.0.0.2就会直接把应答发回给client，而不会返回给应用负载设备，这个时候连接是无法建立的。所以在旁路模式下，到达应用负载设备的请求，除了进行目标IP、目标端口转换，还需要进行源IP的转换，这样，服务器的应答才能返回给应用负载设备，从而应用负载设备才能将转发请求时候更改的相关参数再改回来，如此才能让client和server建立一个完成的连接，完成一个完整的负载分发过程。（旁路模式下，除了让应用负载设备进行请求的源IP转换这个方式外，如果client和server不在同一个网段，则还有另外一种处理，既将server的网关指向应用负载设备，这种方式的优点在于应用负载设备上不需要进行请求的源地址转换，所以server上可以看到请求的真实IP地址，有些应用有这个需求；而缺点在于server上所有走向不同网段的流量，不管是主动还是被动，不管是相关应用流量还是无关应用流量都会发往应用负载设备，从而导致无关流量占用了应用负载设备的宝贵资源。）
经过对以上2个应用过程的分析，我们可以对应用负载分担的本质做出如下总结：
对于到达某个特定的IP及端口的请求进行处理，将该请求的目标IP（和端口）进行目标地址转换（或端口转换）以后发往转换后的IP（和端口），并在需要的时候进行请求的源IP转换。
看起来很简单吧，但是难道仅仅如此吗？
（待续）
本文转自 virtualadc 51CTO博客，原文链接:http://blog.51cto.com/virtualadc/648258
