易盾服务启动手册

外观

antispam-bill — 反垃圾计费结算（用量采集 → 账单结算 → 云支付扣费） ​

分层：业务层（计费结算域）｜ 部署单元：1 个（另有 4 个有启动类但不构建）｜ 数据库：MySQL/TiDB antispam ｜ base image：private-registry.nis.netease.com/library/base-image:jdk17（tag base-250409）

一、模块定位与架构 ​

它把易盾各产品线（文本/图片/音视频/解决方案/审核系统）上报的用量、审核量、试用量汇聚成账单，按客户套餐类型折算费用，再通过云支付平台完成扣费/退款，并为运营后台提供套餐、账单、统计查询。核心诉求是“不少扣（营收）、不多扣不重扣（客诉/资损）”。

架构分层

  • 采集层：collect（RequestStatConsumer/ArchiveStatConsumer/CensorStatConsumer/SupplierStatConsumer/TrialStatConsumer，Kafka 消息入账判定与去重）
  • 业务计算层：service/business（component.stat.*、PackageInfoService、BillStatArithmeticSelector、费用项 Worker、PayRemoteService 对接）
  • 数据访问层：service/base（DAO/Manager/MyBatis Mapper）+ domain（RequestStatMessage/ArchiveStatMessage 等）+ common（套餐/账单类型、状态码）+ client（套餐缓存与事件插件）
  • 定时结算层：scheduler（40+ ElasticJob：计费、费用项、统计、套餐生命周期、通知、回退）
  • 对外接口层：facade/dubbo-provider（套餐/账单/配置/统计 Dubbo 门面）、facade/http-api（骨架）、console/api（控制台骨架）

关键数据流

  1. 检测业务 → Kafka 用量消息（如 Antispam_Text_RequestStat、yidun_request_stat、Antispam_Bill_ArchiveStat）
  2. collect 的 RequestStatConsumer.handleMessage 判套餐/判状态/判重跑
  3. RequestStatComponentV2.collect Redis 累计 + 落库
  4. scheduler 的 RequestStatWorkerV2/BillStatWorker 定时汇总 → package_bill_record 结算记录
  5. BillRecordPayWorker → PayRemoteService 云支付扣款 → 平台余额/流水
  6. 套餐状态变更事件（Antispam_Bill_Package_Change）驱动 AbstractPackageStatusChangeEventListener 分支处理

二、可部署服务清单 ​

部署单元目录artifactId镜像名端口服务类型独立 Dockerfile是否进 kubernetes.yml
facade/dubbo-providerantispam-bill-facade-dubbo-providerprivate-registry.yidun.internal/yidun/antispam-bill-dubbo-provider:1.0.0.privateDubbo port=-1（无 Web）Dubbo Provider有是（replicas=2，cpu 1/2，mem 1024/2048）
collectantispam-bill-collect无（不构建）—Kafka Consumer + 内置 Qos无否
schedulerantispam-bill-scheduler无（不构建）—ElasticJob（40+ 任务）无否
facade/http-apiantispam-bill-facade-http无（不构建）—HTTP无否
console/apiantispam-bill-console-api无（不构建）—控制台后端无否

本仓库 kubernetes.yml 仅一个 Deployment：antispam-bill-facade-dubbo-provider（namespace yidun）；其余单元虽含完整启动类与配置，却没有 build.sh/Dockerfile。

三、同模块启动顺序 ​

  1. facade/dubbo-provider —— Dubbo 契约注册主体，为 CMS/运营与内部消费方提供套餐/账单/配置接口，也是 scheduler/collect 的配置读取对象。
  2. collect —— 用量消息入账入口，依赖套餐/产品配置已可读（经 business.client ZK 与本地 DB），须在结算前启动以累计 Redis 数据。
  3. scheduler —— 依赖 collect 累计的用量数据与套餐状态，跑计费/汇总/扣费；无数据时任务会空跑但不应先于 collect 上线。
  4. facade/http-api / console/api —— 纯读侧展示与查询，最后启动。

四、逐服务启动逻辑 ​

facade/dubbo-provider ​

  • 启动类：com.netease.is.antispam.bill.facade.dubbo.DubboApplication（facade/dubbo-provider/src/main/java/com/netease/is/antispam/bill/facade/dubbo/DubboApplication.java）
  • @SpringBootApplication：无 exclude
  • @Enable* 注解：@EnableAspectJAutoProxy、@EnableTransactionManagement、@EnableRecoverComponent（com.netease.is.antispam.components.recover.spring）、@EnableBusinessClient、@EnableConfigurationProperties({BillPlatformProperties, BillStatProperties})
  • Apollo 接入：无 @EnableApolloConfig，靠 apollo.bootstrap.enabled=true + apollo.cluster=default + app.id=antispam-bill_dubbo + apollo.bootstrap.namespaces=application 自动注入
  • 动态数据源 / Mapper：由 service/base 的 Dao 与 mybatis.mapper-locations 驱动；dubbo.scan.basePackages=com.netease.is.antispam.bill.facade.dubbo.provider 暴露 Provider
  • main()：仅 SpringApplication.run(...)
  • 启动钩子：未发现显式 @PostConstruct/ApplicationListener；@EnableRecoverComponent 会拉起失败重放组件（recover.config.*：recoverFileSizeLimitInMB=-1、recoverThreshold=15、clusterRecoverPoolSize=2），属框架级。

