Rover-Suite 架构设计：注册中心、网关和管理控制台如何协作
上一篇介绍了 Rover-Suite 想解决的实际问题：当业务服务逐渐增多时，团队不希望继续在 Nginx、前端配置和部署脚本中手工维护地址，也不希望一开始就背上过重的基础设施成本。
这篇从系统设计的角度，说明 Rover-Suite 是怎样把服务注册、服务发现、请求转发和运行态管理组织在一起的。
Rover-Suite 的核心不是“多做几个组件”，而是明确区分三类事情：谁维护在线实例、谁处理业务请求、谁帮助人理解运行状态。
一、先把控制面和数据面分开
在微服务基础设施中，服务注册和请求转发看似都和“服务地址”有关，但它们不应该在同一条热路径上完成。
Rover-Suite 把它们拆成两条链路：
【请求数据面】 客户端 → Rover-Gateway → 业务服务 【注册与发现控制面】 业务服务 → Rover-Nameserver 注册、心跳、注销 Rover-Nameserver → Rover-Gateway 实例快照推送 Rover-Gateway → Rover-Nameserver 启动查询与周期对账这套划分带来一个重要结果：Gateway 不会在每个业务请求到来时，同步请求 Nameserver 查询实例。
正常情况下，Gateway 从本地发现缓存读取已经确认的可用实例，再进行负载均衡和 HTTP 转发。Nameserver 的职责是维护服务注册状态、在实例变化时发布快照，并为 Gateway 的启动和周期对账提供数据源。
这样做既减少了请求路径依赖，也避免了注册中心短暂波动立刻放大为业务请求失败。
二、四个核心角色各自负责什么
| 角色 | 主要职责 | 不承担什么 |
|---|---|---|
| Rover-Nameserver | 注册、续约、注销、过期、实例查询、订阅、快照推送。 | 不直接代理业务流量，不主动探测业务服务的 HTTP 健康接口。 |
| Rover-Gateway | 路由匹配、发现缓存、负载均衡、反向代理、Filter、指标和请求追踪。 | 不把同步查询注册中心放进普通请求热路径。 |
| 业务服务 / Registrar | 在端口真正就绪后注册；持续上报心跳；退出时尽力注销。 | 不负责维护消费方缓存或路由规则。 |
| Rover-Admin | 通过管理 API 观察实例、事件、路由、指标和追踪，并转发支持热更新的配置。 | 不直连业务服务，也不进入 Gateway 的转发路径。 |
这四个角色之间有一个基本约束：运行态管理应该帮助定位问题，但不能成为转发请求的额外依赖。因此 Admin 即使未启动，Gateway 和 Nameserver 的业务能力仍然可以独立运行。
三、一次请求是如何走到业务服务的
我们用一个典型路由举例。假设 Gateway 中配置了下面的规则：
rover:gateway:routes:-id:order-apibusinessPrefix:/api/ordersserviceName:order-servicestripPrefix:""当客户端请求：
GET /api/orders/123Gateway 内部会依次完成：
HTTP 请求进入 Netty Server → 执行 FilterChain → 匹配 businessPrefix → 从本地发现缓存读取 order-service 实例 → 调用 LoadBalancer 选择上游 → 建立或复用出站连接 → 反向代理到业务服务 → 将上游响应写回客户端这里有两个容易被忽略的细节。
第一，服务发现不在请求热路径上。假设order-service当前有三个健康实例，Gateway 处理请求时只读取本地快照，不需要为每次请求再去向 Nameserver 询问一次。
第二，路由和上游选择是两个不同环节。路由决定“请求应该去哪个服务”；负载均衡决定“这一次应该选择该服务的哪个实例”。这使得 Filter、路由、静态上游和动态服务发现都可以在清晰边界内演进。
四、一次服务注册是如何影响网关流量的
服务提供方的生命周期与请求转发链路相互协作，但并不耦合在一起。
以 Spring Boot 服务为例：
应用 Web Server ready → RoverNameserverLifecycle → NameserverClient 建立 TCP 连接 → 提交注册信息 → Nameserver 写入内存注册表 → 服务实例快照发生变化 → Nameserver 推送给订阅该服务的 Gateway → Gateway 更新本地发现缓存Java 服务通过rover-nameserver-starter接入，不需要在启动类中增加注解。Starter 会在 Spring Boot 的ApplicationReadyEvent之后执行注册，确保业务监听端口已经准备就绪。
对于 Node.js、Python、Go、长驻 PHP 和 C++ 等服务，Rover-Suite 提供 HTTP+JSON Registration API。非 Java 服务在端口 ready 后调用注册接口，随后按固定间隔发送心跳，并在优雅退出时尝试注销。两种接入路径最后都会进入同一套RegistrationService和内存注册表，因此实例状态的处理规则保持一致。
五、为什么同时使用“推送”和“对账”
如果只依赖推送，Gateway 在启动、断线重连或少数消息异常时，可能缺少一份完整的当前实例状态；如果只依赖拉取，实例变化要等下一次轮询才能被发现，更新时效又会降低。
Rover-Suite 使用的是“推送优先、查询对账兜底”的发现模型：
Gateway 启动 → 订阅服务 → 查询一份完整实例快照 服务实例发生变化 → Nameserver 推送带版本信息的完整快照 → Gateway 更新本地缓存 周期到达，或发现推送异常 → Gateway 再次查询当前状态 → 按当前状态修复本地缓存Nameserver 为每个服务维护单调递增的revision，同时在 Nameserver 重启后生成新的epoch。Gateway 接收快照时，会先比较epoch，再比较revision，避免旧状态覆盖新状态。
这套机制不把系统宣传为强实时一致性系统。它的目标是：在正常情况下尽快同步实例变化，在启动、断线、重连或推送异常后能够回到可确认的当前状态。
六、为什么在线实例采用纯内存软状态
Rover-Nameserver 当前把在线实例保存在内存中。Nameserver 进程重启后，会创建新的epoch和空注册表；仍然存活的服务由客户端重连或下一次心跳恢复注册。
这看上去不像“持久化更多数据”那么直观，但它解决了一个更危险的问题：一个历史地址曾经注册过，并不代表那个地址现在仍然属于原来的服务。
例如容器重建、Pod IP 复用、端口迁移后，把历史实例直接恢复到注册表，可能会让流量被发送给已经不属于原服务的地址。Rover-Suite 选择短暂的重注册窗口，而不是恢复未经活动客户端重新确认的陈旧端点。
这也是 Rover-Suite 当前的明确定位：在线实例是软状态，而不是一份需要长期保存的业务数据。
七、模块结构：核心逻辑与进程入口分离
仓库采用多模块 Maven 结构，目的是让协议、核心逻辑、启动进程和扩展适配层保持可维护的边界。
| 模块 | 职责 |
|---|---|
rover-common | 协议、编解码、公共工具、事件与安全基础能力。 |
rover-nameserver-core | 注册、租约、健康检查、查询、推送和管理 API 的核心逻辑。 |
rover-nameserver-client | Java 客户端连接、心跳、重连和本地实例缓存。 |
rover-nameserver-starter | Spring Boot 自动配置与服务生命周期集成。 |
rover-gateway-core | Gateway 路由、发现、负载均衡、代理、Filter、指标和追踪。 |
rover-gateway-bootstrap | Gateway 进程启动入口。 |
rover-gateway-adapter-nacos | 可选的 Nacos 服务发现适配模块。 |
rover-admin | 可选的管理控制台。 |
examples/http-registration | Node.js、Python、Go、PHP、C++ 的 HTTP 注册参考实现。 |
从这个结构可以看出，Rover-Suite 没有把所有逻辑都压进一个启动工程里。核心能力可以被单独测试和扩展，Bootstrap 模块只负责把它们组装成可运行的进程。
八、管理面为什么不应该抢占业务资源
Rover-Admin 是可选组件，主要通过 Nameserver 和 Gateway 的管理接口读取信息。控制台包含仪表盘、请求追踪、路由管理、实例管理、最近事件和配置管理等页面。
Admin 的设计原则是“可见时实时、不可见时安静”：仪表盘页面可见时才会请求实时快照，切换页面或将标签页放到后台后会停止实时轮询；非仪表盘页面以低频探活和按需读取为主。
在资源有限的小团队环境里，观察能力很重要，但观察组件不能反过来持续挤占 Gateway 和 Nameserver 的资源。这也是 Admin 不直接参与转发热路径的原因。
九、轻量并不等于忽略边界
Rover-Suite 选择少依赖、低部署复杂度和清晰源码边界，但并不意味着所有场景都适用。当前版本需要特别注意以下范围：
- 当前是单机预览版，不提供 Nameserver 集群高可用承诺；
- Nameserver 在线注册表是纯内存状态；
- 普通 HTTP/1.1 API 是当前主要转发场景，不把 WebSocket、SSE 视为已支持能力；
group当前更适合保持默认空值，严格的多组快照推送隔离仍在完善；- Gateway 不终止客户端 HTTPS，HTTPS 终止和外部网络边界应交给反向代理、TLS、ACL 或 VPN；
- 本地限流、进程内熔断和连接失败重试都是 Gateway 单实例能力，不应当被理解为跨实例一致性的流量治理平台。
把这些边界提前说清楚，能够帮助团队更准确地判断是否适合当前阶段，也避免把“可运行的基础设施内核”误用成“已经覆盖全部生产治理能力的平台”。
小结
Rover-Suite 的架构可以概括为一句话：
Nameserver 维护服务的在线状态，Gateway 用本地缓存处理业务流量，Admin 负责让运行状态可见、可查、可调整。
控制面和数据面分离、推送与对账结合、Java 与非 Java 接入共享注册模型、Admin 不进入转发热路径，这些设计共同构成了 Rover-Suite 的基础架构。
下一篇会继续拆解最核心的一段链路：服务从启动开始，如何完成注册、心跳续约、异常摘除，以及 Gateway 如何安全地使用发现缓存转发请求。
项目地址与交流
项目地址：Rover-Suite
如果这套架构思路对你有启发，欢迎在 GitHub 为 Rover-Suite 点亮一个 Star。Star 不只是一个数字，它能帮助更多正在处理服务发现、网关转发和多语言接入问题的开发者看到这个项目，也会推动我们持续打磨项目本身。
如果你有更有趣的使用场景、架构取舍或改进建议，欢迎在本文评论区交流，或直接提交 GitHub Issue。接下来，我们会继续探索 WebSocket、SSE 等长连接协议的接入与转发支持，并通过博客和仓库同步过程与结论。
