Rover-Suite：把服务注册、网关转发和运行态管理放进一套轻量基础设施
当一个团队从一个单体应用逐渐发展出几个独立服务时，最先变得混乱的往往不是业务代码，而是服务地址和流量入口。
后端服务多了以后，常见的维护方式是：在 Nginx、前端配置、脚本甚至文档里分别写一份后端地址。某个服务迁移、扩容或重启后，需要逐个位置排查和修改。对于还没有必要引入完整服务网格、又希望服务治理不再依赖手工维护的小团队来说，这种方式成本并不低。
Rover-Suite 是我们面向这类场景设计的一套轻量微服务基础设施。它把服务注册、服务发现、网关转发和运行态管理放在一套清晰的组件模型中，帮助团队先把"服务如何被发现、请求如何被转发、运行状态如何被看到"这三件基础事情做好。
Rover-Suite 想解决什么问题
Rover-Suite 的目标不是替代所有成熟的云原生平台，而是在服务规模尚不复杂时，提供一套部署依赖少、结构直观、可以继续二次开发的基础设施方案。
一个典型请求流程如下：
text
客户端
→ Rover-Gateway
→ 选择健康的业务服务实例
→ 转发 HTTP 请求
业务服务
→ Rover-Nameserver
→ 注册实例并保持心跳
Rover-Nameserver
→ Rover-Gateway
→ 推送实例快照，供网关更新本地发现缓存也就是说，业务服务不需要把自己的地址逐一写入网关或 Nginx；Gateway 也不会在每次请求进来时再同步查询注册中心。服务实例完成注册后，Gateway 通过本地缓存完成请求路由和负载均衡，注册中心负责维护实例状态并在变更时通知 Gateway。
核心组件
| 组件 | 主要职责 |
|---|---|
| Rover-Nameserver | 服务注册、心跳续约、租约过期、实例查询、订阅与快照推送。 |
| Rover-Gateway | 路由匹配、服务发现、本地实例缓存、负载均衡、HTTP 反向代理和 Filter 扩展。 |
| Rover-Admin | 可选运行态管理控制台，查看路由、实例、事件、请求追踪、指标和配置。 |
| Java Starter | 为 Spring Boot 服务提供自动注册、心跳、重连和优雅注销生命周期。 |
| HTTP Registrar 示例 | 为 Node.js、Python、Go、长驻 PHP、C++ 服务提供最小化注册、心跳和注销参考实现。 |
这几个组件不是简单拼在一起的工具集合。Nameserver 与 Gateway 分别承担控制面和请求数据面的职责，Admin 通过管理接口观察和调整运行状态，但不进入业务请求转发热路径。
为什么不继续手工维护地址
手工配置地址在服务数量很少时没有问题，但随着环境和实例数量增加，会逐渐暴露三个问题：
- 服务实例变化后，流量入口无法及时同步。
- 网关只能转发请求，却不知道上游实例是否仍然可用。
- 排查 404、502、路由不生效等问题时，缺少统一的实例、事件和请求链路视图。
Rover-Suite 的处理方式是把职责拆开：业务服务负责表明"我已就绪并且仍然存活"；Nameserver 负责维护在线实例；Gateway 只从本地发现缓存读取可用实例并转发请求；Admin 则提供可视化的运行态入口。
这种分工的好处是，服务地址变化不再要求业务团队逐个修改配置，网关的请求路径也不需要为每个请求增加一次注册中心访问。
3 分钟跑通一次完整链路
仓库内提供了 Docker Compose 本地演示，默认会启动 Nameserver、Gateway、Admin 和一个 demo 服务。
bash
git clone https://github.com/zzl-qz/Rover-Suite.git roverSuite
cd roverSuite/deploy/docker
docker compose up --build启动后，可以访问以下地址：
| 地址 | 用途 |
|---|---|
http://127.0.0.1:8080/api/hello |
通过 Rover-Gateway 访问 demo 服务。 |
http://127.0.0.1:9090 |
打开 Rover-Admin 控制台。 |
http://127.0.0.1:8889 |
Nameserver 的 HTTP 管理面，本地演示使用。 |
验证网关链路：
bash
curl -i http://127.0.0.1:8080/api/hello如果得到 demo 服务返回的 2xx 响应，说明下面这条链路已经完成：
text
demo 服务启动
→ 通过 Starter 注册到 Nameserver
→ Gateway 获取 demo-service 的实例快照
→ /api/hello 命中 Gateway 路由
→ Gateway 选择实例并完成反向代理
在 Admin 中可以直接看到 Gateway 的流量与进程状态，也可以进一步查看已注册实例、路由、最近事件和请求追踪。对于第一次接触项目的读者，这比只看配置文件更容易建立整体认识。
Rover-Suite 的几个设计亮点
1. 注册中心与网关协同，但不把发现放进每次请求
Gateway 启动时会订阅并查询服务实例，随后将可用实例保存在本地缓存中。实例变更时，Nameserver 推送新的快照；Gateway 仍会按周期向 Nameserver 对账，用于处理启动、重连或推送丢失等情况。
因此，普通 HTTP 请求并不会因为服务发现而同步访问 Nameserver。这样可以减少请求链路依赖，也让 Nameserver 短暂不可用时，Gateway 在本地缓存仍有效的情况下继续处理业务流量。
2. Java 与非 Java 服务使用不同接入方式，但共享同一注册模型
Java / Spring Boot 服务可以直接使用 rover-nameserver-starter，通过 TCP 长连接完成注册、心跳、重连和状态重放。
对 Node.js、Python、Go、长驻 PHP、C++ 等服务，Rover-Suite 提供标准 HTTP+JSON 注册接口和可复制的 Registrar 示例。它只覆盖服务提供方必要的注册生命周期，不强行维护多语言完整 SDK，也不增加 Sidecar 或额外代理进程。
两条传输路径最终进入同一套注册逻辑和内存注册表。这保证了 Java 与非 Java 服务在注册、租约、所有权和实例状态上遵循一致规则。
3. 运行态信息不只停留在日志里
Rover-Admin 提供以下信息入口：
- Gateway 的 QPS、延迟、状态码、JVM 与进程概览；
- 已注册服务实例及健康状态；
- 注册、注销、过期和推送等最近事件；
- Gateway 已采样请求的阶段时间线；
- 路由与部分支持热更新的配置。
对于日常排查来说，"路由是否存在""服务有没有注册""实例是否健康""请求慢在哪一个阶段"应该尽量在同一套运行态视图中获得答案，而不是靠多个组件的日志拼图。
4. 为二次开发留出边界
Rover-Gateway 提供 Java SPI 扩展点。需要增加请求审计、租户标记、简单鉴权或自定义限流时，可以通过 Filter 插件扩展请求处理链；需要替换上游选择逻辑时，可以通过 LoadBalancer 插件扩展负载均衡策略。
这不是为了追求"插件越多越好"，而是为了让每个团队可以按自己的业务需求扩展，而不必把定制逻辑直接改进 Gateway 核心代码。
适合哪些团队先尝试
Rover-Suite 更适合以下场景：
- 正从单体拆分出少量服务，希望先统一入口和服务地址管理；
- Java 服务为主，但同时存在 Python、Node.js、Go 等旁路服务；
- 希望理解服务注册、发现、网关转发的实现过程，并以源码为基础继续改造；
- 需要一套可本地运行、可观察、可用于团队内部验证的轻量基础设施。
当前版本的范围
为了让项目能力与实际代码保持一致，也需要明确说明 Rover-Suite 当前的运行边界：
- 当前版本是
1.0.0-SNAPSHOT单机预览版； - Nameserver 的在线实例是纯内存软状态，进程重启后由仍存活的客户端重新注册；
- Nameserver 集群高可用、WebSocket/SSE、完整分组隔离等能力不应理解为当前已实现功能；
- 默认零配置更适合本地或可信网络。跨越信任边界部署时，应配置 token、收紧监听地址，并在网络层增加 TLS、ACL 或 VPN 等保护；
- SDK 构件当前需要从源码构建，尚未作为稳定版本发布到 Maven Central。
这不是把能力"留给以后再说"，而是有意把当前版本定位在可验证、可阅读、可演进的单机基础设施内核。项目不会恢复未经活动客户端确认的历史实例地址，也不会把尚未完成的治理能力包装成已上线功能。
接下来会写什么
接下来的文章会继续拆解 Rover-Suite 的内部设计：
- 注册中心、网关与管理控制台如何协作；
- 服务如何完成注册、心跳续约、异常摘除和发现对账；
- 如何用 Java SPI 扩展 Gateway 的 Filter 与负载均衡能力；
- 如何通过 Docker Compose 在本地快速验收和排查问题。
项目地址与交流
项目地址：Rover-Suite
如果 Rover-Suite 对你有帮助，或正好为你解决了服务地址维护、流量入口管理、多语言服务接入等问题，欢迎在 GitHub 为项目点亮一个 Star。每一份关注，都会成为我们持续完善文档、稳定性和功能边界的重要反馈。
也欢迎在本文评论区，或通过 GitHub Issue 分享你的使用场景、改进建议和踩坑记录。后续我们也会继续探索 WebSocket、SSE 等长连接协议的接入与转发支持，相关设计与进展会通过博客和仓库持续同步。