插件系统技术概述

技术选型

当安全工具在自称“平台”的时候，插件的编写难度，价值，以及自由度其实是限制工具成为真正“平台”的原因。很久以来，我们一直在探索“插件”模式的最终发展。

在 Python 的时代，其实“插件”也并不是那么棘手的事情。如果不在乎安全性和代码保密性，eval 虽然丑陋，但是好用。

但是当大家的产品变得工程化之后，Golang 这种“静态”特性让插件变得不是那么“自然”，大家可以通过 DLL / .so 来执行插件，但是 “并不是谁都可以写 Golang DLL/.so 的” 不是吗？于是在客户端层面，大家有努力的去想了别的办法，比如 npm 包的格式来封装插件，让他在客户端 “动态” 起来，但是依赖管理仍然是一个比较难过的关。

往往很多时候，我们遇到的这种困难其实换个领域，换个角度已经有了很棒的方案：譬如 Java 中的各种嵌入式脚本语言，经常被用来做“查询”的插件和简单逻辑。既然可以嵌入一些数据库与 IO 的能力，如果嵌入式语言可以使用的话，当然也可以嵌入 “扫描” 能力了。

“嵌入式”是最终方案

当大家有了这个想法之后，我们就发现“嵌入式的语言”作为插件的实现，其实强度和表现力都是远大于 Yaml / Json 这类数据描述语言：表现力层面：图灵完备 > 数据容器(描述)语言。这是毋庸置疑的。

同时，如果为这个图灵完备语言增加和插件平台的各种交互，他理所应当成为一个非常合理的插件系统的。

这件事情是最合适 Yak 来做的，我们的引擎已经可以做到 “零依赖”，“嵌入执行”，“自动代码补全”。难道成为 Yakit 的插件系统核心是一件难事儿吗？当选定了这一条我们认为正确的路线之后，其实后面很多事情就变成了 “加油干” 就能解决的了。

Yakit 的插件是如何运作的？

我们需要固化用户输入的 Schema：当我们把用户输入的参数预先设定好之后，就可以生成用户需要填写的表单了，这其实非常方便，并不需要插件编写者真的去编写“前端”，不需要用户编写界面可以降低很多成本

当我们使用配置好的参数 + Yak脚本的时候，我们就可以把这两个东西保存到 Yak 核心引擎中，作为一个插件的持久化。

所以只要能拿到插件的持久化 ID，我们就可以获取到插件的全部信息，只要填了相对应的参数，我们就可以做到在 Yak 引擎中执行了。