当前IaaS软件更像云控制器软件，要成为一个完整的云解决方案还缺少很多特性（features）。作为一个正在发展中的技术，预测其完整解决方案的所有必备特性是非常困难的，所以一个IaaS软件不可能在一开始就完成它所有的特性。基于以上事实，一个IaaS软件的架构必须有能力，在添加新特性的同时保持核心结构稳定。ZStack的通用插件系统，使得特性可以像插件一样实现（在线程内或在线程外），这样不只能使ZStack的功能得到了拓展，也可以注入业务逻辑内部去改变默认的行为。
动机
eBay管理OpenStack私有云的首席工程师，Subbu Allamaraju曾说过：
OpenStack是一个云资源管理软件，尽管社区为OpenStack的组建做出了巨大贡献，但是安装好的一个OpenStack实例并不能算一个云。作为一个操纵者你必须处理许许多多的用户不一定知道的附加的操作，这些包括员工基础培训、初始化、维护、配置管理、补丁、打包、升级、高可用性、监控、度量、用户支持、容量预测和管理、计费或退款、资源回收、安全、防火墙、DNS、与其他内部的基础设施和工具的集成，等等。这些活动将花费大量的时间和精力。OpenStack给出了一些创建云必备的成分，但并没有把云打包好。
这表达当前IaaS软件的处境，除了一些构建的非常好的IaaS（像AWS），大多数IaaS（包括我们的ZStack）仍然不是一个完整的云解决方案。在诸如Amazon等先驱多年的探索下，对于公有云解决方案应该是什么样子，目前已经有一个更成熟的应用模型。由于仍然处在开发阶段，私有云目前还没有经过验证的完整的解决方案。不像专用的公有云软件，可以专门为制造商的基础设施和服务定制；开源的IaaS软件必须同时考虑公有云和私有云的需求，使得创建一个完整的解决方案变得更加困难。因为我们没有办法预测一个完整的解决方案应该是什么样，我们唯一的办法是提供一个插件式的架构，它能在添加插件的同时，不影响核心业务稳定性。
问题
许多软件声称自己是插件式的，但是很多并不是真的插件式的，或至少不是完全插件式的。在解释原因之前，让我们看看两种主要的插件架构形式。虽然有很多文章讨论过这个话题，以我们的经验来看，我们把所有插件归纳成两种结构，可以被准确的描述为《GoF design patterns》中的策略模式和观察者模式。
源自策略者模式的插件
这种形式的插件通常是通过提供不同的实现，拓展软件特定的功能；或者通过添加插件APIs去添加新的功能。我们熟悉的很多软件都是通过这种模式搭建的，比如，操作系统的驱动，网页浏览器的插件。这种插件组成的工作方式是，允许应用程序通过定义良好的协议去访问插件。
源自观察者模式的插件
这种形式的插件通常注入应用程序的业务逻辑，针对特定的事件。一旦一个事件发生，挂在上面的插件将被调用，以执行一段甚至可能改变执行流的代码，比如，当事件满足某些条件，抛出异常去停止执行流。基于这种模式的插件通常对最终用户是透明的、纯内部实现的，例如，一个监听器监听数据库插入事件。这种插件的工作方式是，允许插件通过定义良好的扩展点去访问应用程序。
大多数软件声称它们是插件式的，要么实现了这些组成方式中的一种，要么有一部分代码实现这些组成方式。为了变得完全插件化，软件必须设想到这么一个想法，即所有的业务逻辑都使用这两种方式实现。这意味着整个软件是由大量的小插件组成的，就像乐高玩具一样。
插件系统
一个重要的设计原则贯穿了所有ZStack的组件：信息最少、自包含且无关其他组件。比如，为了创建一个虚拟机，分配磁盘、提供DHCP、建立SNAT都是非常必要的步骤，管理创建VM的组件应该非常清楚。但是它真的需要知道这么多吗？为什么这个组件不能简化为，分配VM的CPU/内存，然后给主机发送启动请求，让其他组件，像存储、网络来关心它们自己的事情。你可能已经猜到了这个答案：在ZStack中，组件并不需要知道那么多。我们充分意识到这么一个事实，你的组件知道的信息越多，你的应用程序耦合越紧密，最终你得到一个复杂的难以拓展的软件。所以我们提供以下插件形式来保证我们的架构是松耦合的，并且使我们容易添加新特性，最终形成一个完整的云解决方案。
1策略模式插件
通常IaaS软件中的插件是整合不同物理资源的驱动。例如，NFS主存储，ISCSI主存储，基于VLAN的L2网络，基于Open vSwitch的L2网络；这些插件都是我们刚刚提到的策略模式的形式。ZStack已经将云资源抽象成：虚拟机管理器、主存储、备份存储、L2网络、L3网络等等。每个资源都有一个相关的驱动程序，作为一个单独的插件。要添加一个新的驱动程序，开发人员只需要实现三个组件：一个类型，一个工厂，和一个具体的资源实现，这些全部都被封装在单一的插件中，通常被构建成一个jar文件。引用Open vSwitch举一个例子，让我们假定我们将创建一个使用Open vSwitch作为后台的新L2网络，然后开发者需要：
1.1定义一个Open vSwitch类型的L2网络，它将自动注册到ZStack L2网络类型系统中。
1.2创建一个L2网络工厂，负责将一个具体的实现返回给L2网络服务。
1.3创建一个具体的Open vSwitch L2网络实现，跟后台Open vSwitch控制器进行交互。
让三个组件一起放到一个Maven模块中，添加一些必须的Spring配置文件，并编译为JAR文件，你就在ZStack中创建了一个新的L2网络类型。所有的Zstack资源驱动程序都是通过以上步骤实现的（类型，工厂，具体实现）。一旦你已经学会了怎么为一个资源创建驱动程序，你就学会了怎么为所有的资源这么做。正如我们在“ZStack--进程内的微服务架构”中提到的一样，驱动可以有自己的API和配置方法。
2观察者模式插件
策略模式的插件（驱动）允许你扩展现有的ZStack的功能；然而，为了使架构松耦合，插件必须能注入应用程序的业务逻辑，甚至是其他插件的业务逻辑；观察模式插件的关键是拓展点，拓展点允许一段插件的代码在一个代码流运行的时候被调用。目前Zstack定义了大约100个扩展点，暴露了大量让插件去接收事件或改变代码流行为的场景。创建一个新的扩展点就是定义一个java接口，组件可以很容易地创建扩展点，以允许其他组件注入自己的业务逻辑。为了了解它是如何工作的，让我们继续我们的Open vSwitch的例子；假设Open vSwitch L2网络需要钩入创建VM的过程，以在VM创建之前准备好GRE隧道，该插件实现如下：
当ZStack连接到KVM主机，Open vSwitch L2网络想要在主机上检查并启动Open vSwitch的守护进程，那么它实现KVMHostConnectExtensionPoint：
这就是你所需要做的一切。创建一个新类型的L2网络,却不需要更改其他任意一个ZStack组件的甚至一行代码。这是ZStack保持其核心业务流程稳定的基础。
不要OSGI：熟悉Eclipse和OSGI的人可能已经注意到，我们的插件系统和eclipse、OSGI的非常相似。可能有人会问，为什么我们不直接使用OSGI，它可是为Java应用程序创建插件系统而专门设计的。实际上，我们花费了相当多的时间尝试OSGI；然而，我们感觉它是用力过猛。我们不喜欢在我们的应用程序有另一个容器，不喜欢单独的类装载器，不喜欢它创建插件的复杂性。看起来OSGI正付出大量努力使插件相互隔离，但ZStack想让插件扁平化。我们已经注意到，许多项目在代码中引入了不必要的限制，以使整体架构明显是分层的、隔离的，但由于设计糟糕的接口，插件必须写很多丑陋的代码来克服这些限制，反而打乱了真正的架构。ZStack将所有的插件作为自己核心的一部分来考虑，针对核心业务流程拥有一样的特权。我们不是构建一个类似浏览器的消费级应用程序，用户可能会错误地安装恶意插件；我们是在构建一个企业级软件，每一个角落都需要经过严格的测试。一个扁平的插件系统使我们的代码变得简单和健壮。
3进程外的服务（插件）
除了以上两种方式外，开发人员确实有第三种方式扩展ZStack--进程外服务。虽然ZStack把所有的编排服务包装成一个单一的进程，独立于业务流程服务的功能可以被实现为独立的服务，这些服务运行在不同的进程甚至不同的机器上。ZStack Web UI，一个通过RabbitMQ和ZStack编排服务进行交互的Python应用程序，是一个很好的例子。ZStack有一个定义良好的消息规范，进程外的服务可以用任何语言编写，只要它们能通过RabbitMQ进行交互。ZStack也有称为canonical event的机制，用于暴露一些内部事件给总线，比如VM创建，VM停止，磁盘创建。诸如计费系统的软件完全可以通过监听这些事件，建立一个进程外的服务。如果一个服务想要在进程外，但仍需要访问一些还没有暴露的核心业务流程的数据结构，或需要访问数据库，它可以使用一种混合的方式，即在管理节点上的一块小插件负责采集数据并将它们发送给消息代理，在进程外的服务接受这些数据并完成自己的事情。
总结
在这篇文章中，我们展示了ZStack的插件架构。虽然ZStack并没有成为一个完整的云解决方案，但是它提供了一个架构，可以将任何未来所需要的特性构建成插件（进程内或进程外），在保持核心业务流程稳定的同时，使得快速发展成为一个成熟的、完整的云解决方案变得可能。