BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

李孟:迅达云CDN与DNS的设计研发
录制于:

| 受访者 李孟 关注 0 他的粉丝 作者 杨赛 关注 3 他的粉丝 发布于 2015年11月9日 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。
18:01

个人简介 李孟,现任SpeedyCloud研发总监,目前主要负责资源调度系统的设计与研发工作,为迅达云一站式云服务平台提供技术支撑。李孟曾在蓝汛就职7年,专注于CDN GSLB及其衍生领域研发与实践,是蓝汛自主研发CDN DNS的第一人,在研发与运营分析过程中积累了丰富的行业经验。

QCon是由InfoQ主办的全球顶级技术盛会,每年在伦敦、北京、东京、纽约、圣保罗、杭州、旧金山召开。自2007年3月份首次举办以来,已经有包括传统制造、金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。

   

1. 大家好,在QCon上海大会的现场我们高兴邀请到SpeedyCloud技术总监李孟先生接受我们的采访,那么李孟先生之前在CDN领域也有七八年了吧?您当时为什么选择进入这个领域呢?

李孟:进入这个领域完全是很凑巧的一个经历,实际上我进入公司的时候,前两个月还没有比较明确地知道要做一个什么样的东西,这时公司完全没有一个这样的软件基础,是我自己去摸索,一点一点地去做。当时我只有一些运维经验,没有相应的研发经验,这个开源软件也很复杂。当时做这个既要保证稳定性,又要保证兼容性,还要做整个CDN业务的一个独木桥,千均万马过独木桥,如果DNS断了,整个业务都要断。

   

2. 你们自己研发当时有什么选择?

李孟:当时选择的是Bind,按照那个年代的话,Bind已经是发布了8年了,然后它在开发过程中不断地去打Pach,可读性已经变得非常差了,解读DNS行为时,里头有几千行这样的函数,实际上把一个DNS逻辑完全摊平了,因为要照顾性能,要照顾DNS所有的业务,所有业务都要和谐运转在这个平台,代码的可读性就变得很差,当时需要理清DNS在实际应用场景中的使用,还得结合CDN的应用场景,它应该怎么运作,它所含的路径有哪些。就说是跟整个DNS系统的上下游无缝融合在一起,当时是在这个点上考虑了很多。再将互联网协议和真实的运行环境去结合,最终上线的时候能够实现一个平稳,融合性很好,兼容性很好的效果。

   

3. 从那时候到现在已经过了七八年,就是挺长时间,现在新软件也层出不穷,新的开源项目也很多,我听说您本来想分享的是与选型相关的题目?

李孟:对,我的一些老同事,有的时候问这种DNS应该怎么去做,他们就建议我去做一个演讲,让这些概念能够被大家所知。另外一个考虑的原因就是,作为CDN,作为云,它充当一个什么角色。如果CDN调度模型不当,会导致设备上的流量抖动非常厉害,对云平台也是非常不利的,所以我希望能够普及在CDN这个领域里总结的很重要的一些经验,然后能够让CDN的使用者,CDN业务后面承载的云平台,还有CDN厂商,能够在一起协调工作。

   

4. 所以其实您最后选的这个就是一个偏优化方向的题目?

李孟:是的。实际上这个演讲选型时罗列了很多的干货在里面,但是在同行那里预演时,他在更关心的是我如何去优化性能和如何进行流量调度,但是流量调度是个很泛的东西,然而实际上DNS它能够去做的就是把它表达好,如果表达得好,就意味着后面的调度做起来会相对容易一些,做动态调度和静态调度也会相对容易一些。我是集中把这些地方系统化,形成今天这样一个演讲呈现给大家。

   

5. 刚才主题演讲的一位讲师也说了,工具有一个理论性能,但是实际用到生产阶段就完全不一样了?

