ZStack技术白皮书精选架构篇上册.pdfVIP

www.zstack.io ZStack 技术白皮书精选 架构篇：上册 ZStack 可拓展性的秘密武器 扫一扫二维码，获取更多技术干货吧 www.zstack.io 版权声明 本白皮书版权属于上海云轴信息科技有限公司，并受法律保护。转载、摘编或利用其它 方式使用本调查报告文字或者观点的，应注明来源。违反上述声明者，将追究其相关法律责 任。 www.zstack.io 目录 ZStack--可拓展性的秘密武器1：异步架构 1 ZStack—可拓展性秘密武器2：无状态的服务 10 ZStack--可拓展性秘密武器3：无锁架构 18 www.zstack.io 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 软件上的任务运行非常缓慢，通 常一项任务完成需要花费几秒甚至几分钟。所以当整个系统被缓慢的任务填满的时候，新任务 的延迟非常大是很正常的。执行缓慢的任务通常是由一个很长的任务路径组成的，比如，创建 一个虚拟机，需要经过身份验证服务→调度器→镜像服务→存储服务→网络服务→虚拟机管理 www.zstack.io 程序，每一个服务可能会花费几秒甚至几分钟去引导外部硬件完成一些操作，这极大的延长了 任务执行的时间。 同步和异步 传统的IaaS 软件使用同步的方式执行任务，他们通常给每一个任务安排一个线程，这个线 程只有在之前的任务执行完毕时才会开始执行下一个任务。因为任务执行缓慢，当达到一个任 务并发的高峰时，系统会因为线程池容量不足，运行非常缓慢，新来的任务只能被放在队列中 等待被执行。 为了解决这个问题，一个直观的想法是提高线程池容量，但是这个想法在实际中是不可行 的，即使现代操作系统允许一个应用程序拥有成千上万条线程，没有操作系统可以非常有效率 的调度他们。随后有一个想法是把线程分发出去，让不同的操作系统上相似的软件分布式的处 理线程，因为每一个软件都有它自己的线程池，这样最终增加了整个系统的线程容量。然而