标签：扩展 记录 参数 dig 流程 measure 偏差 优先 表示
上一篇给大家介绍了AZURE的下一代负载均衡，今天跟大家聊一聊Traffic Manager（智能DNS）。现在很多AZURE的用户还在使用单站点服务（资源全部在Azure的一个Region），对于理想国度的完美应用架构，从灾备以及应用性能的角度出发，多站点部署必不可少的。如何做到异地的灾备，如何做到用户的近源覆盖达成最优响应延迟？Traffic Manager（智能DNS）其实是必不可少的一环，今天我们就来看一看Traffic Manager的更新。
========阅前必读========
通常我们无论通过桌面端还是移动端访问一个互联网服务时候，访问流程是什么样子的呢？
1. 获取服务站点域名，如想访问微软AZURE服务，我们先要获得访问站点域名www.azure.cn
2. 客户端对站点域名进行解析，客户端发起DNS请求，请求域名结果（域名结果可能是A记录，CNMAE记录，NS记录等），如步骤1的例子，客户端发起DNS请求解析www.azure.cn的IP地址，如下面的dig操作中，我们看到，先获得了一个CNAME记录，然后通过CNMAE记录进一步解析最终获得了A记录（IP地址：61.200.88.84）
:~$ dig www.azure.cn
; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.azure.cn
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10792
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;www.azure.cn. IN A
;; ANSWER SECTION:
www.azure.cn. 29 IN CNAME www.azure.cn.mschcdn.com.
www.azure.cn.mschcdn.com. 522 IN CNAME um4thtubffnsqr.wscloudcdn.com.
um4thtubffnsqr.wscloudcdn.com. 1 IN CNAME 1stcncloud.dtwscachev290.ourwebcdn.com.
1stcncloud.dtwscachev290.ourwebcdn.com. 59 IN A 61.200.88.84
;; Query time: 314 msec
;; SERVER: 10.222.220.5#53(10.222.220.5)
;; WHEN: Mon Nov 06 15:57:38 DST 2017
;; MSG SIZE rcvd: 184
3. 客户端向步骤2获得站点IP地址（61.200.88.84）发起连接，从而获得服务。
通过上述基本的一个业务访问流程，童鞋们应该会发现，域名是个神奇的东西，相对固定IP地址它有更好的灵活性。如果一个业务绑定在静态IP地址上，交付给用户的访问地址直接给成IP地址的话，当该地址不可访问时，整个业务将无法访问。通过域名发布业务，我们可以做到灵活的流量调度，从高可用角度可以在某个业务IP不可用的时候将业务地址切换到其他IP地址，从性能角度可以通过智能调度将用户请求引导到近源的站点。
=========Traffic Manager（智能DNS）智能调度算法介绍============
1. 基于优先级的调度算法：当应用采用多站点部署时，可采用对不同站点进行优先级配置，实现按优先级访问，当高优先级站点不可访问时，访问切换到低优先级站点。简单理解为主备模式
2. 基于权重的调度算法：当应用采用多站点部署时，可采用对不同站点进行权重配置，实现按权重分配调度访问，比如有两个站点，权重按照1:3配置，则有25%的请求调度值站点1，75%的请求调度至站点2。简单理解为权重主主模式，通过该部署方法可实现如站点升级流量牵引等。
3. 基于性能的调度算法：当应用采用多站点部署时，可采用对不同站点进行基于性能访问调度，智能DNS可以基于各个地区DNS代理的延迟指标来对访问请求进行智能分配，延迟指标是一个动态变化的结果，所以该策略也会随时间变化而变化。目前DNS已经有相应扩展来支持将客户端真实IP返回给后端，虽然Azure Traffic Manager已经支持，但是目前并不是所有DNS代理有相应能力（RFC7871）。
4. 基于地域的调度算法：当应用采用多站点部署时，可以根据访问请求来源所在地进行智能调度，将访问请求分配到近源的站点，比如一个全球性站点，将用户引导到离用户最近的Azure Region内站点。
=========Traffic Manager（智能DNS）智能调度算法缺点============
基于优先级和权重的调度算法，相对来说是静态的调度算法，虽然可以满足高可用的要求，但是无法对性能进行优化。性能和地域调度算法都是动态的调度算法，可以保证高可用的同时进行性能的优化。But它们也有不足之处，性能算法基于的性能指标来源是DNS代理服务器并非客户端本身，所以准确性上是有偏差的。地域算法上是基于GeoIP客户IP所在地归属数据库来判别客户请求来源，但判断时基于的时DNS代理服务器的IP并非客户端IP，所以准确性上也有偏差。
=========Traffic Manager（智能DNS）功能优化============
对于性能调度我们上面介绍到，由于性能指标来源并非客户端本身，而是通过DNS代理服务器地址所在区域的性能指标来宏观表示对应区域客户IP的性能。如果我们能拿到客户IP真实的性能指标，那么准确性将有大幅度的提升。Traffic Manager目前增加支持 Real user measurements 功能，可以实现对于真实客户IP性能参数的采集。其通过在页面内或移动端代码中嵌入Javascript，实现客户端侧性能指标的采集，客户端在访问的同时执行Javasript将客户端侧的性能指标反馈被AZURE Traffic Manager。
=========Traffic Manager Real user measurements 演示 ==========
Step 1: 快速创建WebApp服务搭建Java Web Server
参见：https://docs.azure.cn/zh-cn/app-service/app-service-web-get-started-java
Step 2：创建Traffic Manager服务
Routing Method选择Performance，目前Real User Measurements只适用与Perfomance路由模式
Step 3： 添加Endpoint端点
类型选择Azure Endpoint（此示例中采用Azure WebApp服务快速搭建Java Web Server），Target resource type选择Step 1中创建的azure webapp
Step 4：开启Real User Measure
Step 5：将Step 4中获取的Real User Measure Java Script插入到Web页面代码Body部分中，并发布更新Web服务
Step 6：获取服务FQDN尝试访问，并查看页面源码
Step 7：查看Azure访问分布情况
Traffic Manager的另外一个更新是支持访问源分布热图，可以你帮助了解Traffic Manager流量调度情况，以及客户端分布。不足指出目前热图分布是基于DNS代理的IP分布，并非真实用户IP分布（如想了解这部分分布，可以考虑结合WebApp的Access Log通过tailmap等开源软件进行统计，后面有机会我会以tailmap为示例给大家介绍）
==================总结===================
通过上述DEMO可见，Traffic Manager新的功能更多侧重在Telemetry上面，通过精细化的数据来支撑更加有效的调度算法，从而保证客户最优的使用体验，相信后面Traffic Manager还会有更多相关的功能更新，让我们拭目以待。
==================参考资料=================
Real User Measure介绍：https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-rum-overview
Traffic View介绍：https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-traffic-view-overview
MS Ignite 2017 网络服务新功能之高可用-TrafficManager篇
标签：扩展 记录 参数 dig 流程 measure 偏差 优先 表示
原文地址：http://www.cnblogs.com/wekang/p/7793833.html
