【编者按】已经成为IaaS事实标准的OpenStack仍然面临稳定性、易用性等一系列的难题，新近推出的IaaS开源项目ZStack号称要借鉴IaaS先輩的经验，通过新的技术架构解决OpenStack难以解决的技术问题并得到了OpenStack社区的关注。那么ZStack有何特色？能否实现目标ZStack的发起者和总架构师张鑫（Frank），撰文从架构层面全面介绍了ZStack的设计理念和技术实现并就ZStack的市场目标和社区规划进行了解答。以下为文章内容：

ZStack作为一款新开源IaaS軟件自发布后就迅速引起了技术圈的关注，许多朋友都对它架构特点很感兴趣虽然在有16篇博客详细介绍了它的主要架构特点，但仍要婲一定时间进行阅读才能把握其设计要点笔者作为ZStack的发起者和总架构师，希望通过这篇文章对所有架构要点进行一次梳理围绕它要解決的问题出发，为读者进行一个详细的介绍

ZStack从诞生之初没有急于实现各种炫目的功能，而是花了大部分精力做架构设计希望从架构上解决四个问题：易用性，稳定性高性能，以及扩展性ZStack的所有的架构设计，全部围绕这四个方面展开：

在易用性方面ZStack首先考虑的是软件的安装部署与升级，其次是在长期使用的过程中的营运和维护对于安装和部署，ZStack是一个Java项目在编译的完成后，所有的文件都会被打包到一个Java的WAR文件中部署ZStack实际就是部署一个标准的Java WAR文件到Apache Tomcat这样的web container中。这种部署是Java web应用的标准部署方法非常简单且广为熟知。即使没有IaaS经驗的的用户也可以很容易学会安装。同时ZStack对外部的依赖非常少仅仅需要MySQL数据库一个节点，RabbitMQ消息总线以及Ansible系统配置管理软件，这些都昰Linux各个发行版提供的软件一个单管理节点的ZStack部署如图所示：

如果把MySQL和RabbitMQ放到单独的机器，单管理节点的部署可以很容易扩展成多节点部署：

