1. 为什么放弃OpenClaw

OpenClaw 作为一款轻量级 API 网关，在过去两年里支撑了我们的微服务架构。但随着业务规模从 20 个微服务扩展到 80+，日均请求量从 200 万增长到 3000 万，它逐渐暴露出几个难以忽视的问题：

• 性能瓶颈：在高并发场景下（单机 QPS > 5000），OpenClaw 的请求转发延迟从平均 5ms 飙升到 50ms+，成为系统吞吐量的短板。压测数据显示，当并发连接数超过 2000 时，CPU 使用率飙升至 85%，内存占用突破 2GB，频繁触发 GC 导致请求毛刺严重。
• 配置管理混乱：OpenClaw 的配置依赖本地 YAML 文件，缺乏热更新能力，每次路由变更都需要重启网关，严重影响发布效率。据统计，平均每次配置变更耗时 5 分钟，一个月因配置变更导致的停机时间累计超过 2 小时。
• 插件生态匮乏：官方提供的认证、限流、熔断插件功能有限，自定义插件开发成本高且文档不完善。例如我们需要的「基于用户角色的动态路由」功能，需要自己从零实现，开发周期长达两周。
• 社区活跃度低：项目已超过 6 个月未更新，Issue 无人回复，遇到 Bug 只能自己啃源码。我们曾提交过 3 个 PR，但至今未被合并。

经过两个月的调研和 POC 验证，我们最终选择了Hermes作为替代方案。

未更新，Issue 无人回复，遇到 Bug 只能自己啃源码。

经过两个月的调研和 POC 验证，我们最终选择了Hermes作为替代方案。

2. Hermes 的核心优势

Hermes 是一款基于 Go 语言开发的新一代 API 网关，它在设计理念和功能完备性上都远超 OpenClaw：

2.1 极致的性能表现

Hermes 采用事件驱动架构，底层基于 epoll 实现 IO 多路复用，单机 QPS 可达 10 万+，P99 延迟稳定在 5ms 以内。在我们的压测中，同等硬件条件下（4C8G 云服务器）Hermes 的吞吐量是 OpenClaw 的 3 倍。

具体压测数据如下：

从数据可以看出，随着并发数增加，OpenClaw 的性能急剧下降，而 Hermes 依然保持稳定。这得益于 Hermes 的 Go 语言运行时优势——协程调度开销远低于 Java 线程，内存占用也更低（同等负载下 Hermes 仅需 256MB 内存，而 OpenClaw 需要 1.5GB）。

2.2 声明式配置与热更新

Hermes 支持通过 CRD（自定义资源定义）管理路由、上游、插件等配置，配合 Kubernetes 原生能力实现配置热更新，无需重启网关。这意味着配置变更可以在 10 秒内生效，而 OpenClaw 需要 5 分钟的重启时间。

apiVersion:hermes.io/v1kind:Routemetadata:name:user-servicespec:host:api.example.compath:/users/**upstream:service:user-svcport:8080healthCheck:path:/healthinterval:10stimeout:3splugins:-name:jwt-authconfig:secret:${JWT_SECRET}algorithm:RS256-name:rate-limitconfig:requests:1000window:60smode:distributed

除了 CRD，Hermes 还支持通过 Admin API 动态管理配置，方便与 CI/CD 流水线集成：

# 通过 Admin API 动态添加路由curl-XPOST http://hermes-admin:8080/api/v1/routes\-H"Content-Type: application/json"\-d'{ "name": "order-service", "path": "/orders/**", "upstream": { "service": "order-svc", "port": 8081 } }'

2.3 丰富的插件市场

Hermes 内置了 30+ 官方插件，覆盖认证鉴权、流量控制、协议转换、日志监控等场景。以下是常用插件分类：

同时提供完善的 Go Plugin SDK，开发者只需实现Plugin接口即可快速扩展：

packagemainimport("github.com/hermes-gateway/sdk""regexp")typeCustomAuthPluginstruct{}func(p*CustomAuthPlugin)Name()string{return"custom-auth"}func(p*CustomAuthPlugin)Handle(ctx*sdk.Context)error{token:=ctx.Request.Header.Get("X-Auth-Token")iftoken==""{returnctx.Abort(401,"missing auth token")}// 自定义验证逻辑：支持 Bearer Token 和自定义格式bearerRegex:=regexp.MustCompile(`^Bearer\s+(.+)$`)ifmatches:=bearerRegex.FindStringSubmatch(token);len(matches)>1{ctx.Set("token",matches[1])}else{ctx.Set("token",token)}returnctx.Next()}funcmain(){sdk.Register(&CustomAuthPlugin{})}

2.4 活跃的社区与商业支持

Hermes 由 CloudWeGo 团队开源维护，GitHub Star 已突破 8k，每月发布一个稳定版本。同时提供企业版商业支持，包括 7×24 小时技术支持、SLA 保障和专属功能定制。

3. 迁移方案与踩坑记录

3.1 迁移步骤

我们采用「灰度迁移、逐步切换」的策略，整个过程分为三个阶段：

1. 并行部署：在现有 OpenClaw 集群旁部署 Hermes 集群，通过 DNS 权重将 10% 的流量切到 Hermes。
2. 功能验证：观察一周的延迟、错误率、业务日志，确认 Hermes 表现稳定后逐步提升流量比例。
3. 全量切换：流量达到 100% 后，保留 OpenClaw 集群作为冷备，一周后下线。

3.2 遇到的坑

坑一：WebSocket 连接断开

迁移后发现 WebSocket 长连接在 60 秒后自动断开。排查发现 Hermes 默认的idle_timeout为 60s，而 OpenClaw 没有这个限制。解决方案是在 Hermes 配置中调大超时时间：

spec:upstream:idle_timeout:300s

坑二：自定义 Header 丢失

部分业务依赖X-Request-Id和X-User-Id等自定义 Header 进行链路追踪。迁移后发现这些 Header 在转发过程中被 Hermes 过滤掉了。需要在配置中显式声明允许透传的 Header：

spec:headers:preserve:-X-Request-Id-X-User-Id-X-Trace-Id

坑三：限流策略差异

OpenClaw 的限流是「单机模式」，而 Hermes 默认使用「分布式模式」基于 Redis 实现。迁移后部分接口的限流阈值需要重新调整，因为分布式限流的精度更高，但也会引入 Redis 延迟。我们最终将部分非关键接口改为本地限流模式：

plugins:-name:rate-limitconfig:mode:local# 使用本地限流，避免 Redis 依赖requests:500window:1s

4. 迁移后的收益

完成迁移并稳定运行一个月后，我们统计了以下数据：

5. 总结与建议

如果你也在使用 OpenClaw 并遇到了类似的痛点，我强烈建议你尝试 Hermes。迁移过程虽然有一些小坑，但整体收益非常显著。

几点建议供参考：

• 不要一次性全量切换，灰度迁移是降低风险的最佳方式。
• 提前梳理自定义插件，评估是否需要迁移到 Hermes Plugin SDK。
• 关注 WebSocket 和长连接场景，这是最容易踩坑的地方。
• 做好监控和告警，迁移期间重点关注延迟、错误率和业务指标。

技术选型没有银弹，但 Hermes 在当前阶段确实是我们团队的最佳选择。希望这篇实战记录能帮到正在做网关选型的你。