XFORCEPLUS · DevOps Ontology Audit

销项(Seller)域重构调研报告

基于研发本体湖仓(ontoos-probe)对销项开票域的全量证据化探查:服务与仓盘点、依赖拓扑、数据库耦合、MQ 链路、配置真值与变更爆炸半径,最终形成七条工作流的重构方案。
调研日期 2026-09-14 探查方式 ultracode 工作流 · 13 agents · 801 次工具调用 数据源 ontoos 湖仓(ODS/DWD/DWS)+ Apollo + DMS 环境 14 namespaces / fat·sit·prod·ccag·lmt
52
销项相关仓库
133
K8s 工作负载
96.8亿行
sellerinvoice 主库
4-5
发票主表直写服务数
62%
MQ 发送侧不可见
33
athena 消费组衍生负载

一 · 现状全景

销项域实为三条平行产品线并存,规模与漂移同时存在

票易通销项开票域并非单一系统,而是三条平行产品线:① phoenix SaaS 线phoenix-seller 组 36 仓,MyBatis 访问 inv_seller_* 表,集中于 sellerinvoice 库);② taxware 票易通老线(jOOQ / T 系列表,按产品线分库 toi / litchi / tct / xtt,同名表 t_invoice 在 5+ 库独立存在);③ lmt / athena 旧线(独立实现:与 phoenix 线端点重合 1/632、MQ 通道共享 0/45、库零共享)。两线间经 RocketMQ(prod-taxware-standard-makeout-result)事件衔接。

部署层面:14 个 namespace 共 711 个工作负载,其中销项域约 133 个(fat 42 / sit 39 / prod 52,副本 43 / 58 / 131);另有 552 个无归属负载(94-local-crc 两环境 280、122-yango 78、janus 70 等本地化 / 客户环境)。42 个多环境可比仓中仅 2-3 个全环境同版本,fat 普遍超前或漂移。

三条产品线对照

