扩展
eKuiper 允许用户自定义扩展,以支持更多功能。 用户可以通过原生 golang 插件系统编写扩展插件,或者通过eKuiper portable 插件系统编写扩展插件,后者支持更多语言。此外,用户也可以通过配置的方式扩展 SQL 中的函数,用于调用外部已有的 REST 或 RPC 服务。
上述 3 种扩展方法都有其自身适合的场景。 一般来说,原生插件的性能最好,但最为复杂,兼容性最低。 Portable 插件在性能和复杂性之间有更好的平衡。 外部扩展不需要编码,但资源消耗最大,只支持函数扩展。本文将介绍每种扩展方法的特点,并讨论具体使用场景。
原生插件扩展
原生插件扩展利用原生 golang 插件系统在运行时动态加载自定义扩展。 eKuiper 最初支持原生插件。 但是由于 golang 插件系统本身的原因,有许多限制,例如:
- 仅支持 Linux、FreeBSD 和 MacOS 操作系统,不支持 Alpine linux 。
- 插件只初始化一次,不能关闭,即插件安装后无法卸载和管理。
- 对构建和部署的要求非常苛刻,给社区带来了很多问题。 例如,插件必须使用与 eKuiper 程序完全相同的 go 版本、依赖版本等构建。 也就是说,在升级 eKuiper 主程序时,总是需要重新构建插件。
安装后,原生插件像原生代码一样运行,可以与主程序共享或传输内存中的数据,从而保证最佳性能。
因此,原生插件扩展适用于以下情况:用户只在支持的操作系统和环境中运行,在更新期间有能力或基础设施重建插件,不需要在运行时卸载插件,只使用 golang 语言系统。
Portable插件扩展
Portable插件扩展是利用 eKuiper 自身基于 IPC 通信实现的插件系统。 它有可能支持所有编程语言,目前支持 go 和 python。 与原生插件相比,它是可移植的,因为插件将在单独的进程中运行,并且没有那些苛刻的构建/部署要求。
portable 插件扩展旨在提供与原生插件相同的功能,但支持更简单的构建和部署。 如果开发者使用 go,甚至可以通过非常小的修改来重用插件代码,可以只构建和部署独立的插件。
因此,portable 插件扩展是对原生插件的补充。 它适用于使用多种编程语言进行编码的情况,构建一次即可在所有版本运行。
外部函数扩展
外部函数扩展通过提供一种配置的方式,使得 eKuiper 可以使用 SQL 以函数的方式直接调用外部服务,包括各种 rpc 服务、 http 服务等。该方式将可大大提高 eKuiper 扩展的易用性。外部函数将作为插件系统的补充,仅在性能要求较高的情况下才建议使用插件。
以 getFeature 函数为例,假设有 AI 服务基于 grpc 提供 getFeature 服务。则可在 eKuiper 配置之后,使用 SELECT getFeature(self) from demo
的方式,无需定制插件,即可调用该 AI 服务。
详细配置方法,请参考外部函数。
当用户已经导出服务并且不想编写代码时,这种方法很有用, 它可以轻松实现 SQL 函数的批量扩展。
对比
让我们对这 3 种方法进行一些比较。 在下表中,动态重载 表示插件是否可以在运行时更新或删除。 更新时重建 表示更新主程序时是否需要重建插件。 如果是,版本更新将变得复杂。 独立进程 意味着插件是否独立于主程序运行。 如果是,插件崩溃不会影响主程序。 通信 表示主程序和插件之间如何进行通信。内存通信是最有效的方法,要求主程序和插件在同一个进程中运行。 IPC (进程间通信)需要在同一台机器上运行,具有中等的性能和依赖性。 Web 通信是指通过 TCP 等 Web 协议进行通信,可以在不同的机器上运行。
扩展 | 扩展类型 | 需要编码? | 语言 | 操作系统 | 动态重载 | 更新时重建? | 独立进程? | 通信 |
---|---|---|---|---|---|---|---|---|
原生 | 源,目标,函数 | 是 | Go | Linux, FreeBSD, MacOs | 否 | 是 | 否 | 内存通信 |
Portable | 源,目标,函数 | 是 | Go, Python ,将来更多 | 任意 | 是 | 否 | 是 | IPC |
外部 | 函数 | 否 | JSON, protobuf | 任意 | 是 | 否 | 是 | Web |