由于IaaS软件管理数据中心中大量的硬件很多情况下需要安装agent到硬件上，例如安装agent到作为KVM计算节点的Linux机器为了让用户从手动安装配置硬件的枯燥工作中解脱出来，ZStack跟Ansible无缝集成当用户添加一个计算节点时，ZStack调用Ansible自动安装agent并配置系统整个过程对用户透明。用户无需阅读冗長的文档去了解agent需要什么依赖包需要怎么配置，这些全部由ZStack负责用户只需调用一个API即可。类似的设计应用在所有需要安装agent的服务例洳负责提供网络功能的虚拟机(Virutal

WAR文件中，在用户调用API添加一个计算节点时ZStack会自动找到对应的配置文件并调用Ansible去部署agent，用户甚至都不知道这個过程的存在此外，对于高级用户可以通过扩展Ansible配置文件来实现运维过程中的系统维护和升级。例如为了升级KVM机器的某个安装包修复┅个安全漏洞用户只需要在KVM的配置文件中加上相关内容，再调用ZStack的ReconnectHost API就可以自动实现升级功能。

在监控方面ZStack目前提供对关键的系统资源比如物理机，虚拟机的状态进行监控任何在ZStack控制外的状态变化，例如虚拟机的意外宕机都会在一定的时间内被检测到并同步到数据庫一个节点。此外ZStack还通过Java的JMX协议对外暴露监控自身的接口例如监控当前系统运行的任务，系统正在处理的消息消息的平均处理时间和朂大处理时间等。让用户可以实时了解系统动态

丰富的查询API是ZStack为用户运维提供的一个重要功能。ZStack的查询API提供超过400万单项查询条件400万阶塖的组合查询条件。用户在API层面就可以完成数据库一个节点级别的资源查询查询API带来的意义是可以打造真正企业级的UI。在优秀的企业软件中例如微软outlook，JIRA中用户都可以根据自己的需求创建不同的视图。在IaaS中也有同样的需求用户可能需要视图显示所有在同一三级网络中嘚虚拟机，显示所有内存容量低于2G的物理服务器等在没有完善的查询API支持下，UI就只能提供几个默认视图而无法允许用户自定义视图。

ZStack嘚查询API的一个独特之处在于查询框架在接收到API后可以自动生成SQL语句，无需编写代码开发人员只要在数据库一个节点中定义了表，然后茬Java程序中用annotation描述新表与其它表之间的foreign key再为新表继承一个查询API的基础类，所有工作就完成了用户使用新API时，查询框架可以自动感知根據用户的查询条件生成单表SQL以及多表Join的SQL语句。

IaaS软件本身是个集成项目管理了数据中心中大量的子系统，它实际上管理着所有子系统和所囿设备的状态加之IaaS中每一个任务的执行路径非常长，例如创建一个虚拟机就涉及到计算节点网络节点，存储节点状态的变化其中任哬一个步骤都可能出错。一旦错误发生由于当前IaaS缺乏回退机制，某些子系统会遗留在中间状态比如一个虚拟机最后创建失败了，但它嘚DHCP信息却可能遗留在网络节点导致将来可能的DHCP冲突。为此ZStack设计了一个workflow引擎，将任务的每个操作都封装到flow中一旦某个操作出错，workflow引擎會回退(rollback)所以已经执行的flow保证不会系统遗留在中间状态。

例如在上图的创建虚拟机workflow中假设任务在VmCreateOnHypervisorFlow这一步失败了，workflow引擎会回退前面已执行嘚6个flow包括子workflow（图中计算节点分配workflow，创建网络节点虚拟机的workflow）例如删除已创建的网络节点虚拟机，删除已创建的虚拟磁盘归还已分配嘚计算资源到计算节点等。最大程度保证系统状态的完整性

除了可以回退外，workflow引擎还可以允许开发人员通过XML文件来配置关键任务例如茬上图中，创建虚拟机的workflow包含一个创建网络节点虚拟机的子workflow（Creating Appliance VM sub-workflow）这个子workflow跟创建用户虚拟机的workflow类似，只有分配网卡这个flow不同ZStack通过配置XML文件替换掉该条flow（图中绿色部分），就实现了创建网络节点虚拟机的逻辑这种通过XML文件配置workflow的方式被大量运用，例如计算节点分配器(host allocator)存儲分配器(storage allocator)，IP地址分配器(IP allocator)都是通过这种方式实现的开发人员甚至不用写新代码，只需重新组合一些flow的顺序就可以实现新的业务逻辑例如計算节点分配器里的一些实现，就是通过组合已有的flow实现的这种方式使ZStack的组件复用度非常高，帮助整个架构实现了松耦合

除了workflow，ZStack在设計最初期就引入了一个类似于Eclipse的插件系统所有核心功能都是以小插件的形式搭建起来的，保证无论是添加新功能还是移除旧功能都不會修改已有代码，从而保证在快速实现新功能的同时整体系统可以保持稳定。这个插件系统的核心是扩展点(extension point)每个组件都可以定义自己嘚扩展点允许其它组件接入，从而扩展业务逻辑

例如上图所示的安全组(security group)功能，它需要在虚拟机的不同生命期对防火墙规则进行编程但對于虚拟机本身来说，安全组只是一个附加功能所以并不应该实现在虚拟机自身的逻辑当中。基于ZStack的插件系统安全组通过虚拟机模块，网络模块等定义的扩展点插入到了虚拟机生命期网络配置等业务逻辑中，在不修改任何已有模块的情况下实现成一个单独的Java JAR文件。吔就是说安全组本身不会对现有功能造成任何影响，即使删除安全组对应的JAR文件整个系统也只是失去了这个功能而已。通过插件系统ZStack本身架构完全实现了松耦合。

Tag system也是ZStack一个创新虽然很多IaaS软件也有tag的概念，但大多只是帮助用户管理资源ZStack定义一种称为system tag的概念，插件可鉯通过定义system tag在不修改已有数据库一个节点表的情况下，实现为现有表添加新的字段例如在虚拟机表中并不存在一个字段叫hostname，ZStack的一个插件通过定义一个vm::hostname的system tag为虚拟机表增加了这个字段，从而允许用户在创建虚拟机时指定它的hostname通过这种方式，插件在扩展已有功能时无需對现有数据库一个节点表格式进行修改，从而减轻了软件升级过程中数据库一个节点迁移的负担

Workflow引擎，插件系统system tag设计的核心思想是最夶程度的松耦合架构，保证已有系统在快速添加新功能的情况下也能保证整体架构稳定避免因实现新功能而反复修改已有代码，导致产品始终没有一个稳定内核的情况

system可以随机组合API生成测试用例，测试出很多正常使用情况下无法触及的死角为了能够快速重现Model-based testing system发现的死角，我们还开发了一个回放工具它能读入Model-based测试用例产生的日志而生成一个新测试用例，通过回放失败用例来产生一个供开发人员调试的環境避免了人工手动重试数千个API来重现失败用例（因为Model-based测试用例可能随机执行数日，产生数以千计甚至万计的API调用）下面是测试系统運行过程中的一个截图：

ZStack是目前开源软件中，唯一一款号称能够以单管理节点管理几十万物理机器数百万虚拟机，以及响应数万并发API调鼡的软件通过我们的软件模拟器，我们测试过管理10万物理机通过1万到3万并发API创建百万虚拟机的情况。此外我们还进行了虚拟机创建的性能测试数据如下表：

在测试中我们只使用了单网络节点，发现DHCP/DNS软件Dnsmasq成为了性能的瓶颈在跟Dnsmasq社区沟通后，通过打补丁的Dnsmasq我们能将创建10000虚拟机的时间缩短到11分钟。在使用多网络节点（多租户）的环境下我们相信这个数据还可以进一步的提高。

ZStack的高性能受益于三个架构設计：全异步架构无状态服务架构，无锁架构

全异步架构保证一个任务从API调用开始，到最后在外部设备上执行的过程都是全异步的從而任何线程都不会因等待一个操作完成而阻塞。在我们的压力测试中单管理节点响应10000 API调用只用了1000个线程就可以完成。ZStack的全异步架构由彡部分组成：异步消息异步函数调用，异步HTTP调用其中异步消息是服务之间调用时使用的。宏观上看ZStack的功能划分成了多个独立的服务，服务之间通过消息通信连API都是以消息的形式实现。例如有虚拟机服务网络服务，存储服务等在服务的内部存在许多组件，他们协莋完成一个服务的功能这些组件之间的调用使用的是传统的函数调用方式，通过回调函数(callback)实现异步最后，服务与外部agent通信时采用的是異步 HTTP调用例如在创建KVM虚拟机时，虚拟机服务将请求提交给KVM agent后就返回了KVM agent在虚拟机创建完成后，会通过回调HTTP链接通知虚拟机服务

ring)，服务夲身可以和它所管理的具体资源分离开来服务相互之间也无需交换所管理资源的信息。例如在多管理节点部署中会存在多个虚拟机服务他们共同管理系统中的所有虚拟机。但每个服务自身是不需要知道哪些虚拟机是自己管理的哪些是其它人管理的。当其它服务向虚拟機服务发送请求时会用虚拟机的UUID通过一致性哈希环算出管理这个虚拟机的服务，从而保证无论请求在哪个管理节点发起最终都会被发送到相同的服务去处理。

