全局启动顺序与依赖链

本页给出跨模块的启动次序。同一模块内部的次序见各模块文档的「启动顺序」小节。

一、总原则：四档依赖强度

档位	依赖	不满足的后果
第 0 档：基础设施	MySQL/TiDB/PostgreSQL、Redis（哨兵或集群）、ZooKeeper、Kafka、Elasticsearch、OSS/NOS、Apollo	进程起不来（数据源/注册中心/配置中心初始化失败）
第 1 档：配置与计费	`antispam-business`（业务配置中心）、`antispam-bill`（计费）	业务服务能起但配置缓存为空，鉴权/策略全失效
第 2 档：检测引擎	`antispam-keyword`、`antispam-list`、`antispam-rule`、`antispam-textclassify`、`antispam-image`、`antispam-llm`、`netease-image`	业务服务启动后检测链无提供方，提交超时或直接失败
第 3 档：业务/方案层	`antispam-business-`、`antispam--solution`、`netease-antispam`	客户入口不可用
第 4 档：运营/门户	`antispam-cms(-web)`、`yidun-*`、`yidun-midend-dashboard`	人审/控制台不可用（不影响机审主链路）

二、跨模块启动顺序（推荐）

text

① 基础设施
   MySQL/TiDB · PostgreSQL · Redis(Sentinel/Cluster) · ZooKeeper · Kafka · Elasticsearch · OSS/NOS · Apollo

② 平台基础层
   antispam-business/facade/dubbo-provider   ← 全平台配置源，向 ZK /netease-antispam/online/config 写配置
   antispam-business/facade/http-api         ← 配置服务端 + 全量缓存加载（BusinessCacheManager @PostConstruct）
   antispam-bill/facade/dubbo-provider       ← 计费接口
   antispam-bill/collect · scheduler         ← 用量采集与账单（依赖业务配置）

③ 检测引擎层
   antispam-keyword  : dubbo-provider → scheduler → dubbo-check-provider → http-api
   antispam-list     : dubbo-provider / dubbo-admin-provider → scheduler → http-api
   antispam-rule     : data-loader → dubbo-provider → checker(Sharding Provider)
                       → dubbo-check-provider(Sharding Customer) → scheduler → http-api
   antispam-textclassify : dubbo-provider → dubbo-check-provider
   antispam-image        : dubbo-provider → dubbo-check-provider
   antispam-llm          : dubbo-provider → dubbo-check-provider → mq → http-api
   netease-image         : init-db → Redis/LRU → image-provider-*（算法） → image-service-yidun/modify → image-web
                           （注：antispam-image 的检测依赖它的 HTTP 入口，必须先起）

④ 业务检测层（点播/直播）
   每个模块内部统一次序：
     dubbo-provider / dubbo-check-provider  →  storage  →  http-check-api  →  http-api  →  scheduler
   antispam-business-text / -image / -audio / -video / -liveaudio / -livevideo
   netease-antispam：dubbo-provider → HTTP(WAR) 层 → Worker(async/ndc/stats/rule-async/preonline)

⑤ 方案与接入层
   antispam-solution          : storage → parser/file → http-check-api → http-api → dubbo-provider → scheduler
   antispam-file              : storage → checker → http-api → dubbo-provider → scheduler（最后开闸）
   antispam-media-solution    : storage → http-check-api → scheduler → http-api → dubbo-provider
   antispam-video-solution    : storage → http-check-api → http-api → dubbo-provider → scheduler
   antispam-livevideo-solution: storage → dubbo-provider / dubbo-check-provider → http-check-api → http-api → scheduler
   antispam-stream-solution   : mq → dubbo-provider → http-check-api
   antispam-crawler-solution  : dubbo-provider → manager → worker → storage → scheduler → http-check-api
   antispam-guardian          : dubbo-provider / dubbo-check-provider → storage
   antispam-private-cib       : console/api → dubbo-provider → http-api → scheduler → console/web

