vault backup: 2026-01-05 13:03:55

2026-01-05 13:03:55 +08:00
parent 21460fc35d
commit be7c6cdcc9
589 changed files with 396508 additions and 27 deletions
@@ -0,0 +1,8 @@
+
+todesk:
+732 079 023
+Admin@12345
+
+服务器是192.168.2.101
+
+sudo pass: Admin12345
@@ -0,0 +1,49 @@
+
+
+
+```nginx
+
+http { 
+	limit_conn_zone $binary_remote_addr zone=limitperip:10m;
+	 
+	#large_client_header_buffers 2 1k;
+	large_client_header_buffers 4 8k;
+
+	#keepalive_timeout 55;
+	keepalive_timeout 60s;
+
+	#client_header_timeout 10;
+	client_header_timeout 20s;
+
+	#client_header_buffer_size 1k;
+	client_header_buffer_size 4k;
+
+	#client_body_buffer_size 1K;
+	client_body_buffer_size 16k;
+
+	#client_max_body_size 1k;
+	client_max_body_size 50m;
+
+	server_tokens off; # Disable version information globally
+
+	#client_body_timeout 10；
+	client_body_timeout 60s;
+
+	#send_timeout 10;
+	send_timeout 60s;
+	
+	server { 
+		#limit_conn limitperip 10; 
+		if ( $http_referer ~* (babes|forsale|girl|jewelry|love|nudit|organic|poker|porn|sex|teen) ) {
+			return 403;
+		}
+		location / {
+			limit_conn limitperip 10;
+			if ($request_method !~ ^(GET|HEAD|POST|PUT|DELETE)$) {
+                return 405; # Method Not Allowed
+	        }
+		}
+	} 
+}
+
+```
@@ -0,0 +1,146 @@
+
+
+堡垒机 账号：
+luoxin
+Luox@!fh202406
+
+[https://10.8.82.16/](https://10.8.82.16/)
+
+lizx
+7Ghjb@DF1,OgdN
+
+
+
+远程桌面：
+远程机Todesk：
+847422402
+gzZn@2023
+
+
+广汽云的，南基区
+【广汽云中心】您的vpn账户已开通，
+账号： caojinhua@ds.cn
+初始密码为：uStfuNFai6!
+
+
+Mysql 更新
+8.0.35->8.4.1
+
+公司环境：
+10.100.100.95
+root
+gzzn@123
+
+
+公司测试升级：
+local docker install mysql 8.0.35
+use data
+upgrade docker 8.4.1
+
+
+生产环境：85、86
+
+应用：88
+veigue:
+docker stack rm gqxm就好了吧
+
+
+
+启动在 /opt/apps/gqxm/deploy.sh
+
+The error code MY-002061 in MySQL 8.4.1 typically relates to an issue with the replication setup, particularly with the authentication plugin being used. Here are the steps you can take to resolve this issue:
+
+1. **Change the Authentication Plugin**: Since MySQL 8.4 does not enable the `mysql_native_password` plugin by default, and it is completely removed in MySQL 9.0, you need to update your replication user to use the `caching_sha2_password` plugin.
+
+   ```sql
+   ALTER USER 'replication_user'@'%' IDENTIFIED WITH 'caching_sha2_password' BY 'your_password';
+   ```
+
+   This ensures that the user is using an authentication method compatible with MySQL 8.4 and later versions【7†source】【8†source】.
+
+2. **Update the Replication Configuration**: You may also need to modify the replication configuration to use the new authentication method. Add `GET_MASTER_PUBLIC_KEY=1` to your `CHANGE MASTER TO` statement:
+
+   ```sql
+   CHANGE MASTER TO MASTER_HOST='source_host',
+   MASTER_USER='replication_user',
+   MASTER_PASSWORD='your_password',
+   MASTER_AUTO_POSITION=1,
+   GET_MASTER_PUBLIC_KEY=1;
+   ```
+
+   This command configures the replica to request the master's public key, which is necessary for secure connections【6†source】【9†source】.
+
+3. **Verify User Plugins**: Ensure that there are no users still relying on the deprecated `mysql_native_password` plugin by running the following query:
+
+   ```sql
+   SELECT user, host, plugin FROM mysql.user WHERE plugin='mysql_native_password';
+   ```
+
+   Update any users found by this query to use the `caching_sha2_password` plugin as shown in the first step【7†source】.
+
+4. **Check Master and Slave Configuration**: Ensure that both the master and slave servers are configured correctly, especially regarding the paths and permissions of key files. Verify the configuration with:
+
+   ```sql
+   SHOW GLOBAL VARIABLES LIKE 'caching_sha2_password_public_key_path';
+   ```
+
+   Copy the public key file from the master to the slave if necessary, and adjust the `CHANGE MASTER TO` statement accordingly to specify the path to the public key on the slave【6†source】.
+
+By following these steps, you should be able to resolve the MY-002061 error and get your MySQL replication working properly. If issues persist, consider checking the MySQL error log for more detailed messages that might provide additional insights into the problem.
+
+
+CREATE USER "repluser"@"%" IDENTIFIED BY "P@ssw0rd";
+
+
+
+   CHANGE MASTER TO MASTER_HOST='10.8.62.85',
+   MASTER_USER='repluser',
+   MASTER_PASSWORD='P@ssw0rd',
+   MASTER_AUTO_POSITION=1,
+   GET_MASTER_PUBLIC_KEY=1;
+
+ALTER USER 'repluser'@'%' IDENTIFIED WITH 'caching_sha2_password' BY 'P@ssw0rd';
+
+FLUSH PRIVILEGES;
+
+SELECT user, host, plugin FROM mysql.user WHERE user = 'repluser' AND host = '%';
+
+SELECT user, host, plugin 
+FROM mysql.user 
+WHERE plugin NOT IN ('caching_sha2_password', 'mysql_native_password', 'sha256_password');
+
+
+CHANGE MASTER TO MASTER_HOST = '10.8.62.85', MASTER_USER = 'repluser', MASTER_PASSWORD = 'P@ssw0rd', MASTER_AUTO_POSITION = 1, GET_MASTER_PUBLIC_KEY = 1;
+
+change master to master_host='10.8.62.85', master_port=3386, master_user='repl', master_password='P@ssw0rd', MASTER_AUTO_POSITION = 1, GET_MASTER_PUBLIC_KEY = 1;
+
+CHANGE REPLICATION SOURCE TO SOURCE_HOST = '10.8.62.85', SOURCE_USER = 'repluser', SOURCE_PASSWORD = 'Pssw0rd' , SOURCE_PORT = 3886, GET_SOURCE_PUBLIC_KEY = 1, SOURCE_AUTO_POSITION =1;
+
+CHANGE REPLICATION SOURCE TO SOURCE_HOST = '10.8.62.85', SOURCE_USER = 'repluser', SOURCE_PASSWORD = 'P@ssw0rd' , SOURCE_PORT = 3886, GET_SOURCE_PUBLIC_KEY = 1;
+
+
+nacos 更新
+
+
+复测：
+
+漏洞检测：
+Linux kernel 权限提升漏洞(CVE-2024-1086)
+云服务商提供操作系统更新支持
+
+runc: CVE-2024-21626
+升级docker ?
+升级runc ?
+
+fastjson:
+由于autotype开关的限制可被绕过，通过开启safeMode配置完全禁用autoType。三种配置SafeMode的方式如下:
+
+  1）加上JVM启动参数： -Dfastjson.parser.safeMode=true
+
+  2）通过类路径的fastjson.properties文件来配置： fastjson.parser.safeMode=true
+
+  3）在代码中配置： ParserConfig.getGlobalInstance().setSafeMode(true);
+需要核实
+
+
+
@@ -0,0 +1,10 @@
+
+# install
+
+```bash
+mkdir -p mytb-data && sudo chown -R 799:799 mytb-data
+mkdir -p mytb-logs && sudo chown -R 799:799 mytb-logs
+docker run -it -p 8080:9090 -p 7070:7070 -p 1883:1883 -p 5683-5688:5683-5688/udp -v mytb-data:/data \
+-v mytb-logs:/var/log/thingsboard --name mytb --restart unless-stopped thingsboard/tb-postgres
+```
+
@@ -0,0 +1,119 @@
+
+
+一、培训整体框架
+- 培训目的：面向实施/运维人员，讲解在物联网AIoT平台完成设备/网关/平台三种接入模式的配置与落地，包含账号与权限、网络组件、产品与物模型、设备创建与绑定、Topic订阅、数据入库与告警规则等完整流程。
+- 方法论：
+  - 优先原则：鼓励“设备/平台主动推送到本平台”（稳定、低耦合）；“平台主动采集/消费对方MQTT/HTTP”作为兜底方案，尽量少用以减少平台负载与复杂度。
+  - N+1思路：网关场景下，先建“网关产品与网关设备”，再为下挂的N台子设备分别建“设备产品与设备设备”。
+
+二、接入模式与术语
+- 接入模式（南向）：
+  1) 设备直连：设备自身具备网络能力（常见MQTT、HTTP），直接上报至平台。
+  2) 平台直连：第三方平台承接设备数据后，推送至本平台（HTTP/MQTT）或本平台主动去消费其MQTT/HTTP。
+  3) 网关接入：低功耗、无网设备通过网关汇聚后，网关推送或第三方平台转发到本平台；网关承担多设备数据的代理。
+- 北向分发：本平台将数据提供给上级或其它业务系统（省厅、市级平台等），作为北向系统输出。
+- 设备编码（deviceId）：数据路由的唯一关键；平台中需全局唯一，与上报数据字段一致；入库及路由依赖此字段，不能缺失或混用。
+- 物模型：定义产品数据结构（标准字段+业务字段）；产品发布时自动在时序库创建超级表（字段按物模型生成）。
+- Topic（MQTT）：消息主题的层级规范；实施过程中常出现“实际Topic有中间层级/示例不完整”的情况，需客户端校验并使用“+”通配符。
+
+三、账号与权限（运营起步）
+- 管理策略：
+  - 按项目、单位或技术服务商创建独立账号，实现数据隔离与便于运营管理（如番禺救援项目单独账号，城中村、水务局分别账号）。
+  - 管理员具备全局视图；生产环境严格管理账号与设备归属，避免混用。
+- 使用场景：
+  - 技术服务商自助入驻：提供平台账号与使用指引，由对方自行创建设备、配置网关与订阅。
+  - 项目维度管理：平台管理员创建项目账号并分配权限，项目侧仅可查看与管理自身设备与数据。
+
+四、网络组件配置（培训明确步骤）
+- 目标：配置与第三方平台/设备的网络连接（MQTT/HTTP）以便采集或接收数据。
+- 必备技术资料：
+  - 服务地址与端口、认证方式（账号/密码/密钥/签名）、Topic规范、数据结构示例（含设备编码）、是否需要脚本/加密。
+- 操作要点：
+  - MQTT常用：mqt协议为物联网常见；也支持HTTP（对方平台较老或仅支持HTTP上报时使用）。
+  - 对于“平台主动消费对方MQTT”的场景，需要在网络组件中保存对方服务与认证信息，并在网关设备中配置订阅Topic。
+  - ClientId、连接URL可按文档要求设置；数据转换通常不需额外配置，除非对方格式特殊。
+
+五、产品与物模型（网关/设备双模型）
+- 产品类型：
+  - 网关产品：用于承载“平台主动采集/消费”或“网关直推”的数据入口。
+  - 设备产品（物联设备）：真实现场设备的产品定义，用于建立设备实例与业务字段承载。
+- 发布动作：
+  - 产品发布会“动态建库”，在时序库创建超级表（字段来自物模型）；发布成功后方可创建设备并正常入库。
+- 物模型设计细节：
+  - 网关物模型：通常比设备物模型复杂，需包含设备ID（如“sip”或设备编码字段）与外层结构，用于路由解析；同时包含type（类型/事件枚举）、告警信息、时间戳等。
+  - 设备物模型：可不重复配置设备ID（网关路由已确定归属），保留业务核心字段即可（如告警类型、子类、事件时间等）。
+  - 类型字段建议使用枚举；时间戳字段需勾选时序时间属性（long）。
+  - 字段命名与对方对齐，避免与平台保留关键字冲突。
+
+六、设备创建与绑定（网关模式详解）
+- 网关设备（基于网关产品）：
+  - 接入方式：选择“平台记录”（平台主动消费）或“网关直推”；在培训2实例中为“网关记录”（表示设备数据通过网关代理上报）。
+  - 协议备注：标注MQTT（便于识别）；数据方向对网关产品通常为“采集”。
+  - 订阅Topic：配置对方提供的Topic；如文档与现场不一致，使用“+”通配符适配中间层级；实施前用MQTT客户端验证。
+- 子设备（N台设备）：
+  - 创建设备实例（基于设备产品），选择接入方式为“网关记录”（表示数据经网关代理到此设备）。
+  - 填写设备编码（与上报字段一致、平台唯一）；选择所属网关；保持必要业务信息（行业、位置等）。
+  - 数据方向：子设备为“上报”（通过网关代理上报）。
+- 简化原则（培训2强调）：
+  - 设备侧无需重复配置设备ID（路由已确定）；避免冗余存储无用字段。
+  - 枚举值保持一致性；时间字段规范化。
+
+七、真实案例与操作脉络（安全帽案例）
+- 技术方案：安全帽设备→推到其自有MQTT服务→本平台作为消费者订阅其MQTT（平台主动采集）。
+- 实施步骤：
+  1) 获取技术文档与账号（MQTT地址、认证、Topic规范、数据示例）。
+  2) 管理员创建项目或服务商账号，分配权限。
+  3) 在平台网络组件中配置对方MQTT连接。
+  4) 建立网关产品，发布（建表）。
+  5) 建立网关设备，绑定网络组件，配置订阅Topic（必要时使用“+”通配符）。
+  6) 建立设备产品（与网关物模型一致或适当简化），发布。
+  7) 为每个安全帽创建设备实例（选择“网关记录”），填写设备编码，与网关关联。
+  8) 启用网关与设备，开始接收并入库。
+- 实施建议：
+  - 此“平台主动采集”方案为兜底，不建议作为默认；优先引导“设备/平台主动推送到本平台”。
+
+八、规则配置与工作量（培训1说明）
+- 告警规则并非统一套用到所有设备：
+  - 同一产品在不同部署场景要求不一，规则需按设备维度配置。
+  - 批量设备多时，需逐台配置（可考虑后续优化工具/模板导入）。
+- 实操建议：
+  - 先“学会怎么用”，工作量问题后续再评估；规则配置入口位于设备维度。
+
+九、常见问题与排障清单
+- 未收到数据：
+  - 检查网络组件连通与认证（地址、端口、账号/密钥/签名）。
+  - 检查订阅Topic是否正确；使用MQTT客户端现场验证真实Topic与数据样例。
+- 路由不正确：
+  - 网关物模型中设备ID解析是否正确；
+  - 子设备是否绑定对应网关；
+  - 通配符“+”是否覆盖中间层级。
+- 入库异常：
+  - 物模型字段名/类型是否与实际数据对齐；
+  - 时间字段是否设为时序时间；
+  - 设备编码与上报是否一致，平台唯一索引是否冲突。
+- 性能与稳定性：
+  - 尽量使用设备/平台主动推送；平台主动采集会增加任务负载；
+  - 大量设备接入需评估服务器资源（示例提到当前仅32G内存），必要时扩容。
+
+十、实施与管理建议
+- 接入前置清单：必须先拿到技术文档、真实数据样例、Topic清单与认证信息；先用客户端验证再在平台配置。
+- 账号治理：生产环境严控账号与设备归属；按项目或服务商进行隔离。
+- 模型与字段规范：保持与对方对齐命名与枚举；避免保留字；时间统一为long。
+- 批量导入：产品发布后，再批量导入设备，减少手工工作量。
+- 通配符使用：在订阅中用“+”处理中间层级差异，降低实施摩擦。
+
+十一、培训中的关键原话要点（摘录式复原）
+- “两种模式：别人平台推、我们去消费别人数据（安全帽案例为我们消费对方MQTT）。”
+- “网关模式是N+1：网关产品+设备产品；网关设备承载多台子设备。”
+- “设备编码是数据路由核心，平台唯一，数据包必须携带，不支持一个数据包混入多设备。”
+- “设备产品侧可不再配置设备ID（已由网关路由确定），避免冗余。”
+- “平台主动采集是备选兜底方案，为减少平台负载不建议默认采用。”
+- “同产品不同现场规则不一，规则需按设备维度配置。”
+
+十二、可输出的交付物（如需请告知）
+- 设备/网关接入操作手册（带步骤截图与示例字段表）
+- 接入资料清单模板（对方需提供的地址、认证、Topic、示例数据）
+- 网关订阅与通配符指南（含常见Topic偏差案例）
+- 物模型设计规范与示例（网关与设备双模型、枚举/时间字段设置）
+- 排障速查表（采集-解析-路由-入库）
+
@@ -0,0 +1,162 @@
+
+
+
+一、前置准备（必须先完成）
+- 必要资料（向设备方/平台方索取）
+  - 接入模式：设备直连 / 网关代理 / 平台采集（本平台去消费对方MQTT/HTTP）
+  - 协议与地址：MQTT/HTTP服务地址与端口
+  - 认证信息：账号/密码或密钥/签名算法、ClientId要求（若有）
+  - Topic清单：含层级规范与变量段说明（设备编码所在层级）
+  - 数据样例：真实上报JSON（至少包含设备编码、事件类型、事件时间、示例字段）
+  - 物模型草案：关键字段清单、字段类型、枚举值、时间戳格式
+- 平台账号与权限
+  - 建议按项目或服务商使用独立账号；确认账号具备网络组件、产品、设备的增改权限
+
+二、总体流程总览
+1) 配置网络组件（MQTT/HTTP）
+2) 创建产品与物模型
+   - 网关产品（如用网关或平台采集方案）
+   - 设备产品（真实设备）
+   - 发布产品（自动建表）
+3) 创建设备实例
+   - 网关设备（如有）
+   - 子设备（N台）
+4) 绑定网络与Topic
+5) 启用与验证（数据入库校验）
+说明：
+- 直连设备：可不建网关产品/设备，设备产品直连绑定网络并上报
+- 网关/平台采集：需先建网关产品/网关设备，再建子设备并绑定到网关
+
+三、步骤详解（以“网关代理/平台采集”通用流程为例）
+步骤1：配置网络组件
+- 入口：平台-网络管理-新增网络组件
+- 填写项
+  - 类型：MQTT（常用）或HTTP
+  - 地址/端口：对方提供
+  - 认证：账号/密码或密钥/签名（按文档要求）
+  - ClientId/连接参数：若对方有格式要求需按要求填写
+  - 备注：建议标注项目/厂商名称，便于后续识别
+- 校验要点
+  - 先用MQTT客户端连通测试（能订阅到任意公开主题最佳）
+  - 认证失败优先检查账号状态、白名单、TLS/证书要求
+
+步骤2：创建网关产品（如使用网关或平台采集）
+- 入口：平台-产品管理-新增产品（类型：网关）
+- 物模型设计建议
+  - 必含设备标识字段：如 deviceId 或 sip（用于路由到子设备）
+  - 事件类字段：type（枚举）、subType/desc（可选）、eventTime（long时间戳）
+  - 其它业务字段：按对方数据样例补充
+- 发布产品
+  - 发布后平台自动在时序库创建超级表；未发布将导致后续入库失败
+- 检查
+  - 确认字段名与对方数据一致，时间字段勾选为时间列
+
+步骤3：创建设备产品（真实设备）
+- 入口：平台-产品管理-新增产品（类型：设备）
+- 物模型设计建议
+  - 不重复设备标识字段（已由网关路由确定）
+  - 保留设备侧关注的业务字段，如 type、alertSubType、eventTime 等
+  - 将 eventTime 设为时间列；枚举值与对方对齐
+- 发布产品
+  - 发布后生成对应设备超级表
+
+步骤4：创建设备实例-网关设备
+- 入口：平台-设备管理-新增设备（选择网关产品）
+- 关键配置
+  - 接入方式：网关记录 或 平台记录
+    - 网关记录：数据由“网关代理”上报至平台
+    - 平台记录：平台主动去对方平台消费（安全帽MQTT消费属此类）
+  - 协议：MQTT（并备注厂商/平台名称）
+  - 绑定网络组件：选择步骤1创建的网络组件
+  - 订阅Topic：填写对方提供的Topic；中间层级不确定用“+”通配
+    - 示例：/vendor/helmet/+/alarm
+  - 启用：保存后先不启用，待子设备创建完一起启用
+- 校验要点
+  - 用MQTT客户端实测该Topic能收到与样例一致的数据
+  - Topic变量段确定设备编码位置，便于后续路由
+
+步骤5：创建设备实例-子设备（N台）
+- 入口：平台-设备管理-新增设备（选择步骤3的设备产品）
+- 关键配置
+  - 设备编码：与上报数据中的设备标识一致，平台全局唯一
+  - 接入方式：网关记录（通过网关代理）
+  - 所属网关：选择步骤4的网关设备
+  - 其它信息：名称、位置、单位、行业分类等
+- 批量建议
+  - 若数量大，先准备模板CSV后批量导入（如平台支持批量）
+- 注意
+  - 子设备不绑定网络组件与Topic，由网关设备统一订阅与路由
+
+步骤6：启用与联调
+- 入口：设备列表/网关设备详情
+- 操作
+  - 启用网关设备
+  - 启用子设备
+  - 观察监控页/日志：确认网关连接成功、订阅成功、消息接收正常
+- 入库校验
+  - 在平台查询实时/历史数据或直连时序库查询对应表
+  - 核对字段映射是否正确、eventTime是否生效排序
+
+四、直连设备（无网关）的差异化步骤
+- 产品：仅需设备产品（可将设备编码作为辅助字段或不存储，视平台实现）
+- 设备实例：接入方式选“直连”，直接绑定网络组件
+- Topic：在设备实例上配置其专属Topic（若每台设备一个Topic），或采用平台方提供的统一Topic+设备编码路由
+- 其余校验同上
+
+五、平台推送（第三方向本平台推送HTTP/MQTT）
+- 网络组件：配置为“平台接收”端点（若平台提供专属接入地址与认证）
+- 安全策略：为对方创建独立账号与密钥，限制可见与写入范围
+- 物模型与设备：与网关模式的设备侧一致
+- 验证：让对方用真实报文调用接入地址，平台查收并入库
+
+六、字段与物模型设计清单（避免入库失败）
+- 必备
+  - 路由字段：deviceId/sip（在网关模型中必需）
+  - 时间字段：eventTime（long，设为时间列）
+  - 类型字段：type（枚举或字符串，保持与对方一致）
+- 不建议
+  - 在设备模型中重复定义设备ID（已由路由确定）
+  - 使用平台保留关键字作为字段名
+- 变更
+  - 发布后字段调整需评估对历史数据表结构影响，慎重变更；必要时新建版本产品
+
+七、Topic与通配符配置指引
+- 常见差异：文档与现场Topic中间多一层（如项目号/渠道号）
+- 处理方法
+  - 优先使用“+”单层通配匹配中间层
+  - 样例：/v1/device/+/alarm 或 /org/+/helmet/+/event
+- 验证
+  - 使用MQTT客户端先订阅通配符Topic，确认能收到期望设备的数据
+
+八、启用后的自检与排障
+- 收不到数据
+  - 网络组件未连通或认证失败：检查账号/密码/证书/白名单
+  - Topic错误：客户端验证；核对通配层级数量
+  - 未启用：确认网关与子设备均为启用状态
+- 入库异常
+  - 物模型字段名不一致/类型不匹配：对照样例修正
+  - 未发布产品/表未生成：检查发布动作是否成功
+  - 时间列未设置：导致排序/查询异常
+- 路由失败
+  - 网关模型中未正确解析设备编码
+  - 子设备未创建或设备编码不一致（唯一索引冲突或找不到匹配）
+- 性能问题
+  - 平台主动采集负载高：优先引导改为对方推送
+  - 大批量设备：提前估算队列/缓存资源，必要时分批启用
+
+九、最佳实践与建议
+- 先证后配：先用客户端验证MQTT/HTTP链路与Topic，再在平台录入配置
+- N+1建模：网关产品+网关设备（1）+子设备（N），清晰解耦
+- 简化字段：设备模型只保留必要业务字段；网关模型承载路由与原始结构
+- 命名一致：字段名与对方对齐；枚举提前对表
+- 批量导入：产品发布后，再批量导入设备，减少重复劳动
+- 审计与隔离：项目/厂商独立账号与密钥；便于问题定位与权限控制
+
+十、快速清单（实施现场可打印）
+- 我是否拿到：地址/端口、认证、Topic、真实样例、设备编码列表？
+- 我是否：创建了网络组件、创建并发布了网关/设备产品？
+- 我是否：创建了网关设备并配置了Topic与网络组件？
+- 我是否：为每台设备创建了子设备并与网关绑定，设备编码一致？
+- 我是否：启用设备与网关、用监控与日志确认已接收到消息？
+- 我是否：在平台或库中查到实时/历史数据，字段与时间正确？
+
@@ -0,0 +1,4 @@
+
+http://10.100.100.210/portal/   
+
+aiot  aiot123@Admin
@@ -0,0 +1,13 @@
+
+
+生产环境：
+```
+https://218.20.201.147/portal/#/login?backurl=%2F&local=true
+```
+
+
+物联网：https://wlw.panyu.gd.cn 
+账号：aiot  pyqzhsw@PYQ123
+
+
+
@@ -0,0 +1,316 @@
+
+
+---
+
+```markdown
+# 小鹏汽车数据流向与系统架构分析
+*面向系统分析员 · {{date}}*
+
+---
+
+## 🧭 一、总体说明（Overview）
+
+> 小鹏汽车的软件体系是一套“以数据流为核心”的智能系统。  
+> 系统所有功能（自动驾驶、座舱AI、云端训练、OTA）均围绕数据生命周期展开。
+
+数据闭环由以下阶段组成：
+
+```
+
+生成 → 采集 → 上传 → 存储 → 处理 → 学习 → 部署 → 执行 → 反馈
+
+````
+
+---
+
+## 🚘 二、数据流向全景（End-to-End Data Flow）
+
+```mermaid
+flowchart LR
+    A[车辆传感器与控制系统] --> B[车端计算与中间件]
+    B --> C[Telemetry Agent]
+    C --> D[云端数据接入层]
+    D --> E[数据湖与特征仓库]
+    E --> F[AI训练与仿真验证平台]
+    F --> G[模型注册与OTA系统]
+    G --> H[OTA分发至车辆]
+    H --> I[车辆执行与运行反馈]
+    I --> D
+````
+
+---
+
+## 🧩 三、数据生命周期分析（Data Lifecycle）
+
+### 1️⃣ 数据生成（On-Vehicle Generation）
+
+**来源：**
+
+- 感知层：Camera、LiDAR、Radar、IMU、GPS
+    
+- 控制层：加速度、制动、转向、功率数据
+    
+- 座舱层：语音指令、界面交互、AI助手行为
+    
+- 系统层：XOS 日志、诊断数据、错误码
+    
+
+**数据类型：**
+
+|类别|说明|特征|
+|---|---|---|
+|感知数据|图像、点云、环境感知|高频、原始体量大|
+|车辆状态|控制信号、CAN 报文|实时性要求极高|
+|用户交互|语音、触控、行为日志|可匿名化上传|
+|系统日志|软件状态与错误码|用于稳定性评估|
+
+---
+
+### 2️⃣ 数据处理与分发（Vehicle Computing）
+
+- 感知栈（Perception Stack）执行 XNet 模型推理；
+    
+- 规划栈（Planning Stack）生成轨迹与控制策略；
+    
+- DDS（RTI Connext Drive）实现模块间异步消息传递；
+    
+- 重要事件由 **Telemetry Agent** 抽样上传。
+    
+
+**实时路径：**
+
+```
+Sensors → Perception → Fusion → Planning → Control
+```
+
+**本地缓存策略：**
+
+- 高频短期缓存（RAM）
+    
+- 关键片段写入本地Flash（用于回传）
+    
+- 事件触发上传机制（低频）
+    
+
+---
+
+### 3️⃣ 数据上行（Vehicle → Cloud）
+
+**通信协议：** MQTT / HTTPS / gRPC  
+**网络层：** 5G / LTE / V2X  
+**安全层：** TLS + PKI + 签名验证
+
+**上报数据包括：**
+
+- 感知片段与异常场景
+    
+- 驾驶日志与控制参数
+    
+- 车辆状态与健康信息
+    
+- 用户交互与座舱事件
+    
+- 软件运行与错误日志
+    
+
+**云端接入流程：**
+
+```
+Vehicle → API Gateway → Kafka → Flink/Spark → Data Lake
+```
+
+- Kafka：高并发数据流缓冲
+    
+- Flink：实时聚合与清洗
+    
+- Metadata Service：管理数据标签与时间戳
+    
+- Validation Service：完整性与签名验证
+    
+
+---
+
+### 4️⃣ 数据存储与管理（Data Lake & Feature Store）
+
+**数据分层：**
+
+```
+raw/        → 原始传感器数据
+processed/  → 清洗与对齐后的数据
+features/   → 特征化结果
+models/     → 模型输出与版本
+logs/       → 系统运行记录
+```
+
+**管理策略：**
+
+- Schema-on-Read 模式（灵活扩展）
+    
+- 按时间、车型、场景分区
+    
+- 数据血缘追踪与元数据索引
+    
+- 隐私合规（GDPR / 数据出境审计）
+    
+
+---
+
+### 5️⃣ 数据学习与建模（AI Training & Simulation）
+
+**训练流程：**
+
+1. 数据清洗与增强（Data Cleaning & Augmentation）
+    
+2. 特征提取与标签化（Feature Engineering）
+    
+3. 模型训练（Distributed GPU, PyTorch / TensorFlow）
+    
+4. 仿真验证（Carla / Unity / OpenSCENARIO）
+    
+5. 模型注册与评估（MLflow / Kubeflow）
+    
+
+**云端架构：**
+
+```
+Data Lake → Feature Store → Training Cluster → Model Registry
+```
+
+- MLOps：实现模型版本控制与持续训练
+    
+- 分布式计算：Ray / Horovod
+    
+- 模型评估：自动化指标测试、精度报告生成
+    
+
+---
+
+### 6️⃣ 模型与软件下发（Cloud → Vehicle）
+
+**OTA 下发机制：**
+
+```
+Model Registry → OTA Service → CDN Edge → Vehicle OTA Agent
+```
+
+- 分模块差分更新（模型、应用、固件分离）
+    
+- 灰度发布机制（按车型/地区批量推送）
+    
+- 签名校验 + HSM 保障完整性
+    
+- 热重载与回滚机制保证安全性
+    
+
+**车端行为：**
+
+- XOS 校验包完整性
+    
+- OTA Manager 调度模块重启或模型替换
+    
+- 上报更新结果至云端（Update Report）
+    
+
+---
+
+### 7️⃣ 数据反馈与闭环优化（Feedback & Continuous Learning）
+
+闭环目标：形成 **自演化 AI 系统**  
+即车辆使用数据 → 云端优化 → OTA 更新 → 再次反馈
+
+|阶段|输入|输出|作用|
+|---|---|---|---|
+|运行阶段|实际驾驶数据|异常样本|数据补充|
+|分析阶段|大规模日志|优化场景集|精准再训练|
+|训练阶段|特征数据|新模型|性能提升|
+|部署阶段|模型/软件包|OTA 更新|功能增强|
+|反馈阶段|实际指标|改进决策|自我优化|
+
+---
+
+## ☁️ 四、系统架构支撑视图（Architecture Support View）
+
+### 架构逻辑
+
+小鹏的架构以数据流为主线，通过以下系统支撑：
+
+1. **车端：实时计算与分布式通信**
+    
+    - 构建 SOA 化车载平台（DDS + 容器化）
+        
+    - 以中间件实现“数据即服务”
+        
+2. **云端：数据与模型生命周期管理**
+    
+    - 数据湖 → 特征仓库 → 模型训练 → OTA
+        
+3. **研发支撑：CI/CD + MLOps**
+    
+    - 形成从代码、模型到数据的统一流水线
+        
+4. **安全与合规体系**
+    
+    - 全链路加密、身份认证、隐私治理
+        
+
+---
+
+### 架构分层（系统视图）
+
+```mermaid
+graph TD
+    subgraph Vehicle
+        V1[传感器与控制] --> V2[感知/融合/规划模块]
+        V2 --> V3[DDS中间件通信层]
+        V3 --> V4[XOS操作系统]
+    end
+    subgraph Cloud
+        C1[API Gateway / Kafka]
+        C1 --> C2[数据湖 & 特征仓库]
+        C2 --> C3[AI训练与仿真平台]
+        C3 --> C4[Model Registry / OTA Service]
+    end
+    subgraph DevOps
+        D1[CI/CD + MLOps Pipeline]
+        D1 --> C3
+    end
+    V3 --> C1
+    C4 --> V4
+```
+
+---
+
+## 🧮 五、系统分析要点（System Analyst Focus）
+
+|分析维度|说明|
+|---|---|
+|**数据流向**|架构的主线；所有系统围绕数据生命周期设计|
+|**边界清晰**|车端与云端通过安全通道分离职责|
+|**解耦性**|车内 DDS 与云端微服务相互独立|
+|**一致性策略**|数据与模型版本同步控制|
+|**非功能性关注**|实时性、安全性、可靠性、可扩展性|
+|**演化能力**|架构支持快速OTA与模型迭代|
+|**治理与合规**|全链路审计、数据脱敏与访问控制|
+
+---
+
+## 🔁 六、总结（Summary）
+
+> 从数据流角度看，小鹏的软件系统是一个以 **数据驱动决策与学习** 为核心的闭环架构。
+
+**核心特征：**
+
+- 数据是系统的主导对象；
+    
+- 架构的所有层次都服务于数据流动；
+    
+- 软件更新是数据反馈的自然结果；
+    
+- 系统目标是实现“持续学习、持续优化、持续交付”。
+    
+
+最终实现：
+
+> **Software Defined Vehicle = Data Driven + Model Driven + Continuous Evolution**
+
+---
@@ -0,0 +1,253 @@
+
+
+> **「小鹏汽车系统架构（System Architecture）」**
+
+结构清晰、语义标准，格式完全适配 **Obsidian Markdown**。  
+内容聚焦在系统架构本身：分层结构、逻辑与物理视图、关键子系统、非功能性约束，以及架构演化路线。
+
+---
+
+```markdown
+# 小鹏汽车系统架构（System Architecture of XPENG Motors）
+*面向系统分析员 · {{date}}*
+
+---
+
+## 🧭 一、系统定位与架构目标（System Context & Goals）
+
+### 系统定位
+小鹏汽车是一个 **“云-车一体化” 的软件定义汽车系统（Software Defined Vehicle, SDV）**。  
+整体由两大系统域组成：
+- **车端系统（On-Vehicle System）**：负责实时感知、决策、控制与人机交互；
+- **云端系统（In-Cloud System）**：负责数据采集、分析、模型训练、OTA分发与远程运维。
+
+两者通过安全通信通道（5G / V2X / TLS）形成 **闭环数据架构**，  
+实现从感知到学习、从更新到再优化的持续演进。
+
+---
+
+### 架构目标
+| 架构属性 | 目标描述 | 指标或机制 |
+|-----------|-----------|-------------|
+| **可演化性** | 支持软件持续迭代与OTA更新 | 模块化 / 接口稳定 / 热更新 |
+| **实时性** | 满足自动驾驶与控制环路响应 | <10ms 延迟（DDS QoS） |
+| **安全性** | 满足功能安全 + 网络安全 | ISO 26262 + TLS + HSM |
+| **可扩展性** | 支撑多车型、多功能复用 | 微服务 + 容器化 |
+| **可用性** | 高可用冗余与自愈 | 双通道通信 + 监控回退 |
+| **一致性** | 云车状态与数据同步 | 双向版本控制机制 |
+
+---
+
+## 🧩 二、系统总体结构（System Decomposition）
+
+小鹏系统采用“**双域四层**”结构：
+
+```
+
+Cloud System (云端)  
+├─ 数据采集与管道层  
+├─ 数据湖与特征仓库层  
+├─ AI训练与仿真层  
+└─ OTA与运维服务层
+
+Vehicle System (车端)  
+├─ 感知与决策层  
+├─ 通信中间件层  
+├─ 操作系统与座舱层  
+└─ 硬件抽象与控制层
+
+````
+
+---
+
+## 🚗 三、车端系统架构（On-Vehicle Architecture）
+
+### 分层结构
+```mermaid
+graph TD
+    A[应用层: 自动驾驶 / 座舱AI / 车控逻辑]
+    B[服务层: SOA 服务管理 / 语音 / 导航]
+    C[通信层: DDS / RTI Connext / IPC]
+    D[系统层: XOS / Linux / QNX]
+    E[硬件抽象层: ECU / Sensors / Actuators]
+    A --> B --> C --> D --> E
+````
+
+### 主要组成模块
+
+|模块|功能说明|技术要点|
+|---|---|---|
+|**自动驾驶栈 (XPILOT / XNGP)**|感知、预测、规划、控制|XNet 感知模型 + Turing 芯片|
+|**车载操作系统 (XOS)**|座舱交互、语音助手、小P|Linux + QNX + 应用容器|
+|**通信中间件 (DDS)**|模块间消息分发与服务发现|RTI Connext Drive|
+|**E/E 电子架构**|中央计算 + Zonal Controller|与大众 CEA 架构协同|
+|**车控与诊断系统**|电机/制动/能量管理|CAN / LIN / Ethernet|
+|**安全机制**|功能安全 + 网络加密|HSM / PKI / TLS|
+
+### 架构特征
+
+- SOA化设计（Service-Oriented Architecture）
+    
+- 模块以服务形式存在，通过 DDS 异步通信
+    
+- 容器化运行环境，支持模块级 OTA
+    
+- 实时调度与安全隔离（QNX + Linux 双核架构）
+    
+
+---
+
+## ☁️ 四、云端系统架构（In-Cloud Architecture）
+
+### 云端逻辑结构
+
+```mermaid
+flowchart TD
+    A[Telemetry Ingestion 层]
+    B[数据湖 / 特征仓库]
+    C[AI 训练与仿真平台]
+    D[模型注册 / MLOps 管理]
+    E[OTA 分发与运维平台]
+    A --> B --> C --> D --> E
+```
+
+### 云端核心子系统
+
+|模块|功能说明|技术栈 / 架构模式|
+|---|---|---|
+|**数据采集与接入层**|接收车端上报数据|MQTT / Kafka / Flink|
+|**数据湖与仓库层**|存储与管理全量数据|S3 / Hive / DeltaLake|
+|**AI 训练平台**|模型训练与优化|PyTorch / TensorFlow / Ray|
+|**仿真测试系统**|模拟驾驶场景验证算法|Carla / Unity / OpenSCENARIO|
+|**MLOps 管理平台**|模型版本与部署管理|MLflow / Kubeflow|
+|**OTA 系统**|OTA 打包与分发|微服务 + CDN + 签名验证|
+|**监控与运维**|实时监测与异常分析|Prometheus / Grafana / ELK|
+
+### 架构特征
+
+- 微服务化 + 事件驱动架构（EDA）
+    
+- 支持实时流处理与批量分析（Lambda Architecture）
+    
+- 模型与软件分层管理（解耦版本）
+    
+- 数据闭环支持持续学习（DataOps + MLOps）
+    
+
+---
+
+## 🔗 五、云车交互与数据闭环（Cloud-Vehicle Interaction）
+
+### 数据闭环流程
+
+```mermaid
+flowchart LR
+    A[车辆传感器] --> B[车端计算与决策]
+    B --> C[Telemetry Agent 上报]
+    C --> D[云端数据管道 Kafka/Flink]
+    D --> E[数据湖 / 特征仓库]
+    E --> F[AI 训练 / 仿真平台]
+    F --> G[模型注册 / OTA系统]
+    G --> H[OTA 分发]
+    H --> I[车辆端接收更新]
+    I --> B
+```
+
+**说明：**
+
+- 上行：车辆 → 云端 → 数据湖
+    
+- 下行：云端 → OTA → 车辆
+    
+- 闭环：通过反馈数据持续优化模型与策略
+    
+
+---
+
+## 🧠 六、系统架构视图（Architectural Views）
+
+### 1️⃣ 逻辑视图（Logical View）
+
+展示功能模块与交互关系：
+
+```
+[自动驾驶] ─ [座舱系统] ─ [通信中间件]
+        │           │
+        └─────→ 云端数据平台 ←─────┘
+```
+
+### 2️⃣ 物理视图（Physical View）
+
+```
+车辆端：中央计算单元 + 区域控制器
+云  端：Kubernetes 集群 + GPU 训练集群
+通信通道：5G / MQTT / HTTPS / OTA
+```
+
+### 3️⃣ 过程视图（Process View）
+
+- 实时管线：传感器 → 感知 → 规划 → 控制
+    
+- 异步事件：消息总线 DDS
+    
+- 后台任务：日志上传、诊断上报、OTA更新
+    
+- 云端任务：数据清洗 → 模型训练 → 部署 → 下发
+    
+
+---
+
+## ⚙️ 七、非功能性需求（NFR Support）
+
+|类别|架构应对方式|
+|---|---|
+|**性能**|中央计算 + DDS 实时通信|
+|**安全**|端到端加密 + OTA 签名验证|
+|**可靠性**|模块冗余 + 服务回退机制|
+|**可维护性**|模块化服务与标准化接口|
+|**可测试性**|仿真测试 + 数字孪生验证|
+|**可扩展性**|微服务 + K8s 弹性伸缩|
+|**合规性**|数据脱敏 + 日志审计|
+
+---
+
+## 🧭 八、架构演化路线（Architecture Evolution Roadmap）
+
+|阶段|架构形态|关键演进|
+|---|---|---|
+|**V1 分域架构**|多ECU、功能分散|向域控制器集中|
+|**V2 域融合架构**|多域整合、服务化|引入DDS与SOA|
+|**V3 中央计算架构（当前）**|单一计算平台 + 容器化服务|实现统一调度与OTA|
+|**V4 智能体架构（目标）**|大模型驱动、自演化系统|云车协同AI原生架构|
+
+---
+
+## 🔍 九、系统分析要点（Analyst Summary）
+
+|分析维度|关键结论|
+|---|---|
+|**系统类型**|分布式智能系统（Cyber-Physical + Cloud）|
+|**通信模型**|异步事件驱动 + 服务编排|
+|**核心驱动**|数据闭环与模型持续学习|
+|**解耦策略**|SOA / 微服务 / DDS 消息总线|
+|**安全架构**|PKI + OTA签名 + 可信执行环境|
+|**研发体系**|DevOps + MLOps + Digital Twin|
+|**关键特征**|数据驱动、AI原生、自演化|
+
+---
+
+## 🧩 十、总结（Summary）
+
+> 小鹏汽车的系统架构是一种 **数据驱动 + 服务化 + AI原生** 的分布式智能体系。  
+> 它的本质是通过云车数据闭环实现智能进化：
+
+**软件定义汽车 = 数据流动 + 模型迭代 + OTA持续交付**
+
+架构目标：
+
+- 解耦与复用；
+    
+- 实时与可靠；
+    
+- 安全与演化。
+