Azure 基础：使用 Traffic Manager 分流用户请求

为了减小 web 服务器的宕机时间，同时也提升服务器的响应性能，咱们每每部署多个站点并经过负载均衡来对外提供服务。Azure 提供的 Traffic Manager 服务属于负载均衡的一种，特色是工做在 DNS 层，所以具备配置简单的优点。本文将经过一个 demo 演示如何经过 Traffic Manager 实现根据用户的地理位置来分流用户的请求。

Traffic Manager 简介

本质上讲 Traffic Manager 是 Azure 提供的 DNS 解析服务。它提供的核心能力有：

• 提高响应能力(把请求路由到低延迟的节点)
• 减小宕机时间(把请求路由到健康的节点)

Traffic Manager 会经过咱们配置的规则把请求解析到响应延迟最低的节点上去，并同时监控节点的健康情况，若是发现某个节点出现健康问题就会把请求解析到其它健康的节点上。咱们还能够经过更加灵活的配置来决定不一样的节点能够响应不一样数量的请求。或者是随时添加新的节点提高服务的响应能力。经过 Traffic Manager 这些功能都够轻松实现而且配置起来却很简单。
有了这样的能力咱们不只能够轻松的提示服务的响应性能还能够逐个的断开节点进行维护或升级，从而实现无宕机的 web 服务。

Traffic Manager 工做原理

Traffic Manager 工做在 DNS 级别，这一点很是重要！
在整个工做过程当中，Traffic Manager 只负责告诉用户的 web 客户端：你访问的服务器在哪里。因此它没有代理的功能，也不参与用户与服务器的通讯过程：

从上图中咱们能够清晰的看到，用户的 web 客户端只是在进行 DNS 解析的时候经过 DNS 的 CNAME 找到 Traffic Manager，并由 Traffic Manager 根据你的配置完成最终的解析并返回 web 服务的 IP 地址。在这以后，用户的 web 客户端都是直接访问 web 服务器的，直到你设置的 TTL 超时，  web 客户端才会从新进行一次 DNS 解析。因此 Traffic Manager 不是代理或网关，它也看不到 web 客户端与服务器之间的数据传递。

Traffic Manager 支持的路由策略

当咱们部署了多个 web 服务器时，如何设置策略让不一样的用户访问到不一样的 web 服务器上呢？当前 Traffic Manger 内置了四种路由策略：

• Priority (主节点处理全部请求，次节点做为随时可用的备份存在)
• Weighted (按照指定的权重分配流量)
• Performance (按照最小延迟分配流量)
• Geographic (按照地理位置分配流量)

Priority(基于优先级的路由策略) 可按照优先级设置多个从节点(web 服务器)，当其中的某个或多个节点失效时，活着的节点中具备最高优先级者对外提供服务。这个策略主要用来提升服务的可用性。

Weighted(基于权重的路由策略) 能够为不一样的节点(web 服务器)设置不一样的权重。好比服务器1配置高、性能好，就能够设置比较高的权重，这样分配给它的请求就会多些(具体的多少是按照服务器的权重计算出来的)。固然若是其中有服务器离线了，Traffic Manager 就会把负载分配到其它的节点。所以咱们也可使用这种路由策略让服务器逐个的离线并进行升级从而实现渐进式的发布。

Performance(基于性能的路由策略) 提高服务器的响应时间可谓是重中之重，这种策略会根据最小的网络延迟来路由用户的请求。

Geographic(基于地理位置的路由策略) 对于全球化的服务，最好是在不一样的地理位置上部署服务器以就近响应用户的请求。Traffic Manager 也支持这样的策略。本文中接下来的 demo 就将演示如何建立一个基于地理位置进行路由的 Traffic Manager 设置。

配置基于地理位置进行路由的 Traffic Manager

假设咱们有两台主机，一台在香港，另外一台在新加坡。咱们但愿新加坡的用户访问的是放在新加坡的主机，香港的用户和全世界其它地方的用户访问的都是放在香港的主机。

建立 Traffic Manager 配置文件

使用 Traffic Manager 服务须要从建立 Traffic Manager 配置文件开始。在 Azure 的门户网站上新建一个 "Traffic Manager profile"(不太熟悉 Azure 的朋友能够先去申请建立一个免费的 Azure 帐户)：

