其实写这个博客的时候想先小小吐槽一下咱们的博客系统，我觉得第一希望我们的编辑器系统能够升级一下，现在这个真算不上好用啊，例如贴图只能上传；如果用微软方式格式转换也不是很准确；另外类型选择上我觉得应该与时俱进，云计算，大数据，自动化这些内容都应该逐渐加入进来，这些部分真希望能够得到改进！

好了，言归正传；先说说Azure的负载均衡模式，Azure最初的设计是一种云计算可扩展结构PAAS服务，前端是Web接入层可以有多个实例，工作实例层次可以实现应用松耦合逻辑处理；接入层都是可以通过互联网接入的每个外网服务部署都是通过外部软件负载均衡器的外网连接的；因此发展至今提供了虚拟机的IAAS层服务，这个服务实际也是通过Cloud Service云服务包裹的，在创建虚拟机时都会加入或者创建一个新的Cloud Service，创建的Cloud Service内通实现多个实例的高可用，那么外部连接也希望实现网络层次的高可用，这个当然需要网络负载均衡器的支持；这也就是Azure的负载均衡器存在的意义。

这个内置的负载均衡器的特性和配置方法，，但是从这里我们也可以看出这个负载均衡器算法策略比较简单，就是一个五元组哈希负载均衡器（通过源端口+IP地址，协议TCP或UDP，目标端口+IP地址）分布到后端虚拟机节点；当然也提供了探测策略例如探测指定健康检查网页并且根据返回状态（例如IIS返回状态不是200）判断是否转发。但是这里可以看出有两个局限性，首先如果健康检查希望实现一些高级功能例如插入脚本实现超时判断等，另外一个关键的问题就是是否可以实现高级例如硬件提供的负载均衡器实现的会话粘滞功能；例如有些服务类似FTP或视频服务，通常有个TCP控制端口有个传输UDP端口，如果不能实现会话粘滞根据五元组策略将会被转发到不同的节点，这样就有问题了。现在提供的五元组粘滞方式是基于会话Session的。同一个TCP或者UDP的会话会被转发到后端的同一个虚拟机，当客户端从同一个原地址关闭或重新打开连接并建立新的会话，那么 如果原端口改变也会因为5元组Hash计算后的不同被转发到另一个后端虚拟机节点。

所以原来提供的解决方式是通过在WEB Farm负载前面通过实现负载均衡，通过与现在开源很流行的Nginx或HAproxy很类似的"Cookie Insertion" 技术实现会话粘滞, 将所有需要作为负载均衡的负载连接通过Azure负载均衡器全部转发ARR服务器，因为ARR部署在客户端与后端虚拟机之间，可以截获所有转发请求，在根据负载均衡策略（ARR提供的负载均衡方式也比较丰富而不仅仅是轮询方式，可以参考）选择后端虚拟机，然后将在后端虚拟机服务器的响应中插入定制 包含虚拟机哈希值的HTTP Cookie，这样后继的客户端连接都会根据这个Cookie返回的值发送到ARR再有ARR转发到同一个后端虚拟机，这样就实现了会话粘滞功能。通常部署方式如下图。

为了防止单点故障，因为Azure提供的负载均衡器是高可用的，自己部署ARR也希望通过负载均衡高可用的话也需要通过构建ARR的可用性集，因此构建起来并不轻松。而且这种方式如果连接IIS环境的话需要IIS 7以上的版本；因此有没有折中的方式呢？现在Azure负载均衡器已经开放了一种新的二元组方式了。

二元组方式实现的会话粘滞也称为IP亲和性策略方式，这种方式下的Azure提供的负载均衡器只提供基于源IP地址和目标IP地址或源IP地址和目标IP地址加协议哈希转发到后端。通过这种IP亲和性策略可以实现同一个客户端连接请求总是被转发到指定的后端虚拟机（当然后端虚拟机状态是OK的前提下）。

之所以要叫做折中方式是因为目前这种方式也有局限性，后端虚拟机节点变化都会造成哈希节点重新计算，因此同一个客户端新的请求仍然会因为这一改变被转发到其他节点。另外，由于二元组策略的天然局限性，如果多个客户端通过NAT或者Proxy连接都会被视为同一个源地址而容易造成这些请求总被转发到指定节点造成不均衡负载的情况。

配置Azure二元组方式负载均衡器有三种途径：

• 通过Powershell或者Service Management API配置虚拟机端点负载均衡策略方式

• 通过Powershell或者Service Management API配置。

• 如果是PAAS Cloud Service实现的Web/Worker角色可以通过.进行配置。

通过Powershell的配置方法比较简单，首先确保已经更新了最新的。

对已有虚拟机Azure端点配置负载均衡策略：

LoadBalancerDistribution有三个参数

• sourceIP为二元组

• sourceIPProtocol为三元组

• none为默认五元组。

也可以通过直接设置以后的已有负载均衡集的方式修改：