牧云插件系统开发历程之插件接口设计，看似简单实则困难重重！

本文将介绍基于WASM 的牧云插件系统开发过程中如何设计插件接口。我们会分享一下我们对插件接口设计的一些想法，以及我们最终实现的插件接口的决策结果。

### 1.引言：本文的目的和背景

在之前的文章中，我们从多个角度分析了牧云插件系统的创新路径、设计原理以及各种技术选型挑战和解决方案。本文旨在详细解释插件接口设计的复杂性和挑战。为了向新读者提供背景信息，本系列文章深入探讨了多个方面，包括但不限于：

- 创新之路：我们如何从一开始无法解决的问题，走到现在“好玩”的阶段。

- 设计原则：明确牧云插件系统面向未来的设计思路。

- 技术选型：包括Agent开发、插件开发、通信框架，甚至是经常引起争议的序列化方法和WASM运行时选型。

本文重点讨论插件接口设计中存在的问题及解决策略。在插件-Agent-服务器-前端的整体架构中，插件接口是插件与Agent通信的关键部分，其设计至关重要。我们将从以下几个方面进行深入探讨：

-插件接口的基本设计原则

- 实际开发过程中遇到的问题及应对策略

- 如何实现高性能、安全、可扩展的插件接口

### 2.插件架构和数据流

#### 2.1 插件如何与Agent通信

插件和Agent之间如何通信是一个大问题。所有安全功能都是通过插件实现的。所有监控事件和信息收集均来自Agent。所有事件和信息都必须由代理传递给插件来执行。因此，插件与Agent之间的通信是最终安全能力实现的关键过程。这个沟通过程需要兼顾易用性和沟通效率。

#### 2.2 数据流的设计与实现

插件本身与Agent之间的通信是类似于进程间通信的进程内通信。

一方面，部分信息来自Agent进程之外的辅助进程，但主要通信仍然来自进程本身；另一方面，存在将数据格式和内部表示从主机进程环境转换到虚拟机本身的问题。因此，这种通信是类似于进程间通信的进程内通信。通常，如果一个进程内的两个进程需要共享一段数据，它们只需要共享一个指向这段数据的指针即可。那么两个进程就可以分别通过指针间接读取和修改这个共享数据。跨进程的时候，还有一个类似的方法，就是共享内存。通过共享内存的思想从辅助进程获取需要的数据是非常高效的。同样，运行插件的虚拟机也可以通过类似于共享内存的方式进行通信，但是此时不可能让虚拟机直接访问宿主进程的内存空间，但是反过来宿主进程访问虚拟机进程的内存空间是完全可行的，因为虚拟机本身的运行也是由宿主进程控制的。这样，就不同程度地解决了两个方向的通信效率问题。

对于从Agent进程传递到插件虚拟机进程的事件有两个优化。首先是Agent进程只向插件虚拟机提供事件标识符和相关操作方法，让插件通过调用相关方法来间接操作宿主内存空间中存储的数据。这种方法适用于数据量本身比较大且操作比较简单的情况，即重点在于选择报告哪些字段而不是运行大量的检测算法。二是以扁平化的方式提供基础数据类型，然后在插件端通过二次封装重新形成复杂的数据结构。这种方式避免了大量的序列化操作，而且插件端的封装是零拷贝的，因此也能提供更高的性能。

对于插件传递给Agent进程的数据，即插件上报的安全事件，情况比较简单。因为这个时候通常需要的是序列化大量的数据，然后传递给Agent。然后Agent根据上报要求再次序列化并提交给服务器。最后，服务器解析数据并将其传递给前端进行显示。但由于宿主进程可以直接访问虚拟机内存，因此可以省去将插件虚拟机中的数据复制到宿主进程的过程。而是直接访问虚拟机内存读取数据，直接向服务器报告RPC序列化步骤。

通过上述优化方法，大大提高了插件运行和上报的通信效率。

### 3. 平衡、挑战和解决方案

#### 3.1 施工过程中遇到的具体问题

WASI标准支持并不全面，有的存在实现问题，有的限制太多不适合我们的场景。我们的插件使用基于Wasmtime 支持的WebAssembly 虚拟机支持，并且专门使用WASI 标准接口编写，以提供良好的性能和互操作性以及代码编写的一致性。得益于Wasmtime 的高质量实现，我们实现了许多优秀的功能。但WASI在实际使用过程中发现了一些问题。一方面，它提供的一些功能还处于早期开发阶段，在支持跨平台功能方面还存在一些不足。同时，一些跨平台操作存在明显的Bug。另一方面，WebAssembly适合浏览器环境的默认设置有很多限制，无法满足安全产品的实际需求。当前支持的基于能力的限制粒度太粗，无法支持最小特权原则。

#### 3.2 如何解决这些问题

尽管存在上述问题，继续使用WASI 是必要的，以提供与传统可执行编写方法的基本一致性，同时也受益于WASI 标准社区在各个专业领域的最新贡献。由于上述问题和限制的存在，我们必须在WASI现有的能力上进行扩展。我们不仅要提供WASI现有的一些API能力来扩展跨平台能力，还要增加大量新的接口来满足安全检测的需求。

