2015年4月，一家全新的基础架构即服务的软件产品ZStack面世。ZStack的主创人员是自在海外云计算公司的中国人。ZStack是基于Java语言，结合了OpenStack和CloudStack上的一些优势，又全新的设计了整套管理软件的架构。
ZStack的架构特点包括：全异步，进程内微服务，无锁架构，无状态，全插件系统，自高可靠，基于工作流的回滚架构，资源管理瀑布架构。提供的能力包括，一键安装，无缝升级，灵活配置，单台管理节点可以管理数十万的物理服务器和上百万的虚拟机，超快的云主机创建和部署能力。
ZStack是全异步架构。全异步是说，所有ZStack中的操作都以异步操作完成，无需占用任何当前线程等待其他操作的完成，这是ZStack能够同时响应和管理数十万主机节点的关键。而同步架构通常需要占用当前thread，等待所有操作完成后才返回。例如，通常基础架构即服务创建一个VM需要完成以下操作：
创建VM数据结构(compute 服务) ---> 选择VM的目的host(compute 服务) ---> 分配存储资源(storage 服务) ----> 分配网络服务(network 服务) ---> 在host上创建VM(compute 服务)
在上述过程中，如果使用同步架构，在并发量大的情况下，比如1000人同时创建VM，至少要占用1000个thread，这极大的消耗了系统的资源。但在ZStack全异步的架构下，用户创建VM的操作提交并注册callback后立即返回，不占用任何thread等待。当所有创建VM的步骤完成后，之前注册的callback把结果返回给操作的发起者。
ZStack的异步架构分为三个部分：
1. 消息总线: 服务之间通过消息异步通讯。一个服务完成了另一个服务提交的请求后，将结果通过返回消息返回给消息来源方。消息请求方无需等待，只需在发送消息的时候注册一个回调函数，返回消息到达时会自动调用该回调函数来通知结果
2. 异步函数调用: 服务内部的操作，通过类似JavaScript的aysnc method call实现。一个操作无需等待起调用的操作完成，而是在调用某个函数的时，同时注册一个回调函数用于接收结果
3. 异步http请求: ZStack在跟运行在不同机器上的Agent（例如kvm agent）通讯时，使用的异步http请求。agent在完成具体操作后，会将结果通过http发回到ZStack管理程序，再通过回调函数通知操作的发起者
以上三个方面，贯穿了ZStack的整个实现。凡是秒级以上的操作，都是以异步的方式实现的。
其它项目例如OpenStack/CloudStack，90%以上的是同步操作。偶有异步操作，由于不是全异步架构，反而会占用更多的线程。比如CloudStack的storage操作，请求方会起一个新的thread来完成操作，同时发起操作的thread睡眠等待另一个thread的完成，这就造成原来同步只需要一个thread的情况，变成了需要两个thread。反而让情况更糟，这就是因为整个架构不是全异步引起的。
稳定性ZStack设计中最强调的部分。ZStack的稳定性依靠两个部分保证：架构和测试。ZStack架构宏观上采用微服务，类似Openstack，将不同的功能的模块实现成不同的服务，服务相互之间并没有直接依赖，使用消息总线通讯，从而实现宏观架构的松耦合。与Openstack不同，ZStack并没有将不同服务运行在不同的进程中，而是所有服务仍然共享同进程。ZStack称之为进程内微服务，这主要是为了解决各服务之间通过RPC调用的天然不稳定性，难以实现事务的问题。ZStack的各服务，可以通过被称为工作流（workflow）的机制，实现事务操作，保证某一个服务的操作失败后，能够rollback此前其它服务已经完成的操作，从而保证系统状态始终处于一致。同时ZStack具有的多节点扩展性（下一节描述）可以解决负载平衡和高可用性的问题。在微观方面，ZStack采用跟著名Java IDE eclipse类似的插件系统。ZStack的每个服务本身都是由不同的插件构成的，插件之间无直接耦合调用关系，而是通过插件系统分发各种事件，以实现服务本身的微观松耦合。
一个独立的ZStack进程称为一个ZStack节点，同一台机器只能运行一个ZStack节点，运行在不同机器上的ZStack节点可以构成一个ZStack 集群用以管理拥有数量庞大服务器的数据中心。
ZStack 集群中的每一个节点都是平等关系，没有master-slave关系，这就保证了ZStack 集群没有单点失效（single failure point）。当集群中某一个节点出现问题后，集群中的其它节点会自动接管该节点的工作。为了提高集群的稳定性，每个ZStack 节点又是无状态的，其管理的的资源跟其它节点管理的资源之间没有任何关联。为了实现这一点，ZStack借鉴了数据库中sharding的概念（http://en.wikipedia.org/wiki/Shard_(database_architecture)），其核心思想是，将每个节点管理的资源（集群，host, vm，以及vm相关的volume等资源）通过sharding算法，分散到不同的节点中去。所有针对资源的操作，例如VM，都会被消息总线转发到管理该资源的mgmt 节点。当某个节点出现问题时，集群会重新shard失效节点上的资源，让集群中的其它节点接管。
在基础架构即服务中，针对某一个资源的操作，往往会经过多个服务，例如创建一个VM，可能经历compute, storage, network等服务，在OpenStack架构中，这些服务是运行在不同进程不同机器上的，由于RPC的天然不稳定性（见稳定性章节），服务之间的相互调用会很容易失败，而且在发起调用的服务很难确定被调用服务的状体，例如它是否在运行。一旦发生错误，调用方往往要等待一个超时时间才能发现错误，占用了调用方的资源。在ZStack中，所有服务都运行在同一进程空间，这就意味着，每个ZStack 节点，都有相同的服务在本地运行，配合ZStack resource的sharding算法，针对某一个resource例如VM的操作，都会在本地相关的服务中完成，其可靠性大大提高。并且由于操作都在一个ZStack 节点完成，当该ZStack 节点发生错误时，用户看到的是整个操作失败，而不会停留在等待某个服务响应的中间状体。
基于ZStack节点集群，用户可以很容易根据需要添加多个ZStack节点，每次添加和减少节点，ZStack都会重新shard resource，以保证节点之间的负载均衡。同时ZStack节点之间的心跳，可以监测到失效的节点，以重新shard该节点的资源。用户可以根据自己数据中心的稳定性，灵活配置该heartbeat值，以达到最佳效果。
基础架构即服务是云计算最底层的基础架构，它质量的高低很大程度上决定了整个云计算的稳定与否。如果仅有先进的架构，但没有完备的质量保证方案，再优秀的开发人员也无法确保高质量的产品。ZStack从项目伊始就并行构架了一个完善的自动化测试系统。该测试系统的设计原则是，强大，自动，易用（容易添加更多的测试）。
ZStack的自动化测试系统主要分两大类：单元测试和集成测试。ZStack的开发过程中采用了类似敏捷开发模式中测试优先（或者测试驱动开发Test Driven Development）的方式，确保每增加一个新的功能模块和API都需要添加对应的单元测试，这样就可以把大部分的基础bugs消灭在萌芽阶段。基础架构即服务内部功能众多，如果仅按照传统的集成测试方法，很难覆盖各种复杂的操作路径，遗留测试真空地带。ZStack的集成测试结合了传统集成测试和基于模型的测试（Model Based Test）。首先利用传统的集成测试手段构造各种常见的基础架构即服务操作，例如VM的启动，网络/存储的分配，以检查ZStack的基本功能。其次把所有用户可能的操作都抽象出来，确定它们之间的依赖关系，并构建模型。通过模型的*组合来测试各种复杂的结合操作。这种模型测试的过程就好比模拟一个用户各种随机的操作可能，从而最大程度的检查ZStack在各种操作组合中的稳定表现。ZStack的测试系统和build系统进行了完美结合，在每一次ZStack代码更新后，都会自动执行一次测试，以检查新代码是否会带来新的缺陷。
基础架构即服务的能力是管理大量的物理资源（如机器，网络，存储）。ZStack开发了一个高效的模拟器。通过模拟物理资源的行为，可以在一台普通的4核笔记本上模拟出超过3万台主机，10万台虚拟机的操作环境。有了这样的模拟环境，无疑是给ZStack的测试提供了坚强的后盾。 在现有用户的分析报告中，在模拟同时创建500个云主机的场景下， ZStack可以轻松的在2.5秒内完成任务；而相同环境下CloudStack无法完成并发500次的请求。
此外，ZStack的插件系统提供了丰富的插件接口，用于实现对用户体验非常重要的功能(例如前面的VM事件审计功能）。每个新加入ZStack的功能或模块，都可以通过插件系统公开自己的插件接口，从而不断扩展ZStack功能以实现增强易用性，完善用户体验的。
ZStack本身也是参照了EC2的设计，并以之为基础。同时，ZStack也借鉴了很多源自VMware vcloud的概念，向客户提供更适合私有云的使用模式。由于ZStack各个服务都是由一组插件构成的，可以很容易的基于EC2的模式，实现一个基于现有插件接口新的插件，将EC2的功能整合成类似vcloud中的相应功能。
欲了解更多信息，请查看Zstack官方网站:http://www.zstack.org