首页 / 系统架构 / 总体架构
总体架构
双引擎分工、分层架构图、数据流与演进方向。
从入口到服务内部
以下图片按请求进入系统后的路径排列：访问源 → 全球入口 → Global Center 路由控制 → 区域隔离 → 区域内部部署 → Java/Go 双平台。继续下钻可分别查看 Java 控制面、Go 数据面以及协议与数据归属。
以下架构图用于说明目标分工与部署方案，不自动代表当前生产环境已经按图完成部署。服务、协议、端口和数据归属仍以代码、配置与已评审决策为准。
第 1 步：访问源进入全球入口
myentrax.com 欧美多区域简化落地版：从 Web/App、IoT 设备和第三方系统进入 Global DNS、CDN/WAF、Bootstrap Service，再返回 EU/US 区域入口。来源：architecture/ChatGPT Image 2026年8月19日 15_31_31.png。第 2 步：全球流量调度到区域入口
architecture/ChatGPT Image 2026年8月19日 15_17_36 (2).png。第 3 步：Global Center 解析归属区域
home_region，Bootstrap API 返回 Region Endpoint 与 Route Ticket，App/设备后续直连 NA、EU 或 GLOBAL 数据面；Global Center 只保存路由元数据，不代理或保存用户业务数据、GPS 与视频。来源：architecture/ChatGPT Image 2026年8月19日 20_27_56.png。第 4 步：区域隔离与数据驻留
architecture/ChatGPT Image 2026年8月19日 15_17_36 (1).png。第 5 步：进入区域内部部署主链路
entrax-server、Go 服务、MQTT、NATS、Redis、MySQL 与 TDengine 的关系；图中“当前”应理解为方案基线，实际运行状态需结合环境配置核验。来源：architecture/ChatGPT Image 2026年8月19日 15_17_54 (2).png。第 6 步：进入 Java/Go 双平台
architecture/ChatGPT Image 2026年8月19日 15_17_54 (1).png。双引擎分工
平台采用 Java（业务治理核心）+ Go（网络数据引擎） 双引擎微服务架构，遵循业界车联网/物联网平台的标准实践：
| 维度 | Go 数据面 cloud-go | Java 业务面 cloud-java |
|---|---|---|
| 定位 | 基础设施与 IoT Hub：协议接入、海量长连接、高频时序数据、流媒体转发 | 业务执行面：复杂业务流、RBAC、支付计费、规则配置、管理后台 |
| 核心能力 | MQTT 接入、GPS 编解码、轨迹存储查询、行程检测、风险区域匹配、告警执行、实时视频、WebSocket 推送、OTA、AI Agent | 用户/会员、设备与产品档案、绑定流程、支付订阅、SIM、告警配置、通知、报表、MCP |
| 技术栈 | Go + go-zero + GORM + NATS/JetStream + EMQX + TDengine + ZLMediaKit/WebRTC + MinIO/OSS | Java 17 + Spring Boot 3 + Spring Cloud Alibaba + MyBatis Plus + Nacos + gRPC + Redis + MySQL + RocketMQ |
| 数据职责 | 高频流水（GPS、设备遥测）写入 TDengine；在线状态写入 Redis | 核心业务元数据写入 MySQL；报表读取 TDengine |
分层架构图
用户与终端层
iOS / Android App
Web 管理后台
车载设备 / 摄像头
GPS Tracker
▼
接入层
Nginx / APISIX 网关
EMQX MQTT
WebSocket
gRPC
▼
双引擎服务层
Go 数据面 cloud-go
dgsvr 接入
gpscodecsvr 解码
geosvr 轨迹
tripsvr 行程
risksvr 风险
alertsvr 规则
eventsvr 分发
videosvr 视频
wssvr 推送
dmsvr / otasvr / iamsvr / agentsvr
Java 业务面 cloud-java
system 系统
member 会员
iot 设备
pay 支付
subscription 订阅
sim SIM
prod-gps GPS
alarm 告警
notify 通知
infra 基建
mcp AI 接入
▼
中间件与数据层
MySQL
Redis
NATS / JetStream
Kafka / RocketMQ
TDengine
MinIO / OSS
Nacos
数据流与事实边界
端到端数据流
- 设备经 MQTT/TCP 上报 → Go dgsvr 认证接入 → gpscodecsvr 解码为物模型
- 原始点经 NATS 进入 geosvr → 纠偏后写 TDengine；tripsvr 离线计算行程
- 风险/告警事件（risksvr/alertsvr）→ eventsvr 分发 → Java alarm 落记录、notify 发通知
- 业务配置与状态由 Java 维护（MySQL/Redis），Go 通过 gRPC/NATS/共享 Redis 消费
必须守住的事实边界
- 支付事实 ≠ 订阅权益：支付成功只是激活前置条件，权益以 subscription_active/seat 为准。
- 客户订阅 ≠ SIM 套餐：SIM 用量与订阅权益是两条独立事实线。
- GPS 原始点 ≠ 清洗轨迹：原始点保留证据，轨迹用于业务展示与计算。
- 实时通知 ≠ 可靠消息：WebSocket 推送是尽力而为，业务完成必须依赖可靠消息与状态确认。
- 告警产生 ≠ 通知送达：规则命中、告警记录、消息任务、推送成功是四级事实。
演进方向
- 区域化部署：面向海外市场按合规大区（EU/US/CN）拆分，Go 侧数据带
region字段，Java 报表按 region 过滤。 - 10 万级设备架构：现有蓝图以高并发接入、流媒体云边端协同为目标，接入层可横向扩容，TDengine 支撑海量轨迹。
- 影像能力：家庭影像与车载影像需要统一的"设备-录像-GPS-时间线"关联模型，为视频检索、轨迹联动、事件回溯预留空间（见影像数据章节）。
- AI 能力：MCP 接入 + Go agentsvr 智能文案，后续可扩展路线偏离检测与 C 端对话。