李孟:为什么要定制开发呢?一个就是刚才你提到性能上的差异,性能上不能达成目标,现场的表现可能跟测试的差距比较大。另外是开源的DNS提供的功能相对比较可靠,也确实可以用,但是它会有一些差异,比如说它只能做地域性的切割,只能做流量的均分。因为有的场合,你想调度流量时,比如达成3:1这样的概念,就没法直接用这个开源软件去做。但是呢,在做3:1很容易,给一个三次,再给另外一个一次,就达成3:1的效果。但是我演讲里说了,这种做法是不行的,用了这种做法,你就会看到演示中的指出的毛刺,流量是按照3:1去区分的,但是反映出来的是,它会有60%,70%的抖动,这样的抖动机器会受不了,如果说由后台的一个云主机去承载这样的业务,也会受到这些流量的的冲击。因为云资源抖动50%,那么我就要多采购50%,配置要更高的设备,就不能达到最优化的利用。

   

6. 也就是说,工具本身并不没有设计应对这种需求,用户就用错误的方法使用了工具?

李孟:是这样的。按照最直接的这种方式去做了,但是结合CDN的环境的时候,你会发现,这个环境导致数据与预设的严重失真。

   

7. 除了你刚才说的用多调度的方式实现某个功能是错误的做法,是不是还有其他更多类似这样的误区?

李孟:其实有时候这种误区会变得比较隐蔽,在演讲中我也提到了,就像刚才说的CDN使用者将流量均分给两个CDN厂商,会经常有的这样的问题,分的时候会采用CName,分成两支的做法,CName分两支的这种做法不是DNS协议里一个标准内容,就是定制开发。这种定制开发实际上是,有一个请求来了,第一次给了A厂商,第二次给了B厂商。如果放大到全国范围,这样一个区分,从CDN厂商的底层去看,你会发现,这个动作意味着某一个系的城市里细节被上层给打散了,比如北京有5台主要的用户DNS,因为被你打散了,这5个Local DNS是飘动的。就像掷硬币,5个硬币去掷下去以后,可能会得到2:3,也可能得到1:4,也可能得到0:5。那么从厂商的角度一看,北京市的流量一会儿漂移到那个厂商,一会儿漂移到这个厂商。所以说有些看似很直观,很可靠的方式,到了底层影响就很大,到后面更底层的细节是由上层继承下去了,问题很隐蔽。另外一个隐蔽的事情就是,用户去定制特别的流量调度,在流量调度过程中,正常来讲是要按照固定属性确定调度方式,但是有时候他希望达成定量的或者是非常隐蔽的定量调度时,会把调整渗透下去,把定量的行为加入到DNS里。其实做DNS定量时,它的信息是不对等的,你做一个1:1的定量,落到DNS调配时,可能会因为它在访问过程中的访问不对称,导致调度也不对称。

   

8. 作为这方面的工程师,如果做事情只考虑把上面调配实现的效果做了,但是不去考虑对下层的影响,很可能做出来是错的?

李孟:DNS在调度表达上确实是有些不符合直觉,它带来的效果有时候是不可预期的。

   

9. 对这方面的工作应该怎么样去避免这些问题?

李孟:我建议的工程师去结合数据分析,拿到一线的真实数据,完整的数据,然后做相应的调研,再决定是不是采用这种方式。

   

10. 一定要把它先跑上去,然后快速反馈发现问题再马上改?

李孟:我建议做这个的研发人员去做一段运维。我的经历蛮特别的,我当时不太清楚这个东西应该做成什么样子,只能严格按照协议去走,它就会不出乱子。DNS毕竟是个轻量服务,它的开发量不是很大,上线以后,我参与了更多的运维工作,接触DNS的各种数据,分析这些数据,总结出规律。其实另外一个我准备做的分享是关于如何部署的。做过数据分析,就知道了什么事情能做,什么事情不能做。后来调度的算法也是被砍掉了,最后形成的调度曲线就是一个大花脸式的曲线,但这个经历还是蛮有意思的。

   

11. 希望听完你的分享的同学们可以避开那些技术上的坑,最后还请您分享一下今后的计划?

李孟:实际上我也是刚加入迅达云不久,关于DNS这方面的业务也在规划中,是不是以这个CDN为重点,也是待考虑的。现在只要是做DNS功能,几乎必带CDN特征,希望能够在今年年底形成一个产品,能够跟大家去分享、展示。

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT