除了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设计的核心思想是最大程度的松耦合架构，保证已有系统在快速添加新功能的情况下也能保证整体架构稳定，避免因实现新功能而反复修改已有代码，导致产品始终没有一个稳定内核的情况。 最后，ZStack从诞生开始就是测试驱动的。在ZStack中验证功能点的唯一方法就是写测试用例。我们有三个全自动化的测试系统：Integration testing system, System testing system，以及Model-based testing system来保证整个项目的质量。其中Model-based testing 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链接通知虚拟机服务。
无状态服务是指通过一致性哈希环(consistent hashing ring)，服务本身可以和它所管理的具体资源分离开来，服务相互之间也无需交换所管理资源的信息。例如在多管理节点部署中会存在多个虚拟机服务，他们共同管理系统中的所有虚拟机。但每个服务自身是不需要知道哪些虚拟机是自己管理的，哪些是其它人管理的。当其它服务向虚拟机服务发送请求时，会用虚拟机的UUID通过一致性哈希环算出管理这个虚拟机的服务，从而保证无论请求在哪个管理节点发起，最终都会被发送到相同的服务去处理。
得益于无状态服务，ZStack的所有业务逻辑无需通过锁相互竞争资源，资源竞争完全通过队列控制。由于一致性哈希环会把针对某一个资源的操作全部转发到同一个服务，ZStack允许每个服务在内存中创建FIFO队列，以请求到达的顺序响应。对于所有操作只能顺序执行的资源，例如虚拟机，服务可以创建并发度为1的队列，保证同一时间只有一个操作在执行。
对于允许并发操作的资源，例如物理服务器可以允许同时执行多个操作，可以创建并发度大于1的队列。
通过基于队列的无锁架构，ZStack即实现了对关键资源的操作同步，又实现了对操作并发度的控制，在提高系统的吞吐性同时，又保证了系统在大吞吐量时的稳定性。例如物理服务器(host)资源的默认并发度是10，在系统大负荷的情况下，ZStack保证物理服务器最多响应10个请求，多的请求排队，避免了过多的请求造成资源的崩溃。当然，资源的并发度完全是可配置的，用户可以通过API配置例如物理服务器的并发度，根据系统的负荷调整参数。 |
