Skip to main content

技术总览:"地表最强" 的插件系统

技术选型#

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

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

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

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

“嵌入式”是最终方案#

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

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

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

Yakit 的插件是如何运作的?#

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

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

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

案例:Yakit 中的基础爬虫功能#

大家从视频中可以看到,我们的插件其实非常简单,就可以配置好,编写合适的代码完成自己想做的事情,UI 并不需要用户来做多少事情。