并行计算和分布式计算_云计算分布式计算_经典的分布式计算模型(3)

传统的方式是线下搭建一个对等测试集群来验证，在我们的大数据下面是行不通的。原因在于：第一，我们是一个大数据的场景，要测试集群调度或者Scalability等方面的改进往往需要建立一个相同规模的测试集群，浪费巨大；第二，测试集群没有相应的任务负载，在测试集群中可以跑一个测试用例，但是想把生产集群里面水位线达到非常高，将几万台机器上跑的任务复制到集群里面，根本就做不了，因为消耗的资源是非常惊人的，没有办法复制全部的负载，只能一个一个任务去看，无法构造对应测试场景；最后，数据安全问题，我们需要脱敏的方式从生产集群拖数据到测试集群里测，脱敏处理很容易人为疏忽，造成数据泄露风险，同时脱敏数据不等于用户数据，可能违背用户程序的期望，从而造成用户程序崩溃，从而达不到测试的目的，同时整个测试过程冗长，把数据拷贝过来再搭环境做测试，这样严重影响了整个开发的效率，所以是不理想的一种方式。

我们采取线上验证测试，我们把99%的资源去跑线上的作业，把原来用于测试的机器并入到生产集群里面，通过调度器的能力，把1%的机器资源提供给程序员可以自己提交一个私有版本，把这1%的资源用于测试任务。

资源隔离。我们需要做到很好的资源隔离，因为我们不希望线上的测试影响到线上生产作业的可靠性。我们在系统资源隔离上做了很多的工作，在CPU、内存上，我们加强cgroup实现，能够支撑更多更灵活资源控制；在磁盘上统一的管理下面的磁盘，并且提供存储上优先级控制；在Network万兆网上，我们加强流量的控制等等。当然这里1%其实是个弹性的，假设我们没有测试任务，1%的资源也会用于线上的任务，从而能够充分利用我们的资源。

安全性。我们需要完善多租户支持，和用户数据安全管理，使得提交测试任务的系统开发者不能触碰到用户的数据。并且我们这些测试任务的结果也会落盘，而是直接对接后面的MD5等自动化验证手段进行结果对比，确保任务正确性。

通过这种方式，相比传统方式我们能够更加保护用户的数据，因为不需要人工干预进行数据脱敏，从而避免人为犯错的可能同时这种方式最大程度复制真实场景，能够可靠地进行执行性能等分析，因为所有的背景噪音是一模一样的，能够很好的验证我们在调度上，规模上各种改进的效果。

调度器优化

不可测性。上改了一个算法，拿新的任务调到线上，就改变了负载，因为和老的不一样，在对比的时候，新的调度算法已经改了负载均衡，会有一系列的影响，最后会发现要观察这个行为已经影响去观察的东西的本身，这是调度的不可测性。

少数者光环。我们往往会发现一种现象，当新的调度器渐渐成为主流，优化性能越来越差，这往往是性能提高主要因为新的优化器对比老优化器具有不公平竞争的关系。

那么如何验证新的调度算法。在分布式场景里面怎么做到新算法的调优，将线上workload记录下来进行模拟器进行模拟，因为workload是线上用老的方法记录下来，再跑新的算法的时候，所有的workload都是有先后关系的，变化前面一个就会变成后面一个，这个偏差误差就会越来越宽，甚至有时候方向性的判断都不能给你。所以我们也是采用flighting的方式上进行验证，但是为了避免少数者光环这个问题，我们需要先把新的调度器调整参数使得其和老调度器能够公平的使用资源，然后在进行验证。等到新的优化器成为主体后在来调整剩下这些。

MaxCompute灰度上线、细粒度回滚

上面我们谈了怎么运用并行分析能力验证查询器和优化器，以及怎么用flighting的工具去验证线上执行，执行时候怎么能保证产生正确结果和怎么去验证调度器的算法。这些步骤都做完，我们就要发布了，为了控制上线风险，我们支持非常细粒的灰度发布，当发现危险在不用人工干预的情况下迅速回滚。我们先把任务里面按照重要程度进行分级，然后通过一定的比例去用新版本，如果中间出现了任何问题迅速回零。

有了这几个技术，整体的开发流程分为开发、回归和上线。所有的开发工程师可以自己进行线上的认证，自己提交私有版本，也不会影响线上的版本，利用1%的线上资源可以做这个flighting。验证完就可以做回归测试，我们的发布过程中会用灰度发布来控制上线的风险，开发人员可以等上个版本的回归发布时，开始下一个版本的研发，这样才能迅速的做到快速迭代，使得大数据的分布式平台，做到持续的发布和演化。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/tongxinshuyu/article-30114-3.html