collect（有启动类，不构建） ​

  • 启动类：com.netease.is.antispam.bill.collect.CollectApplication
  • @EnableBusinessClient、@SpringBootApplication、@EnableAspectJAutoProxy、@EnableTransactionManagement、@EnableConfigurationProperties({BillCollectProperties, BillCacheProperties})、@EnableApolloConfig、@EnableScheduling、@EnableIsolateComponent
  • Kafka Consumer：netease.kafka.consumer.enable=true、groupId=netease-antispam-collect、concurrency=4；生产者 netease.kafka.producer.enable=true
  • 内置 YidunQosApplication（collect/configruation/YidunQosApplication，@QosRegister）提供 Qos 限流
  • app.id=antispam-bill_collect；main() 仅 run；启动钩子：未发现

scheduler（有启动类，不构建） ​

  • 启动类：com.netease.is.antispam.bill.scheduler.SchedulerApplication
  • @SpringBootApplication、@EnableElasticJob、@EnableRecoverComponent、@EnableBusinessClient、@EnableConfigurationProperties({BillPlatformProperties, BillStatProperties, BillCacheProperties})、@EnableApolloConfig、@EnableEventClient（mplatform-event）
  • 任务：40+ @ElasticJobConf，如 amountBillWorker、chargeDailyWorker、monthlyBillWorker、billStatWorker、packageExpireWorker、fixNosBillWorker 等，elastic.job.<worker>.overwrite=true 大量声明
  • 内置 YidunQosApplication（scheduler/configuration/YidunQosApplication）；app.id=antispam-bill_scheduler；main() 仅 run

facade/http-api 与 console/api（有启动类，不构建） ​

  • com.netease.is.antispam.bill.facade.http.HttpApplication、com.netease.is.antispam.bill.console.api.ConsoleApplication：均无独立 Dockerfile，仅有 @SpringBootApplication 骨架与 application*.properties；启动钩子未发现。

五、启动前置依赖 ​

依赖配置键 / 地址阻塞 or 弱依赖配置文件
MySQL/TiDBspring.datasource.url=jdbc:mysql://tidb-cluster0-tidb.tidb.svc:4000/antispam阻塞（dubbo-provider）application-private.properties
ZK — Dubbo 注册中心dubbo.registry.address=zookeeper://zk-0.zookeeper.yidun-infra:2181?backup=...，group /yidun/antispam/online-new/yidun-antispam-dubbo阻塞application-private.properties
ZK — business.client（配置源）business.client.options.zookeeper.*（operateTargetTypes=PRODUCT,PRODUCT_CONFIG,TARGET,TARGET_CONFIG,TARGET_CHECKER）阻塞（配置读取）application.properties + application-private.properties
Apolloapp.id=antispam-bill_dubbo / antispam-bill_collect / antispam-bill_scheduler，apollo.bootstrap.enabled=true弱application.properties
Redis（Sentinel）spring.redis.sentinel.master=master01，spring.redis.sentinel.nodes=redis0-redis-ha.yidun-infra.svc:26379弱application-private.properties
Kafkanetease.kafka.producer.cluster.[default].bootstrap.servers=yidun-test-commonkafka01...（private 指向测试集群）；collect 另有 consumer弱 / collect 阻塞application-private.properties、application.properties
OSS（NOS）oss.client.instance-map.yidun-antispam.endpoint=nos-eastchina1.126.net（含 AK/SK）弱application.properties
云支付平台bill.platform.url=http://yidun-api.service.163.org，bill.platform.secret-id/key=1弱application-private.properties
ElasticJob ZKelastic.job.zk.*阻塞（scheduler）scheduler 配置