得益于无状态服务ZStack的所有业务逻辑无需通过锁相互竞争资源，资源竞争完全通过队列控制由于一致性哈希环會把针对某一个资源的操作全部转发到同一个服务，ZStack允许每个服务在内存中创建FIFO队列以请求到达的顺序响应。对于所有操作只能顺序执荇的资源例如虚拟机，服务可以创建并发度为1的队列保证同一时间只有一个操作在执行。

对于允许并发操作的资源例如物理服务器鈳以允许同时执行多个操作，可以创建并发度大于1的队列

通过基于队列的无锁架构，ZStack即实现了对关键资源的操作同步又实现了对操作並发度的控制，在提高系统的吞吐性同时又保证了系统在大吞吐量时的稳定性。例如物理服务器(host)资源的默认并发度是10在系统大负荷的凊况下，ZStack保证物理服务器最多响应10个请求多的请求排队，避免了过多的请求造成资源的崩溃当然，资源的并发度完全是可配置的用戶可以通过API配置例如物理服务器的并发度，根据系统的负荷调整参数

ZStack在设计之初就考虑到了不同的用户对云的使用模式的差异性。例如公有云提供商服务提供商，倾向于亚马逊的模式而传统企业用户，则更喜欢VMWare的企业虚拟化模式(Enterprise Virtualization)基于插件系统，ZStack将每个功能实现成小插件默认是亚马逊的EC2模式，也就是各种资源池化然后在这个基础上，通过一些辅助插件ZStack可以在EC2的模式上组合出VMWare这种以虚拟机为中心嘚模式。这样不同的用户就可以根据自己的需求选择相应的模式并且两种模式还可以互通，比如以虚拟机为中心的模式也可以使用EC2模式所提供的安全组（security group）弹性IP（EIP）这样的网络服务。

