机器人调度系统展示

Robot scheduling system demonstration

Jimmy Chen 陈峥

目录 Portfolio

1. 项目概览（Executive Summary）�
2. 架构与演进（Architecture & Evolution）�
3. 运行效果（Live Demo）�
4. Nacos 配置中心（Configuration Center）�

​

​

​

6. 可观测性：Services / Topology / Traces（SkyWalking）�
7. 异步化抗洪与可观测闭环：RabbitMQ�
8. Docker容器化部署（Dockerized Deployment）�
9. 高并发压测与可观测佐证（JMeter + SkyWalking）

​

本项目所有部分均由本人独立从 0 到 1 设计与实现。

(This project was independently designed and implemented by me from scratch.)

• 稳定性：限流 / 熔断（Sentinel）�

​

• 问题—原因—修复（Issues · Root Cause · Fixes）�

​

What / Why 机器人管理平台 — Robot Management Platform

​

• 统一管理： 机器人状态、地图/区域、临时任务� Manage robot status, maps/zones, and ad-hoc tasks in one place.�
• 聚合开放接口： 多厂商 OpenAPI（如 Gaussian），对外提供一致接口� Aggregate vendor OpenAPIs (e.g., Gaussian) behind a consistent API.�
• 统一入口与治理： Gateway 鉴权、审计，限流前置� Single entry via Gateway for auth, audit, and rate limiting.

​

• 接口变化快、能力差异大： 先把“接口聚合/任务下发”独立，可快速迭代与回滚� Fast-changing vendor APIs → split aggregation/dispatch for safer iteration and rollback.�
• 峰值与抖动： 需要限流/熔断与故障隔离，避免拖垮核心链路� Peaks & vendor hiccups → rate limiting/circuit breaking and isolation.�
• 多环境协作与交付： Docker 一键交付，服务独立发布/扩缩容� Multi-env delivery → one-click Docker; independent deploy/scale.

演进路线见「架构与演进（Architecture & Evolution）」 / See “Architecture & Evolution” for the roadmap.

What（在做什么）

Why（为什么从单体演进）

单体 → RuoYi-Cloud 微服务 (Monolith → Microservices)

