ZStack云计算架构探秘（二）： 高可伸缩性

可伸缩性是衡量IaaS能力的重要指标，几乎所有的IaaS都宣称自己具有高弹性的扩展能力。但是到底能够伸缩到什么程度，只有谁用谁知道了。对于ZStack来说，我们的设计目标就是能够利用单台管理节点管理数十万台物理主机和数百万台虚拟机。管理的过程中必须完成及时有效的响应。单从ZStack提出的这个数量级来说，应该可以绝对领先当今市面上其他的开源IaaS了。也许你对此会嗤之以鼻：支持这么多虚拟机有必要吗？我现在用的IaaS没这么高也挺好的啊。但是我会告诉你，这非常有必要。原因不仅仅是因为以后的云计算管理的服务器的体量一定会越来越大，而且还体现了IaaS软件自身设计的健壮性和稳定性。如果可以利用单台服务器就能满足的能力，你非要通过10台，100台服务器来实现，这只能说明你用的IaaS内部逻辑实现的过于复杂，而且过多的复杂的控制节点必然会带来整个架构不稳定的风险。

那么ZStack是如何实现这么高的调度能力呢？我们有三项核心技术：异步架构，无状态的服务（StatelessService Arch）以及无锁架构（Lock-free Architecture）。

大家都知道“异步调用”最大的好处是可以提高系统响应性，让程序在有限的资源（Linux系统的总进程数量是有限的）调度中不会被海量的服务请求挂住。对于云计算而言，由于它需要协调各种计算，存储，网络的资源。有很多操作涉及I/O（网络，存储）调用，这些调用过程通常都是以秒为单位计时的。但是在管理数百万台虚拟机的时候，ZStack必须能够具有每秒处理数万个API请求的能力。如果不采用异步调用，在发生耗时的I/O操作的时候，为了继续保持系统响应能力，就必然会创建更多的同步的进程。最终到达系统处理的上限。所以利用异步调用，ZStack只需要使用一千个服务线程就可以完成海量的工作请求。每个服务线程负责把任务转发给对应的Agent（这些Agent跑在不同的主机上，例如VM1的在Host1上，那么VM1的操作会转发给跑在Host1上的Agent）。当Agent完成对应的操作，就会返回一个结果告诉服务线程。服务线程再进行后续的操作。在Agent执行操作的过程中，管理节点的服务线程并不会傻等Agent返回结果，而是转头处理其他的服务请求。

当然在生产环境中，考虑到更高效和安全性，IaaS往往会部署超过一个管理节点。管理节点的增加和减少也是一个很关键的Scalability的指标。对ZStack来说，管理节点的添加和删除都是非常轻量级的工作，因为ZStack采用了一种叫做“无状态服务”的机制（Stateless Service）。这好比CPU的流水线作业，每一个前端API的请求，最后都会被分配成很多微小的任务按照顺序独立完成。由于每个任务可以独立完成，所以不同的任务可以被分派给不同的管理节点。实际调度过程中，服务调度程序会根据当前节点的数量利用ConsistenceHashing Ring，公平的分派任务给每一个节点。每个服务节点可以自己完成注册任务，请求获得任务的处理权。所以一旦需要提供更高规模的服务请求，用户只需要简单的再启动一个服务节点就可以了。同理，如果一旦有服务节点退出，它就会被从Hashing Ring中移除。它的退出既不影响已经完成的任务，以后也不会有任务调度到这个服务节点上来。

需要指出的是，hashing ring算法会保证相同资源（通过UUID)的操作会被相同的管理节点所处理。这点对下面一个特性也是非常重要的支撑。

软件锁和信号量通常是解决互斥资源被同步调用问题的常见手段。IaaS管理的资源有大部分都有共享问题，例如同时对一个虚拟机进行不同的操作，或者同时在一个Host上创建不同的网络设备。我们之前介绍过的ZStack采用了异步架构，如果我们一旦在异步系统里使用锁，就会立即失去异步特性的优势。例如，当一个异步线程由于被锁住而无法立即返回，它就会消耗可用的服务线程数量，当全部的线程被锁住，哪怕是短暂的，那也会降低ZStack服务的响应能力。那如果我们不用锁，还有什么其他办法呢？ZStack遵循了非常简单的设计原则，采用任务队列来最大化的避免了使用软件锁。所谓队列，也就是先进先出。一串会引起竞争资源的任务被放进一个队列里，按照先来先服务的原则，也就避免了可能的锁操作。服务的队列会根据任务是否可以并行执行，而采取单线程服务:

或是多线程服务模型:

总结一下，利用队列，无状态服务以及异步架构，可以让ZStack达到极高的可伸缩性。健壮的系统将会给未来的云市场提供强大的动力支持。如果你希望自己的云产品，或者云服务，或者自己的机房未来能够有最好的技术支撑。可以来尝试一下ZStack，一定会让你有耳目一新的感觉。