Web_AutoNotificatPhone_Server_Prod

1. 项目概述

这是一个基于 ASP.NET Core 8 MVC 的通知与巡检服务，核心职责是：

1. 提供 HTTP API，接收“电话/短信”通知请求并发布到 Redis 频道。
2. 运行后台定时任务（TimerClass），每分钟做系统状态检查。
3. 根据 Redis 指标和 PostgreSQL 心跳数据触发自动告警（短信 + 电话）。

项目本质上是一个“告警编排层”：

• 输入来源：HTTP 请求、Redis 指标、PostgreSQL 心跳表。
• 输出目标：Redis 发布（供下游呼叫/短信系统消费）。

---

2. 技术栈与依赖

• .NET: net8.0
• Web: ASP.NET Core MVC + API Controller
• Redis: CSRedisCore
• PostgreSQL: Npgsql
• Logging: NLog

AutoNotificatPhone.csproj 关键包：

• CSRedisCore
• NLog
• Npgsql

---

3. 目录与核心文件

• Program.cs：应用启动、CORS、路由、HostedService 注册。
• Controllers/CallAndMsgController.cs：通知入站 API（电话/短信）。
• Models/TimerClass.cs：后台巡检与告警主流程。
• CSRedisCacheHelper.cs：Redis 连接与基础操作封装。
• Models/SmsRequest.cs：通知请求模型。
• Models/ReturnInfo.cs：统一接口返回结构。
• appsettings.json：日志级别、Postgres 连接配置。
• nlog.config：日志落盘规则。

---

4. 启动流程（程序生命周期）

4.1 Program 启动阶段

Program.cs 主要行为：

1. AddControllersWithViews()：注册 MVC 和 API 支持。
2. 注册 CORS 策略 AllowAnyOrigin：
   • 允许任意源
   • 允许任意方法
   • 允许任意请求头
3. AddHostedService<TimerClass>()：注册后台巡检服务。
4. 管道顺序：
   • UseStaticFiles()
   • UseRouting()
   • UseCors("AllowAnyOrigin")
   • UseAuthorization()
   • MapControllerRoute(...)

4.2 后台服务启动

应用启动后，TimerClass 自动运行：

• 持续循环，直到应用停止。
• 每分钟固定在第 30 秒执行一次巡检逻辑。

---

5. API 处理流程（CallAndMsgController）

5.1 路由

Controller 路由前缀：

• api/CallAndMsg/{action}

核心接口：

• POST api/CallAndMsg/SendToPhone

5.2 请求模型（SmsRequest）

• PhoneNumber：目标手机号
• CallerName：任务标识/来电显示名
• Content：消息内容
• StartingPoint：开始时间（Unix 秒）
• DeadLine：截止时间（Unix 秒）
• Type：1 电话，2 短信

5.3 接口执行逻辑

SendToPhone 内部流程：

1. 接收 SmsRequest。
2. 组装 notification 对象。
3. 使用固定频道 MsgAndCall 发布到 Redis：
   • CSRedisCacheHelper.Publish("MsgAndCall", payload)
4. 返回 ReturnInfo：
   • 成功：status=200 + 根据 Type 返回“已加入队列”文案
   • 失败：status=500 + 异常信息

说明：ConvertTimestampToIso 名称为“转 ISO”，但实际仍返回 Unix 秒。

---

6. Redis 封装（CSRedisCacheHelper）

6.1 连接

静态初始化时连接本地 Redis：

• Host: 127.0.0.1
• Port: 10079
• 密码：代码中硬编码
• DB0: redis
• DB1: redis1

6.2 用途

• DB0：主要用于发布通知频道（MsgAndCall）。
• DB1：主要用于读取巡检指标（CPU、在线数、收发包等）。

6.3 方法

• Set/Get/Forever/Del/Contains
• Publish

---

7. 核心：TimerClass 业务流程详解

TimerClass 是项目核心，分为 调度层、检查层、告警层。

7.1 调度层（每分钟触发）

主循环执行顺序：

1. 计算下次执行时间（每分钟第 30 秒）。
2. 检查电话机进程是否在线（进程名 Telephone）。
3. 运行整点任务调度。
4. 依次执行检查任务：
   • CPU 阈值
   • RCU 在线数量
   • 总发送包
   • 总接收包
   • PostgreSQL 心跳

出现异常时：

• 记录日志
• 延迟 10 秒重试

7.2 整点任务调度

方法：RunHourlyNotificationTask()

规则：

• 使用北京时间（UTC+8）。
• 非整点（Minute != 0）不执行。
• 同一整点只执行一次（_executedTasks 去重）。
• 10/15/22 点执行每日任务，其余整点发整点短信。

7.2.1 整点短信（SendHourlySms）

• 给 Mobile1 发送一条短信任务。
• 文案包含当前“月/日/时”。

7.2.2 每日任务（ExecuteDailyTask）

• 给 Mobile1 和 Mobile2 发送短信。
• 给 Mobile1 发送电话任务。
• 任意发送失败记录错误日志。

7.3 Redis 指标检查

7.3.1 CPU 检查（CheckCpuThreshold）

