Docker7530
79 lines
3.8 KiB
Markdown
79 lines
3.8 KiB
Markdown
我梳理了一下，这块是“URL 封禁/解封”能力，入口是 [ProhibitionController.java](D:/MyCode/Work/yd-hy/ibs-portal/cdn-web/src/main/java/com/cmcc/cdn/platform/selfservice/controller/ProhibitionController.java:217) 的 `POST /api/url/ban`，回调是 [OmsApiDomainController.java](D:/MyCode/Work/yd-hy/ibs-portal/cdn-web/src/main/java/com/cmcc/cdn/platform/selfservice/controller/OmsApiDomainController.java:1462) 的 `POST /action?commandType=banCallBack&version=1`。
|
||
|
||
**主流程**
|
||
|
||
`/api/url/ban` 根据两个配置开关分流：
|
||
|
||
`WG_TOTAL_SWITCH=true`，或当前企业在 `WG_ENTERPRISE_ID_SWITCH` 里时，走统一网管新链路：
|
||
|
||
1. 从请求头 `Tenant-Id` 查企业。
|
||
2. 把 `URLDenyAllowTaskVO.urls` 转成统一网管 `UrlBanLiftTaskVO.urls`。
|
||
3. 校验 URL、域名归属、操作类型、重复封禁等。
|
||
4. 生成 `WG_` 开头的 `taskId`。
|
||
5. 调统一网管/BPM：`bpmService.urlBanOrLiftOperate(…)`。
|
||
6. 下发成功后落库，返回 `taskId`。
|
||
|
||
不命中开关时，走旧链路：
|
||
|
||
1. 生成 `WS_` 开头的 `itemId`。
|
||
2. 校验 URL、域名归属、操作类型、重复封禁等。
|
||
3. 调旧配管/各平面下发。
|
||
4. 落库任务、URL 明细、配管记录、平面下发记录。
|
||
|
||
**统一网管新链路写入的表**
|
||
|
||
在 [URLBanLiftServiceImpl.java](D:/MyCode/Work/yd-hy/ibs-portal/cdn-service/src/main/java/com/cmcc/cdn/platform/selfservice/service/impl/URLBanLiftServiceImpl.java:76) 里，下发成功后写：
|
||
|
||
- `ban_lift_task`
|
||
对应实体 `NetworkURLBanLiftTask`。记录任务主表：`task_id`、`cp_id`、`operate`。
|
||
|
||
- `ban_lift_url`
|
||
对应实体 `NetworkBanLiftURL`。记录每个 URL：`url`、`task_id`、`areas`、`method`、`forbid_share_cache`、`operate`、`status`、`start_time`。初始 `status=11`，表示进行中。
|
||
|
||
- `ban_lift_task_url`
|
||
`ban_lift_task` 和 `ban_lift_url` 的关联表。
|
||
|
||
统一网管链路下发失败时，代码里没有保存这几张表，只返回失败。
|
||
|
||
**旧链路写入的表**
|
||
|
||
旧链路在 [ProhibitionServiceImpl.java](D:/MyCode/Work/yd-hy/ibs-portal/cdn-service/src/main/java/com/cmcc/cdn/platform/selfservice/service/impl/ProhibitionServiceImpl.java:253) 的 `pipeUrlDenyAllowed` 里写：
|
||
|
||
- `deny_allow_task`
|
||
任务主表，记录 `item_id`、`type`、`status`、`start_time`、`cp_id`、`task_state` 等。
|
||
|
||
- `deny_allow_url`
|
||
URL 明细表，记录 `url`、`domain`、`method`、`areas`。
|
||
|
||
- `deny_allow_task_url`
|
||
任务和 URL 的关联表。
|
||
|
||
- `pipe_config_entity`
|
||
配管消息记录，保存 `message_id`、`target_name=itemId`、`type=WANG_SU_DENY/WANG_SU_DENY_RESET` 等，用于后续配管回调匹配。
|
||
|
||
- `ban_or_filter_record`
|
||
平面下发记录，保存 `task_id`、`distribution_plane`、`success_plane`、`error_plane`、`reason`、`urls`、`type=ban/unban`。
|
||
|
||
另外，旧链路会更新 Redis 里的企业每日操作次数限制，不是数据库表。
|
||
|
||
**统一网管回调改哪些表**
|
||
|
||
你贴的 `banCallBack` 回调只处理统一网管新链路。逻辑在 [URLBanLiftServiceImpl.java](D:/MyCode/Work/yd-hy/ibs-portal/cdn-service/src/main/java/com/cmcc/cdn/platform/selfservice/service/impl/URLBanLiftServiceImpl.java:163)：
|
||
|
||
1. 按回调里的 `taskId` 查 `ban_lift_task`。
|
||
2. 找到该任务下所有 `ban_lift_url`。
|
||
3. 更新每条 URL 的：
|
||
- `status`
|
||
- `operate`
|
||
- `start_time`
|
||
- `end_time`
|
||
4. 再通过 `urlBanLiftTaskDao.save(networkURLBanLiftTask)` 保存。
|
||
|
||
所以业务上主要修改的是：
|
||
|
||
- `ban_lift_url`
|
||
|
||
同时因为是通过父对象 `ban_lift_task` 保存，JPA 可能会触发 `ban_lift_task.updated_time` 更新；但任务主表没有业务字段被主动改，关联表 `ban_lift_task_url` 也不会变。
|
||
|
||
旧链路的回调不是这个接口，它会更新 `deny_allow_task` 的 `success_rate`、`end_time`、`status`、`task_state`；但你贴的 `banCallBack` 不会改 `deny_allow_task`。
|