RuView WiFi-DensePose 系统架构详解从 CSI 数据采集到多协议服务的五层可扩展设计【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView导读本文以 plans/phase2-architecture/system-architecture.md 为核心骨架系统拆解 RuViewWiFi-DensePose项目如何将普通商用 WiFi 路由器采集的信道状态信息CSI经信号预处理、神经网络推理、多目标跟踪最终通过 REST / WebSocket / MQTT / Webhook 多协议接口交付给上层应用。文中所有架构决策、组件职责、数据流参数与部署规格均完整继承自该设计文档并结合仓库中v2/crates的 Rust 实现、docker/docker-compose.yml 部署文件与 monitoring/prometheus-config.yml 监控配置逐一印证。读完本文你将掌握该系统的分层设计方法、端到端数据管线、容器/K8s 部署规格、性能与安全架构以及如何在当前仓库中对照源码定位每一层的落地实现。1. 系统全景五层架构与关键特性1.1 设计定位WiFi-DensePose 是一套隐私保护的无线人体姿态估计系统不依赖摄像头与光学传感器仅通过普通 WiFi 基础设施上的 CSI 信号完成实时人体姿态估计。其核心思路是把WiFi 信号这一物理媒介转化为空间智能数据源从而在医疗看护、零售分析、安防等场景提供无感、无摄像头的感知能力。架构文档将整个系统划分为五个逻辑层每一层职责单一、边界清晰1.2 关键系统特性隐私保护全链路无摄像头、无光学传感器规避视频隐私风险实时处理设计目标为端到端延迟低于 100ms穿墙检测可穿透墙体与障碍物感知人体姿态多人跟踪设计支持同时跟踪最多 5 人模块化可扩展组件松耦合可适配边缘设备到云端多种部署形态领域专属分析面向医疗、零售、安防等垂直领域提供专门化分析能力。需要说明的是本文档Version 1.0Status: Draft中的精度 87.2%、延迟 100ms 等指标属于架构规划阶段设定的设计目标而非仓库实测数据仓库侧的真实能力请以各模块的测试与基准结果为准。2. 组件分解与职责2.1 硬件接口层WiFi Router Interface负责与路由器建立并维护通信包括配置路由器进行 CSI 提取、管理连接生命周期、处理路由器故障与重连并支持 Atheros、Intel、ASUS 等多种路由器类型。CSI Data Collector从路由器提取并收集 CSI 数据具体职责包括接收来自路由器的 UDP 数据流、解析 CSI 数据包格式、缓冲输入数据、同步多路数据流以及处理丢包与数据损坏。在仓库中该层已有成熟的 Rust 落地v2/crates/wifi-densepose-hardware/src下包含esp32/含 tdm.rs、quic_transport.rs、secure_tdm.rs 三个传输/加密模块、ieee80211bf/、aggregator/等子模块src/bin/下则提供了aggregator.rs、mediatek-csi-sim.rs、qualcomm-csi-sim.rs、rtl8720f-sim.rs、vendor-rf-sim.rs等多个厂商 CSI 仿真器用于在没有真实硬件时验证采集与解析链路。更完整的硬件接入细节可参考姊妹文档 plans/phase2-architecture/hardware-integration.md包含 Atheros / Intel 5300 的 CSI 格式解析、UDP 流式协议与硬件抽象层设计。2.2 核心处理层Signal Preprocessor清洗与归一化原始 CSI涵盖相位解卷绕phase unwrapping、幅度归一化、时域滤波、背景减除、降噪与环境标定Neural Network Pipeline完成模态翻译CSI → 空间表征、特征提取、DensePose 估计、置信度评分与批处理优化。模型侧设计详见 plans/phase2-architecture/neural-network-architecture.md双分支编码器、空间上采样网络、DensePose-RCNN 集成、知识蒸馏与多阶段训练策略Pose Estimation Engine编排端到端处理管线协调组件间数据流、管理处理队列、优化资源分配、处理错误恢复并维持处理性能Multi-Person Tracker跨时间跟踪多个个体负责人员检测与 ID 分配、轨迹跟踪与预测、遮挡处理、轨迹生命周期管理创建/更新/终止与时序一致性约束。仓库侧的对应实现集中在v2/crates/wifi-densepose-sensing-server/src例如 pose.rs 定义了PersonDetection、PoseKeypoint等数据结构实现了基于置信度、SNR 因子与噪声因子的关键点置信度计算以及apply_temporal_smoothing基于上一帧关键点做指数平滑正是文档中时序一致性约束的实现engine_bridge.rs 与v2/crates/wifi-densepose-engine/srclib.rs、mesh_guard.rs则承担引擎编排与网格防护职责。2.3 服务层API Gateway统一访问入口负责请求路由、负载均衡、认证授权、限流、请求/响应转换与 API 版本管理REST API Service提供 HTTP 访问能力包括姿态数据访问当前/历史、系统控制启动/停止/状态、配置管理、分析报表与领域专属端点WebSocket Server支持实时数据流负责连接管理、订阅处理、实时姿态流推送、系统状态更新与告警通知External Integration Services对接外部系统包括 MQTT 发布IoT 集成、Webhook 事件通知、Restream 直播对接与第三方 API 集成。2.4 管理层Configuration Management配置存储与检索、模板管理、校验与验证、动态配置更新、多环境差异化配置Monitoring and Diagnostics性能指标采集、资源利用率监控、错误检测与上报、日志与审计轨迹、告警与通知。仓库中服务层的实际实现与文档高度对应v2/crates/wifi-densepose-sensing-server/src下既有 mqtt/ 目录MQTT 连接、HA Discovery、发布器详见第 5 节也有matter/Matter 协议、semantic/语义层、training_api.rs训练接口等模块cli.rs 中定义了 REST 端口默认 8080、WebSocket 端口默认 8765、UDP 端口默认 5005等参数。3. 数据流架构从原始 CSI 到客户端姿态数据3.1 主数据流3.2 各处理阶段规格阶段输入处理输出关键参数CSI 数据采集路由器天线原始 WiFi 信号数据包解析、缓冲、同步结构化 CSI幅度 相位采样率 10–30 Hz约 ~100 KB/s/路由器信号预处理结构化 CSI相位解卷绕、滤波、归一化干净归一化的 CSI 特征降噪、背景移除以信噪比提升为质量指标神经网络推理预处理后的 CSI 特征深度学习推理空间表征与姿态估计GPU 推理 50ms最优条件下 AP50 目标 87.2%多人跟踪原始姿态估计ID 分配、轨迹预测带 ID 的连续跟踪姿态遮挡处理、轨迹连续容量最多 5 人API 分发跟踪后的姿态数据格式化、序列化、流式推送REST 响应 / WebSocket 消息 / MQTT 发布API 响应生成 10ms支持 100 并发客户端3.3 数据存储流存储流将姿态数据拆分为短期缓存与时序数据库时间序列库、聚合分析、报表引擎三条通道配置数据与系统指标则分别进入配置库与指标库实现运行态 / 历史态 / 观测态三类数据的隔离管理。4. 服务边界与内部接口契约4.1 组件接口边界硬件接口层外部接口为 UDP socketCSI 数据接收与路由器配置接口内部接口为预处理器的 CSI 数据队列与监控用的路由器状态事件核心处理层外部接口为参数调优的配置 API 与性能监控的指标 API内部接口为神经网络预处理数据队列、跟踪器姿态估计队列以及系统状态更新的事件总线服务层外部接口为 REST 端点、WebSocket 实时流、MQTT 主题与 Webhook 端点内部接口为姿态数据访问、认证授权、限流与节流服务。4.2 内部 API 契约架构文档为组件间通信定义了三个核心 TypeScript 契约是理解数据形状的关键CSI Collector → Signal Preprocessorinterface CSIData { timestamp: number; routerId: string; amplitude: Float32Array[][]; phase: Float32Array[][]; rssi: number; metadata: Recordstring, any; }Neural Network → Pose Estimatorinterface SpatialRepresentation { features: Float32Array[][][]; confidence: number; timestamp: number; processingTime: number; }Pose Estimator → Multi-Person Trackerinterface PoseEstimate { keypoints: Array{x: number, y: number, confidence: number}; boundingBox: {x: number, y: number, width: number, height: number}; confidence: number; timestamp: number; }值得注意姿态数据统一采用归一化坐标0–1与置信度0–1的表示这与仓库实现一致——pose.rs 中PoseKeypoint的关键点坐标与置信度即为归一化数值且置信度通过clamp(0.1, 1.0)保证输出区间稳定。外部 API 契约的完整定义REST 端点、WebSocket 消息、MQTT 主题、版本化策略与鉴权流程见 plans/phase2-architecture/api-architecture.md。4.3 事件驱动通信系统通过事件总线解耦各层按硬件事件、处理事件、API 事件与告警事件四类分发5. 部署架构Docker 与 Kubernetes 双轨方案5.1 Docker 容器架构5.2 容器规格设计文档定义核心容器容器基础镜像资源卷 / 网络备注CSI CollectorPython 3.9-slim1 CPU / 1GB配置卷host 网络UDP 接收重启策略 AlwaysNeural NetworkNVIDIA CUDA 11.6 Python 3.92 CPU / 4GB / 1 GPU模型卷 共享数据卷内部网络重启策略 AlwaysPose EstimationPython 3.9-slim2 CPU / 2GB共享数据卷内部网络重启策略 AlwaysAPI ServicesPython 3.9-slim2 CPU / 2GB配置卷内外双网络端口 8000REST、8001WebSocket支撑容器容器基础镜像资源端口说明DatabaseTimescaleDBPostgreSQL 扩展2 CPU / 4GB—持久化数据卷内部网络MQTT BrokerEclipse Mosquitto1 CPU / 1GB1883MQTT、8883MQTT over TLS内外双网络Redis CacheRedis Alpine1 CPU / 2GB—持久化数据卷内部网络MonitoringPrometheus Grafana1 CPU / 2GB9090Prometheus、3000Grafana持久化数据卷内部网络5.3 仓库中的实际部署实现设计文档中的容器化思路在仓库里已有对应落地。docker/docker-compose.yml 定义了sensing-serverRust与python-sensing两个服务sensing-server镜像ruvnet/wifi-densepose:latestREST API 绑定127.0.0.1:3000、WebSocket 绑定127.0.0.1:3001UDP 端口5005暴露给 ESP32 节点通过CSI_SOURCE环境变量控制数据源可选auto默认自动探测 ESP32 UDP → 主机 WiFi两者都不可用时以退出码 78 硬失败、esp32从 UDP 5005 接收真实 CSI、wifiWindows netsh 主机 RSSI/扫描数据、simulated显式生成合成 CSI 用于演示MODELS_DIR指定.rvf模型扫描目录并配置了no-new-privileges、cap_drop: ALL与 2 CPU / 1G 的资源上限、kill -0 1健康检查python-sensing镜像ruvnet/wifi-densepose:pythonWebSocket8765、UI80801 CPU / 512M 资源上限健康检查探测 8765 端口连通性。CLI 层与之一一对应见 cli.rs 中--source默认auto、--udp-port默认 5005、--tick-ms默认 100即处理节拍、SENSING_BIND_ADDR默认127.0.0.1等参数。镜像构建说明见 docker/Dockerfile.rust 与 docker/Dockerfile.python入口脚本 docker/docker-entrypoint.sh 依据CSI_SOURCE决定启动方式。5.4 Kubernetes 部署架构K8s 形态下核心服务采集/推理/姿态/网关以 Deployment 部署有状态的数据组件数据库、Redis采用 StatefulSetMQTT 用 Deployment前端与流媒体服务器独立 Deployment基础设施侧由 Ingress Controller 统一暴露入口Prometheus Operator 负责指标采集Cert Manager 管理 TLS 证书。5.5 四类部署环境配置环境部署方式基础设施扩展性数据持久化监控开发环境Docker Compose本地开发机每容器单实例本地卷基础日志与指标测试环境Kubernetesminikube/kind专用测试服务器单实例 真实数据测试数据集临时完整监控栈用于性能测试生产环境Kubernetes云厂商或本地集群多实例 自动扩缩容托管数据库或持久卷全面监控、告警、日志多可用区冗余高可用边缘部署Docker 或 K3s带 GPU 的边缘设备资源受限单实例本地存储 云备份轻量监控 云端上报支持离线运行与同步6. 可扩展性与性能架构6.1 水平扩展策略无状态的处理管线采集→推理→跟踪→网关通过负载均衡横向扩展有状态的数据库与缓存以共享集群形式作为后端从而在容量扩展的同时保持数据一致性。6.2 垂直扩展考量神经网络容器GPU 显存是首要瓶颈数据库容器时序数据的 I/O 性能与内存API 服务容器并发请求处理依赖 CPU 核数CSI 采集容器多路由器数据流依赖网络 I/O。6.3 性能优化要点批处理推理神经网络推理合并批量、多级缓存API 响应、时序查询的数据库索引优化、数据库与服务连接池复用、全链路非阻塞异步 I/O以及按负载合理设定容器资源规格。7. 安全架构7.1 认证与授权请求统一经 API Gateway 完成认证JWT / API Key与授权角色 / 权限两道校验未通过即拒绝通过后进入处理链路。7.2 数据保护传输中外部通信全部使用 TLS 1.3静态存储敏感数据落库加密处理中内存保护与安全编码实践隐私数据最小化与匿名化设计。7.3 网络安全API Gateway 作为带安全控制的唯一入口内部服务不直接对外暴露网络分段配合严格的防火墙出入规则与限流机制抵御滥用与 DoS。仓库侧同样体现了最小权限原则例如 docker/docker-compose.yml 中cap_drop: ALL与no-new-privileges: trueREST/WebSocket 默认仅绑定回环地址127.0.0.1仅 UDP 5005 对 ESP32 开放鉴权实现可参考v2/crates/wifi-densepose-sensing-server/src/bearer_auth.rs与 ws_ticket.rsWebSocket 票据认证。8. 监控与可观测性架构8.1 指标采集8.2 日志架构集中式日志ELK 或同类方案日志级别覆盖 ERROR / WARN / INFO / DEBUG / TRACE采用带一致字段的 JSON 结构化日志通过 Correlation ID 跨组件追踪请求并按年龄分级存储、分层保留。8.3 健康检查与探针Liveness Probe检测并重启故障容器Readiness Probe阻止流量进入初始化中的容器Startup Probe允许较长的启动初始化时间深健康检查在基础连通性之上验证组件真实功能。仓库侧的观测实现与文档一一对应监控配置 monitoring/prometheus-config.yml 定义了wifi-densepose-app抓取任务scrape_interval: 10s按appwifi-densepose标签过滤从/metrics采集、Prometheus 自身 / K8s 节点 / Node Exporter / cAdvisor / kube-state-metrics / CoreDNS / ingress / blackbox 等全栈抓取任务并配置了 Alertmanager、remote_write远程长期存储、TSDB 15 天 / 50GB 保留策略与 WAL 压缩告警规则见 monitoring/alerting-rules.yml可视化面板见 monitoring/grafana-dashboard.json日志侧 logging/fluentd-config.yml 提供集中日志采集docker/otel-compose.yml 与 docker/otel-collector.yaml 提供 OpenTelemetry 观测链路更多细节可参考 docs/observability.md。9. 灾备与高可用9.1 备份策略数据库备份定期快照与事务日志配置备份版本化的配置仓库模型备份神经网络模型的版本化存储恢复演练定期验证备份恢复流程。9.2 高可用架构全局负载均衡将流量分发到多可用区数据库节点间环形复制任一可用区故障时其余区继续提供服务。9.3 故障恢复流程常见故障场景自动自愈复杂故障遵循文档化的手动干预流程资源受限时优雅降级恢复全程保证数据一致性。仓库中v2/crates/wifi-densepose-engine/src/mesh_guard.rs即承担了网格级防护与容错职责。10. 未来扩展性10.1 扩展点插件架构模块化设计支持自定义扩展API 版本化向后兼容的版本演进API 文档中定义了 v1 稳定、v2 beta 的版本协商中间件与Sunset/Deprecation响应头特性开关运行时启停实验性功能配置模板面向领域的配置包。10.2 集成能力标准协议REST、WebSocket、MQTT、Webhook之外还提供自定义适配器框架、标准化数据导出格式与实时事件分发。仓库中 MQTT 集成已经深度落地v2/crates/wifi-densepose-sensing-server/src/mqtt/下 config.rs 定义MqttConfig与PublishRates对应RUVIEW_MQTT_*系列环境变量见 cli.rsdiscovery.rs 按{prefix}/wifi_densepose_{node_id}/{entity}/availability的格式发布 Home Assistant Discovery 主题并通过 LWT遗嘱消息上报实体可用性publisher.rs 负责在连接成功与每 30 秒重发布 retained discovery 配置并发布 presence存在性等二进制实体状态对应文档中system/status、pose/zone//occupancy等主题设计注释标注依据 ADR-115。完整的 Home Assistant / Matter 接入方案可进一步参考 docs/integration/home-assistant.md 与 ui/components 下的前端组件。11. 结论WiFi-DensePose 系统架构为基于 WiFi 信号的隐私保护人体姿态估计提供了一套健壮、可扩展、安全的基础框架实时性优先端到端延迟设计目标 100ms隐私内生通过无摄像头感知从源头消除视频隐私风险可扩展支持多并发用户与多节点网格高可靠容错与多可用区高可用设计安全设计传输、存储、处理三态保护与最小权限网络模型可扩展模块化组件 标准接口REST / WebSocket / MQTT / Webhook / Matter。这一架构既是实现路线图的蓝图也为后续增强预留了清晰入口。建议读者结合 plans/phase2-architecture/api-architecture.md、plans/phase2-architecture/hardware-integration.md 与 plans/phase2-architecture/neural-network-architecture.md 三份配套设计文档以及v2/crates下的 Rust 源码与 docker/docker-compose.yml 实际部署文件逐层验证本文所述的设计与实现映射关系。【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 RuView WiFi-DensePose 系统架构详解：从 CSI 数据采集到多协议服务的五层可扩展设计
RuView WiFi-DensePose 系统架构详解从 CSI 数据采集到多协议服务的五层可扩展设计【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView导读本文以 plans/phase2-architecture/system-architecture.md 为核心骨架系统拆解 RuViewWiFi-DensePose项目如何将普通商用 WiFi 路由器采集的信道状态信息CSI经信号预处理、神经网络推理、多目标跟踪最终通过 REST / WebSocket / MQTT / Webhook 多协议接口交付给上层应用。文中所有架构决策、组件职责、数据流参数与部署规格均完整继承自该设计文档并结合仓库中v2/crates的 Rust 实现、docker/docker-compose.yml 部署文件与 monitoring/prometheus-config.yml 监控配置逐一印证。读完本文你将掌握该系统的分层设计方法、端到端数据管线、容器/K8s 部署规格、性能与安全架构以及如何在当前仓库中对照源码定位每一层的落地实现。1. 系统全景五层架构与关键特性1.1 设计定位WiFi-DensePose 是一套隐私保护的无线人体姿态估计系统不依赖摄像头与光学传感器仅通过普通 WiFi 基础设施上的 CSI 信号完成实时人体姿态估计。其核心思路是把WiFi 信号这一物理媒介转化为空间智能数据源从而在医疗看护、零售分析、安防等场景提供无感、无摄像头的感知能力。架构文档将整个系统划分为五个逻辑层每一层职责单一、边界清晰1.2 关键系统特性隐私保护全链路无摄像头、无光学传感器规避视频隐私风险实时处理设计目标为端到端延迟低于 100ms穿墙检测可穿透墙体与障碍物感知人体姿态多人跟踪设计支持同时跟踪最多 5 人模块化可扩展组件松耦合可适配边缘设备到云端多种部署形态领域专属分析面向医疗、零售、安防等垂直领域提供专门化分析能力。需要说明的是本文档Version 1.0Status: Draft中的精度 87.2%、延迟 100ms 等指标属于架构规划阶段设定的设计目标而非仓库实测数据仓库侧的真实能力请以各模块的测试与基准结果为准。2. 组件分解与职责2.1 硬件接口层WiFi Router Interface负责与路由器建立并维护通信包括配置路由器进行 CSI 提取、管理连接生命周期、处理路由器故障与重连并支持 Atheros、Intel、ASUS 等多种路由器类型。CSI Data Collector从路由器提取并收集 CSI 数据具体职责包括接收来自路由器的 UDP 数据流、解析 CSI 数据包格式、缓冲输入数据、同步多路数据流以及处理丢包与数据损坏。在仓库中该层已有成熟的 Rust 落地v2/crates/wifi-densepose-hardware/src下包含esp32/含 tdm.rs、quic_transport.rs、secure_tdm.rs 三个传输/加密模块、ieee80211bf/、aggregator/等子模块src/bin/下则提供了aggregator.rs、mediatek-csi-sim.rs、qualcomm-csi-sim.rs、rtl8720f-sim.rs、vendor-rf-sim.rs等多个厂商 CSI 仿真器用于在没有真实硬件时验证采集与解析链路。更完整的硬件接入细节可参考姊妹文档 plans/phase2-architecture/hardware-integration.md包含 Atheros / Intel 5300 的 CSI 格式解析、UDP 流式协议与硬件抽象层设计。2.2 核心处理层Signal Preprocessor清洗与归一化原始 CSI涵盖相位解卷绕phase unwrapping、幅度归一化、时域滤波、背景减除、降噪与环境标定Neural Network Pipeline完成模态翻译CSI → 空间表征、特征提取、DensePose 估计、置信度评分与批处理优化。模型侧设计详见 plans/phase2-architecture/neural-network-architecture.md双分支编码器、空间上采样网络、DensePose-RCNN 集成、知识蒸馏与多阶段训练策略Pose Estimation Engine编排端到端处理管线协调组件间数据流、管理处理队列、优化资源分配、处理错误恢复并维持处理性能Multi-Person Tracker跨时间跟踪多个个体负责人员检测与 ID 分配、轨迹跟踪与预测、遮挡处理、轨迹生命周期管理创建/更新/终止与时序一致性约束。仓库侧的对应实现集中在v2/crates/wifi-densepose-sensing-server/src例如 pose.rs 定义了PersonDetection、PoseKeypoint等数据结构实现了基于置信度、SNR 因子与噪声因子的关键点置信度计算以及apply_temporal_smoothing基于上一帧关键点做指数平滑正是文档中时序一致性约束的实现engine_bridge.rs 与v2/crates/wifi-densepose-engine/srclib.rs、mesh_guard.rs则承担引擎编排与网格防护职责。2.3 服务层API Gateway统一访问入口负责请求路由、负载均衡、认证授权、限流、请求/响应转换与 API 版本管理REST API Service提供 HTTP 访问能力包括姿态数据访问当前/历史、系统控制启动/停止/状态、配置管理、分析报表与领域专属端点WebSocket Server支持实时数据流负责连接管理、订阅处理、实时姿态流推送、系统状态更新与告警通知External Integration Services对接外部系统包括 MQTT 发布IoT 集成、Webhook 事件通知、Restream 直播对接与第三方 API 集成。2.4 管理层Configuration Management配置存储与检索、模板管理、校验与验证、动态配置更新、多环境差异化配置Monitoring and Diagnostics性能指标采集、资源利用率监控、错误检测与上报、日志与审计轨迹、告警与通知。仓库中服务层的实际实现与文档高度对应v2/crates/wifi-densepose-sensing-server/src下既有 mqtt/ 目录MQTT 连接、HA Discovery、发布器详见第 5 节也有matter/Matter 协议、semantic/语义层、training_api.rs训练接口等模块cli.rs 中定义了 REST 端口默认 8080、WebSocket 端口默认 8765、UDP 端口默认 5005等参数。3. 数据流架构从原始 CSI 到客户端姿态数据3.1 主数据流3.2 各处理阶段规格阶段输入处理输出关键参数CSI 数据采集路由器天线原始 WiFi 信号数据包解析、缓冲、同步结构化 CSI幅度 相位采样率 10–30 Hz约 ~100 KB/s/路由器信号预处理结构化 CSI相位解卷绕、滤波、归一化干净归一化的 CSI 特征降噪、背景移除以信噪比提升为质量指标神经网络推理预处理后的 CSI 特征深度学习推理空间表征与姿态估计GPU 推理 50ms最优条件下 AP50 目标 87.2%多人跟踪原始姿态估计ID 分配、轨迹预测带 ID 的连续跟踪姿态遮挡处理、轨迹连续容量最多 5 人API 分发跟踪后的姿态数据格式化、序列化、流式推送REST 响应 / WebSocket 消息 / MQTT 发布API 响应生成 10ms支持 100 并发客户端3.3 数据存储流存储流将姿态数据拆分为短期缓存与时序数据库时间序列库、聚合分析、报表引擎三条通道配置数据与系统指标则分别进入配置库与指标库实现运行态 / 历史态 / 观测态三类数据的隔离管理。4. 服务边界与内部接口契约4.1 组件接口边界硬件接口层外部接口为 UDP socketCSI 数据接收与路由器配置接口内部接口为预处理器的 CSI 数据队列与监控用的路由器状态事件核心处理层外部接口为参数调优的配置 API 与性能监控的指标 API内部接口为神经网络预处理数据队列、跟踪器姿态估计队列以及系统状态更新的事件总线服务层外部接口为 REST 端点、WebSocket 实时流、MQTT 主题与 Webhook 端点内部接口为姿态数据访问、认证授权、限流与节流服务。4.2 内部 API 契约架构文档为组件间通信定义了三个核心 TypeScript 契约是理解数据形状的关键CSI Collector → Signal Preprocessorinterface CSIData { timestamp: number; routerId: string; amplitude: Float32Array[][]; phase: Float32Array[][]; rssi: number; metadata: Recordstring, any; }Neural Network → Pose Estimatorinterface SpatialRepresentation { features: Float32Array[][][]; confidence: number; timestamp: number; processingTime: number; }Pose Estimator → Multi-Person Trackerinterface PoseEstimate { keypoints: Array{x: number, y: number, confidence: number}; boundingBox: {x: number, y: number, width: number, height: number}; confidence: number; timestamp: number; }值得注意姿态数据统一采用归一化坐标0–1与置信度0–1的表示这与仓库实现一致——pose.rs 中PoseKeypoint的关键点坐标与置信度即为归一化数值且置信度通过clamp(0.1, 1.0)保证输出区间稳定。外部 API 契约的完整定义REST 端点、WebSocket 消息、MQTT 主题、版本化策略与鉴权流程见 plans/phase2-architecture/api-architecture.md。4.3 事件驱动通信系统通过事件总线解耦各层按硬件事件、处理事件、API 事件与告警事件四类分发5. 部署架构Docker 与 Kubernetes 双轨方案5.1 Docker 容器架构5.2 容器规格设计文档定义核心容器容器基础镜像资源卷 / 网络备注CSI CollectorPython 3.9-slim1 CPU / 1GB配置卷host 网络UDP 接收重启策略 AlwaysNeural NetworkNVIDIA CUDA 11.6 Python 3.92 CPU / 4GB / 1 GPU模型卷 共享数据卷内部网络重启策略 AlwaysPose EstimationPython 3.9-slim2 CPU / 2GB共享数据卷内部网络重启策略 AlwaysAPI ServicesPython 3.9-slim2 CPU / 2GB配置卷内外双网络端口 8000REST、8001WebSocket支撑容器容器基础镜像资源端口说明DatabaseTimescaleDBPostgreSQL 扩展2 CPU / 4GB—持久化数据卷内部网络MQTT BrokerEclipse Mosquitto1 CPU / 1GB1883MQTT、8883MQTT over TLS内外双网络Redis CacheRedis Alpine1 CPU / 2GB—持久化数据卷内部网络MonitoringPrometheus Grafana1 CPU / 2GB9090Prometheus、3000Grafana持久化数据卷内部网络5.3 仓库中的实际部署实现设计文档中的容器化思路在仓库里已有对应落地。docker/docker-compose.yml 定义了sensing-serverRust与python-sensing两个服务sensing-server镜像ruvnet/wifi-densepose:latestREST API 绑定127.0.0.1:3000、WebSocket 绑定127.0.0.1:3001UDP 端口5005暴露给 ESP32 节点通过CSI_SOURCE环境变量控制数据源可选auto默认自动探测 ESP32 UDP → 主机 WiFi两者都不可用时以退出码 78 硬失败、esp32从 UDP 5005 接收真实 CSI、wifiWindows netsh 主机 RSSI/扫描数据、simulated显式生成合成 CSI 用于演示MODELS_DIR指定.rvf模型扫描目录并配置了no-new-privileges、cap_drop: ALL与 2 CPU / 1G 的资源上限、kill -0 1健康检查python-sensing镜像ruvnet/wifi-densepose:pythonWebSocket8765、UI80801 CPU / 512M 资源上限健康检查探测 8765 端口连通性。CLI 层与之一一对应见 cli.rs 中--source默认auto、--udp-port默认 5005、--tick-ms默认 100即处理节拍、SENSING_BIND_ADDR默认127.0.0.1等参数。镜像构建说明见 docker/Dockerfile.rust 与 docker/Dockerfile.python入口脚本 docker/docker-entrypoint.sh 依据CSI_SOURCE决定启动方式。5.4 Kubernetes 部署架构K8s 形态下核心服务采集/推理/姿态/网关以 Deployment 部署有状态的数据组件数据库、Redis采用 StatefulSetMQTT 用 Deployment前端与流媒体服务器独立 Deployment基础设施侧由 Ingress Controller 统一暴露入口Prometheus Operator 负责指标采集Cert Manager 管理 TLS 证书。5.5 四类部署环境配置环境部署方式基础设施扩展性数据持久化监控开发环境Docker Compose本地开发机每容器单实例本地卷基础日志与指标测试环境Kubernetesminikube/kind专用测试服务器单实例 真实数据测试数据集临时完整监控栈用于性能测试生产环境Kubernetes云厂商或本地集群多实例 自动扩缩容托管数据库或持久卷全面监控、告警、日志多可用区冗余高可用边缘部署Docker 或 K3s带 GPU 的边缘设备资源受限单实例本地存储 云备份轻量监控 云端上报支持离线运行与同步6. 可扩展性与性能架构6.1 水平扩展策略无状态的处理管线采集→推理→跟踪→网关通过负载均衡横向扩展有状态的数据库与缓存以共享集群形式作为后端从而在容量扩展的同时保持数据一致性。6.2 垂直扩展考量神经网络容器GPU 显存是首要瓶颈数据库容器时序数据的 I/O 性能与内存API 服务容器并发请求处理依赖 CPU 核数CSI 采集容器多路由器数据流依赖网络 I/O。6.3 性能优化要点批处理推理神经网络推理合并批量、多级缓存API 响应、时序查询的数据库索引优化、数据库与服务连接池复用、全链路非阻塞异步 I/O以及按负载合理设定容器资源规格。7. 安全架构7.1 认证与授权请求统一经 API Gateway 完成认证JWT / API Key与授权角色 / 权限两道校验未通过即拒绝通过后进入处理链路。7.2 数据保护传输中外部通信全部使用 TLS 1.3静态存储敏感数据落库加密处理中内存保护与安全编码实践隐私数据最小化与匿名化设计。7.3 网络安全API Gateway 作为带安全控制的唯一入口内部服务不直接对外暴露网络分段配合严格的防火墙出入规则与限流机制抵御滥用与 DoS。仓库侧同样体现了最小权限原则例如 docker/docker-compose.yml 中cap_drop: ALL与no-new-privileges: trueREST/WebSocket 默认仅绑定回环地址127.0.0.1仅 UDP 5005 对 ESP32 开放鉴权实现可参考v2/crates/wifi-densepose-sensing-server/src/bearer_auth.rs与 ws_ticket.rsWebSocket 票据认证。8. 监控与可观测性架构8.1 指标采集8.2 日志架构集中式日志ELK 或同类方案日志级别覆盖 ERROR / WARN / INFO / DEBUG / TRACE采用带一致字段的 JSON 结构化日志通过 Correlation ID 跨组件追踪请求并按年龄分级存储、分层保留。8.3 健康检查与探针Liveness Probe检测并重启故障容器Readiness Probe阻止流量进入初始化中的容器Startup Probe允许较长的启动初始化时间深健康检查在基础连通性之上验证组件真实功能。仓库侧的观测实现与文档一一对应监控配置 monitoring/prometheus-config.yml 定义了wifi-densepose-app抓取任务scrape_interval: 10s按appwifi-densepose标签过滤从/metrics采集、Prometheus 自身 / K8s 节点 / Node Exporter / cAdvisor / kube-state-metrics / CoreDNS / ingress / blackbox 等全栈抓取任务并配置了 Alertmanager、remote_write远程长期存储、TSDB 15 天 / 50GB 保留策略与 WAL 压缩告警规则见 monitoring/alerting-rules.yml可视化面板见 monitoring/grafana-dashboard.json日志侧 logging/fluentd-config.yml 提供集中日志采集docker/otel-compose.yml 与 docker/otel-collector.yaml 提供 OpenTelemetry 观测链路更多细节可参考 docs/observability.md。9. 灾备与高可用9.1 备份策略数据库备份定期快照与事务日志配置备份版本化的配置仓库模型备份神经网络模型的版本化存储恢复演练定期验证备份恢复流程。9.2 高可用架构全局负载均衡将流量分发到多可用区数据库节点间环形复制任一可用区故障时其余区继续提供服务。9.3 故障恢复流程常见故障场景自动自愈复杂故障遵循文档化的手动干预流程资源受限时优雅降级恢复全程保证数据一致性。仓库中v2/crates/wifi-densepose-engine/src/mesh_guard.rs即承担了网格级防护与容错职责。10. 未来扩展性10.1 扩展点插件架构模块化设计支持自定义扩展API 版本化向后兼容的版本演进API 文档中定义了 v1 稳定、v2 beta 的版本协商中间件与Sunset/Deprecation响应头特性开关运行时启停实验性功能配置模板面向领域的配置包。10.2 集成能力标准协议REST、WebSocket、MQTT、Webhook之外还提供自定义适配器框架、标准化数据导出格式与实时事件分发。仓库中 MQTT 集成已经深度落地v2/crates/wifi-densepose-sensing-server/src/mqtt/下 config.rs 定义MqttConfig与PublishRates对应RUVIEW_MQTT_*系列环境变量见 cli.rsdiscovery.rs 按{prefix}/wifi_densepose_{node_id}/{entity}/availability的格式发布 Home Assistant Discovery 主题并通过 LWT遗嘱消息上报实体可用性publisher.rs 负责在连接成功与每 30 秒重发布 retained discovery 配置并发布 presence存在性等二进制实体状态对应文档中system/status、pose/zone//occupancy等主题设计注释标注依据 ADR-115。完整的 Home Assistant / Matter 接入方案可进一步参考 docs/integration/home-assistant.md 与 ui/components 下的前端组件。11. 结论WiFi-DensePose 系统架构为基于 WiFi 信号的隐私保护人体姿态估计提供了一套健壮、可扩展、安全的基础框架实时性优先端到端延迟设计目标 100ms隐私内生通过无摄像头感知从源头消除视频隐私风险可扩展支持多并发用户与多节点网格高可靠容错与多可用区高可用设计安全设计传输、存储、处理三态保护与最小权限网络模型可扩展模块化组件 标准接口REST / WebSocket / MQTT / Webhook / Matter。这一架构既是实现路线图的蓝图也为后续增强预留了清晰入口。建议读者结合 plans/phase2-architecture/api-architecture.md、plans/phase2-architecture/hardware-integration.md 与 plans/phase2-architecture/neural-network-architecture.md 三份配套设计文档以及v2/crates下的 Rust 源码与 docker/docker-compose.yml 实际部署文件逐层验证本文所述的设计与实现映射关系。【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考