转载

视频访谈：李孟：迅达云CDN与DNS的设计研发

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的这样一个特征的，希望能够在今年年底形成一个产品，能够跟大家去分享、展示。

正文到此结束