除了插件系统外ZStack也认识到很多IaaS的功能可以实现成单独的服务，并且允许开发者用他们熟悉的语言来实现这种创建单独服务的方法在ZStack中称为进程外插件(out-of-process plugin)。开发者可以根据自己的喜好选用自己喜欢的语言创建与ZStack管理节点进程分离的服务。如果服务本身功能单一可以订阅ZStack管理节点组播到消息总线的事件(canonical events)，例如账单系统就可以监听各种资源的创建和销毁事件完全实现独立开发。对于功能复杂的服务例如需要访问数据库一个节点的服务，可以通过写一个轻量级的插件安装在管理节点中然後跟进程外服务通信。第二种方式有点类似应用程序通过在操作系统中安装驱动来实现对内核的访问。ZStack的web UI就是以这种进程外插件的方式實现的

基于插件系统和进程外服务，ZStack可以在持续创新开发出各种适应用户需求的应用场景的同时，保持架构的稳定和松耦合

ZStack的整个架构并非离散的功能点的组合，而是在经过精密设计后相辅相成的例如要实现查询API自动化，数据模型就必须预先定义完备；又比如要实現无锁架构就必须要有无状态服务的基础。通过对架构的缜密思考ZStack有信心解决当前IaaS行业面临的困难，为用户提供一款优秀的开源软件

CSDN：OpenStack生态已经比较成熟，公有云私有云的成功案例都有了我们为何还需要ZStack项目？

张鑫：IaaS领域是时候需要新鲜血液了

自亚马逊2006年发布EC2公囿云以来，IaaS（基础架构即服务）领域持续创新先后出现了Eucalyptus, CloudStack，OpenNebula这样的开源软件到2010年OpenStack出现，整个创新达到了一个高潮从业者都认为云计算的春天来了，认为传统企业可以很快的从上个世纪的IT架构中解脱出来迅速迁移到由软件定义的数据中心。但让人大跌眼镜的是5年过詓了，Eucalyptus, CloudStackOpenNebula已渐渐淡出人们的视线，OpenStack一统天下却迟迟打不开企业软件的市场。就在去年OpenStack的发起者Rackspace，宣布不再以纯IaaS提供商的身份进入市场而是转向专注于核心业务“为客户管理服务”，在跟以亚马逊为首的公有云巨头的竞争中败下阵来最近，著名OpenStack公司Nebula倒闭给出的理由昰“市场不成熟”，更是给整个IaaS产业浇了一盆冷水一时间各种悲观论调四起，例如认为企业云市场根本不存在又例如公有云最终统治卋界，企业不再需要自己维护数据中心