为了减少 web 服务器的宕机时间，同时也提高服务器的响应性能，我们往往部署多个站点并通过负载均衡来对外提供服务。Azure 提供的 Traffic Manager 服务属于负载均衡的一种，特点是工作在 DNS 层，因此具有配置简单的优势。本文将通过一个 demo 演示如何通过 Traffic Manager 实现根据用户的地理位置来分流用户的请求。
本质上讲 Traffic Manager 是 Azure 提供的 DNS 解析服务。它提供的核心能力有：
- 提升响应能力(把请求路由到低延迟的节点)
- 减少宕机时间(把请求路由到健康的节点)
Traffic Manager 会通过我们配置的规则把请求解析到响应延迟最低的节点上去，并同时监控节点的健康状况，如果发现某个节点出现健康问题就会把请求解析到其它健康的节点上。我们还可以通过更加灵活的配置来决定不同的节点可以响应不同数量的请求。或者是随时添加新的节点提升服务的响应能力。通过 Traffic Manager 这些功能都够轻松实现并且配置起来却很简单。
有了这样的能力我们不仅可以轻松的提示服务的响应性能还可以逐个的断开节点进行维护或升级，从而实现无宕机的 web 服务。
Traffic Manager 工作在 DNS 级别，这一点非常重要！
在整个工作过程中，Traffic Manager 只负责告诉用户的 web 客户端：你访问的服务器在哪里。所以它没有代理的功能，也不参与用户与服务器的通信过程：
从上图中我们可以清晰的看到，用户的 web 客户端只是在进行 DNS 解析的时候通过 DNS 的 CNAME 找到 Traffic Manager，并由 Traffic Manager 根据你的配置完成最终的解析并返回 web 服务的 IP 地址。在这之后，用户的 web 客户端都是直接访问 web 服务器的，直到你设置的 TTL 超时， web 客户端才会重新进行一次 DNS 解析。所以 Traffic Manager 不是代理或网关，它也看不到 web 客户端与服务器之间的数据传递。
当我们部署了多个 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 配置文件开始。在 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 就是依靠健康监控来实现自动故障转移的。
完成 Traffic Manager 配置的最后一步是在 DNS 解析中配置域名的 CNAME。笔者在 GoDaddy 购买了域名 filterinto.com，现在我们就给它添加一个 CNAME 并指向前面创建的 Traffic Manager 服务：demox.traffimanager.net：
保存上面的配置就可以了。
接下来该测试我们的配置是否达到了目的。重新说明一下我们预定的目标：
- 新加坡的用户访问的是放在新加坡的主机
- 香港的用户和全世界其它地方的用户访问的都是放在香港的主机
先登录到一台放置在新加坡的虚拟机(使用云服务的好处是你可以在全世界的任何区域随意的创建虚拟主机！)，然后执行 dig 命令：
这就是我们希望新加坡的用户访问到的主机，它的 IP 地址为：52.230.11.28。
接下来直接在本地(哥们儿是天朝子民)执行相同的 dig 命令：
其实你只要在新加坡之外的其它地方执行这个命令，解析到的主机 IP 地址都是：52.229.175.83。到这里我们可以证明 Traffic Manager 已经能够正常工作了。
注意，IP 地址与国家和区域的关系是由专门的机构管理的，我们基本不需要怀疑其正确性。
从 dig 命令的输出中我们也可以看到 DNS 的解析过程为：
其中第二三两行的解析都是由 Azure 完成的。
负载均衡可以在不同的层级以不同的技术实现，本文介绍的 Traffic Manager 就是在 DNS 层的一种实现。本文选择尽可能简单的 demo 只是为了说明 Traffic Manager 是什么、能够做什么。如果要把它应用到生产中则需要考察并测试更多的细节，具体请参考 Azure 的官方文档。
原文链接：https://www.cnblogs.com/sparkdev/p/8017001.html
原创文章，作者：优速盾-小U，如若转载，请注明出处：https://www.cdnb.net/bbs/archives/32529
