没有涉及salt插件的讨论那所有关于salt方法的讨论都是不完整的。理解插件和salt的可插拔架构往往就像发现新大陆的感觉，把salt研究者变成salt的福音传道者。
基本的解释是：salt的核心框架提供了高速通信和事件总线。
此框架连接并验证受管系统，并为这些系统提供发送通知的方法。
在这个核心框架上层，Salt的其余功能暴露为一组松散耦合的可插入子系统。
可插拔的子系统
salt包含超过20个的可插拔子系统，但大多数用户只对用于直接管理系统的少数感兴趣。下表包含Salt中一些更常见的子系统的列表：
“可插拔是什么意思”
Salt没有定义一个内置的方式来执行任何子系统的任务，每个子系统仅仅是把它的工作委托给插件。salt为每个系统提供一系列的插件，不过更改一个插件在大多数情况下跟更新一个配置文件那样的简单。这种可插拔性使salt非常灵活。
为了说明，下图显示了几个常见的子系统以及每个子系统最常见的插件。
此图表只显示了一些可用的子系统和插件，但应该能给你对salt一般架构有一个初步了解。
作业运行期间的子系统
当一个作业运行时，几个salt子系统被调用用来处理作业。下面的图表显示一个经典的状态运行或远程执行作业的子系统流程:
插件？听起来像讨论salt模块!
在salt中，插件就是Python中的模块，既然每个插件就是一个Python模块，大多数时候，他们被简单地称为模块，或更准确地，Salt子系统模块（Salt auth模块，Salt文件服务器模块等）。只要你明白每个Salt模块都是一个扩展Salt中许多子系统之一的插件，你就会很好地理解这种关系。
在每一步中，子系统委托它的工作给配置的插件。例如，在第7步的job returner插件可能是30个插件中的一个，包含MySQL,redis或者根本没有配置的(在第4步后job returner插件也可以直接在受管系统上运行)。
在每一步中，有许多可用的插件用于完成一个任务，从而可以产生数百种可能的salt配置和工作流。
伸缩性
伸缩性使salt成为一个非常强大和可定制的工具，不过当你在学习这个工具时使得很难回答一些标准的问题。
为了有趣些，我们采取“技术上正确”的方法，并回答几个关于Salt的常见问题：
除了让你非常讨厌的对话，以这种方式回答这些问题确实说了一些关于salt方法管理的事情。你了解你的基础设施，在目前复杂的环境中，没有做任何事情最好的方式。
没有必要为这些事情烦恼，salt为大多数用户设置了出色的默认值。主要是，当你什么时候需要伸缩性，它就在那里。
salt组件
有了salt的可插拔子系统的新知识，希望你开始明白，salt组件实际上是salt中的可插拔子系统，具有相应的插件。Salt grains? Salt pillar? Salt runners?所有可插拔子系统都很容易扩展。
虚拟模块
我们在这里已经讨论了很多，但是还有一个我们需要讨论的模块。还记得早些时候我们解释了salt如何抽象操作系统的底层细节吗？salt实现这种抽象的一种方式是使用虚拟模块。
一些管理任务在不同的操作系统之间非常的不一样，在编写插件时，它们之间能使用的重复代码很少。
例如，Debian系统上的包管理使用一个名为aptpkg的执行模块完成。在Redhat上，它使用一个名为yumpkg的执行模块完成（原因很明显）。如果你一直使用Salt，你会知道salt调用pkg远程执行模块进行包管理，它可以在所有操作系统上使用。
为了启用这种类型的抽象，Salt使用虚拟模块名称加载这些类型的模块。aptpkg模块包含的说明基本上说“如果你是Debian系统，请将此模块加载为pkg。 否则，不要加载这个！类似的代码存在于对Redhat或CentOS的检查决定使用yumpkg中。这样可以存在多个模块来执行相同的任务，但只加载了一个虚拟名称。
在阅读模块文档时，请记住这一点，因为你经常需要阅读非虚拟模块的文档以了解其行为。你可以在Salt模块中搜索__virtualname__，以找到Salt在加载该模块时使用的名称。
下一篇文章我们讨论salt的通信。