关于 NATS 执行引擎的常见问题
Nex 是一个开源、轻量级的执行引擎，可与 NATS 并行运行。通过运行 Nex 节点，您可以构建一个通用资源池，在其中部署 服务和函数。服务和函数允许是 JavaScript、WebAssembly 甚至常规操作系统可执行二进制文件。
Nex 的代码可以在相应的 Synadia 仓库中找到。这是一个由 NATS 的创建者 Synadia 支持的开源项目。
Nex 代码的主要维护者是 Synadia 的员工，但我们也始终欢迎更多的维护者加入。
嗯，Nex 仓库中的所有代码都是免费的，并使用 Apache-2.0 许可证授权给你。
Nex 支持两类工作负载：服务和函数。服务 是长期运行的，而函数 是短时运行的，并根据某些触发条件按需启动。
服务 可以是原生编译的二进制文件（启用 Firecracker 时为 64 位 elf），而 函数 可以是 WebAssembly 模块或导出的 JavaScript 函数。OCI 镜像支持即将推出。
默认情况下，Nex 使用 Firecracker 来启动小型、安全、快速且轻量的虚拟机。这些虚拟机各自运行一个代理，负责管理该虚拟机中的工作负载以及与 Nex 节点之间的通信。
根文件系统本质上是一个操作系统磁盘映像的快照，用于启动虚拟机时使用。它类似于 Docker 层，但效率更高。
命名空间是一种有关多租户的单元。所有工作负载都限定在某个命名空间内。如果您将 echoservice 工作负载部署到 default 命名空间，然后同样再将其部署到 sample 命名空间，Nex 不会将它们视为相同的。命名空间是逻辑分组，Nex 不强制实施严格的网络边界，也不强制规定您如何使用命名空间。
绝对安全！每个运行工作负载的请求都会发送到特定的 Nex 节点。该 Nex 节点有一个公钥 Xkey，用于加密发送到该节点的数据，例如环境变量和其他敏感数据。只有该节点才能解密发给它的数据。
此外，只有启动工作负载的实体才能终止该工作负载。
简而言之，nex run 适用于生产环境和实际部署，而 nex devrun 则适用于开发人员的迭代循环和测试环境。常规运行工作负载的请求必须包含以下所有内容：
nats://{BUCKET}/{key}；当您只是在本地机器上进行开发和测试时，手动提供所有这些信息会很麻烦，因此使用 devrun 时，您只需提供工作负载二进制文件（.wasm、.js、ELF 二进制）的路径和环境变量，nex CLI 将为您处理其余部分，包括自动将您的文件上传到对象存储。
Kubernetes 是一个分布式工作负载执行引擎，Nex 也是如此。但两者在此开始分道扬镳。Nex 能够提供高效且量身定制的用户体验，因为它对基于 NATS 的工作负载进行了优化和专门设计；而 Kubernetes 则被设计为高度通用，只要投入足够的时间或资金，几乎可以做任何事情。这种广泛的用例使 Kubernetes 在管理、部署和配置方面变得复杂。
大多数用户通过 Kubernetes 的 声明式 层进行交互，该层需要大量的 YAML 配置来管理，而 Nex 是一个纯粹的命令式系统，可通过 CLI 和简单的 API 轻松管理。
简单来说，不需要。Nex 节点进程负责生成包含 Nex 代理的 Firecracker VM。作为 Firecracker 进程的管理者，Nex 节点本身不能运行在 Firecracker VM 中。大部分复杂性应该对最终用户隐藏。