项目业务与应用场景
海洋、气象与设备数据来自多种协议和存储系统，既要稳定接入高频数据，又要在地图上快速查询时空信息并管理 PB 级文件。
08GIS DATA PLATFORM
GIS 大数据可视化平台
整合海洋环境监测、气象和设备运维等 10+ 分系统数据源，支撑千万级空间数据实时渲染与高并发设备接入。
Spring Cloud AlibabaNettyMySQLPostgreSQLPostGISInfluxDBShardingJDBCRedisNacosZooKeeperKafkaActiveMQMinIO
多源数据汇成统一空间视图
整合海洋环境、气象与设备运维等 10+ 分系统，日均处理 1000 万+条综合数据，其中设备链路日均 900 万+条。
空间、时序与文件各有承载
地图查询千万级空间点，同时管理监测时序、遥感影像、NC 数据与 PB 级文件。
设备接入与告警推送联动
高频设备数据进入消息链后形成状态与告警，关键变化经实时推送到达业务界面。
BUSINESS FLOW
核心业务链路
从用户进入系统开始，查看业务数据如何经过各环节并形成最终结果。
SYSTEM NODE 01
多源接入
Netty、Kafka 与业务适配器接入 10+ 分系统。
ENGINEERING DECISIONS
难题如何变成系统能力
从业务约束出发，说明机制为什么成立、边界在哪里。
协议接入与消息解耦
- 难题
- 高频设备上报与业务查询同时发生，需要避免采集吞吐受下游处理波动影响。
- 机制
- Netty 解析二进制协议，Kafka 采用 3 Broker、3 副本与每 Topic 9 分区；ActiveMQ + WebSocket 承载实时推送。
- 结果
- 原项目记录为单 Topic 12MB/s，设备链路日均 900 万+条，告警延迟 ≤100ms。
按数据特点分治查询
- 难题
- 业务、空间和时序数据使用单一存储策略难以兼顾查询效率。
- 机制
- MySQL 垂直分库与按时间分表，经 ShardingJDBC 路由；PostGIS 空间索引、InfluxDB 时序聚合与 Redis 热点缓存协作。
- 结果
- 原项目 MySQL 查询性能提升 60%，同时支撑千万级空间数据呈现。
微服务与大文件分离
- 难题
- 文件规模与业务服务扩展需要独立管理，不能让大型文件占用核心业务链。
- 机制
- Spring Cloud Alibaba + Nacos 提供注册发现，MinIO 统一管理影像、NC 与媒体文件。
- 结果
- 原项目注册发现响应不超过 50ms，文件体系支持 PB 级管理。
展开补充设计与约束
- MySQL 按业务垂直分库、按时间水平分表并通过 ShardingJDBC 透明路由。
- PostGIS 承载空间索引、InfluxDB 负责时序聚合、Redis 缓存热点查询。
- Kafka 解耦采集与处理，MinIO 统一管理遥感影像、NC 数据和媒体文件。
PROJECT RECORD
原项目记录与量化结果
以下为原简历中已确认的项目指标；与本站演示样例数据分别展示。
0110+ 数据源
02日均 1000 万+条综合数据
03设备链路日均 900 万+条
04单 Topic 12MB/s
05告警延迟 ≤100ms
06查询性能提升 60%
07千万级空间点
08PB 级文件