##### 3.2.1 实现组件模型和WIT

Component-Model是WebAssembly综合标准化进程中极其重要的提案，正在积极实施； WIT是与Component-Model配合的标准化IDL。对于我们这些选择未来的人来说，自然要抓住这两个关键要素。通过充分利用两者带来的最新功能，可以极大地丰富WebAssembly的功能，并成倍地提高团队之间的协作效率。

##### 3.2.2 如何获得新能力

当你需要某个能力时，你需要选择如何获取它，包括在插件内部实现、借用WASI能力、在Agent上实现、导出到插件等。虽然没有确切的规则来指导我们如何在这个插件系统中获得新的能力，但是有一些通用的原则。

对于我们来说，这个插件机制的具体实现是跨越多个团队的，所以必须考虑团队之间的沟通成本以及每个团队擅长的领域。例如，如果您只需要实现一些模式或引入一些纯逻辑计算并包含密码学等安全关键操作，那么直接在插件中实现并编译为WebAssembly 是最合适的选择，这样可以避免团队之间的沟通成本，并充分利用WASI。如果需要进行一些常见的操作，比如通过标准输入输出与虚拟机管理器进行通信，直接利用WASI的特性并与传统的写法保持一致是最简单的。最后，如果涉及到跨平台兼容性、系统监控机制、计算密集型操作、安全关键操作等，最好在Agent上实现，以便复用Agent团队的技术积累，更新相关WIT描述文件，并将相关操作导出到插件中。

不同方案之间的权衡如下，重点包括实现效率、通信效率、计算效率、内存效率和易用性：

|领域/实现方法|插件内部实现|借用WASI 能力| Agent 上的实现|

| ------------- | ------------ | ---------------- | ------------ |

|执行效率|高|无需实施|低|

|沟通效率|无成本|无需沟通|高|

|计算效率|中等|无需计算|高|

|内存效率|高|高|中等|

|易于使用|高|中等|低|

最终，我们决定在基础编程模式下复用WASI能力，即以与编写命令行程序相同的模式编写插件，并尽可能启用WASI扩展。大多数编码、解码、数据解析等操作都是在插件内部实现的。其余涉及底层系统机制和安全相关操作的操作均在Agent中实现。

##### 3.2.3 多团队协作的挑战与解决方案

跨多个团队工作通常会导致一系列协作和沟通问题。为了解决这个问题，我们采取了一系列措施：

1. **标准化的接口文档**：通过标准化的接口描述语言（IDL），确保不同团队能够在接口理解上达成共识。

2. **版本控制和API稳定性**：通过语义版本控制来保证不同版本之间插件和Agent的兼容性。

3. **代码审查**：建立代码审查机制，严格审查接口实现，尤其是涉及安全敏感功能时。

4. **持续集成和测试**：自动化测试和集成过程，确保新添加的功能或修改不会影响现有系统。

5. **异步事件驱动**：采用事件驱动的合作模型，允许多个团队并行开发。

### 4.总结

本文深入探讨了插件接口设计的复杂性和挑战，以及如何克服使用WebAssembly 和WASI 标准时的现有限制和问题。我们还针对WASI 标准在实际使用中出现的问题和限制提出了相应的解决方案，包括扩展WASI 功能、密切关注WebAssembly 的新提案、以及为未来实现Component-Model 和WIT。展望未来，我们将积极参与WebAssembly社区，贡献更多适用于安全场景的实践经验。

本系列文章后续文章将进一步探讨各种插件开发的最佳实践和具体案例分析，敬请期待。

## 推荐相关博文

上一篇：**【牧云插件系统技术选型：选择哪种WASM运行时？如果不选择这个，就会出大问题！ 】](https://stack.chaitin.com/techblog/detail?id=105)**

系列文章目录：【【预览】主机Agent插件引擎开发故事总结】（https://stack.chaitin.com/techblog/detail?id=82）

1. **[[揭秘牧云插件开发者的创新之路：从无法解决的问题到“充满乐趣”]](https://stack.chaitin.com/techblog/detail?id=72)**

2. **[【牧云插件系统面向未来的设计原则]](https://stack.chaitin.com/techblog/detail?id=73)**

3. **【【牧云插件系统选型之争】】(https://stack.chaitin.com/techblog/detail?id=77)**

4. **【【牧云插件系统技术选型中探针开发用什么？ 】](https://stack.chaitin.com/techblog/detail?id=83)**

5. **【【牧云插件系统技术选型及插件开发？ 】](https://stack.chaitin.com/techblog/detail?id=85)**

6. **【【牧云插件系统技术选型插件通信框架PK】】(https://stack.chaitin.com/techblog/detail?id=94)**

7. **[【牧云插件系统技术选型：大家都会抱怨的序列化方法选择之争]](https://stack.chaitin.com/techblog/detail?id=97)**

8. **[【牧云插件系统技术选型：应该选择哪种WASM运行时？如果不选择这个，就会出大问题！ 】](https://stack.chaitin.com/techblog/detail?id=105)**