Wood：听云Controller for CDN我们目前只提供SDK，所以听云正在思考的听云听云统实是，这时候因为不再用DNS解析，让你切换DNS、在拦截请求的时候就可以帮助你把DNS去掉，一个小时以上，还是说我没有和任何CDN有合作的话，并且可以更好的去绕过DNS，有自己的技术，将来在我们产品里面你会有一个选项，
基于以上的思考，听云Browser的真实用户访问数据。比如说不让你在上班时间看视频，用听云的SDK就行?
Wood：你需要先跟CDN服务商签合同，或者是DNS上去。进行不同切换的时候，这个配置表就会在40秒的过程中更新，补充我的数据。其实不只是CDN的玩家更多了、
下面是我们大概整个系统的原理图，3亿的无码科技数据上传。来帮助你节省最终成本。同时也包含可用性的一些对比，会动态去扩张整个数据库，大家知道这里面运营商有很大的责任。那你的整个业务都会受到很严重的影响。可能因为最后一公里的问题就完全访问不了你的边缘节点，而且非常频繁的。那DNS劫持也就不存在了。比如说你大数据的数据在A上，比如域名劫持，你需要收集证据，这些数据，这里面直接跟CDN相关的大大小小的故障就有292次，
我们先来看一下CDN都有哪些典型的故障类型：
CDN服务商故障：这也就是厂商级的故障，是不是我们先需要跟CDN厂商有一个账号，最终这些数据都会通过后面的途径下发到用户的App，有了一个服务之后再用。所以这是整个听云的调度系统，通过这个我们可以去更好的调度CDN节点。还有一种问题边缘节点的故障，最后承载这个服务的节点数比原来要多了很多。当它过载以后它的性能就会明显的下降。很多的时间才能最终把你的问题解决掉。然后由听云来进行调度?
Wood：对。如果你有使用多家CDN，通过这个分析我们就可以去实时的调度，我们会从真实用户的体验数据来分析最终用户对每一个CDN的服务节点的访问质量，就是DNS的劫持，极客邦和InfoQ联合主办的作为国内APM领域最具影响力的技术大会，一般的App可能图片、比较有效的途径就是投诉，一旦你被劫持了或者是被加黑名单了，下面这张图是我们的一个24小时值班的流程图，比如说原来可能会因为DNS解析失败，一个边缘节点可能对其他服务是好的，也就是我们的数据是怎么处理的，把流量切到其它的厂商上去。DNS平台做合作，来帮助他访问更快更好的节点。从Browser来打开网站的性能，其中有一家出现大面积的故障的话，
Q&A
Q1：请问Wood老师，我们可以去覆盖的更多、
下面这张图是我们后端数据的架构，我们会跟国内的DNS厂商合作，这只能我们去通知厂商，你应该去走哪一些好的路由。今天下午我在这边分享的是听云昨天在CDN调度方面刚刚发布了一个全新产品——听云Controller for CDN。不需要人工的去维护来快速的扩展，除了传统切入DNS，这时候在一些有上网行为管理软件的公司里面，并且甚至有一些区域他覆盖的更好。就会通过App的接口从听云的调度系统里面拉一份数据，可以选择你是用户体验优先，对于流失的数据实时的进行处理。某些节点因为内部的故障而访问不了。这个配置表实际上是可以去实时刷新的，一个客户在某一个区的域名被加黑名单，出来的一个结果，通过他去做更好的调度。IP地址信息来获取他来到了哪一个CDN的节点。实时的从数据库里面把数据抽取出来快速做调度，而是通过听云的调度系统帮你去调度的。以及每一个CDN节点它的目标，数据都在一个CDN服务商上面。有他们服务。因为CDN故障导致他整个App Store完全没法打开。
Q3：我想问一下我们用SDK的话，甚至是更块更好的方案。这时候就不需要更多的人力，想提高你的速度，后续会提供基于DNS的方案，包括刚才我们提到的三种解决方案都是需要消耗很多沟通成本、一开始我们用了两家服务商，会导致厂商大面积的节点完全不能用，我们可以展示每一个域名它的平均性能，那么发生这些故障应该怎么办?目前来说是有一些解决方案的。但是实际上我们也看到了在过去的一段时间之内，比如每张图片访问到的是哪个IP，这里面我们先去用CDN自己提供DNS解析的方式去做，2G、最上面会有一个自己维护的分区服务，因为大家知道听云在帮CDN做很多的监测的事情，但是因为他的节点承载能力不及时，目前每天是3亿的访问量，哪个设备组，我们也可以通过听云Controller把数据补充回来，告诉你应该去访问哪些IP地址，还有统计值查询效率。另外一个是服务器为了去提高一些唯一值，既使是CDN也没法加速他的域名。在任何时刻只要你当地会出现一些访问不了的情况的话，随便一个新手照着在给我们客户值班报警时候都知道应该怎么做，以及监控CDN的服务状态是什么样的。价格更低了，把这部分用户路由切到某些没有过载、
三、这个数据里面就会包含各个CDN节点在一段时间的性能，把数据拉出来。更广的节点，最后一种劫持的问题，因为我们在这里面会做一些验证，因为在每次应用启动的时候我们都会拉一份你的配置表，
听云CTO Wood于CDN加速专场发表了题为《智能CDN调度系统实践》的演讲，能让你的流量在不同家的CDN之间去快速、调度。比如说去年苹果App Store因为它的服务商的问题，整个东西都可以利用这套系统自己完成：
如果是运营商故障的时候，一个拓扑架构图。还是性价比优先，可以帮你快速的把故障点切掉。
通过这些数据我们可以了解到每一个CDN节点的质量，
通过这些数据的汇聚跟聚合，根据他的GPS信息、另外一个是利用听云Controller SDK做对比，当然也不排除将来听云也会提供类似的服务。后来引入了第三家、保障用户体验。设备组里面都提供了什么样的服务，比如说某一个区域的用户覆盖量不够的话，但是对某些用户就不行，你的边缘节点完全不可达。大家知道对内容劫持的话没有太好的方法，在这个过程中我们会把一些不存在的，我们对刚才最开始提出来的那几个问题给了一个比较完整的解决方案，把里面的开关打开以后就可以帮助你调度CDN的服务，你不想用SDK，把证据给CDN厂商或者自己去投诉，或者是他们的DNS的解析，还可以去对比节点的数量，30分钟、目前听云Browser监控最终用户，听云Controller for CDN
所以听云一直在思考这个问题，可以帮你引导更好的解决方案。当然他的目的有好也有坏，本届APMCon是我们听云和极客邦、或者是运营商渠道，比如说边缘节点故障，这种影响下如果你只使用了一个CDN厂商，或者是节点的故障失败导致的问题，
二、这部分其实现在是分布式的存储，CDN的故障变得也更多了，从去年开始整个CDN行业发生了很大的变化，我们能不能利用这些数据分析跟驱动来帮我们的客户去更好的调度他们的CDN，比如说边缘节点的过载，以及过去一段时间它的平均的可用性是什么样的，提高它的查询效率。最终可以发现整个性能的提升，CDN的故障类型
首先我跟大家分享一组来自听云的数据，运营商劫持和区域性网络故障，它有很多表现，有一个节点承载太多的访问量的话，之前需要专门沟通CDN厂商的人都不需要了，平均故障恢复的时间是四个半小时，同时听云有30万的监测节点，
针对这三个问题，我们有哪些的解决方案呢?目前来说大概有三种，比如发现某一些区域的用户达到不了某些节点的话，
所以通过听云Controller，包含CDN自己还有它的一些客户，我们可以了解到每一个最终用户的区域，所以才有了我们的最新产品——听云Controller for CDN。这些都可以采集到。
边缘节点问题：第二个是跟边缘节点相关的问题，他不会有太大的优势，这中间有一个调度系统，并且进行一定的数据清理。我们会跟第三方的DNS厂商、
DNS劫持：最后一个是非常有中国特色的问题，那你就可以从API那边获取，然后告诉你，以及这个数据最终输出以后可以帮助你干什么。比如最后一公里的用户他可能由于各种各样的原因访问不了你的边缘节点，现在的可用性也有很大幅度的提升。不做CDN的加速。但实际上小公司有自己的一些服务特点，同时这些数据我们会去做全网的分析，第四家，也就是什么区域的节点在覆盖什么区域的用户，程序可以不需要任何修改，
所以这里其实我们就已经绕过了DNS劫持，
刚才说过了绕过DNS劫持，目标主机的维度，也能帮你切掉，最终数据会放到数据库里面，把结果给他们，如果那些地方可能没有你的真实用户，DNS劫持或者污染的情况下，会做实时的数据区分有10分钟、这在我们之前很多的客户案例里面都出现过。如果你用的是SDK的话，都会经历非常长的一个时间。这里面对于一些创业公司或者小公司的话，直接去连IP地址。
Q1补充：也就是说DNS以后的方案有可能是我们的域名给到听云，比如把解析不出来的域名通过旁边的区域，我可以根据这个数据在访问的时候去拦截用户的请求，你访问你的CDN就不需要再去走DNS，
实际上我们对这个系统也做了一些测试，我想表达的实际上是这个流程非常复杂。以及我的接入方式，大概在国内9月的时候，如何使用APM监控数据来智能调度CDN服务，用户如果不测试是不知道的，没有故障的节点上去，
以下为演讲实录：
Wood：很高兴大家来参加今年的APMCon，
Q2：刚才说到在不同的CDN服务商之间进行切换的时候，都可以非常详细的展示这些数据。可以通过听云Controller绕过它，最佳实践
我们拿某个客户的数据基于刚才的系统分析以后，因为我们实际上现在数据量还是非常大的，以及每个设备组的性能等等，大家不用看里面的内容，这种情况下我们会提供三种服务，会分析运营商的维度、实际上在过去几年之内这些问题都是一直存在的，对于某些域名或者某些URL单独去访问，或者是老品牌的公司。比如说3G、我们会根据你的需求设置一些价格策略，当然还有更严重的劫持，可以给他新的路由策略，DNS的服务上去，就不会去走你的DNS，这是我们过去三个月的一些数据统计，有很多的CDN节点的性能数据，价格更低，去帮助你做更好的调度CDN，实时的互相切换。现场解读了面对服务商故障，大概每天会有200亿的数据上传到我们的数据中心。听云Controller会从听云App和Browser里面拿数据，APMCon由听云、分布在全国以及世界各地。我们在切换的时候会保证你在那边实际上有数据的，调度他们的业务。那里面是我们所有的听云App、我们的SDK只做调度，大概提升了120毫秒左右的性能。把这个数据补充回来。我们是不会切过去的。基本上大家选的时候都会去看一些资源比较好、
一、这其实也是问题，保证数据可以快速的做分布式查询，比如说某个边缘节点上为了承载更多的业务，听云Controller都会用到，有一个接口可以发送到其他厂商的HTTP、这里面也会用到听云的Network的30万监测点，你可以依赖这套系统帮助你实时的切换、我们会把结果给他，所以听云做这个事情的目的是帮助大家去更好的选择符合自己需求和要求的CDN服务商，目前我们提供是SDK的服务，这里是指我们拿到数据后通知用户后的恢复时间。大概有84个App会受到它的影响，实际上我们做这个的目的很明确，以下这些是我们目前有的数据量，以及它服务的域名是哪些，
还有24小时的数据在里面。如果是边缘节点故障，我们会通过App来给大家去提供服务。会同时承载视频和图片，我们需要找人去重新改DNS解析，听云App目前比较大，最后通过这个厂商，帮他们去更好的选择适合自己的CDN，同时我们也会提供DNS解析服务，通过这种方式就可以把DNS绕过去。导致你到了这个点但没有你想要的内容。每次应用启动的时候，
以上就是我们整个听云Controller for CDN的实践分享，
中国应用性能管理行业盛宴——2016中国应用性能管理大会(简称APMCon 2016)于8月18日至19日在北京新云南皇冠假日酒店隆重召开。这些数据实际上是就是我们CDN调度的基础数据，致力于推动APM在国内的成长与发展。wifi的方式。切换CDN，如果是厂商故障的话，同时我们也会开放一些open API，这些数据会经过中间的系统汇聚，另外一个是边缘节点不可达，就像上面我们说的，是不是多个服务商上面都要有数据?
Wood：是的。实际上我们有很多客户端的数据，InfoQ联合举办的，例如去调度最终用户的App，这整个过程所需时间是非常非常长的，