您所在的位置：&正文
企业上云催生第三方融合云平台，「云端智度」获3200万元A轮融资
大数据－全文略读：现阶段，云端智度已经与 20 多家 CDN 厂商完成双向对接，为百度、腾讯、芒果等近 80 家客户提供服务。周强表示，本轮融资过后，云端智度将继续完善融合CSN技术，并加入机器学习机制。同时，也将加大市场推广。未来，云端智度还将涉足云链接等领域...
/百度
日前，&云端智度&对外宣布完成两轮共&#万元融资，其中包&#万元天使轮融资&#万元A轮融资，投资方包括杭州兴富投资管理合伙企业（有限合伙）、杭州梦龙投资管理合伙企业（有限合伙）、欣昕资产管理（上海）有限公司等。
&云端智度&成立&#年，主打的产品是智能融合CDN，即不用自建CDN，而是将多家CDN提供商的节点聚合起来，这样一来，客户就可一次使用多厂商资源。云端智度做为中间的聚合平台要做的是，通过自身技术预判节点故障及带宽的弹性扩容，相当于智能分配和运维的角色。据创始人周强透露，云端智度已经积累了30T的带宽储备量，相当于传统CDN厂商十年的累积。
周强有多年CDN行业的从业经验，先后任职于网宿、快网和实际互联，战略顾问张诚曾在中国电信(微博)、百度等公司任职，其核心员工也多来自BAT等大型科技公司。周强认为，随着云计算发展，企业把业务迁移上云，接下来就是面临多厂商对接、多云管理、云间迁移等问题，这就是第三方的云服务平台的机会所在。
整体看CDN这个行业，其本质就是缓存＋就近访问，而客户的需求是快速、稳定。
在国内提供第三方 CDN 服务的公司，已经有比较传统的上市公司，代表性是网宿、蓝汛、帝联等，他们占据了绝大部分市场。有数据显示，网宿&#个客户，年收Ÿ多，ARPU̪万。
同时，也有新兴的创业公司想要分一杯羹，ʲ此前报道过的七牛、白山云、云熵CDN等。
另外，像腾讯、阿里、百度等互联网巨头也在做CDN业务，起初他们建立节点主要用于支撑自有业务，后期也逐渐开放出来给其他企业使用。阿里云就是其中的典型，不过，阿里通常是跟自身的云计算、大数据业务一起打包出售方案。
目前，除云端智度外，七牛云、Ucloud也已推出融合CDN的相关服务。问及壁垒时，云端智度技术合伙人汪志武强调，智能融合CDN并不是简单的聚合，它将从监控体系、智能调度、聚合管理三大方面给企业主提供服务，这就需要对渠道的节点质量、带宽，以及每个厂商的架构等了如指掌。现阶段，云端智度已经与 20 多家 CDN 厂商完成双向对接，为百度、腾讯、芒果等近 80 家客户提供服务。
周强表示，本轮融资过后，云端智度将继续完善融合CSN技术，并加入机器学习机制。同时，也将加大市场推广。未来，云端智度还将涉足云链接等领域。返回搜狐，查看更多互联网龙头企业自建CDN发展状况，多元格局引发CDN生态重组
我的图书馆
互联网龙头企业自建CDN发展状况，多元格局引发CDN生态重组
随着互联网业务的持续发展，单纯的第三方CDN服务已经开始不能满足互联网企业的要求，企业纷纷开始自建CDN。一方面自建CDN能够取长补短，更好的契合自身业务，同时当CDN规模足够强大的时候，IDC服务提供商以及互联网服务平台，也越来越多地加入到原先“纯”CDN厂商的竞争格局中，逐步开始对外提供商用服务。以下是国内互联网企业的CDN自建发展状况：腾讯腾讯目前只有15%的业务流量采用了专业的CDN服务提供商的服务，其余业务都通过自建CDN来支持，并开始对外提供CDN商业服务。CDN宽带服务达到10Tbps,节点总数达到400个，服务器总数超过10000台。覆盖了全球200个国家和地区。阿里巴巴阿里巴巴的CDN覆盖全球200多个国家的200多个节点，带宽达到6Tbps，超过1Tbps的服务能力储备。从2014年3月份开始正式提供商业化服务，支持近两万客户。阿里云覆盖CDN国内节点280个，覆盖了电信、联通、移动、铁通、教育、长宽等各主要运营商。百度百度在全国建设100多个CDN节点，除了用于自身搜索引擎业务外，还为用户提供云加速服务，CDN节点在京津冀、东部和南部沿海、华中、四川等地区覆盖较密。优酷优酷作为国内最顶尖的视频服务提供商，其对于CDN的运用主要集中在自身在线视频直播及点播业务，其境外主要覆盖北美、港澳台、日韩、新加坡、澳洲和英国，境内主要覆盖北上广深以及长三角、珠三角地区。搜狐搜狐也自建了167Gbps的CDN，共有29个节点，1000多台服务器，主要用于自身页面加速，国际上主要覆盖美国和亚洲。乐视600个节点，覆盖60多个国家和地区，带宽达到了10Tbps，主要用于支撑乐视分布式云视频平台。乐视云已经正式去乐视化，在视频CDN与行业云定价中采用免费模式，并也于CES上宣布成立乐视美国子公司。而国际上，出于降低业务成本、提高业务质量与灵活性、拓展业务范围等考虑。国外一些龙头互联网企业也逐步陆续开展自建CDN的项目，有起有落，究竟是在自建还是租用上的选择，似乎还并不明晰。那么我们看一下目前国际方面的一些CDN自建发展状况。AmazonAmazon自建CDN与AWS云结合，一方面提高云端内容的分发速度：另一方面利用云提升CDN服务质量。降价和免费模式对传统CDN模式带来很大影响。CloudFront的定位与传统CDN，Akamai、Limelight等第三方CDN服务提供商不同，但一系列的降价却给CDN市场带来巨大影响，甚至CloudFront还推出AWS Free Usage Tier，为新用户提供免费的50GB数据流出量和两百万HTTP/HTTPS访问请求额度。GoogleGoogle利用云与搜索引擎优势，于2015年12月开始免费提供CloudCDN服务，一方面将其遍布全球的数据中心打造成高性能的CDN服务节点：另一方面，利用搜索引擎服务优势、为用户提供网站开发运行、内容存储分发等一条龙特殊服务。AppleApple公司自建CDN，并将业务流量逐渐迂回，基于ATS及时建造自己的CDN，将以前主要采用Akamai和level3的iTunes、视频以及APP下载等业务迁移到自己的CDN上。NetflixNetflix基于Nginx技术建设了用于视频点播业务的CDN，目前已在全国50个国家和地区都部署了CDN节点，并计划两年内扩展到200个国家和地区。基本取代了原来使用的Akamai、Limelight和level3的CDN服务。Windows Azure除此之外，微软2015年初，停止了Azure CDN建设，全面转向使用Verizon的Edge-Cast CDN服务，Windous、office等也开始采用Akamai、Limelight和level3的CDN服务。随着运营商、专业CDN服务提供商、互联网CDN、缓存服务提供商等企业的争相介入。2015年，国内CDN犹如冰火两重天，一方面，“互联网 ”的高速推动，让CDN一边享受着“互联网”格局带来的红利，另一方面，随着多元生态的介入，也在产业内深深感觉到竞争的压力。如何通过建立CDN行业生态，针对于云计算、DDOS、移动、视频等不同产品，将行业细分，将成为下一个行业重点。2016年亚太CDN峰会将于4月26日~27日正式召开，针对于全新CDN生态环境的形成，如何保障良性竞争与合作在行业内生根将成为当下CDN市场的重中之重，其最终目的都是为互联网用户提供质量安全保障、性价比妥当的互联网IDC/CDN服务。文/DVBCN众视网【推荐阅读】↓↓↓ 点击阅读原文，了解2016亚太CDN峰会详情
TA的最新馆藏
喜欢该文的人也喜欢创新型CDN已就位，企业还需要自建CDN吗?
稿源：站长之家用户
过去几年，由于传统CDN行业的发展“滞后”，很多企业不得不自建CDN，甚至在自建以后输出CDN服务。但现在，不同于传统CDN服务商和云服务商，全新CDN服务商星域和其独创的无限节点CDN的加入，正使这个局面被打破，并促使市场迎来“新型CDN服务逐步取代企业自建”的格局变动。图为网心科技销售总经理曾卓7 月 26 日，迅雷旗下网心科技的创新型专业CDN——星域CDN亮相China
Joy，向包括在线游戏、游戏直播、视频直播等企业在内的众多互联网企业，展示了独创无限节点技术的颠覆性优势，和远优于自建CDN的优质服务和超低售价。网心科技销售总经理曾卓指出，与近期弥漫于业内的一个观点一致：未来企业自建CDN将变得无必要性，更具性价比的新型CDN服务已是市场上的更好选择。物美价廉完胜自建 新型CDN重磅就位企业自建为的是高质量CDN和低于外采的成本，而在这两大“考核点”上，创新型专业CDN的崛起，以及云服务商的涌入，已经为各企业提供了比自建更优的选择。以星域CDN为例，曾卓介绍，凭借“共享经济云计算”模式，星域CDN的无限节点技术优势带来的是颠覆级别的使用体验。在CDN服务比较关键的节点规模上，传统CDN、云服务商以及企业自建的节点都基本在几百个数量级上，而星域CDN的节点数已经突破 30 万，甚至拥有了百万节点的布局能力。企业通过星域CDN，让跨领域、跨网络及跨设备的大容量信息轻松实现最短距的就近交换，使用户从自家小区内即可拉取内容数据，信息传输距离近至一公里，速度更快，稳定性更佳。这将让有大规模高质量CDN需求的企业也能从容应对各种突发状况，一个典型的场景是，在各购物节的高峰交易时段，大量集结了末端节点的无限节点CDN将让购物网站避开骨干网峰值压力，表现出更稳定更快的响应。此外，无限节点CDN还带来业界最顶尖的直播、点播、下载等不同领域的解决方案，实现了首屏毫秒级打开、直播延迟小于 2 秒、卡顿率低至1%等业内顶尖技术指标。在企业高度在意的安全方面，无限节点CDN独有的动态防御技术配合防盗链机制，使客户实现最高安全级的自定义防盗，可确保内容的传输安全性和稳定性。取代自建潮掀起 新型服务商或促CDN市场格局改变众所周知，自建兴起缘于传统CDN技术落后、价格高昂。近年来，越来越多的企业正在选择自建。但现在，创新型专业CDN服务商正在就位，企业自建或将逐渐被专业服务所取代。曾卓告诉媒体，除更好的技术和价格外，作为完全不同于传统服务商和云服务商的新型CDN服务商，星域甚至还将向用户提供更中立的服务。一方面，星域CDN将以用户的价值为价值，致力于为企业的终端用户提供如下载速度更快、视频质量更高等优质服务体验;另一方面，星域将主动放弃部分收入，通过旗下核心的P2SP、H. 265 编码等技术，帮助客户够降低成本和流量。且这一过程中，与客户无业务、利益相关性的星域将保持足够的中立性。显然，高质量、低价格，且具有专业中立性的创新型专业CDN，正在使企业自建失去必要性。事实上，像星域CDN这样具有代表性的服务商，已获取了如小米、爱奇艺、熊猫直播、快手、bilibili、陌陌、触手、战旗直播、大朋VR、GoGal够格等行业TOP客户的信赖，而外采正在成为越来越多企业的选择。可预见的一个趋势是，未来自建将逐渐减少乃至被取代，且在这一过程中，志在专精于CDN的新型专业服务商，将扮演起主导者角色。曾卓对此直言不讳：“星域CDN的目标就是为互联网企业提供更具性价比的专业级服务，让其本就出自无奈的自建就此逐渐退出,从而更高效专注于自身业务。”
有好的文章希望站长之家帮助分享推广，猛戳这里
本网页浏览已超过3分钟，点击关闭或灰色背景，即可回到网页CDN是Content Delivery Network的缩写，直译为“内容分发网络”。工作思路是把用户需要访问的内容缓存在边缘节点，就近访问，进而绕开经互联网骨干传输数据的不稳定性和速度瓶颈，起到提升最终用户体验的效果。通过在网络各处放置节点服务器所构成的基于现有互联网基础的一层智能虚拟网络，CDN系统能够实时地根据网络流量和各节点的连接、负载状况，以及到用户的距离和响应时间等综合信息，将用户的请求重新导向离用户最近的服务节点上。其目的是使用户就近获取所需的内容，解决 Internet拥挤的状况，提高用户访问网站的响应速度。
CDN分为静态加速和动态加速两部分，分别介绍如下。
通过缓存静态资源到CDN节点，使用户可以就近访问CDN节点来获取资源，避免用户直接从源站获取数据，提升用户访问速度和质量。
如图11-1所示，相比用户直接访问源站，访问CDN节点可以带来以下收益：CDN节点更靠近用户，可以提供更小的网络延迟及更快的访问速度；CDN节点数量远大于源站，可以支撑更大的请求数量；CDN节点多地域部署，可以提供更好的容灾能力。
静态加速可以分为小文件类业务、下载类业务。两者之间的区别在于文件大小以及访问方式，以及由此带来的业务不同侧重点。
小文件类业务：主要是通过浏览器访问的网页、图片、JS、CSS等内容尺寸比较小（无严格限制，一般为数KB至几百KB）的文件。特点是单次请求文件较小，请求总数较大，主要消耗CPU和带宽资源。一般都是直接在浏览器中展示，对访问成功率要求较高，要求RTT延时要尽量低，即节点要部署得离用户近。
下载类业务：相对于静态资源类业务，下载类业务的单文件尺寸要大很多，需要更多的磁盘空间和带宽资源，对CPU的消耗不如小文件类业务大。并且下载类业务的下载时间会比较长，相对于静态资源类业务更注重于吞吐量，而不是RTT延时。
静态加速业务是通过将文件缓存至CDN节点来提高用户的访问速度的，而动态加速是通过尽量减少用户到源站之间请求的网络耗时来提高用户体验的。可用的技术有TCP单边加速、多路TCP合并回源、回源压缩。
TCP单边加速：主要原理就是在用户通过公网直接访问源站比较慢时，通过各种方式让用户请求绕过拥堵的网络环节。例如，在用户访问质量良好的区域建立CDN节点，用户访问先经过CDN节点，通过CDN节点中转至源站；或者在某些关键CDN节点使用专线和源站联通，以确保CDN节点到源站的回源质量（图如下）。
多路TCP合并回源：在CDN节点将多个用户的数据合并在一个TCP连接上回源至源站，以减少回源时新建TCP连接带来的额外时间消耗（图如下）。
回源压缩：将回源数据流进行压缩，减少在网络上传输的回源数据量。
初期公司更多的是使用第三方公司提供的CDN服务，随着业务量和业务需求的增加，第三方CDN在质量和运维效率上逐渐不能满足业务需求。为了提升CDN的质量，提高运维效率，自建CDN是一个不错的选择。在某案例中，使用自建CDN后，不仅业务质量有了明显提升，成本也有了大幅度降低，并且从侧面帮助公司在使用第三方CDN服务时提高了议价能力。
该案例中，自建CDN支持静态加速和动态加速业务，带宽容量达数百Gbps，日常支撑了全公司90%以上的CDN流量，多次支撑了业务的大型发布推广活动（活动带宽相比日常带宽增长数倍）。自建CDN在设计之初就针对公司业务的特性，以及从节点选择、软硬件配置到参数优化都进行了有针对性的调整。
在该案例中，针对公司业务的特点，我们首先开始了大文件静态加速的工作，随后逐步进行小文件静态加速和动态加速的工作。同时，CDN管理和调度系统也随着CDN的发展不断完善。CDN系统整体框图如下。
◎ CDN业务系统：对用户直接提供CDN加速的缓存服务器和代理服务器。
◎ 私有调度系统：公司的HTTP调度服务器和302调度服务器。
◎ GSLB系统：支持智能解析的DNS服务器。
◎ 流量收集系统：采集节点交换机、服务器和各业务的流量。
◎ 质量收集系统：对质量评测数据的采集、存储。
◎ 日志统计系统：统计CDN访问日志、调度系统日志。
◎ 质量分析系统：通过质量评测数据和日志统计数据，汇总统计出质量排序结果。
◎ CMDB系统：管理CDN节点的资产信息及状态跟踪。
◎ 调度决策系统：根据质量排序结果、流量数据以及CMDB系统的服务器状态，计算出一个最优化的调度方案，并生成相关调度系统的配置文件。
◎ 监控系统：对节点各类设备的基础监控及业务可用性监控。
◎ 告警系统：CDN告警系统会做两件事情，一是在告警发生时通知运维人员；二是会同时向调度决策系统发送信令，可以实现某些特定故障的自动化修改调度处理。
◎ 自动化接口：提供给CDN业务使用者的一些刷新、预加载等接口。
◎ Portal展示系统：展示CDN业务运行的各项数据。
◎ 配置变更系统：CDN运维人员进行各种日常运维操作的系统。
CDN硬件及节点选型
CDN的目的是在尽量低的成本下为用户提供尽可能高的服务质量，所以在硬件选型时成本是一个很重要的考虑因素。
针对静态资源类业务，在硬件选型上主要评估在节点出口带宽满载时，所使用的硬件总成本。例如，相同配置的1台万兆服务器和10台千兆服务器都可以跑满10Gbps带宽，这时肯定会选择万兆服务器。当然，在硬件选型时还要考虑实际业务对CPU、内存、磁盘的使用情况。
CDN服务器选型策略
静态资源类业务使用的机型规格为E5-2620 *2 + 128GB RAM + 2TB SAS *4 + 480GB SSD *6。关键指标：万兆网卡+大内存+SSD存储。使用万兆网卡可以有效避免单机网络吞吐达到瓶颈；大内存可以将更多的数据缓存在内存中，降低磁盘IO的使用；SSD可以提供更好的随机IO读/写性能。总体目标就是避免出现木桶效应。
动态加速类业务使用的机型规格为E5-2620 *2 + 64GB RAM + 600GB SAS *2。因为此类业务对带宽使用量较少，主要是大量TCP连接数对CPU的消耗，所以在硬件选型上主要侧重于CPU和内存，对于磁盘和网卡没有要求。
在做硬件选型时，发现相对于Broadcom网卡，Intel网卡无论是在CPU使用率还是小包性能上都要优秀很多，所以无论是千兆还是万兆服务器，都推荐使用Intel网卡。
CDN节点建设策略
伴随着业务发展，会需要陆续新建CDN节点，以保证CDN的整体带宽使用率控制在一个合理的水平。显而易见，在带宽缺口最大的区域新建CDN节点是最优的节点建设策略。通过日志统计系统可以得出各个省份运营商的带宽使用量及使用比例（将日志中的客户端IP地址通过IP地址库映射为具体的省份运营商，再将每条请求响应的大小以5分钟为粒度做聚合，除以300秒后即得到各个省份运营商的带宽使用量），再和当前已有节点的分布做对比，即可得到各省份运营商带宽需求及当前带宽供应、当前带宽缺口一览表（图如下，仅做示例）。
确定了在哪些区域新建CDN节点后，后续的工作就是实际的选点了。在选点过程中，主要考核候选节点的成本和质量，节点的成本可以用单位带宽成本来衡量，这个不是本文重点，暂且按下不表。
这里主要介绍如何测量评估候选节点质量。为了使评测结果更接近用户真实体验及更具有横向可比性，我们使用JS测速来评测一个候选节点的质量。简单来讲，就是让部分真实用户去下载被评估的候选节点的一个固定大小的文件，然后记录每次用户下载的成功率及耗时，统计全部用户的平均下载成功率及耗时作为衡量节点质量的依据。从实践上看，此种方法效果良好。
在节点建设方面，我们采用的是模块化方案，一个节点有多少交换机、多少服务器，交换机以及服务器的型号配置如何，网线怎么连、电源线怎么插，全部都是固定统一的。基本可以说，各个节点的区别就只有IP地址是不一样的。并且交换机和服务器都是预先配置好后才发往外地节点上架的。采用这样的模块化方案，不仅可以显著降低使用过程中的运维成本，而且在节点建设中的便利性也是很显著的——无须我们的工程师去现场施工，数据中心现场代维工程师只要参照我们提供的一份标准化上架文档，就可以快速地完成上架施工。并且配置和流程都是高度标准化的，可以最大程度地避免（以及快速发现）上架误操作或漏操作。
CDN缓存系统
常见缓存服务器的简要对比
◎ Squid：老牌的缓存服务器，但是性能较差，无法满足自建CDN对于高性能的需求。
◎ Nginx：性能好，插件丰富，支持广泛，但缓存功能偏弱，在某案例中，动态加速服务就是在Nginx的基础上修改而来的。
◎ Varnish：配置方便，性能好，但不支持持久化缓存是其一大缺陷。
◎ Apache Traffic Server（ATS）：性能好，对于缓存的支持很完善，但是插件不够丰富，很多业务需求需要自行开发插件来完成。
经过综合对比，自建CDN的静态加速服务使用了ATS。
ATS功能介绍
◎ 具有完整的正向代理和反向代理功能，并且支持集群工作模式。
◎ 使用parent配置时可以自动屏蔽故障源站。
◎ 具有内存缓存和磁盘缓存自动淘汰功能，支持直接写裸磁盘。
◎ 拥有丰富的日志格式配置。
◎ 支持插件开发，可以定制业务专有需求。
ATS配置要点说明
1．回源配置
回源配置示意图如下
使用parent配置有以下好处：
实现多个源站负载均衡；故障源站自动屏蔽；源站DNS解析和回源Host解耦合。
remap和parent配置的区别如下：
remap是将用户访问的域名映射成另一个域名（可以是其本身），映射后的域名将用作回源请求和用来生成缓存的key。即，如果两个不同的域名同时remap到同一个域名，则两个域名下的相同的URI指向同一份缓存。而parent则负责将回源请求发送到特定的parent域名（或IP地址），而不是去DNS查询remap后的域名。
record.config文件配置如下：
CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1 #启用parent.config配置
CONFIG proxy.config.url_remap.remap_required INT 1 #启用remap.config配置
CONFIG proxy.config.url_remap.pristine_host_hdr INT 0 #这个配置项的意思是在remap后是否保留HTTP请求头中的Host项，务必配置成0（不保留）
remap.config文件配置如下：
上面的三个remap配置都是很典型的配置，按字面意思理解即可。
2．缓存配置
（1）内存缓存配置（record.config文件）
CONFIG proxy.config.cache.ram_cache.size INT 1G #配置内存缓存大小
CONFIG proxy.config.cache.ram_cache_cutoff INT 50M #配置内存缓存的最大单文件尺寸
CONFIG proxy.config.http.record_tcp_mem_hit INT 1 #记录内存缓存命中
CONFIG proxy.config.cache.ram_cache.algorithm INT 1 #内存淘汰方式，默认为1（LRU）即可
（2）磁盘缓存配置（storage.config文件）
ATS支持两种磁盘缓存方式，一种是以文件的形式缓存在文件系统上，配置项是：/var/cache 500G（路径+存储大小）；另一种是直接写裸盘，配置项是：/dev/sdb（磁盘设备的路径），这时不需要指定存储大小。
需要注意的是，ATS使用裸盘时需要更改磁盘设备的权限。在CentOS环境中可以在/etc/udev/rules.d/下新建一个99-trafficserver.rules文件，并添加如下内容：
KERNEL==＂sd[c-z]*＂, MODE=＂0660＂,OWNER=＂root＂, GROUP=＂root＂
（3）interim storage缓存配置（record.config文件）
为了解决SATA磁盘随机读/写差的问题，ATS支持内存——SSD（interim storage）——SATA磁盘三级缓存。将最常访问的内容放到SSD中，降低对SATA磁盘的随机读数量。相关配置项如下：
LOCAL proxy.config.cache.interim.storage STRING /dev/sdb
注意：interim storage机制默认是不开启的，请在编译时使用“–enable-interim-cache”参数开启。
更详细的资料请参见官方文档：http://trafficserver.readthedocs.org/en/latest/。
CDN调度系统
DNS调度示意图如下
DNS调度是通过对不同的Local DNS服务器返回不同的解析结果来实现智能解析和就近调度的。比如，给黑龙江联通的Local DNS返回黑龙江联通CDN节点的IP地址，给广东电信Local DNS返回广东电信CDN节点的IP地址。
CDN的DNS服务主要实现两个需求：智能解析以及edns-client-subnet支持。也有很多开源的DNS软件支持IP解析调度和edns-client-subnet，如PowerDNS。在某案例中，CDN主要使用DNSPod服务，小部分使用自建DNS服务（后续会逐步迁移到自建DNS服务）。自己研发DNS服务，主要考虑到一些特殊的业务场景和监控需求。
1．一个自建DNS服务实现简述——SmartDNS
SmartDNS（智能DNS），根据配置，能够支持针对不同的DNS请求返回不同的解析结果。SmartDNS获取DNS请求的源IP地址或者客户端IP地址（支持EDNS协议的请求可以获取客户端IP地址），根据本地的静态IP地址库获取请求IP地址的特性，包括所在的国家、省份、城市、ISP等，然后根据调度配置返回解析结果。支持A、SOA、NS记录的查询，支持DNS forward功能。
一个开源的Python版本SmartDNS，供大家参考：/xiaomi- sa/smartdns。接下来介绍它的部分细节实现。
SmartDNS响应DNS请求的处理流程如图11-7所示。
IPPool类的初始化和该类中的FindIP函数进行解析处理是SmartDNS中最关键的两个要素，这两个要素在下面详细介绍。IPPool类的初始化示意图如图11-8所示。
ip.csv为IP地址库文件，格式如下：
，，中国，陕西，西安，电信
其中各个字段的含义分别为IP段起始地址，IP段截止地址，IP段所属国家，IP段所属省份，IP段所属城市，IP段所属ISP。
a.yaml配置文件格式如下：
default: 5.5.5.5 2.2.2.2
中国,广东,,联通: 1.1.1.1 3.3.3.1
中国,广东,,电信: 1.1.1.2 3.3.3.2
配置中地域信息的key包括4个字段，分别带有不同的权重——国家：8；省份：4；城市：2；运营商：1。
在初始化阶段，会生成一个名为iphash的字典，结构如图11-9所示。
其中，iphash的key为ip.csv每一条记录的起始IP地址，value为一个list，list长度为6，list的前5个字段分别为以该key为起始IP记录的IP段截止、IP段所属国家、IP段所属省份、IP段所属城市、IP段所属ISP，第6个字段是一个hash，key为a.yaml里面配置的域名，value为长度为2的list。iphash[IP段起始地址][6][域名1][0]为域名1在该IP段的最优解析，iphash[IP段起始地址][6][域名1][1]为该最优解析的总权值，该总权值暂时只做参考。
在iphash初始化过程中最关键的是iphash[IP段起始地址][6][域名1]的最优解析的计算，最简单、直接的方式是直接遍历域名1的所有调度配置，挑选出满足条件且总权值最高的解析，即为最优解析。这种方式记录整个iphash的时间复杂度为O（xyz），x为ip.csv记录数，y为域名总数量，z为各个域名的调度配置数。为了优化启动速度，优化了寻找最优解析的方法：事先将每个域名调度配置生成一棵树，这棵树是用字典模拟出来的，这样需要最优解析的时候就不需要遍历所有的调度配置了，而是最多检索15次即可找到最优，即时间复杂度为O（15xy）。具体实现请参考IPPool的LoadRecord和JoinIP两个方法。
有了初始化后的iphash数据结构之后，每次请求处理的时候，只需要定位请求IP地址处于哪个IP段，找到IP段起始IP地址，然后从iphash中取出最优解析即可。具体流程如图11-10所示。
2．edns-client-subnet支持
CDN使用DNS获取查询IP地址，根据IP地址对用户进行地域调度。但这里获取的IP地址是DNS地址，而不是用户真实的IP地址。在大多数情况下，我们假设用户通常会使用离自己网络最近的Local DNS，CDN调度基本还是准确的。但也有很多Local DNS设置错误的情况，或者用户使用Google Public DNS（8.8.8.8/8.8.4.4）或openDNS。
比如国内用户设置了Local DNS为8.8.8.8，我们得到的DNS Query IP地址是74.125.16.208，判断IP地址属于美国加利福尼亚州山景市谷歌公司，这个时候，我们的DNS会返回离美国加州最近的CDN节点IP地址给用户，于是国内用户错误地调度到美国CDN节点上。
为了解决上述问题，Google提交了一份DNS扩展协议，允许Local DNS传递用户的IP地址给authoritative DNS Server。CDN的DNS支持该协议后，就可以获取用户真实的IP地址，进行准确的调度。
edns-client-subnet流程示意图如图11-11所示。
DNS Query会包含header和RR两部分，这里只介绍我们关注的地方，在网上可以搜到很多关于DNS协议的介绍，在这里就不做过多描述了。header会描述本次请求中Questions、Answer RRs、Authority RRs和Additional RRs的数量，RR部分会详细描述每个资源的内容，所有的RR格式是相同的，如下所示：
edns-client-subnet是对EDNS协议的扩展，附加在一个DNS请求的Additional RRs区域，这里重点描述edns-client-subnet的结构。EDNS协议Extension mechanisms for DNS（EDNS0），请参考http://tools.ietf.org/html/draft-ietf-dnsind-edns0-01。
EDNS0每个字段的结构和描述如下：
Field Name Field Type Description
——————————————————
NAME domain name empty (root domain)
TYPE u_int16_t OPT
CLASS u_int16_t sender’s UDP payload size
TTL u_int32_t extended RCODE and flags
RDLEN u_int16_t describes RDATA
RDATA octet stream {attribute,value} pairs
OPT的值为41，详细的协议值如下：
(A, NS, MD, MF, CNAME, SOA, MB, MG, MR, NULL, WKS, PTR, HINFO, MINFO, MX, TXT,RP, AFSDB) = range(1, 19)
NAPTR = 35
DNAME = 39
RDLENGTH描述RDATAD的长度，edns-client-subnet的详细格式存在RDATA中，如下所示：
OPTION-CODE：两个字节。
OPTION-LENGTH：两个字节，描述它之后的内容长度（byte）。
FAMILY：两个字节，1表示IPv4，2表示IPv6。
ADDRESS：实际存放IP地址的地方，IPv4长度为4，Google发送过来的长度一般为3，隐藏了IP地址最后一位。
理解了以上协议，就可以动手实现了。判断DNS Query是否包含Additional RRs，如果包含，则按照EDNS协议描述获取地址。用获取到的地址进行来源IP地址判断调度，封装结果返回。
BIND 9.10版本后自带的dig工具可以支持生成带EDNS扩展的请求来验证EDNS功能是否生效。命令示例：
./ @127.0.0.1 +subnet=1.1.1.1
使用WireShark抓取的支持edns-clinet-subnet的DNS请求截图如下。
1．HTTP调度
用户通过访问一个HTTP接口，HTTP接口会判断用户的来源IP地址及其他诸如业务类型等信息，然后返回给用户一个JSON字符串，JSON字符串中包含相关的调度结果。客户端通过解析JSON字符串可以得到所需要访问的服务器IP地址列表。
HTTP调度相比DNS调度有以下优势：
可以识别用户来源IP地址，调度结果更精确；可以在URL中包含更多的业务信息，功能更强大；可以支持一次返回多个查询的结果。
HTTP调度的不便之处就是要依赖客户端支持。
2．302调度
当Web Server收到一个用户请求时，通过识别用户来源IP地址和其URL，返回一个302响应将用户的请求重定向至一个新的URL，用户使用新的URL再去下载真实的资源。
302调度可以做到针对单次请求动态调度，比DNS调度粒度更细，变更生效也更迅速，并且可以在URL上添加防盗链等信息。
302调度的缺点是增加了一次HTTP访问的时间，只适用于下载及流媒体等下载耗时较长的业务，静态小文件不适用于302调度。
302调度既可以独立使用，也可以作为DNS调度的补充。自建CDN当前就是在混合部署DNS调度和302调度，将访问国外CDN节点的中国大陆用户再重定向至国内CDN节点。
全局调度逻辑
为了实现更好的业务容灾，当前公司业务都是在多CDN供应商同时部署的。在需要时可以通过DNS View功能实现区域用户的导向；同一区域用户可以通过第三方和自建互备，提高了业务的容灾能力（见图11-12）。
IP地址库维护
不管使用什么样的调度方式，一个准确的IP地址库都是调度系统中重中之重的部分，并且IP地址库在诸如日志分析等方面也有着重要的用途。所以维护一份可靠的、高准确度的IP地址库的工作具有重要意义。
我们的IP地址库最开始是直接使用网上的纯真IP地址库，这个地址库现在来看是一团糟，地理位置标记很不规范。后来陆续使用业内的收费IP地址库及友商的IP地址接口对此地址库进行了矫正规范，最终得出了一个格式规范、可信度比较高的地址库。
首先，我们将IP地址库的格式及地理位置命名进行了规范，纯真IP地址库大量存在某某学校、某某网吧的地理位置。规范后IP地址库格式为：起始IP地址，结束IP地址，国家，省份，城市，运营商。规范化格式带来的好处就是后期使用及合并裁剪都变得轻而易举。
其次，我们通过收集和购买基础库，采用投票方法进行整合，对IP地址库进行了矫正，得到自己的基础库。矫正的流程是，我们将整个IP地址库拆成以C段为单位，分别和其他的IP地址库进行比对，按照多数服从少数的原则对每个条目的信息做聚合，最后得出一个集各家之长的IP地址库。
在得到集各家之长的IP地址库后，我们和公司业务团队合作，拿到了几千万条IP地址和GPS地理坐标的关系数据（这些数据是通过天气App获取的，可信度很高），通过这些数据校验和进一步修正我们的IP地址库。经过上述一系列校验、矫正后，针对个别仍不能确认的IP地址，我们通过多节点traceroute，拿到各地到此IP地址的路由路径，以此来反推IP地址的归属。
海外CDN建设
自建还是第三方
当我们考虑海外自建CDN时，有很多现实的问题摆在眼前：服务器使用物理机还是虚拟机？服务器购买还是租赁？数据中心托管怎么解决？现场代维如何做？困难重重。反向比较的话，海外自建CDN相比海外现成的第三方CDN服务有什么优势？访问质量更好，还是成本更低？仔细评估下来，出于快速部署和扩展的考虑，主要采用了成熟的产品。海外是按照流量计费的，所以在数量小的规模下，自建优势不大。后续随着量的增长，我们会在合适的阶段评估自建。
具体到海外自建CDN节点，针对某些用户量大、我们自身掌控力也强的地区（例如中国香港地区），我们采用部署物理服务器的方式将节点直接建设到本地；针对其他用户量大的地区，则使用第三方云服务虚拟机进行节点部署。
海外源站部署
在CDN海外部署的过程中，我们遇到最多的问题就是海外回源：海外CDN节点回源到国内质量差，还会由于各种原因导致回源连接被墙。针对上述问题，我们在海外CDN回源上也做了很多优化。
针对一些文件总量较小的业务（官网静态页面等），我们将海外源站直接部署到了海外虚拟机上，这样就完全规避了回源的问题。
针对一些文件总量较大或者发布时效性要求比较高的业务，我们在海外源站新增了一个Proxy层，Proxy层会优先将回源请求代理到海外源站，针对暂时没有发步到海外源站的资源会代理到国内源站。
针对一些不便进行海外源站部署的业务，我们在中国香港地区做了一组中间层缓存服务器，通过香港地区的缓存服务器再统一回源至国内。
总而言之，尽可能地降低海外CDN回源到国内源站的次数，提升回源速度，降低被墙的风险。这是海外源站部署的主体思路。
质量评测系统
质量评测的目的是评估CDN服务质量的好坏，而监控系统则是为了及时发现服务中的问题并告警、处理。质量评测关注大层面的服务质量，监控系统关注细节的服务质量，这两个系统的主要目的还是有区别的。当然，质量评测的数据发生异常波动时，也会发送告警、处理。
客户端测试
从客户端角度去评测一个服务的质量情况，大体上可以分成以下几种方式。
（1）类似于博睿所提供的服务，通过部署在全国各地的测试节点去定期访问我们的被测试业务，统计相应的成功率和访问耗时。此种方式由于可以拿到详细的访问数据，所以在发现问题时更容易定位问题的原因。但是劣势也很明显，需要在全国各地部署节点或者使用第三方的付费服务，并且测试样本偏少，不能有效地代表真实用户，所以此种方式在我们的质量评测中已经很少使用了。
（2）对于有客户端的业务，我们联合业务开发，对一些关键的网络交互环节进行打点，统计访问成功率及访问耗时，这样得出来的结果是业务真实的质量数据，可信度及数据的丰富程度都很高。缺点是需要有客户端支持，不是所有的业务都有此条件。
（3）对于HTTP类的业务，通过在Web页面中嵌入一个JS脚本，使用JS脚本去下载业务的一个资源，统计访问的成功率及访问耗时。相比客户端打点，此种方式具有更广泛的适用性，只要被测试的业务是HTTP类型即可（CDN绝大部分业务都符合此条件）。当前我们大量使用的是此种测试方式。
服务器抓包分析
我们开发了一个工具，可以抓取用户访问的TCP流，通过服务器端全流量分析，可以对访问请求分析TCP流各个过程耗时情况（例如三次握手完成后，服务器返回了某个特定信息，累积下载了1MB的文件等）。通过大数据分析，可以得到各用户单元到不同节点的整体图表，对调度表格进行循环优化。下面就简单介绍一下这个抓包工具的实现。Tcpxm已经开源：/xiaomi-sa/tcpxm。
Tcpxm是使用Python开发的，调用Pylibcap进行抓包的工具。它共有3个线程：一个负责抓包并分析内容；一个负责写日志；一个用来清除过期数据。Tcpxm可以很方便地抓取和分析TCP请求，打印成所需要的日志形式。
最初我们用它来抓取和分析某个App的登录时间，稍加改造就可以抓取网站访问等时间，计算用户建立TCP连接的时间、第一次发包的时间等。如下是我们之前抓取App登录时间的日志格式和每个字段说明。
21:25:25 tcpxm.py [line:229] [INFO] 221.179.36.189:3103-&xxx. xxx.xxx.xx:2424 [usr:] [login(t6-t0+rtt):2760] [t1:0] [rtt:217] [t3:137] [t4:0] [t5:118] [t6:2069] [t7:193]
在此用户的登录时间= t6（发送的时间）– t0（收到SYN的时间）+ rtt（估算出的收到SYN包和发送ACK包的路径时间）。
具体每个t代表的时间含义如图11-13所示。日志中的t3=T3-T2，t4=T4-T3，rrt（t2）=T2-T1，……
CDN故障处理预案
在CDN系统运行过程中，各种大大小小的故障或者突发情况是不可避免的。因此，针对各种已知故障进行归纳总结，整理成故障处理预案，并逐步沉淀成自动化的处理过程。通过这样的不断迭代，可以不断提高服务能力，降低故障发生的概率；在故障发生时可以快速有效地介入处理，减少故障影响的范围及时间。
在CDN服务中，某业务突发增长数倍甚至十几倍的情况还是时有发生的。针对这种情况，我们建立了详细的应对预案。
故障场景：业务突发（未提前通知）导致CDN整体带宽利用率超过80%，且有进一步上涨的趋势。
关键动作：联系业务同事，确认业务突发原因（推广活动还是受攻击，抑或是其他）；通盘评估，确定对此次突发是进行资源保障还是资源打压，并和业务同事达成一致；发出通告，通知可能受此影响的第三方业务。
CDN故障处理预案：
（1）我们的所有CDN业务都是多厂商部署的，并且平时对热门的资源在各厂商都有做预加载，当某一家资源不能满足业务需求时，可以快速灵活地将部分流量调度到其他厂商。
（2）我们在CDN交换机上预配置了高、中、低等不同的QoS策略，通过切换业务使用的CDN域名，让突发业务匹配高优先级的QoS策略，可以重点保证此业务的质量。如果需要打压突发业务的流量，则让突发业务匹配低优先级的QoS策略。
（3）在极端情况下，会损失突发业务的部分可用性，隔离突发业务。修改调度，将突发业务的流量调度到预配置的有限个节点，将其流量和正常业务从物理上隔离（类似数据中心将受攻击的IP流量牵引到黑洞），只提供有限的服务能力。
转载请注明： &
版权所有，保留一切权利 ·