ZStack--可拓展性的秘密武器1：异步架构

ZStack的架构使得其中99%的任务能被异步执行。基于这点，ZStack中单一的管理节点可以管理几千台物理服务器，上万台虚拟机，处理成千上万个并发任务。

动机

对于管理大量硬件和虚拟机的公有云而言，可拓展性是一个IaaS软件必须解决的关键问题之一。对于一个大概拥有5万台物理服务器的中型数据中心，预计可能有150万台虚拟机，1万名用户。虽然用户开关虚拟机的频率不会像刷朋友圈一样频繁，但是在某一时刻，IaaS系统可能有成千上万个任务要处理，这些任务可能来自API也可能来自内部组件。在糟糕的情况下，用户为了创建一台新的虚拟机可能需要等待一个小时，因为系统同时被5000个任务阻塞，然而线程池仅有1000条线程。

问题

首先，我们非常不赞同一些文章里面描写的关于“一些基础配套设施，尤其是数据库和消息代理（message brokers）限制了IaaS的可拓展性”的观点。首先，对于数据库而言，IaaS软件的数据量相比facebook和twitter而言只能勉强算中小型，facebook和twitter的数据量是万亿级别，IaaS软件只处于百万级别（对于一些非常大型的数据中心），而facebook和twitter依旧坚强的使用Mysql作为他们主要的数据库。其次，对于消息代理而言，ZStack使用的rabbitmq相对Apache Kafka或ZeroMQ是一个中型的消息代理，但是它依然可以维持平均每秒5万条消息的吞吐量，对于IaaS软件内部通信而言这不就足够了么？我们认为足够了。

限制IaaS可拓展性的主要原因在于：任务执行缓慢。IaaS软件上的任务运行非常缓慢，通常一项任务完成需要花费几秒甚至几分钟。所以当整个系统被缓慢的任务填满的时候，新任务的延迟非常大是很正常的。执行缓慢的任务通常是由一个很长的任务路径组成的，比如，创建一个虚拟机，需要经过身份验证服务à调度器à镜像服务à存储服务à网络服务à虚拟机管理程序，每一个服务可能会花费几秒甚至几分钟去引导外部硬件完成一些操作，这极大的延长了任务执行的时间。

同步和异步

传统的IaaS软件使用同步的方式执行任务，他们通常给每一个任务安排一个线程，这个线程只有在之前的任务执行完毕时才会开始执行下一个任务。因为任务执行缓慢，当达到一个任务并发的高峰时，系统会因为线程池容量不足，运行非常缓慢，新来的任务只能被放在队列中等待被执行。

为了解决这个问题，一个直观的想法是提高线程池容量，但是这个想法在实际中是不可行的，即使现代操作系统允许一个应用程序拥有成千上万条线程，没有操作系统可以非常有效率的调度他们。随后有一个想法是把线程分发出去，让不同的操作系统上相似的软件分布式的处理线程，因为每一个软件都有它自己的线程池，这样最终增加了整个系统的线程容量。然而，分发会带来一定的开销，它增加了管理的复杂度，同时集群软件在软件设计层面依旧