步骤：

1. 读取 UDPPackage_DetectTime：
   • 若超过 10 分钟未更新，触发“监控程序无法访问”告警。
2. 读取：
   • UDPPackage_CPUMax
   • UDPPackage_CPUAvg
   • UDPPackage_CPUMin
3. 若 CPUAvg 中满足“>=80 的点数达到 6 个”，触发 CPU 告警。

7.3.2 通用 Redis 规则（CheckRedisValue）

用于在线数/发送包/接收包的基线跌落判断：

1. 读取 CSV 序列。
2. 取前 baselineCount 个点做平均。
3. 阈值 = 平均值 × thresholdRatio。
4. 若后续两个点都低于阈值，触发告警。

具体调用：

• RCUOnLine：baselineCount=8，ratio=0.8
• UDPPackage_TotalSendPackage：baselineCount=8，ratio=0.6
• UDPPackage_TotalRecvPackage：baselineCount=8，ratio=0.75

7.3.3 接收包特殊规则（CheckTotalRecvPackage）

在通用规则之前，先判断：

• 若最后 3 个值都 < 70000，立即触发告警。

7.4 PostgreSQL 心跳检查

方法：CheckKafkaHeartbeatAsync()

目标：判断“Kafka 入库是否活跃”。

流程：

1. 从 appsettings.json 的 Postgres 节生成连接串。
2. 查询 heartbeat.heartbeat_events：
   • 先按 ts_ms desc 取最近 3000 条
   • 再按 write_ts_ms desc 取最新一条
3. 结果为空或解析失败：走“数据库连接失败”告警路径。
4. 若 nowMs - lastTsMs > KafkaStaleMinutes：触发“入库停滞”告警。
5. 异常（连接失败/SQL 异常）同样走“数据库连接失败”告警。

7.4.1 数据库连接失败节流

• 字段：_kafkaDbConnectionAlertCount
• 逻辑：失败累计到 KafkaDbAlertTriggerCount=8 才真正发一次告警，之后计数清零。

---

8. 告警发送机制

统一通过 SendAlert(...)：

1. 计算过期时间：
   • 普通：短信 1800 秒、电话 900 秒
   • 扩展：短信 3600 秒、电话 1800 秒
2. 构造 3 条任务：
   • 短信：Mobile1
   • 短信：Mobile2
   • 电话：Mobile1
3. 调用 CallAndMsgController.SendToPhone 投递。
4. 任一失败，记录错误日志。

---

9. 配置说明

9.1 appsettings.json

当前包含：

• Logging
• AllowedHosts
• Postgres
  • Host
  • Port
  • Database
  • User
  • Password
  • MaxConnections
  • IdleTimeoutMs

9.2 nlog.config

• 文件落盘目录：{basedir}/Logs/{shortdate}
• 文件：info_*.txt、error_*.txt
• 当前规则：
  • FATAL 写入 info 文件
  • Error 及以上写入 error 文件

---

10. 快速运行

10.1 开发运行

dotnet restore
dotnet build AutoNotificatPhone.csproj
dotnet run --project AutoNotificatPhone.csproj

默认开发地址见 Properties/launchSettings.json：

• http://localhost:5080

10.2 VS Code Tasks

项目已配置任务：

• build
• publish
• watch

---

11. 对外接口示例

请求：

POST /api/CallAndMsg/SendToPhone
Content-Type: application/json

{
  "PhoneNumber": "13500000000",
  "CallerName": "测试任务",
  "Content": "测试短信内容",
  "StartingPoint": 1760000000,
  "DeadLine": 1760001800,
  "Type": "2"
}

成功响应：

{
  "isok": true,
  "message": "短信已加入发送队列",
  "status": 200,
  "response": "success"
}

---

12. 关键数据流（一句话版）

外部请求/定时巡检 -> 生成 SmsRequest -> CallAndMsgController -> Redis 频道 MsgAndCall -> 下游系统消费执行。

---

13. 当前实现中的注意点

1. CallAndMsgController 中 ConvertTimestampToIso 命名与实现含义不一致（返回 Unix 秒）。
2. CSRedisCacheHelper 中 Redis 密码硬编码在代码，不利于安全与环境切换。
3. TimerClass 的 KafkaStaleMinutes 与告警文案“3分钟内入库数据为0”存在语义不一致风险（建议统一）。
4. 当前 CORS 为完全放开，生产环境建议收敛来源。

---

14. 后续可优化方向（可选）

1. 将手机号、阈值、执行小时、告警文案全部配置化。
2. 让 TimerClass 通过接口服务发送通知，避免直接 new Controller。
3. 增加单元测试：
   • Redis 阈值计算
   • Kafka 心跳判定
   • 告警节流逻辑
4. 增加健康检查端点（数据库/Redis 连通性）。

---

15. 维护建议

每次修改巡检规则后，至少验证：

1. dotnet build 无编译错误。
2. Redis 有模拟数据时告警触发正确。
3. PostgreSQL 心跳超时/失败路径可复现。
4. MsgAndCall 频道消息格式未破坏下游兼容。