李孟：迅达云CDN与DNS的设计研发

个人简介 李孟,现任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特征，希望能够在今年年底形成一个产品，能够跟大家去分享、展示。