当我们谈论分布式系统时，调度器、注册中心、配置中心几乎成为默认标配。然而 Pollen 项目反其道而行之，用纯 Go 实现了一个无需任何控制平面的自组织 WASM 运行时。工作负载像种子一样撒入集群，自主选址、动态迁移、就近路由 —— 这一切都发生在节点本地决策中。本文将剖析其核心架构，为想在边缘场景部署无服务器计算能力的团队提供可落地的技术参数。
自组织 mesh 的理论基础
传统分布式系统的核心难题在于全局状态一致性。通常的解法是引入一个中心组件 ——etcd、Consul、ZooKeeper—— 负责协调所有节点的认知。然而中心组件本身成为可用性瓶颈，也带来了运维复杂度。Pollen 的设计哲学是让每个节点拥有相同的运行时状态视图，通过 gossip 协议传播 CRDT（无冲突复制数据类型）来实现最终一致性。
具体而言，Pollen 在每个节点上维护一个收敛文档（converging document），记录当前集群的拓扑信息、已发布的工作负载（官方称为 "seeds"）以及路由表。当任意节点执行 pln seed ./hello.wasm 时，该操作先在本地生成一条 CRDT 更新，随后通过 gossip 协议周期性地与相邻节点交换增量。得益于 CRDT 的数学属性，这些更新在任何顺序下合并都会得到相同结果 —— 这正是 "无需协调器" 的底气所在。
gossip 层的实现基于 QUIC 协议，单一 UDP 连接即可复用传输控制消息、gossip 同步和服务流量。节点之间会尝试直连，如果双方都能暴露公网地址则直接建立 mTLS 隧道；否则流量会经由任意可达节点中转，整个过程对上层透明。
工作负载 placement 的本地决策机制
没有中心调度器， workload 该去往哪个节点？Pollen 的答案是：每个节点自行评分。评分公式综合考量三个维度：当前可用内存容量、本地是否已缓存对应 artifact（以 SHA-256 哈希为标识）、以及该节点距离请求来源的网络拓扑距离。
当一个 seed 被发布到集群时，gossip 协议会将 seed 的哈希与元数据传播到所有节点。收到广播的节点独立计算「是否应该 claim 这个 replica」—— 如果本地资源充裕且缓存命中，概率上更容易主动「认领」；反之则保持旁观。被认领的 replica 会持续向集群广播自己的存活状态，形成一种「声明式」的服务注册机制。
这种设计的优势在于容错：节点宕机后，存活节点会在下一个 gossip 周期内发现其「消失」，随即重新评估本地资源并可能「捡起」原属于失败节点的工作负载。demo 演示中，10 个全球分布的节点在约 5000 req/s 的压力下能够自发生成 replicas 并相互分流流量，背后正是这套本地决策逻辑在驱动。
WASM 运行时与宿主交互模型
Pollen 依赖 Extism 作为 WASM 运行时抽象层。Extism 支持用 Go、Rust、JavaScript、Python、C#、Zig 等多种语言编写插件，并通过统一的 PDK（Plugin Development Kit）处理宿主与插件之间的调用。这意味着团队可以沿用现有技能栈，而无需强制迁移到某一门特定语言。
seed 的调用采用 pln://seed/<name>/<function> 形式的 URI 方案，授权策略、路由规则和业务逻辑均可内嵌在 WASM 模块内部。每个调用会携带调用者的 Peer ID 和证书属性（通过 pln grant --prop 注入），因此业务代码可以自行实现基于属性的访问控制，无需额外部署 API 网关。
资源约束方面，官方文档未给出硬性数值，但 Extism 本身提供内存限制与执行时间预算的配置接口。建议在生产环境中为单个 seed 设置内存上限在 64MB 至 256MB 之间，执行超时控制在 5 秒以内，并通过监控节点的 CPU 与内存利用率动态调整全局并发阈值。
边缘部署实战：从零到集群
部署一个 Pollen 节点的过程极度精简。安装脚本 curl -fsSL https://pln.sh/install.sh | bash 会根据平台自动选择包管理器（macOS 用 Homebrew，Linux 用 apt/yum），并生成服务文件。初始化集群只需两条命令：
pln init # 创建以本机为根节点的集群
pln bootstrap ssh user@host --admin # 通过 SSH 将新节点纳入 mesh
新节点会自动发现集群中的公网中继节点，从而实现 NAT 穿透。如果目标机器无法通过 SSH 访问，也可以用「邀请制」：在管理节点执行 pln invite --subject <peer-id> 生成带签名的 token，线下发送给目标机器后执行 pln join <token> 完成入网。token 包含集群根密钥、所有已知的公网中继地址以及预设的属性，TTL 过期后需重新生成。
服务暴露同样简洁。在机器 A 上运行 pln serve 8080 api，机器 B 只需执行 pln connect api 即可将 localhost:8080 映射到 A 的服务，整个过程不依赖 DNS、端口映射或 ingress controller。QUIC 的多路复用特性使得单一连接可以同时承载控制平面 gossip、服务流量和 artifact 传输。
可观测性与运维边界
尽管没有中心监控组件，Pollen 仍提供基础的可观测能力。每个节点暴露 /metrics 端点（可通过 pln set static-http 9000 配置端口），输出包括 gossip 同步延迟、活跃连接数、seed 调用计数等指标。对接 Prometheus 时建议额外采集节点级别的基础资源（CPU、内存、磁盘 I/O），因为本地决策逻辑依赖这些数据做 placement 评分。
一个关键的运维边界是：所有节点必须保持「对称视图」。当网络分区发生时，分裂的两侧仍能独立运行 —— 这正是 partition tolerance 的体现。但分区间的工作负载不再共享状态，恢复连通后 CRDT 会自动合并，冲突由数据类型本身的语义决定。若业务对一致性要求极高，需评估是否在应用层引入额外的事务机制。
整体而言，Pollen 为边缘场景提供了一条「单二进制、无控制平面、自组织」的技术路径。其核心价值在于将调度决策从中心组件转移到每个节点的本地评分算法，结合 CRDT + gossip 实现全局收敛。对成本敏感、节点分布广且希望最小化运维依赖的团队，这个架构值得在测试环境中验证其流量迁移与故障自愈行为。
资料来源：Pollen 官方 GitHub 仓库（https://github.com/sambigeara/pollen）