第 23 章 服务提供者、Publisher 与 Aggregator 运维

Walrus 生产运维分三种角色：

• 应用接入运维：维护 publisher、aggregator、缓存和索引器。
• 存储节点运维：运行 Walrus storage node，参与网络存储。
• 协议服务提供者：为团队或客户提供稳定的写入和读取 endpoint。

大多数应用团队先从第一种开始。不要一上来就运行 storage node，除非你已经准备好长期维护磁盘、网络、密钥、监控和升级。

Publisher 运维边界

publisher 是写入入口，生产上要把它当成有成本的交易服务：

• 只对认证用户开放。
• 配置请求体大小上限。
• 记录 upload job 和 Sui tx digest。
• 对 429、5xx、Sui 交易不确定状态做分阶段重试。
• 监控写入成功率、P95/P99 延迟、失败原因。
• 保护私钥和 sponsor 账户。

如果 publisher 代用户付费，要把预算控制写进服务逻辑，而不是只靠钱包余额自然耗尽。

Aggregator 运维边界

aggregator 是读取入口，主要压力来自热点内容和大文件：

• 横向扩展读取服务。
• 对热点 Blob 做缓存。
• 支持 Range 或分片下载策略。
• 配置超时、重试和备用 upstream。
• 监控读取成功率、重构耗时、出口带宽。
• 对异常流量做限速。

如果你在前面加 CDN，要明确缓存失效策略。用户替换业务对象后，旧 Blob 仍可能被缓存；前端 URL 应包含业务版本或内容 ID，避免拿到旧内容。

Storage node 运维边界

storage node 是长期承诺，不只是启动一个二进制。你需要：

• 稳定磁盘和容量规划。
• 可靠网络和公网可达性。
• 钱包、节点密钥、备份和权限隔离。
• 跟随 Mainnet/Testnet release 升级。
• 监控磁盘、CPU、内存、网络、协议错误。
• 明确参与网络的经济和惩罚规则。

生产主网以 mainnet-v1.47.1 为稳定版本事实；测试环境以 testnet-v1.47.1 为准。Devnet devnet-v1.48.0 是预发布，节点运维只能用于试验升级路径。

配置管理

所有服务都应该显式配置网络：

WALRUS_NETWORK=mainnet
WALRUS_CONFIG=/etc/walrus/client.yaml
SUI_RPC_URL=https://...
PUBLISHER_BIND=0.0.0.0:...
AGGREGATOR_BIND=0.0.0.0:...

不要靠“当前 CLI active env”决定生产服务连哪个网络。容器重建、运维手工命令和 CI 环境都可能让 active env 变成错误值。

发布策略

升级 publisher/aggregator：

1. 在 testnet 用同版本配置跑集成测试。
2. 新实例启动后只接健康检查。
3. 小流量切换。
4. 观察写入/读取错误率。
5. 完成切换后保留旧实例一段时间。

升级 storage node 更谨慎：

• 先读官方 release note。
• 确认目标网络版本。
• 备份配置和密钥。
• 避免在 epoch 边界或业务高峰做无准备升级。
• 升级后检查节点同步、存储服务和日志。

实操边界

应用团队常见误区：

• 把公共 publisher 当成永久 SLA。
• 没有保存 tx digest，上传失败后无法判断是否已上链。
• aggregator 没有限流，被大文件下载打满出口。
• 所有环境共用一个 sponsor 钱包。
• 日志记录明文文件名和敏感 blob_id。
• 只在前端配置网络，后端索引器连了另一个网络。

先把这些基础问题解决，再考虑更复杂的节点运维。