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