除了填写合适的名称还要选择正确的路由策略，这里咱们选择的 "Geographic" 表示基于地理位置的路由策略。

添加 endpoint

所谓的 endpont 这里就是须要进行域名解析的主机或者是服务。本文的 demo 使用的是两台放在 Azure 上的虚拟主机。咱们先添加放在新加坡的主机(请保证你已经建立了该主机，而且区域选的是 Southeast Asia，同时设置了主机的 DNS 名称)：

上图中 webvm2-ip 实际上是虚拟主机的 IP。另外在选择 Regional grouping 为 "Asia"，而后选择 Contry/Region 为 "Sinqapore"。此时 Regional grouping 中的 "Asia" 被清空了，看来是个 bug。可是这种状况并不影响保存。这个问题存在挺长时间了，难道是个 feature ？？

按照相同的方式咱们再添加一个位于香港的节点，因为香港的主机会被除了新加坡以外的其它全部地区的用户访问，因此在 Geo-mapping 中设置为 "All(World)" 就能够了(Azure 的 Traffic Manager 服务会保证用户的请求会被解析到正确的节点)：

监控节点健康情况

当咱们完成节点的添加后，Traffic Manager 会监控节点的健康情况：

"Degraded" 说明当前监控到的节点有问题，因此咱们须要调整一下相关的配置。
打开 Traffic Manager 中的 "Configuration" 界面，把 "Endpoint monitor settings" 中的 Protocol 改成 TCP，端口改为 22，并清空 Path 中的内容：

缘由是默认的配置中经过 http 协议和 80 端口监控服务器的健康情况，可是笔者并无在两个节点上运行 web 服务。改为 TCP 协议和 22 号端口(demo 中的两台虚拟主机运行的是 linux，而且都监听了 22 号端口)就能够了。修改配置后，节点的状态立刻就变成 "Online" 了：

"Online" 说明节点处于健康的，能够稳定提供服务的状态。
对节点监控是很是重要的，Traffic Manager 就是依靠健康监控来实现自动故障转移的。

配置 DNS 的 CNAME

完成 Traffic Manager 配置的最后一步是在 DNS 解析中配置域名的 CNAME。笔者在 GoDaddy 购买了域名 filterinto.com，如今咱们就给它添加一个 CNAME 并指向前面建立的 Traffic Manager 服务：demox.traffimanager.net：

保存上面的配置就能够了。

测试

接下来该测试咱们的配置是否达到了目的。从新说明一下咱们预约的目标：

• 新加坡的用户访问的是放在新加坡的主机
• 香港的用户和全世界其它地方的用户访问的都是放在香港的主机

先登陆到一台放置在新加坡的虚拟机(使用云服务的好处是你能够在全世界的任何区域随意的建立虚拟主机！)，而后执行 dig 命令：

$ dig demo.filterinto.com +noall +answer

这就是咱们但愿新加坡的用户访问到的主机，它的 IP 地址为：52.230.11.28。

接下来直接在本地(哥们儿是天朝子民)执行相同的 dig 命令：

$ dig demo.filterinto.com +noall +answer

其实你只要在新加坡以外的其它地方执行这个命令，解析到的主机 IP 地址都是：52.229.175.83。到这里咱们能够证实 Traffic Manager 已经可以正常工做了。
注意，IP 地址与国家和区域的关系是由专门的机构管理的，咱们基本不须要怀疑其正确性。

从 dig 命令的输出中咱们也能够看到 DNS 的解析过程为：

demo.filterinto.com
demox.trafficmanager.net             // 咱们建立的 Traffic Manager 服务
eagle.eastasia.cloudapp.azure.com    // Azure 提供的主机域名
52.229.175.83

其中第二三两行的解析都是由 Azure 完成的。

总结

负载均衡能够在不一样的层级以不一样的技术实现，本文介绍的 Traffic Manager 就是在 DNS 层的一种实现。本文选择尽量简单的 demo 只是为了说明 Traffic Manager 是什么、可以作什么。若是要把它应用到生产中则须要考察并测试更多的细节，具体请参考 Azure 的官方文档。