在上一篇博文中简单说了说Azure的Websites服务，Websites可以支持多实例扩展，也就实现了负载平衡功能，此外像Azure的虚拟机服务本身所在的云服务其实也是一个负载平衡的形式存在着，那么在Azure当中除了这些内置的负载平衡功能之外，还单独的推出了一个叫做Traffic Manager的服务，那么这个traffic manager到底是干嘛用的呢？
从微软官方的说明来看如下：
“使用 Azure Traffic Manager 可以控制向指定的终结点（可能包括 Azure 云服务、网站和其他终结点）分配用户流量。Traffic Manager 的工作原理是将智能策略引擎应用到对 Internet 资源域名执行的域名系统 (DNS) 查询。Azure 云服务或网站可以在世界各地不同的数据中心内运行。”
可以见得Traffic Manager是一个基于流量导向的负载平衡类服务，那它和传统的NLB相比较有什么区别呢？举例如下几个场景来看一看：
用户的服务同时部署在“中国北部”和“中国东部”，希望北部作为active站点来提供服务，东部则为standby。
用户的服务同时部署在“中国北部”和“中国东部”，希望内蒙的客户访问应用时从北部获取数据，浙江的客户访问应用时从东部获取数据。
用户的服务同事部署在“中国北部”和“中国东部”，希望无论何地的客户访问应用时，两地数据中心轮询响应。
如上这三类场景我相信传统的NLB是不太适用的，而traffic manager恰恰解决了这种需求，它的工作机制大致如下：
首先用户需要在Azure当中创建一个Traffic Manager域名（唯一有效），然后通过运营商做别名绑定（CNAME），之后客户对原有域名的DNS请求将会转向Traffic Manager域名，接着根据Traffic Manger具体的配置策略来进行处理，是基于性能，还是基于轮询，亦或是故障转移：
####################################################################
Traffic Manager属于网络服务下的一个分支，登录门户之后可以快速创建一个Traffic Manager服务，输入一个唯一有效的DNS域名以及负载平衡的方式（本示例使用“性能”方法，创建之后可以修改），如下图：
我创建了一个叫“xieruitraffic01”的域名，进入之后可以点击配置，在配置页中能看到三类负载平衡方法：
除此之外，还可以选择针对哪种协议、端口、或者相对路径来进行负载平衡处理：
在配置文件配置好之后，就该添加终结点了，所谓终结点就是你想要实现负载平衡的资源，如下图：
服务的类型有多种，website，cloudservice等等，以下图website为例，我将上次博文中创建的两个站点作为端点进行添加，而且xieruitest02是在东部，xieruitest01是在北部，在下图中还可以看到有一个警示“只有标准模式的website才能够支持traffic manager，此外每个区域只对应一个website”
添加完成之后，两个终结点进入到了联机状态，如下图：
在traffic manager首页中可以看到它的URL，之类可以复制下来用作测试访问：
此时查看作为“终结点”的website，域名属性下已经自动的添加了traffic manager的DNS链接：
以我的个人电脑为例，我的物理位置是在北京，进行nslookup查询traffic manager的域名，多次返回结果一样，都是61.50.248.117这个IP，如下图：
查询这个IP属于北京市的一个地址，如下图：
为了更进一步验证traffic manager的有效性，我找一台位于中国北部的虚拟机进行测试，如下图：
用该虚拟机访问xieruitraffic01.trafficmanager.cn，返回的是我唯一中国北部的website，也就是xieruitest01这个站点（上篇博文中所创建的，见篇首链接）
这时候我再创建一台中国东部的VM来测试一下，如下图：
创建完成，登录这台位于东部的虚拟机：
同样访问xieruitraffic01.trafficmanager.cn链接，返回的却是位于中国东部的website，也就是xieruitest02这个站点，也是在上篇博文中部署的node.js网站，如下图：
######################################################################
从上述的实践来看，traffic manger的效果达到了预期，那么以性能方法为例，它的运行原理是怎样的呢，见下图：
简单来说Azure维护着一个性能表，记录着不同数据中心与终结点之间的响应时间，当接收到用户查询请求时，选择一个最优条目返回给DNS并告知客户端依次为查询结果进行解析。
本文出自 “技术不宅” 博客，请务必保留此出处http://maomaostyle.blog.51cto.com/2220531/1568489
原文地址：http://maomaostyle.blog.51cto.com/2220531/1568489