六、启动参数与 Profile ​

  • -Dspring.profiles.active：base 默认 dev；仓库含 dev/test/private/online/jiande-online/jiande-validate/test-validate；容器统一 private（Dockerfile ENV + k8s env）
  • maven profile：本仓库根 pom.xml 未自定义 profile，-P private 由父/平台 POM 提供
  • JAVA_OPTS：Dockerfile -Xmx512m -Xms512m -XX:+UseG1GC -Dspring.profiles.active=private；k8s 覆写 -Xmx1024m -Xms1024m -XX:+UseG1GC ...（resources limits 2048Mi 与之匹配）
  • base image 与镜像仓库：private-registry.nis.netease.com/library/base-image:jdk17；build.sh DOCKER_REPOSITORY=private-registry.nis.netease.com/yidun，产出 antispam-bill-dubbo-provider:base-250409；k8s 引用的是 private-registry.yidun.internal/yidun/antispam-bill-dubbo-provider:1.0.0.private（仓库与 tag 与 build.sh 默认值不一致，依赖 K8s 侧拉取策略/重打 tag）
  • build.sh 关键参数：MODEL_NAME=facade/dubbo-provider、BUILD_ENV=private、DOCKER_IMAGE_NAME=antispam-bill-dubbo-provider、DOCKER_IMAGE_TAG=base-250409、docker buildx build --platform linux/amd64,linux/arm64 --push（双架构）；buildAll.sh 固定 GLOBAL_ENV=private 并遍历 find . -name build.sh

七、启动期踩坑 ​

  1. 本仓库只有 facade/dubbo-provider 能出包：collect/scheduler/facade/http-api/console/api 有启动类与配置，但无 build.sh/Dockerfile，buildAll.sh 不会构建它们。
  2. scheduler 40+ 任务全 overwrite=true + ElasticJob namespace 跨环境共用 → 同一 ZK namespace 下多环境任务互相覆盖，改 cron 会串环境。
  3. collect/scheduler 缺 application-private.properties：两模块仅有 dev/test/online/jiande/test-validate 配置，一旦以 -Dspring.profiles.active=private 启动将取不到数据源等关键配置。
  4. private Kafka 指向测试集群：netease.kafka.producer.cluster.[default].bootstrap.servers=yidun-test-commonkafka01/02/03.service.163.org:9092，collect 的 supplier.monitor.kafka.bootstrap.servers 同样是测试集群。
  5. @EnableRecoverComponent 的 recover.config.recoverFileSizeLimitInMB=-1（不设上限）在失败重放积压时可能撑爆磁盘。
  6. 凭据硬编码：oss.client.instance-map.yidun-antispam.access-key/secret-key、bill.platform.secret-id/secret-key=1 直接写在 properties。
  7. 仓库/tag 双轨：build.sh 推 private-registry.nis.netease.com/yidun:base-250409，kubernetes.yml 拉 private-registry.yidun.internal/yidun:1.0.0.private，需人工对齐。
  8. dubbo.protocol.port=-1：dubbo-provider 随机端口，消费方必须走 ZK 注册发现。
  9. dubbo-provider 不用 @EnableApolloConfig：只靠 apollo.bootstrap.enabled=true + app.id=antispam-bill_dubbo 生效，apollo.bootstrap.namespaces=application（只有 application 一个 namespace，与 business 的 application,application.yml 不同）。
  10. 结果包名与部署名不一致：collect/scheduler 的 finalName 是 ${project.artifactId}-${project.version}-application（版本号内嵌），而唯一有 Dockerfile 的 dubbo-provider finalName=antispam-bill-dubbo-provider；若日后给 collect/scheduler 补 Dockerfile，COPY ./target/*.jar 必须按版本化命名。
  11. dubbo.consumer.retries=1 / timeout=10000：bill 消费端短超时 + 1 次重试，下游抖动会较快抛出，定时任务侧需依赖 @EnableRecoverComponent 重放兜底。
  12. bill.platform.secret-id/secret-key=1：private 用占位凭据直连 http://yidun-api.service.163.org，扣费链路在 private 实际不可用，验证计费只能看落库的 package_bill_record 而看水面账单。
  13. k8s 引用 2 副本而 Dubbo 随机端口：replicas=2 + dubbo.protocol.port=-1 决定了两个 Pod 端口不同，任何固定端口探测/网络策略都会失效，只能依赖 ZK 注册。

八、跨模块前置 ​

  • 配置源：依赖 antispam-business（Dubbo Provider + ZK /netease-antispam/online/config）—— 经 business.client 读取 Product/Target/Checker 配置，属启动期阻塞的配置读取，建议 antispam-business 先运行。
  • 运行期弱依赖：云支付平台（yidun-api.service.163.org / bill.platform.url）、yidun-message（套餐到期/超额通知，bill.platform.email-url）、mplatform-event（套餐变更事件，@EnableEventClient）。
  • 上游数据源：antispam-business-*、antispam-solution 等把用量消息投到 Kafka，本模块 collect 才能累计——它们不是启动前置，但未上线时账单为空。
  • 客户端插件：client 模块（PackageInfoCache/EventListenerPlugin）会被下游集成，套餐变更需通过它把缓存推给消费方。
  • 除此之外无其它业务模块硬前置。

相关：全局启动顺序 · 部署单元矩阵 · 踩坑速查

内部技术文档 · 请勿外传

网易易盾 · 反垃圾内容安全平台