• 背景/痛点：先用单体快速验证；规模上来后发布影响面大、配置分散�
• 目标：平滑迁移、前端基本无感、分钟级回滚�
• 关键设计：Gateway /external/gs/**；Nacos 注册/配置（多环境）；Docker Compose 一键多容器�
• 难点与取舍：DTO 抽到 ruoyi-api-robot；Controller 薄化→逻辑下沉 GsOpenApiServiceImpl�
• 指标与结果：冷启动〈原〉→〈现〉；回滚〈小时〉→〈分钟〉；p95 〈数值〉ms�
• 复盘：先交付后演进；统一资源名/规则/异常体/日志字段

​

• Background / Pain points: Started with a monolith to validate quickly; as scale grew, releases had wide blast radius and configs were scattered.�
• Goals: Smooth migration, frontend largely transparent, minute-level rollback.�
• Key design: Gateway /external/gs/**; Nacos for service registry/config (multi-env); Docker Compose for one-click multi-container.�
• Challenges & trade-offs: Extract DTOs to ruoyi-api-robot; thin Controllers → push logic down into GsOpenApiServiceImpl.�
• Metrics & results: Cold start <before> → <after>; rollback <hours> → <minutes>; p95 <value> ms.�
• Retrospective: Deliver first, evolve later; unify resource names / rules / error body / log fields.

​

RuoYi 单体 → RuoYi-Cloud 微服务（业务驱动升级）(Monolith → Microservices)

Gaussian OpenAPI 封装与稳定性治理 Gaussian OpenAPI & Stability

• 背景/痛点：厂商 API RT/错误不稳，调用方易被拖慢�
• 目标：鉴权/重试/幂等/Trace 统一；双层保护（网关+方法级）；读多写少下缓存兜底�
• 关键设计：GsOpenApiServiceImpl + @SentinelResource（资源名与 Nacos 规则一致）；Nacos 下发 Flow/Degrade；RestTemplate 超时/连接池/禁自动重试�
• 难点与取舍：网关 vs 应用谁先挡；压测需放宽网关阈值观察熔断�
• 指标与结果：突发下 429 快速失败；p95 〈数值〉ms；读接口降级返回最近数据�
• 复盘：限流优先于熔断；统一异常体/日志字段便于排障

​

• Background / Pain points: Vendor API latency/errors were unstable; callers easily got dragged down.�
• Goals: Unified auth/retry/idempotency/trace; dual protection (gateway + method level); read-heavy paths use cache fallback.�
• Key design: GsOpenApiServiceImpl + @SentinelResource (resource names aligned with Nacos rules); Nacos-pushed Flow/Degrade rules; RestTemplate with timeouts/connection pool/auto-retry disabled.�
• Challenges & trade-offs: Gateway vs application—who throttles first; during load tests, loosen gateway thresholds to observe circuit breaking.�
• Metrics & results: Under bursts, HTTP 429 fast-fail; p95 <value> ms; read APIs degrade to most recent data.�
• Retrospective: Rate limiting before circuit breaking; standardized error body/log fields to ease troubleshooting.�

​

项目阶段 / 演进路线 Project Phases & Evolution Path

路径：单体 MVP → Docker “clone→run” → 微服务试点（Gateway + Nacos）→ 观测/治理（SkyWalking + Sentinel）

里程碑 & 可量化产出 Milestones & Quantifiable Outputs

架构设计 Architecture

可观测性拓扑 Observability Topology

首页 Dashboard

机器人管理 Robot Management

实机展示画面

点击机器人列表 Click on the robot list

创建机器人任务 Creating the Robot Task

机器人任务状态查询 Robot task status query

现场联调｜Gaussian 机器人 OpenAPI

说明：照片与界面已脱敏；项目所有密钥已移除，仅展示联调流程与结果。

Note: Images/UI redacted; all keys removed. Flow and outcomes only.

园区驾驶舱 Park Operations Cockpit

说明：当前为演示数据；待与园区系统联调完成后，将切换为实时数据展示。

园区驾驶舱 - 3D效果展示 Park Operations Cockpit

说明：当前为演示数据；待与园区系统联调完成后，将切换为实时数据展示。

园区驾驶舱 - 发现险情 Park Operations Cockpit

说明：当前为演示数据；待与园区系统联调完成后，将切换为实时数据展示。

Nacos配置中心 Configuration Center

统一注册/配置；多环境分组；敏感参数集中管理（热更新）

Nacos配置中心 Configuration Center

统一注册/配置；多环境分组；敏感参数集中管理（热更新）

SkyWalking全链路观测 End-to-end observability

“端到端 tracing；gateway→下游可串；traceId 注入日志，实现 trace↔log 互查”

SkyWalking可观测性 · 服务拓扑（Service Topology）

SkyWalking可观测性 · 链路追踪：异步任务路径（Trace View）

SkyWalking可观测性 · 服务概览看板：关键指标（Overview Dashboard）

Sentinel限流和熔断 Rate limiting and Circuit breaking

“规则集中下发；读：短 TTL 缓存；写：429/503 快速失败，防级联”。

Sentinel限流 Rate limiting

限流测试结果Rate limiting result

“压测方式 + 触发阈值 + 期望行为（不拖垮主流程）”

Sentinel熔断降级 Circuit breaking

熔断测试结果 Circuit breaking Result

“压测方式 + 触发阈值 + 期望行为（不拖垮主流程）”

代码示例片段 Code example

“接口对接/任务下发的 Fallback 聚合在 Service 层（Controller 变薄）”

RabbitMQ - 异步化架构

RabbitMQ - 接入设计与关键参数

手动 ack；异常不重回 → 进 DLQ”�

“confirm/return 开启；mandatory=true 确保 return 可见”�

“并发=2、预取=20（合计 40 in-flight）”�

“幂等 TTL 3600s，任务结果 TTL 86400s”

​

RabbitMQ - 消费与错误处理

RabbitMQ - 联调结果（Postman）｜创建任务 202 & 任务状态查询

Docker容器化部署 Dockerized Deployment

Docker容器化部署 Dockerized Deployment

测试目标与链路范围

风险控制（不会打实机）

1. Dry-Run 开关：所有请求都带 X-Dry-Run: true，网关无此头一律 403（拦截真实分支）。�
2. 消费者禁用：机器人任务 Consumer 进程关闭/线程数=0，仅验证生产端写入与链路吞吐，RabbitMQ 只产生堆积。�
3. 无外设调用：任务为模拟/空实现，不会触发真实设备动作（不会打实机）。

​

流量模型与压测方法（JMeter）

验证入口链路（Gateway → ruoyi-robot → MQ）在 100 QPS、持续 3 分钟 的稳态承载能力。

结果总览（JMeter· Aggregate Report）

结果总览（JMeter· View Results Tree）

消息侧证据（RabbitMQ）

​

网关服务指标（SkyWalking · ruoyi-gateway)

业务服务指标（SkyWalking · ruoyi-robot）

端点负载与延迟明细（SkyWalking · ruoyi-robot / Endpoint）

Swagger UI

Swagger UI

问题—原因—修复（Issues · Root Cause · Fixes）

更多规则样例见「稳定性（Sentinel）」章节。

Gateway / Nacos / Sentinel

• Nacos 启动 STARTING — 持久化 MySQL 配置/版本不匹配 — 配 spring.datasource.*，初始化 SQL，建议 2.2.3。�
• Sentinel API 分组空白/规则不生效 — 缺 sentinel-datasource-nacos 或 DataId/Group 不一致 — 补依赖，统一 ruoyi-gateway-gw-api-defs/gw-flow/gw-degrade 与 JSON 结构。�
• 网关 404 / Swagger “Try it out” 失败 — Path/StripPrefix 与服务前缀或 context-path 不对齐 — 统一 Path=/external/gs/** + StripPrefix=1，必要时移除 context-path。�
• 限流口径不一致 — @SentinelResource 分散在 Controller、资源名混乱 — 逻辑下沉到 GsOpenApiServiceImpl，统一资源名并与 Nacos 规则对齐。�
• 看不到熔断 — 网关阈值太小，入口就被 429 挡住 — 压测时上调网关阈值；读用“慢调用比例”，写用“异常比例”。�

​

问题—原因—修复（Issues · Root Cause · Fixes）

拓扑/Trace 示例见「可观测性（SkyWalking）」章节。

可观测性 & 基础设施 Observability & Infrastructure

• SkyWalking 无 Gateway 链路/日志无 traceId — 未加载 SCG/WebFlux 插件/未注入 agent/Logback 无 MDC — 复制 apm-spring-cloud-gateway-3.x-plugin 到 plugins，-javaagent 注入，Logback 加 %X{traceId}。�
• Docker：MySQL 端口冲突/首次无数据 — 3306 被占/未导入初始化 SQL — 改端口映射或停本机 MySQL；compose 前导入 SQL；加健康检查。�
• 容器内互访失败（127.0.0.1） — 混用宿主与容器地址 — 改为 服务名:端口，宿主用 host.docker.internal（Win/Mac）。�
• 依赖/插件冲突 — Reactor Netty 系列不匹配/插件缺失 — 对齐 Spring Boot/Cloud 版本矩阵；按需引入 gateway/webflux 插件；锁定依赖版本。�

​

问题—原因—修复（Issues · Root Cause · Fixes）

代码与客户端 Code & Client

• MyBatis Invalid bound statement — mapper-locations 路径错误/namespace 与接口 FQN 不一致/XML 未打包 — 校对 @MapperScan + namespace，确保 XML 进 jar。�
• RestTemplate 堆积/重试放大故障 — 未设超时/连接池/禁自动重试 — 设 connect/read 超时与池大小；禁自动重试；写操作加幂等键。�
• CORS 预检被拦 — 网关未放行 OPTIONS/响应头不全 — 全局 CORS：允许 Origin/Headers/Methods，暴露必要头，放行 OPTIONS。�

​