负载平衡是云计算服务中的一个必备服务项目，通常用来对负载平衡后端的计算实例（虚拟机）或应用程序进行外部访问请求的负载，以缓解处理压力并提供容错能力。在微软的私有云产品体系中，System Center的VMM组件具备创建windows系统原生NLB以及兼容第三方软硬负载平衡器的能力（比如F5），但是个人认为目前使用还是不便的，特别是在租户端。反观Azure公有云平台上，云服务功能肩负起了NLB的作用，除此之外Azure还提供了一个“内部负载平衡”功能，即对于外部NLB后面的应用或数据层继续进行负载均衡配置，同时避免暴露在外网以达到安全要求，如下图所示：
要在Azure实现内部负载平衡功能需要通过PowerShell方式实现，下图为我的测试环境，有若干台虚拟机，该应用分为三层，最外层使用云服务NLB接受用户访问，中间层需要进行外部用户数据写入的处理，因此需要内部NLB来继续实现负载均衡的作用，最后端是一个DB做数据持久化。
首先我做了几步针对整套应用所需的配置工作，例如下图给云服务指定了保留IP。
按功能对不同层的应用服务器进行可用性集划分，已充分利用Azure平台的容错能力，此外对前两层计算实例进行缩放配置，很遗憾的是该应用用于存储消息队列数据没有保存在Azure Queue里，所以无法根据Queue来触发scale-out选项，只能退而求其次根据CPU阀值进行设置了。
下图中是根据不同应用服务器进行虚拟网络的静态IP配置，避免因维护重启产生IP地址变动。
#####################################################################
针对内部负载平衡器，大家可以参考msdn上的guide，这里我将其写入脚本文件比较好辨别，大致分为几部分：
- 创建内部负载平衡实例
- 把相应的端点（例如VM）加入到该实例中
最后把服务请求指向新生成的负载平衡器IP就可以了，这里有个tips，我记得好像官方说明中在创建内部负载平衡器实例时没要求加“-lbsetname”这个字段，但在执行过程中该字段是必须的，如下图：
配置成功之后可以get到这个内部负载平衡器的相关信息（internalloadbalancername），如下图：
同时可以通过powershell查看ILB（内部负载平衡器）里面的member和发布的端口，如下图：
Azure的ILB功能使得负载平衡服务更加完善，在互联网微服务的大趋势下，应用的架构设计会更加细腻，不同功能之间强调松耦合，可扩展，这就给负载平衡技术以更大的发挥空间，同时ILB在安全方面也有它的优势，目前SDN技术日趋标准化，就等着NFV大放异彩，希望微软能在私有云领域更加完善自己的NFV功能，早日看齐openstack