产品线技术栈数据库代表仓与 phoenix 线关系
phoenix SaaSSpring + MyBatissellerinvoice(PolarDB)phoenix-seller/*(36 仓)
taxware 老线jOOQ / T 系列表toi / litchi / tct / xtt 分库taxware-*、output-invoice-serviceRocketMQ 事件衔接
lmt / athena 旧线独立实现issp(PolarDB 2529445)lmt-seller/*(8 仓)端点重合 1/632 · MQ 0/45 · 库零共享

环境分布与版本一致性

销项域工作负载按环境分布
数据源:dws.workload_active · 14 目标 namespace · 副本数含无归属镜像推测
0 50 100 150 prod: 52 负载 / 131 副本 prod 52 · 131 副本 fat: 42 负载 / 43 副本 fat 42 · 43 副本 sit: 39 负载 / 58 副本 sit 39 · 58 副本 其他(ccag/lmt/wmt/crc 等本地化): 34 推测负载 本地化* ≈34
* 本地化环境为 match_quality=none 按镜像推测的归属,包含 ccag-fat、lmt-prod/sit、p1099-wmt-prod、94-local-crc、122-yango 等。

版本一致性:42 个多环境可比仓中仅 10 个全环境同版本(模式为 sit≈prod 走 release 分支、fat 超前或漂移)。典型不一致:phoenix-seller-invoice(fat=8f75c2ab / sit=e589edf2 / prod=c4d0af8a);94-local-crc 两环境大量跑 2025 年旧版镜像(release-20250708 / 20251209),存在合规风险。

二 · 核心问题

十条重构动因,按严重度分级,每条附证据锚点

发票核心表族多写者直写,无 API 隔离

inv_seller_invoice / inv_seller_pre_invoice / inv_seller_invoice_item 等 6 张主表被 4-5 个服务同时 write+upsert,40 张表有 ≥2 个写者;phoenix-script-invoice 触及 238 张表(写 235)是域内最大写者,phoenix-seller-invoice 51 张全写;另有运维工具(unify-maintenance)旁路直写 15+ 张表。

证据:code_mybatis_table_refs × code_archive_components 按服务×表读写矩阵(TOP 30 表 + 共享写清单);共享数据源 7 服务连 sellerinvoice(prod)。

MQ 发送侧黑洞与双栈冗余

send 操作 1410 行中 62% invisible-dynamic(878 行):rocketmq 发送 209 条全部 <dynamic> 不可见,athena 系发送 100% 动态不可见(经 BaseMBListener / LoggedMessageService / SqsMessageService 封装);同时同一业务通道存在 rabbitmq + rocketmq 双栈双 listener。

证据:dws.v_mq_send_visibility 六态分布(invisible-dynamic 878 / closed 378 / orphan 146 / symbolic 8);v_all_mq_operations receive 4366 行五栈并存(rabbitmq 2380 / xplat-sqs 1098 / rocketmq 754 / kafka 119 / janus 15)。

athena-elastic-consumer 消费组爆炸

一个仓以 8 个分支衍生 33 个负载横跨 9 个 namespace,承接 canal / DTS binlog→ES 同步;消费路由靠 pod_label_branch 部署级隐式约定(bill 变体订 v4_bill_dts / phoenix-bill-shard,find 变体订 phoenix-invoice-master / shared-rds,rds 变体订 seller-invoice-rds-topic…),非配置显式声明。

证据:dws.workload_active 按 main_images 含 athena-elastic-consumer 过滤(33 行分布 9 ns);pod_label_branch × 订阅主题对照。

环境分叉与无归属负载堆积

42 个多环境可比仓中仅 2-3 个全环境同版本(sit≈prod 走 release、fat 普遍超前或漂移);94-local-crc 两环境 280 个负载几乎全无归属且跑 2025 年旧版镜像(合规风险)。

证据:workload_active 按仓×环境聚合 distinct sha 前 8 位;94-local-crc-fat 141 / 94-local-crc-prod 139 负载中 131+127 个 match_quality=none。

phoenix-seller-config 绝对枢纽单点 + 仓归属错组

被销项域内 8 仓 + 域外 4 仓(phoenix-bill / phoenix-casm-service / ant-coop-app / ant-coop-service)共 12 仓调用,819 条声明、跨 10 ns 部署,是全图入度第一的枢纽;且该仓归属在 xf-bm-xplat-msg 组(GitLab 建仓时间线显示为历史组织原因)。

证据:dws.v_deployed_spring_feign_clients 入度统计;gitlab_projects created_at 时间线。

边界强耦合与环依赖

phoenix-bill-service(域外计费域)与销项双向强耦合:590 行 Feign 声明、销项 5 仓调用、其自身回调销项 5 服务(bill.abandon.invoice / bill.red.invoice 等反向 MQ);存在 phoenix-seller-open-api ↔ source-bill-service 环依赖;13 条调用经网关目标不可见。

证据:Feign 声明 1777 行 / 102 组件 / 58 条仓级出边;最长链 4 跳出域:invoice-sharing→file→inventory→seller-invoice→bill。

代码级克隆与错误签名裸奔

『当前获取token出现异常』『查询终端信息失败』等 6+ 高频模板横跨 46-60 个组件——辅助类被复制进几十个镜像,单点修复无法收敛;seller-invoice 775 个 throw 点位中错误码仅少量覆盖。

证据:code_error_signatures 跨组件高频模板统计(225120 行中销项域筛选)。

定时任务幂等缺陷与迁移暂停风险

全 taxware-aggregation 仓 0 个 ShedLock 依赖,Spring @Scheduled 任务同时编译进 api / mq 两个部署体且生产多副本(如 13 个 pod 每分钟各执行一次);存在直接删数据的 Gc*Job(GcPreInvoiceDataJob 等 4 个)——重构迁移期必须先建立暂停清单。

证据:v_deployed_schedulers + pom_dependencies ShedLock 缺失 + 副本数对照。

湖仓可观测结构性缺口

核心前端 6 仓(seller-main-fe / seller-config-fe 等,承载 215 菜单 / 192 微应用)走 OSS 静态资产部署,代码结构零入湖;v_fe_to_be 的 fe_workload 全空(页面→后端只能反向匹配)。

证据:code_fe_packages 350 组件中销项域仅 20 个有镜像;portal_menus 215 / portal_micro_apps 192。

三条平行产品线并存,同步语义多套实现

taxware 老线(jOOQ / T 表 / 分库)与 phoenix 新线经 RocketMQ 事件衔接;lmt / athena 旧线与 phoenix 线端点重合 1/632、MQ 通道 0/45、库零共享——同步开票语义存在多套平行实现。

证据:Spring 端点(http_method + path 去重后 JOIN)、MQ 通道、数据库三组对照 SQL。

三 · 拓扑证据

同步依赖(Feign)与异步链路(MQ)双面证据

同步调用图

销项域 12 个仓共 1777 行 Feign 声明、102 个组件、58 条仓级去重出边。域内互相调用 825 行 vs 域外 952 行——边界依赖略大于域内。主要出口:计费(phoenix-bill-service / phoenix-casm-service)、进项订单(purchaser-order-service / purchaser-invoice-paas-service)、用户中心(phoenix-ucenter-service)、协同域(ant-coop-center)、税控(taxware,经 xforce-gateway 直连)。

Feign 依赖热点:出边 / 入度 TOP
数据源:dws.v_deployed_spring_feign_clients(部署位点,滤 repo-scope)
域外目标(销项出边)域内枢纽(被调用)
300 600 590 行声明 · 5 个销项仓调用(域外计费域) phoenix-bill-service 590 819 条声明 · 销项 8 仓 + 域外 4 仓调用(入度第一) phoenix-seller-config 819* 284~308 条声明调用销项(域外最重调用方) phoenix-bill (调用销项) ≈296 销项域内互相调用 域内互相调用 825 销项调用域外(总出边) 销项→域外 952 13 条边的目标 feign_name 未匹配到 K8s Service(多为网关路由) 目标不可见 13
* seller-config 的 819 为被调用声明总量(入度),其余为出边方向;未匹配 Service 的 13 条多为经网关(xforce-gateway)路由。

公网入口链(降级链路实测)

api.xforceplus.com 经 WAF(CNAME 接入)→ Internet ALB alb-y93dh70a7oer1krcm7/sales/*/invoicedata/*/config/* 等规则 → 后端 K8s worker ECS NodePort 32139;seller-open-api.phoenix 直接 CNAME 到另一 Internet ALB;seller-config 走内网 ALB;另有 AWS ELB 出口(seller-open-api-aws)——后端载体湖仓不覆盖。

变更爆炸半径(以两大核心为例)

核心服务部署版本调用线索方法节点DI 边爆炸半径最大入口
phoenix-seller-invoicerelease-2026081813,11488,042423abandon-and-reverse 系(85-87 sinks)
xplat-bill-enginefeature-dev5,63319,309790v2/external/order(144 sinks)、CycleBillRetryJob(140)

DI 扇入最广 Bean:seller-invoice 的 UserInfoHolder(33 注入方)、SellerInvoiceDataService(14);bill-engine 的 IPriceTenantService(29)、IOrderInfoService(26)。域内最大切面:phoenix-bill 的 BillCallBackAdapterAop(187 边 / 47 类,罩住 bill 全链)。

四 · 数据耦合

库规模 · 表所有权 · 共享写风险——重构拆分的最大约束面
销项生产库容量(PolarDB 实例,行数)
数据源:ods_current.dms_databases · store_capacity
50亿 100亿 72 表 / 7329.5GB sellerinvoice 主库 96.8亿 · 7.3TB 27 表 / 3917.2GB sellerinvoice shard01 55.2亿 · 3.9TB 64 表 / 4971.4GB bill 52.1亿 · 5.0TB 18 表 / 303.6GB rednotification 5.6亿 69 表 / 17.2GB sellerconfig 0.52亿

服务 × 表写矩阵(TOP)

服务触及表写表数说明
phoenix-script-invoice238235域内最大写者(脚本/批量通道)
phoenix-seller-invoice5151核心开票服务,全写
phoenix-openapi3627开放 API 入口
phoenix-red-notification1918红冲通知
walmart-sync-service1919沃尔玛同步
athena-elastic-consumer32binlog→ES 消费

共享写风险:6 张发票主表被 4 服务写(inv_seller_invoice:openapi write15 + script upsert3/write33 + seller-invoice write44 + walmart write7;同族还有 invoice_item / pre_invoice / pre_bill_detail / pre_invoice_item / pre_original_sales_detail);另有 6 张表被 3 服务写。共享库:sellerinvoice(prod) 被 7 服务声明连接、shard01 被 5 服务、bill 被 4 服务。K8s 层明文 JDBC 极少(274 负载仅 7 个),连接配置集中在 Apollo(24 app,快照 resolved 43%)。

五 · 异步链路

五栈并存 · 发送侧黑洞 · 消费组拓扑
MQ 栈分布(部署位点操作行数)
数据源:v_all_mq_operations 滤 repo-scope · 销项域 6 类镜像前缀收敛
rabbitmqxplat-sqsrocketmqkafkajanus/pubsub
1500 3000 receive 2380 行 / 155 通道 rabbitmq · 收 2380 receive 1098 行 / 303 通道 xplat-sqs · 收 1098 receive 754 行 / 145 通道 rocketmq · 收 754 send 788 行 / 30 通道 xplat-sqs · 发 788 receive 119 行 / 38 通道 kafka · 收 119 send 217 行 / 6 通道 rabbitmq · 发 217 send 209 行 / 1 通道(全部 dynamic 不可见) rocketmq · 发 209⚠

发送侧六态(v_mq_send_visibility)

1410 行 send 操作的可见性分布
invisible-dynamic 878 / closed 378 / orphan 146 / invisible-symbolic 8
invisible-dynamic 878 (62%) closed 378 (27%) orphan 146 (10%) invisible-symbolic 8 invisible-dynamic 62% closed 27% orphan 10% ⚠ 修好解析会表现为 orphan 上升——治理面板必须同时看 invisible 分布

消费管道拓扑(athena-elastic-consumer 衍生)

prod 按主题分组部署 10 个负载、总副本 24:phoenix-paas 分支(bill-consumer 3 / bill-shard-consumer 2 / invoice-master-consumer 3 / invoice-shard1-consumer 2 / rednotification-consumer 2)订 binlog 主题;phoenix-find 分支订查询主题(find 变体);phoenix-source-bill-canal 订 sourcebill。配套 canal-server / canal-client 基础设施遍布各环境(janus-prod 有 43 个 canal-* 负载)。athena 系服务的消费通道全部为孤儿通道——生产者(taxware 开票引擎 output-invoice-service、issp / 宝信金税接口、DTS / canal 基础设施)要么发送侧全部 dynamic,要么不在湖仓抽取范围内。

六 · 重构方案

总体策略 + 七条工作流

总体策略:以「数据所有权收敛」为主线、先治理后拆分——第一阶段建立资产清册与运行安全网(归属、监控、暂停清单),第二阶段收敛表写路径与 MQ 契约(消除多写者与发送黑洞),第三阶段再做服务边界重构(破环依赖、降枢纽、消费管道显式化),第四阶段产品线收敛评估(taxware 老线 / lmt 线的退役或合并决策)。每阶段有明确可验收产出,且以湖仓可观测补齐为贯穿性支撑。

WS1

资产归属与环境收敛

建立销项域权威资产清册(服务×仓×镜像×环境×库表),消除 552 个无归属负载中的销项盲区,收敛环境版本漂移。

  • 94-local-crc 版本差距清单 → 合规评审
  • 本地化镜像 registry 来源确认
  • 建仓归属修正(seller-config 归组)
WS2

数据库表所有权与写路径收敛

inv_seller_* 主表族收敛到唯一写服务,消除 4-5 服务直写与运维旁路写,为 sellerinvoice 大库拆分创造前置条件。

  • 6 张 4-写者主表 → API 化写路径
  • unify-maintenance 旁路写收编
  • 确认 DTS 双写切流状态
WS3

MQ 契约治理与双栈收敛

建立 MQ 通道注册中心,消灭 62% invisible-dynamic 发送黑洞,收敛双栈冗余通道,使事件契约可评估、断裂可监控。

  • rocketmq send 词表补齐(209 条)
  • 同业务双栈通道合并评估
  • 8 个无消费者 send 通道处置
WS4

消费管道重构

把「一仓 8 分支 33 负载」的部署级隐式路由改为显式配置驱动,控制单次消费代码变更的影响面。

  • 消费变体配置显式化(profile 声明订阅)
  • binlog 管道 schema 变更流程
  • ES 消费可观测(kafka group 实测)
WS5

服务边界与依赖重构

降低 phoenix-seller-config 单点爆炸半径,破除 open-api↔source-bill 环依赖,与计费域边界事件化。

  • seller-config 拆分(配置中心 vs 业务配置)
  • 环依赖解环(事件驱动)
  • bill 域回调改事件契约
WS6

代码质量与运行安全收编

公共库收编跨镜像克隆的辅助类,建立错误码基线,治理策略工厂与定时任务幂等/双注册,消除重构期运行安全风险。

  • 6+ 跨 46-60 组件克隆模板收编
  • Gc*Job 迁移暂停清单落地 xxl-job
  • ShedLock / 幂等键补齐
WS7

可观测与湖仓覆盖补齐

补齐静态抽取的结构性盲区(核心前端仓、fe_workload 回归、配置快照 unresolved、流水线数据),使重构各阶段有完整可对照的基线。

  • 6 个 OSS 部署前端仓入湖
  • include_pipelines 开关重抽
  • Apollo app↔workload 桥补 27%

七 · 快赢项

两周内可完成的低风险动作(checkbox 可勾选)

八 · 未决风险

证据不足、需进一步探查的点(重构决策的前置检查项)
#未决风险影响的决策
1DTS 迁移/双写切流状态未知:sellerinvoice__dts 库表明存在双写,无运行态证据确认是否已切流WS2 表所有权收敛
2rocketmq send 词表缺失:209 条 send 全部 dynamic;janus/mb-client 自研总线 201 条全不可见WS3 通道注册中心
3athena 队列真实生产者未确认:preInvoiceMake 等 40+ JMS 队列生产者推测为 taxware output-invoice-service(推测级)WS3 / 产品线收敛
4租户/行级隔离约定未证:phoenix-openapi、athena-elastic-consumer 与主服务写同一 sellerinvoice 库WS2 库拆分前置检查
5athena 8 分支各自消费主题需源码+Apollo 确认;kafka consumer_group 湖仓全空,广播 vs 单组需连 Kafka 实测WS4 消费管道
6552 个 none 负载的镜像 registry 来源未确认(独立 harbor 或离线导入),归属裁定无法自动化WS1 资产清册
7边界归属未裁定:inv_seller_invoice_bill_relations 等边界表归销项还是账单中心;phoenix-bill 是否「半成员」WS5 边界重构
8AWS 宁夏 ELB(seller-open-api-aws)后端载体湖仓不覆盖;lmt 私网 host 不在 ECS 台账入口链完整性
9lmt-prod 的 issp(PolarDB 2529445)与 20-phoenix 销项域是否共享底层表未做 code 层对照产品线收敛评估
105 个无 gitlab project 的 taxware 归档(tag-fallback 还原)provenance 可信度中等,表访问面需复核证据基线可信度

九 · 证据与方法

全部结论可溯源至 ontoos 湖仓 SQL;完整证据档案已随本报告保存在工作目录

调研方法

本次调研以 ultracode 工作流编排 13 个探查 agent(801 次工具调用、四阶段):①资产盘点(工作负载 / 仓库 / 数据库 / 配置 / 前端五维并行)→ ②架构探查(Feign 依赖图 / MQ 链路图 / 数据库耦合 / 定时任务 / 爆炸半径)→ ③验证整合(关键断言交叉复核 + 五项缺口补齐)→ ④方案综合(证据 → 重构工作流)。每条结论标注置信度(observed = 连库实测 / declared = 声明面 / 推测)。

核心数据源(探查表)

关键表 / 视图用途
K8s 部署dws.workload_active · k8s_containers负载×环境×版本×归属
代码归档code_archives · code_archive_components镜像→commit 溯源
同步调用v_deployed_spring_feign_clientsFeign 依赖图
异步链路v_all_mq_operations · v_mq_send_visibility · v_mq_channel_closureMQ 五栈 / 六态 / 闭合
数据耦合code_mybatis_table_refs · code_jpa_entities · dms_databases服务×表读写矩阵 / 库容量
调用线索code_call_threads · code_methods · code_di_edges · code_aop_edges爆炸半径 / Bean 扇入 / 切面
错误签名code_error_signatures高频报错模板跨组件分布
配置真值apollo_apps · code_config_snapshots · v_all_datasourcesApollo 24 app / 数据源清单
入口链dns_records · waf_domains · alb 规则公网入口降级链

随报告保存的产出物

路径内容
01-inventory/*.md五维资产盘点(工作负载 / 仓库 / 数据库 / 配置 / 前端),每条事实含 SQL + 行数 + 置信度
02-evidence/*.md架构证据(依赖图 / MQ 图 / 数据库耦合 / 定时任务 / 爆炸半径)+ 验证与缺口补齐
02-evidence/dossier.json完整结构化档案(13 agent 全部返回值)
03-analysis/refactor-plan.md/.json重构方案(现状 / 问题 / 策略 / 七工作流 / 快赢 / 风险)