下面介绍了 Microsoft Azure 负载平衡服务的主要功能：

 PaaS/IaaS 支持

Microsoft Azure 负载平衡服务适用于所有租户类型（IaaS 或 PaaS）和所有操作系统类型（支持 Windows 或任何基于 Linux 的操作系统）。

PaaS 租户通过服务模型进行配置。IaaS 租户通过管理门户或 PowerShell 进行配置。

Layer-4负载平衡器，基于哈希算法分配

Microsoft Azure 负载平衡器是一种 Layer-4负载平衡器。Microsoft Azure 负载平衡器通过针对给定输入端点上接收到的流量计算哈希函数，在一组可用的服务器（虚拟机）之间分配负载。计算哈希函数是为了使来自同一连接（TCP 或 UDP）的所有数据包最终位于同一台服务器上。Microsoft Azure 负载平衡器采用 5个信息（源 IP、源端口、目标 IP、目标端口、协议类型）计算用于将流量映射到可用服务器的哈希函数。我们选择的哈希函数使到服务器的连接的分布非常随机。但是，根据流量模式，不同的连接可能映射到同一台服务器。（请注意，到服务器的连接的分布不是轮询的，也不像其他文章或博客中误称的那样具有请求队列）。哈希函数的基本前提是获得了大量来自不同客户端的请求，这样请求就可以跨服务器完美分配。

多协议支持

Microsoft Azure 中的负载平衡服务支持 TCP 和 UDP 协议。客户可以在其服务模型的输入端点规范中通过 PowerShell 或管理门户指定协议。

多端点支持

托管服务可以指定多个输入端点，这些端点将自动在负载平衡服务上完成配置。

目前，不支持具有相同端口和协议的多个端点。托管服务可以拥有的最大端口数也存在限制，目前设置为 150。

内部端点支持

每个服务最多可以指定 25 个内部端口，这些端口未暴露给负载平衡器，且用于服务角色之间的通信。

直接端口端点支持（实例输入端点）

托管服务可以指定给定端点不应实现负载平衡, 而是直接访问托管此服务的虚拟机。这样应用程序就可以控制客户端直接重定向到给定应用程序实例 (VM) ，而不必让每个请求都实现负载平衡（负载平衡有可能造成重定向到不同的实例）。

自动重新配置扩展/缩小、服务修复和更新

负载平衡服务与 Microsoft Azure 计算服务一起协作，以确保在为输入端点指定的服务器实例数扩大或缩小（由于 web role/worker role 实例数的增加或在相同负载平衡组下放置了额外的持久 VM）时，负载平衡服务会自动重新配置以针对增加或减少的实例实现负载平衡。

负载平衡服务也会以透明的方式重新配置，以响应 Microsoft Azure Fabric Controller 执行的服务修复操作或客户执行的服务更新。

服务监控

负载平衡服务提供了一项功能，可探测各种服务器实例的运行状况并让运行不佳的服务器实例不再被轮询。支持以下三种类型的探测器：来宾代理探测器（在 PaaS VM 上）、HTTP 自定义探测器和 TCP 自定义探测器。对于来宾代理，负载平衡服务会查询 VM 中的来宾代理以了解服务的状态。对于 HTTP，负载平衡服务通过获取指定的 URL 来确定实例的运行状况。对于 TCP，则依赖于成功建立与已定义探测端口的 TCP 会话。

源 NAT (SNAT)

所有来自服务的出站流量均使用与入站流量相同的 VIP 地址进行源 NAT (SNAT) 处理。我们将在以后的文章中深入介绍 SNAT 的工作原理。

数据中心内部的流量优化

Microsoft Azure 负载平衡器会优化同一区域中 Microsoft Azure 数据中心之间的流量，使通过 VIP 通信且位于同一区域中的 Azure 租户之间的流量可在 TCP/IP 连接启动后完全绕过 Microsoft Azure 负载平衡器。

VIP 交换

Microsoft Azure 负载平衡器支持交换两个租户的 VIP，让处于“暂存”环境的租户移动到“生产”环境，反之亦然。VIP 交换操作允许客户端在部署服务的新版本时使用相同的 VIP 与服务通信。可以在 staging 环境中部署和测试服务的新版本，而不会干扰生产流量。当新版本通过所有必要的测试后，可以通过与现有的生产服务交换将其提送到生产环境。与“旧”生产环境建立的现有连接将保持不变。新连接将被定向到“新”的生产环境。