本文将介绍在基于WASM的牧云插件系统开发过程中，如何设计插件接口。我们将分享我们对插件接口设计的一些思考，以及我们最终实现的插件接口的决策结果。
在之前的文章中，我们从多角度解析了牧云插件系统的创新之路，设计原则，以及各种技术选型的挑战与解决方案。这一篇文章旨在细致解读插件接口设计的复杂性和挑战。为了给新读者提供背景信息，本系列文章已经深入探讨了多个方面，包括但不限于：
本文专注于插件接口设计的问题与解决策略。在插件-Agent-服务器-前端的整体架构中，插件接口作为插件与 Agent 之间通信的关键部分，其设计至关重要。我们将从以下几个方面进行深入探讨：
插件和 Agent 之间如何通信是个大问题。所有安全功能都是通过插件实现的，所有监控事件和信息采集都是来自 Agent 的，所有事件和信息都要由 Agent 传递给插件执行，因此插件和 Agent 之间的通信是最终安全能力实现的关键过程。这个通信过程需要兼顾易用性和通信效率。
插件本身和 Agent 之间是类似于进程间通信的进程内通信。
一方面，有一部分信息是来自于 Agent 进程之外的辅助进程的，但主要的通信仍然来自于进程自身；另一方面，从宿主进程环境到虚拟机内本身就存在数据格式和内部表示形式的转换的问题。因此说这种通信是类似于进程间通信的进程内通信。通常，如果是进程内部的两个过程需要共享一段数据，那么只需要共享指向这段数据的指针就可以了。然后两个过程就可以分别通过指针来间接读取和修改这段共享的数据。当跨进程的时候，也存在一种类似的方式，也就是共享内存。通过共享内存的思路来从辅助进程中获取所需的数据非常高效。类似的，运行插件的虚拟机也可以使用类似与共享内存的方式来通信，但是这次不可能允许虚拟机直接访问宿主进程的内存空间，但反过来由宿主进程访问虚拟机进程的内存空间则是完全可行的，因为虚拟机本身的运行也同样受宿主进程的控制。通过这种方式从不同程度上解决了两个方向上的通信效率问题。
对于从 Agent 进程传递到插件虚拟机进程的事件来说，有两种优化。第一种是 Agent 进程仅向插件虚拟机提供事件标识符和相关的操作方法，让插件通过调用相关的方法来间接操作存储于宿主内存空间中的数据，这种方法适合本身数据量比较大同时操作比较简单的情况，也就是着重于选择上报哪些字段而不是需要运行大量检测算法的情况。第二种是通过平坦的方式提供基本数据类型，然后通过二次封装在插件侧重新形成复杂数据结构，这种方式避免了大量的序列化操作的需求，而在插件侧的封装则是零拷贝的，因此也可以提供较高的性能。
对于插件传递到 Agent 进程的数据，也就是插件上报的安全事件来说，情况更简单一些。因为此时通常需要进行的操作是序列化大量的数据然后传递给 Agent。然后 Agent 再次根据上报要求序列化后提交给服务端，最后服务端解析数据传递给前端进行展示。但由于宿主进程可以直接访问虚拟机内存，因此可以节约插件虚拟机内的数据复制到宿主进程的过程，而是通过直接访问虚拟机内存读取数据来直接进程向服务端上报的 RPC 序列化步骤。
通过上述的优化方法，极大提高了插件运行和上报的通信效率。
WASI 标准支持不全面，部分存在实现问题，部分进行了过多的限制不适合我们的场景。我们的插件采用了基于 Wasmtime 支持的 WebAssembly 虚拟机支持，尤其是采用 WASI 标准接口进行编写，以提供良好的性能和互操作性，以及代码编写上的一致性。得益于 Wasmtime 的高质量实现，我们实现了很多优良的特性。但实际使用 WASI 的过程中还是发现了一些问题。一方面，其提供的一部分特性仍然处于早期开发阶段，对于涉及跨平台的特性支持存在一些不足，同时还有一些可以跨平台的操作存在比较明显的 Bug；另一方面，WebAssembly 适合于浏览器环境的默认设置有非常多限制，不能满足一个安全产品的实际需求，而基于 Capability 的限制当前支持的粒度还太粗，不足以支撑最小权限原则。
虽然有以上各种问题，但继续使用 WASI 仍然是必要的，这可以提供与常规可执行文件编写方法的基础一致性，同时还可以受益于各个专业领域中 WASI 标准社区的最新贡献。由于以上问题和限制的存在，我们必须在 WASI 已有能力的基础上进行拓展，既要提供 WASI 已有的部分 API 能力以拓展跨平台能力，也要增加大量新的接口来满足安全检测需求。
Component-Model 是 WebAssembly 上综合性的标准化进程中极为重要的一个提案，并且正在积极实现当中；WIT 则是配合 Component-Model 的标准化 IDL。对于选择未来的我们来说，自然需要紧紧抓住这两个关键要素。通过充分利用两者带来的最新特性，可以极大丰富 WebAssembly 的能力并成倍提高各团队间协作的效率。
当需要一个能力的时候需要选择如何获得，具体包括插件内部实现、借用 WASI 的能力、在 Agent 上实现并导出到插件。虽然没有一些确切的规则指导我们具体应该如何在这套插件体系中获得一个新的能力，但确实存在一些一般性的原则。
对我们来说，这一插件机制的具体实现跨多个团队，因此必须考虑团队之间的沟通成本以及各个团队擅长的领域。例如，如果仅仅需要实现一些模式或者引入一些纯逻辑的计算且包含密码学等安全攸关的操作，则直接在插件中实现并编译到 WebAssembly 是最合适的选择，既可以避免团队间沟通的成本又充分利用了 WASI。如果需要进行一些通用操作，例如通过标准输入输出与虚拟机管理器进行沟通，则直接利用 WASI 的特性最为简便且能保持与传统编写方法一致。最后，如果涉及到跨平台兼容性、系统监控机制、计算密集型操作和安全攸关的操作，则最好在 Agent 上实现，以便复用 Agent 团队的技术积累，并更新相关的 WIT 描述文件，导出相关操作到插件中。
不同选择的权衡如下，关键点包括实现效率、通信效率、计算效率、内存效率和易用度：
| 领域 / 实现方式 | 插件内部实现 | 借用 WASI 能力 | 在 Agent 上实现 |
|---|---|---|---|
| 实现效率 | 高 | 无需实现 | 低 |
| 通信效率 | 无成本 | 无需通信 | 高 |
| 计算效率 | 中 | 无需计算 | 高 |
| 内存效率 | 高 | 高 | 中 |
| 易用度 | 高 | 中 | 低 |
最终我们决定，基础编程模式复用 WASI 能力，即像编写命令行程序一样的模式编写插件，同时尽量启用 WASI 拓展。多数编解码、数据解析等操作在插件内部实现。其余涉及系统底层机制和安全攸关的操作在 Agent 中实现。
跨多个团队的合作往往会引发一系列协作与沟通的问题。为了解决这一问题，我们采取了一系列措施：
本文深入探讨了插件接口设计的复杂性和挑战，以及如何在使用 WebAssembly 和 WASI 标准时，克服现有的限制和问题。我们也针对 WASI 标准在实际使用中的问题和限制提出了相应的解决方案，包括拓展 WASI 能力、密切关注 WebAssembly 的新提案、面向未来贯彻 Component-Model 和 WIT 等措施。展望未来，我们将积极参与到 WebAssembly 社区中，贡献更多适用于安全场景的实践经验。
本系列文章的后续篇章将进一步探讨各种插件开发的最佳实践和具体案例分析，敬请期待。
上一篇：【牧云插件系统技术选型之WASM运行时选哪个？不选这个竟然出大问题！】
系列文章目录：【预告】主机Agent插件引擎开发故事汇总