⑥ 审核运营层
   antispam-cms      : console/api → dubbo-provider → dispatcher → cdc → scheduler
   yidun-supervision-cms : dubbo-provider → console/api → cdc → scheduler
   antispam-cms-web  : nginx 静态站点，必须晚于 antispam-cms console/api 与反代就绪
   yidun-midend-dashboard : 纯前端产物 + 外部 nginx，依赖后端网关

⑦ 门户 / 账号 / 中台 / AI
   yidun-account        : facade/dubbo-provider（唯一可构建单元）
   yidun-cms            : facade/dubbo-provider
   yidun-message        : consumer → facade/http-api
   yidun-export         : facade/http-api（任务调度内嵌于此，scheduler 为空壳）
   yidun-mplatform-event: dubbo-provider → http-api
   yidun-website        : yidun-website-upload（根 pom 仅激活 common + upload）
   yidun-model-evaluation : support/database → console/api 等 → scheduler
   yidun-ai-agent         : support/database → ai-dhs-worker → console/api 等 → scheduler
   AI-data                : docs/database → ai-data-admin → scheduler → collector
   yidun-private-consume  : storage（EDA 消费，链路未接线）
   yidun-private-custom   : facade/http-api-pwd（唯一可部署单元，无中间件依赖）

三、关键依赖边（为什么必须按这个顺序）

依赖边	原因
`antispam-business` → 所有业务/引擎服务	`@EnableBusinessClient` 在 Bean 创建阶段从 ZK `/netease-antispam/online/config` 拉 Product/Target/Secret/Label 配置
`antispam-rule/checker` → `antispam-rule/dubbo-check-provider`	checker 是 Sharding Provider（发布规则分片），dubbo-check-provider 是 Sharding Customer（订阅），Provider 先发布 Customer 才有数据
`netease-image/image-service-yidun` → `antispam-image/dubbo-check-provider`	`antispam-image` 的 `app.image.check-url` 指向算法平台的 HTTP 入口
各模块 `storage` → `http-check-api`	提交端生产 Kafka 消息，消费端先起可避免消息积压与重试风暴
各模块 `scheduler` → 最后启动	`scheduler` 一跑就向 Kafka 投递任务，上游未就绪会产生大量失败重试
`yidun-ai-agent/ai-dhs-worker` → `scheduler`	`CmsDigitalHumanDispatchJob` 通过 ZK 中已注册的 worker 列表派发任务
`antispam-cms/console/api` → `antispam-cms-web`	前端 `/api/`、`/webSocket/` 全部走 CMS 后端反代
`antispam-business` 的检测配置变更	必须走同步服务触发版本刷新（`KeywordStrategyDataSyncSpi`、`ListFullSyncService`），改库不会自动生效

四、启动「三档健康判定」

新人排查顺序建议固定为：

基础设施探测：ZK 能连吗？TiDB 能连吗？Kafka topic 存在吗？Apollo 对应 app.id 的 namespace 建了吗？
Dubbo 注册面：目标服务的 Provider 在注册中心出现吗？（注意：部分模块 dubbo.protocol.register=false，查不到属预期）
应用日志：看 @PostConstruct 预热是否完成（如 BusinessCacheManager、ImageConfigSyncService、ListFullSyncService）。

常见误判

「Dubbo 注册中心查不到服务」可能不是故障：antispam-keyword/antispam-list 多个单元配置了 dubbo.protocol.register=false。
「服务起来了但检测无结果」通常是netease-image 或 textalg 等算法侧未就绪，属弱依赖。
「定时任务没跑」先确认该模块 scheduler 是否真的部署（antispam-business-text、antispam-business-image 的 scheduler 不在 kubernetes.yml 中）。

全局启动顺序与依赖链 ​

一、总原则：四档依赖强度 ​

二、跨模块启动顺序（推荐） ​

三、关键依赖边（为什么必须按这个顺序） ​

四、启动「三档健康判定」 ​

全局启动顺序与依赖链

一、总原则：四档依赖强度

二、跨模块启动顺序（推荐）

三、关键依赖边（为什么必须按这个顺序）

四、启动「三档健康判定」