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