new

2025-12-27 11:44:50 +08:00
commit ccd43fac1f
1193 changed files with 384161 additions and 0 deletions
@@ -0,0 +1,72 @@
+### 业务分析：
+#### 管理体系
+* 平台运维：
+	1. 系统需要内置一个网格管理平台运维团队，做团队业务授权，信息审核工作。
+	2. 部分小区所在居委，没有入驻平台，挂靠到运维团队中。
+	3. 由市场人员向相关居委推进入驻事宜。
+
+* 居委入驻：
+	1. 为居委创建团队，居委人员入驻，业务授权。
+	2. 小区新小区挂靠居委，小区所属居委关系转入转出。
+
+* 小区入驻：
+	1. 旧版本小区系统，升级服务，增加居委对接功能
+	2. 新版本小区系统上线，
+	3. 网格管理平台添加新小区信息，
+	4. 如果我们统一是通过kafka来做对接，考虚如何设计消息格式、分配消息通道
+	5. 新小区向所在居委信息注册，如果没有注册到平台运维团队下，日后转出
+
+### 区域管理
+* 区域管理示意图
+![[网格管理区域.excalidraw]]
+
+### 消息队列初步设计
+* 消息通道方案设想
+![[消息队列示意.excalidraw]]
+
+* 消息处理机制
+![[消息处理机制.excalidraw]]
+
+### 数据类型：
+定义小区系统，与网格平台交换数据的类型，定义以下两类：
+* 数据上报
+平台定义数据标准，各小区向网格平台提交。此标准面向所有小区，包括不在使用我们智慧小区平台的。此标准或将申请政府认可，纳入统一的数字城市管理规范。
+小区等级，满足数据上报标准的小区进行数字化评级。（这让我想起了五级等子病历）
+* 业务对接，我们会向大数据，智慧化方向，逐步建立，并完善网格管理体系，以及服务能力。
+	1. 业主委员会
+	2. 地区投票调研
+	3. 公告公示
+	4. 人员管理
+	5. 社区纠纷调节
+	6. 自愿者服务
+
+### 基础逻辑分析
+1. 网格管理体系，集成物业系统
+对于本身没有系统的小区，我们可以配置一个完整方案，可是一些成熟小区，如休让他们加入到我们网格管理体系？答：方案二。我们把社区系统当中的功能，减去物业部分的内容，上线其他功能模块。如下图：
+![[小区系统集成体系.excalidraw]]
+
+1. 小区加入网格
+小区端系统管理，仅对运维人员可见相关网格管理的配置。
+![[小区注册.excalidraw]]
+
+### 业务消息整理
+用于小区与网格管理平台的消息交互。下表内容仅为示意，具体业务与消息节点，需要结合业务分析。
+
+| 业务名       | 类型     | 上报项            | 发出方 | 接收方 | 备注         |
+|:------------ | -------- | ----------------- | ------ | ------ |:------------ |
+| 系统监控     | 数据上报 | 在线心跳包        | 小区   | 网格   | 小区基本信息 |
+| 业委会       | 业务对接 | 资料上传/流程节点 | 小区   | 居委   |              |
+| ^^           | 业务对接 | 审核/批复         | 居委   | 小区   |              |
+| 日常数据上报 | 数据上报 | 人口动态信息      | 小区   | 居委   |              |
+| ^^           | 数据上报 | 园区设备运行检查  | 小区   | 居委   |              |
+| ^^           | 数据上报 | 卫生工作检查      | 小区   | 居委   |              |
+| ^^           | 数据上报 | 投诉建议          | 小区   | 居委   |              |
+| 区域投票调研 | 业务对接 | 下发投票          | 居委   | 小区   |              |
+| ^^           | 业务对接 | 上报投票结果      | 小区   | 居委   |              |
+| 区域公告     | 业务对接 | 下发公告          | 居委   | 小区   |              |
+
+![[网格管理节点]]
+![[消息格式]]
+
+### 网格管理数据
+![[网格管理内容.excalidraw]]
@@ -0,0 +1,24 @@
+消息头
+	发信方，收信方，消息基础类型，消息体路由信息
+消息体
+	消息处理器处理消息
+
+```json 消息设计，草稿
+{
+	"header": {
+		"from": {
+			"type": "community", 
+			"code": "community_id"
+		},
+		"receiver": {
+			"type": "grid",
+			"code": "grid_id"
+		},
+		"timestamp": "yyyymmddhhMMssssss",
+		"msg_type": "data_report", // 
+		"msg_title": "community_population", // body的解析格式名
+		"msg_version": "1" // body的解析格式版本
+	},
+	"body": {} // 消息内容由各场景具休定义
+}
+```
@@ -0,0 +1,3 @@
+<div style="text-align:center">
+	<img src="http://thoughts.taotechip.com/uPic/zQbpez.jpg"/>
+</div>
@@ -0,0 +1,25 @@
+### 发送方接收方
+收发方类型：
+* 小区: community 
+* 网格平台: grid 
+* 居委会: committee
+
+### 收发方标识：
+#### 网格管理
+1. 网格管理按区域布署，平台维护一套编码，区域之间唯一 #区域唯一标识
+2. 区域划分，每个省独立一个区
+
+| 名称   | 编码 |
+| ------ | ---- |
+| 大湾区 | dwq  | 
+| 广东区 | gd   |
+| 浙江区 | zj   |
+
+#### 居委
+1. 由网格管理平台添加居委，为居委生成全平台唯一标识 #居委唯一标识
+
+#### 小区：
+1. 小区系统可以独立于网格管理平台运行
+2. 由网格管理平台添加小区，为小区生成全平台唯一标识 #小区唯一标识
+3. 需要为小区系统添加网格管理对接服务，并且在管理后台配置网格管理端，
+