00 · 目录
本文档结构
01 · 执行摘要
一张图说清楚
从 10 个超大仓到 19 个清晰域,本质上解决的是业务边界、数据边界、稳定性边界、组织边界的重新对齐。
核心判断
销项域已不是"微服务",而是 4 个超大型单体(phoenix-bill / phoenix-seller-invoice / phoenix-seller-config / output-invoice-service),通过 Feign + MQ 拼装为分布式大泥球。最严重的是 output-invoice-service 拥有 5475 个 API 端点但 MyBatis 抽取等于 0 — 真实的表结构、SQL 模式、调用矩阵完全不可见,这是定时炸弹。
核心后端仓
10仓
→ 19 自治域
最大单仓端点
11,596
↓ 至 ≤ 2,000
生产 db_id
35个
↓ 至 4 套角色
异构 MQ
6套
↓ 至 2 套（RMQ + Kafka）
业务表
47张
12,684 处 MyBatis 引用
盲区服务
1
↓ 至 0
BC Owner
3人
→ ≥ 15 人
周期
24月
治理 6m / 拆分 8m / 收敛 10m
销项域 8 大后端仓 · 端点与表引用分布
来源:ontoos-probe 2026-09-11 / 仓库:phoenix-seller/*, taxware-aggregation/output-invoice-service, pscc/*
02 · 现状诊断
7 大痛点(全部有数据证据)
2.1 超大型单体与级联雪崩
销项域已不是"微服务",而是 4 个超大型单体。phoenix-bill 单仓 11,596 端点被 5 个仓 / 387 个站点反向 Feign 调用 — 任何一次发布波及 5 个上游仓,灰度无法做到"功能级"。phoenix-seller-invoice 单仓 549 张业务表、18,116 处 MyBatis 引用,跨域访问、数据库自治彻底破缺。
2.2 数据库治理失控
35 个 db_id 持有 inv_seller_* 副本,横跨 4 套云 + 5 套数据库引擎(RDS / DRDS / PolarDB / Azure MySQL / AWS Aurora)。同一逻辑实体在异构库 schema drift 风险高;11 套生产库 = 11 套备份、容灾、慢查询治理成本。
2.3 异构 MQ 无收敛
6 套异构 MQ 通道分布
来源:code_mq_operations · 销项服务 MQ 操作(代码静态抽取)
6 套同时在线 = 6 套 SDK 维护 + 6 套监控 + 6 套告警 + 6 套容量规划,直接放大排障 MTTR 3-5 倍。其中 xplat-sqs 是公司老旧自研协议,跨 IDC 同步依赖网络通道,故障 RTO > 30min。
2.4 调用链爆炸
bill 387 站点 / 5 仓被调 + seller-config 282 / 8 + seller-invoice 238 / 4 — 推断单业务请求平均 5-8 跳。盲区服务 output-invoice-service 进一步让 Trace 拼接不完整,一旦线上故障无法定位到真实代码位置。
2.5 部署环境多套导致"同一服务四份资产"
ali-devops-prod (5+8) / qcloud-paas-prod (10+6) / local-crc-prod (4/2/2/2) / ali-pscc-prod (2) — 镜像 tag、Apollo namespace、网关路由在 4 套集群事实不一致风险高。
2.6 PSCC 跨"进-转-销"三态
purchase-resale-service 56 端点横跨 3 个 Bounded Context(进项 → 转销售 → 销项),复用 inv_seller_* 表 + 进项库直查,没有 ACL(防腐层),演进必然互相掣肘。
2.7 前端微应用碎片化
629 个销项相关菜单,分布于 198 个微应用,主前端仓 5 个(phoenix-seller-fe/seller-main-fe / seller-config-fe / ultraman-fe-monorepo / cc-biz-frontend-mono / mobile/one-main-fe)。一个开票业务变更往往要"后端 2 仓 + 前端 3 微应用"协同,发布协调成本 > 开发成本。
03 · 关键 KPI 基线
从数据出发,立指标
不立指标,24 个月后无法证明成功。下表是 2026-09-11 实测的基线值,作为后续对比依据。
3.1 规模 KPI
| 指标 | 基线 | Phase 1 末 | Phase 2 末 | Phase 3 目标 |
|---|---|---|---|---|
| 服务域总数 | 10 | 12 (+BFF+gateway) | 17 | 19 |
| 单仓最大端点 | 11,596 | 11,596(未动) | ≤ 4,000 | ≤ 2,000 |
| 单仓最大表数 | 549 | 549(未动) | ≤ 100 | ≤ 50 |
| 单仓最大 controllers | 80 | 80(未动) | ≤ 40 | ≤ 30 |
| 异构 MQ 套数 | 6 | 3 | 3 | 2 (RMQ + Kafka) |
| 生产 db_id | 35 | 35 | 20 | 4 (主+镜像+归档+海外) |
| K8s 集群数 | 4 | 4 | 4 (同源) | 4 (同源) |
| Apollo namespace | 6 | 9 (双写) | 19 | 19 + 1 公共 |
| 盲区服务数 | 1 | 0 | 0 | 0 |
3.2 业务 KPI(对用户的可见改进)
| 指标 | 基线 | 目标 |
|---|---|---|
| 开票事务首屏 P95 | 3-5 s(推断) | ≤ 1.5 s |
| 销项台账查询 | ~3 s | ≤ 500 ms |
| 开票失败自动补偿率 | 人工 | ≥ 90% 自动 |
| 销项到税控可追溯 | ~60% | 100% |
| 单功能发布涉及仓数 | 4-5 | ≤ 2 |
| 端到端发布频率 | 周 1-2 次 | 每日多次 |
04 · 目标架构
5 层蓝图:从接入到基础设施
10 仓 → 19 个清晰自治域:2 接入层 + 2 编排层 + 8 领域服务 + 4 平台服务 + 3 基础设施。
┌──────────────────────────────────────────────────────────────────┐
│ 接入层 (Edge) │
│ ├─ seller-gateway (Kong/APISIX 统一鉴权/限流/灰度) │
│ └─ seller-bff-aggregate (3 个 BFF, 按业务场景) │
├──────────────────────────────────────────────────────────────────┤
│ 编排层 (Orchestration) │
│ ├─ invoice-saga-orchestrator (开票 Saga) │
│ └─ pscc-orchestrator (PSCC 跨三态) │
├──────────────────────────────────────────────────────────────────┤
│ 领域服务层 (Domain) — 8 域 │
│ ├─ invoice-write / invoice-read (CQRS) │
│ ├─ invoice-state-machine (Cola-Statemachine) │
│ ├─ invoice-aggregation-svc (替代盲区) │
│ ├─ bill-core / bill-write / bill-read (账单域) │
│ └─ pscc-presale / pscc-resale (PSCC 域) │
├──────────────────────────────────────────────────────────────────┤
│ 平台服务层 (Platform) — 4 域 │
│ ├─ seller-config-platform │
│ ├─ notification-center │
│ ├─ smart-match-platform │
│ └─ event-bus-gateway │
├──────────────────────────────────────────────────────────────────┤
│ 基础设施层 (Infra) — 4 域 │
│ ├─ id-center / idempotent-center / audit-platform │
│ ├─ file-gateway │
│ └─ DB Proxy (PolarDB-X + Azure + AWS 适配) │
└──────────────────────────────────────────────────────────────────┘
BFF 黄金法则
BFF 自身不持有数据、不写 DB、不发业务 MQ(仅编排),错误全部以 Saga 事件上抛。代码量 < 3K 行 / BFF,启动 < 3s。3 个核心 BFF 按业务场景划分:
| BFF | 场景 | 聚合下游 | 端点目标 |
|---|---|---|---|
seller-bff-invoice | 开票工作台 | invoice-write + state-machine + config + match | ≤ 80 |
seller-bff-bill | 账单/销项台账 | bill + invoice-read + aggregation | ≤ 120 |
seller-bff-pscc | 进转销一站式 | pscc-core + invoice-write + config | ≤ 60 |
05 · 架构师方案
微服务拆分 / 合并 / 下沉
详细方案见 03-arch-refactor.md。本节为摘要。
5.1 拆分清单(10 仓 → 13 域)
| 源仓 | 动作 | 目标 | 拆分依据 |
|---|---|---|---|
| phoenix-bill (11,596) | 拆 | bill-core + bill-write + bill-read + 余下归并 | 销项相关占 ~70% |
| phoenix-seller-invoice (8,543, 549 表) | 拆 | invoice-write + invoice-read(CQRS) + state-machine + aggregation | 读写比 1:3, 写集中在前 200 端点 |
| phoenix-seller-config (6,657, 80 ctrl) | 拆+下 | config-biz + config-dict + config-rule → seller-config-platform | 三种语义变更频率/责任人差异巨大 |
| output-invoice-service (5,475 盲区) | 重建 | 新建 invoice-aggregation-svc | 不可在不可见代码上做"重构",需先 ontoos-code-probe 拉真实实现 |
| phoenix-seller-open-api (2,157) | 改 | 不拆,改为 OpenAPI 治理网关,接入统一鉴权 | 已是门面 |
| phoenix-red-notification (579) | 合 | 并入 notification-center | 通用能力 |
| phoenix-smart-match-invoice (474) | 合+下 | 并入 smart-match-platform | 多个调用方共用 |
| purchase-resale-service (PSCC) | 拆+ACL | pscc-presale + pscc-resale + 引入进-转-销 ACL | 跨三态 BC 必须显式防腐 |
5.2 平台化下沉
- seller-config-platform — 合并 phoenix-seller-config + 字典服务,80 controllers 拆开但统一 schema 治理
- notification-center — 合并 phoenix-red-notification + 短信/邮件/IM,销项只是 1/N 租户
- smart-match-platform — 合并 smart-match-invoice + 抬头匹配,多业务域共用
- event-bus-gateway — 6 套 MQ 适配器 + 死信中心 + 重放中心
06 · 数据治理方案
35 db_id → 4 套角色
详细方案见 04-data-governance.md。本节为摘要。
6.1 三维切分模型
切分键优先级:业务域 (domain) → 租户 (tenant_id) → 时间 (invoice_year)。
6.2 业务域切库(8 个独立库)
| 逻辑库 | 物理集群 | 现有服务 | 关键表(Top by 引用) |
|---|---|---|---|
seller_invoice_db | PolarDB-X-1 (cn-shanghai) | phoenix-seller-invoice, open-api | inv_seller_invoice 874, pre_invoice 619 |
seller_config_db | PolarDB-X-1 | phoenix-seller-config | 配置类表 |
bill_aggregation_db | PolarDB (cn-beijing) | phoenix-bill | 聚合/对账相关表 |
output_invoice_db | PolarDB (cn-shenzhen) | output-invoice-service ⚠盲区 | 销项汇总/下发(MyBatis 抽取=0 需先 ontoos-code-probe) |
pscc_db | PolarDB (cn-chengdu) | purchase-resale-service | PSCC 进/转/销三态表 |
notification_db | PolarDB (cn-hangzhou) | phoenix-red-notification | 通知消息表 |
smart_match_db | PolarDB (cn-beijing) | phoenix-smart-match-invoice | 智能匹配 |
seller_global_db | PolarDB (cn-shenzhen) | 跨域公共 | 字典/枚举/白名单(low-cardinality, 单库不分片) |
6.3 47 张 inv_seller_* 表冷热分层
Tier-1 高热度表(启用分片+冷热)
| 表名 | MyBatis 引用 | 分片键 | 冷热策略 |
|---|---|---|---|
inv_seller_invoice | 874 | tenant_id + invoice_year | 13 月热 + 归档 |
inv_seller_pre_invoice | 619 | tenant_id + pre_year | 13 月热 + 归档 |
inv_seller_pre_invoice_item | 507 | tenant_id + pre_year | 随主表分片 |
inv_seller_invoice_item | 479 | tenant_id + invoice_year | 随主表分片 |
inv_seller_operation | 398 | tenant_id + op_year | 6 月热 + 归档 |
inv_seller_make_out_request | 368 | tenant_id + request_year | 13 月热 + 归档 |
inv_seller_pre_original_sales_detail | 359 | tenant_id + pre_year | 随主表分片 |
6.4 DMS 100% 纳管 + 审计 + 脱敏
- 行级安全:仅本租户数据可见 —
CREATE POLICY tenant_isolation ON inv_seller_invoice USING (tenant_id = current_setting('app.tenant_id')::BIGINT) - 列级脱敏:身份证号、银行卡(
buyer_id_card走CONCAT(LEFT,4,'****',RIGHT,4)) - SQL 审核:所有写操作走 DMS 工单,命中风险规则需审批
- DDL 灰度:DMS OnlineDDL 内置 gh-ost,分批执行,秒级回滚
- 跨境数据:AWS-4.0、Azure、信创之间数据流动走 DMS 跨云同步通道,单独审计
07 · 稳定性方案
6 套 MQ → 2 套 · 全链路可观测
详细方案见 05-stability-middleware.md。本节为摘要。
7.1 MQ 双轨制(保留+桥接)
┌──────────────────────┐ ┌──────────────────────┐
│ 业务消息总线 │ │ 数据消息总线 │
│ RocketMQ 5.x │ │ Kafka 3.x (KRaft) │
│ - 事务消息 │ │ - Exactly Once │
│ - 顺序消息 │ │ - 长保留(30d) │
│ - 定时消息 │ │ - 镜像(MM2) │
└──────────────────────┘ └──────────────────────┘
▲ ▲
xplat-sqs / rabbit CDC / 审计
(桥接代理过渡) (直接走 Kafka)
7.2 异构中间件处置矩阵
| 中间件 | 操作点 | 决策 | 时间表 |
|---|---|---|---|
| xplat-sqs | 1549+609 | 桥接 → 2027-Q1 下线 | 2026-Q4 灰度 10% → Q1 切 100% |
| rabbitmq | 975+133 | 2027-Q1 下线 | 与 sqs 同步 |
| rocketmq | 420+80 | 保留主力 | 升级 5.x,Name Server 3 副本 + Dledger |
| pubsub | 157 | 收缩到 Azure 桥 | 2026-Q4 |
| jms | 147 | 仅税局接口 | 立即,不再扩展 |
| kafka | 58 | 保留为数据总线 | 升级 KRaft、副本=3、幂等 producer |
7.3 可观测性三大支柱
- Tracing:SkyWalking 为主(国产中间件原生支持),Jaeger 辅;跨 MQ header 注入
sw8TraceID,采样率核心链路 100% / 后台 10% / 健康检查 0% - Metrics:Prometheus + VictoriaMetrics 长期存储;RED 指标覆盖 8 核心仓;USE 指标覆盖 DB/MQ/JVM
- Logging:EFK(主) + Loki(聚合)双写,统一 logback-spring.xml 格式,保留 7d 热 / 30d 冷 / 1y 归档
7.4 SLO 体系(核心交易)
| 服务 | 可用性 SLO | 关键接口 P99 | 错误预算(30d) |
|---|---|---|---|
| phoenix-bill | 99.95% | ≤ 800ms | 21.6 分钟 |
| phoenix-seller-invoice | 99.9% | ≤ 1.2s | 43.2 分钟 |
| phoenix-seller-config | 99.95% | ≤ 200ms | 21.6 分钟 |
| output-invoice-service | 99.9% | ≤ 2s | 43.2 分钟 |
| phoenix-smart-match-invoice | 99.5% | — | 216 分钟 |
| phoenix-red-notification | 99.9% | — | 43.2 分钟 |
| phoenix-seller-open-api | 99.9% | — | 43.2 分钟 |
| purchase-resale-service (PSCC) | 99.5% | — | 216 分钟 |
7.5 盲区服务补救
⚠ output-invoice-service MyBatis 抽取 = 0
5,475 端点 / 47 controllers 真实表结构不可见。补救方案:
- 用
ontoos-code-probe检出真实 commit,做 AST + ripgrep 分析,覆盖率 2026-Q4 提升至 80% - 用 jvm-sandbox / arthas 在生产录制 24h 真实 SQL,补充动态 SQL 场景
- 立即 freeze(只修 bug),禁止新功能,新功能在新服务
invoice-aggregation-svc写 - 2027-Q1 抽取覆盖率 ≥ 95%
08 · 优先级矩阵
20 项举措 · 业务价值 × 实施难度 × 风险
优先级公式:Priority = 业务价值 × (1 + 实施难度^-1) × (1 + 风险^-1),分数越高越优先。
| 排名 | 重构举措 | B | D | R | Priority | Phase |
|---|---|---|---|---|---|---|
| 1 | 盲区真相补全 (output-invoice-service) | 5 | 2 | 5 | 19.5 | P0 |
| 2 | BFF 旁路上线 (seller-bff-invoice) | 5 | 2 | 3 | 16.0 | P1 |
| 3 | MQ-Bridge 上线 (sqs/rabbit → RMQ) | 5 | 3 | 4 | 15.6 | P1 |
| 4 | Trace/Metric/Log 统一 (OTel) | 5 | 3 | 3 | 15.0 | P1 |
| 5 | Sentinel 全量入口限流 | 4 | 2 | 3 | 13.3 | P1 |
| 6 | Apollo namespace 拆分 (6 → 19 + 1) | 4 | 2 | 2 | 12.0 | P1 |
| 7 | DMS 100% 纳管 + 审计 + 脱敏 | 4 | 3 | 3 | 12.0 | P0-1 |
| 8 | schema 漂移检测 + Schema Registry | 4 | 3 | 4 | 12.0 | P1 |
| 9 | seller-config-platform 拆分 | 4 | 3 | 3 | 12.0 | P2 |
| 10 | CQRS 读写分离 (invoice-write/read) | 5 | 4 | 4 | 11.9 | P2 |
| 11 | notification-center 收编 red-notification | 4 | 3 | 3 | 11.7 | P2 |
| 12 | invoice-state-machine 上线 (Cola) | 5 | 4 | 3 | 11.5 | P2 |
| 13 | phoenix-bill 拆分 (bill-core + write/read) | 4 | 4 | 4 | 10.5 | P2 |
| 14 | PSCC ACL + pscc-orchestrator | 4 | 4 | 4 | 10.5 | P2 |
| 15 | 冷热分层 (Tier-1 七张主表) | 3 | 3 | 4 | 10.0 | P2 |
| 16 | invoice-aggregation-svc strangler | 3 | 4 | 4 | 8.6 | P2 |
| 17 | DB 双写迁移 (M3-M6) | 4 | 5 | 5 | 8.4 | P2-3 |
| 18 | MQ 收敛 (6 → 2 最终态) | 3 | 4 | 4 | 8.6 | P3 |
| 19 | 跨云切换 (AWS→Azure→信创) | 3 | 5 | 5 | 7.5 | P3 |
| 20 | 老 10 仓退役 | 2 | 4 | 4 | 6.0 | P3 |
关键解读:Top 5 全部是"非破坏性"动作(补盲区、引 BFF、桥接、可观测、限流),先做这五项 0 风险获 80% 业务价值。
09 · 24 月路线图
Phase 0 → 1 → 2 → 3
不立指标,24 个月后无法证明成功;不排阶段,团队永远在救火。
Phase 0 · 准备期
真相 + 治理基础
W1-W2 · 2 月
- ontoos-code-probe 拉取 output-invoice-service 真实 commit + 47 controllers SQL 地图
- 47 张 inv_seller_* + 549 张表全量入 OntoOS 湖仓
- 11+ 套生产库 + 35 db_id 全量入 DMS
- 任命架构治理小组(1 主架构 + 3 BC Owner + SRE 平台)
- 基线快照实测,7 大类应急 Runbook 文档化
- Schema Registry 选型与 PoC
完成标志 盲区不再是黑盒、35 db_id 可查可控、Runbook 全员培训、基线指标实测落表
Phase 1 · 治理期
平台先于业务
M1-M6 · 6 月
- MQ-Bridge 上线,sqs/rabbit 首批 50 topic 收编
- seller-bff-invoice 旁路,前 50 高频调用收编
- OTel SDK 全量注入 + SkyWalking + Prometheus + EFK
- Sentinel 全量覆盖核心入口 100%
- Apollo 6 应用 → 19 namespace 双写兼容
- Schema Registry 接入,DDL 入湖
- output-invoice-service 抽取率 ≥ 80%
完成标志 80% 高频调用可观测 · MQ 6→3 · seller-config 100% 切流 · 通知准召率 ≥ 99.9%
Phase 2 · 拆分期
Strangler Fig 双跑
M7-M14 · 8 月
- phoenix-seller-config 归档只读
- phoenix-red-notification 归档
- invoice-write/read 物理分离 + CQRS(Debezium CDC)
- invoice-state-machine(Cola)上线,398 处引用收敛
- invoice-aggregation-svc strangler 替代 output-invoice-service
- phoenix-bill 拆 bill-core + write/read
- pscc-orchestrator + ACL 完整上线
- 切流大爆炸:6 个核心域同时灰度
完成标志 10 仓→19 域 · 主链路 ≤ 5 跳 · 100% 走 CQRS · PSCC 三态物理隔离
Phase 3 · 收敛期
同构化 + 全面收口
M15-M24 · 10 月
- MQ 收敛 6→2(RMQ + Kafka),老 SDK 全量移除
- DB 收敛 35 db_id → 4 套角色
- K8s 同源:4 集群镜像同源,Helm Chart 100% 复用
- 跨云切换:AWS→Azure→信创 + DR 演练
- 前端收敛:198 微应用 → 5 中台 + N 业务壳
- 冷热分层:13 月热 + 36 月温 + 3 年+冷
- 老 10 仓退役
- 19 域稳定性运行 90 天验证
完成标志 19 域稳定 90 天 · 老仓 100% 退役 · KPI 全部达标 · RTO ≤ 15min / RPO ≤ 5min
10 · 团队组织
从 3 Owner 到 15+ BC Owner
10.1 现状盘点
| 责任人 | 现有负责范围 | 工作量风险 |
|---|---|---|
| gulei@ | phoenix-bill + phoenix-seller-invoice + phoenix-seller-config + phoenix-seller-adapter + purchase-resale-service(共 5 仓) | 严重过载 |
| yefei@ | phoenix-seller-adapter / output-invoice-service | 中等 |
| rongying@ | phoenix-smart-match-invoice + phoenix-red-notification | 可承受 |
10.2 目标"4+8+3"模式
平台 SRE 组
4Owner
config / notification / match / event-bus
业务 BC 组 A (销项核心)
4Owner
invoice-write/read/state-machine/aggregation
业务 BC 组 B (跨态/账单)
4Owner
bill-core/write/read / pscc-core
+ 编排组 3 Owner + 基础设施组 4 Owner + 架构治理委员会 5 名 = 22 名核心 Owner。
10.3 关键制度
- BC Owner 制度:每 BC 域必须 1 主 1 副 Owner,主 Owner 离职需 30 天交接;Owner 拥有发布权、变更审批权、SLO 制定权,背负 SLA、稳定性指标、技术债清单
- ADR 制度:任何跨域架构变更必须写 ADR(背景/选项/决策/后果),沉淀在 OntoOS 湖仓可被 ontoos-probe 查询
- 双 Owner 制度:平台域强制双 Owner(业务方 + 平台方),关键 owner 离职的应急方案:副 Owner 自动接管 + ADR 沉淀决策
- 轮值 SRE:每月 1 名 SRE 轮值 P0 故障响应,故障复盘必须 72h 内完成,改进项 3 周内闭环
11 · 风险登记册
20 项风险,4 级处置
#
风险
概率
影响
缓解措施
R1
output-invoice-service 真实实现比预估更糟糕
中
高
M0.1 ontoos-code-probe 必做;若真实表 > 800 涉及资金,直接 freeze + strangler 重建
R2
CQRS 读模型同步延迟导致业务看到旧数据
高
中
关键字段(状态/金额)走强一致旁路;非关键字段允许 ≤ 1s 最终一致
R3
跨域 Saga 补偿失败导致数据不一致
中
高
Outbox 模式 + 幂等键 + 72h 自动重试 + 人工兜底
R4
35 db_id 数据迁移导致业务中断
中
高
DB Proxy 屏蔽差异 + DTS 双写 + 每日 diff + DR 演练
R5
盲区服务 M0 未及时完成
中
高
强制 2 周内完成;超时即提升为 P0 阻塞;ontoos-code-probe 双轨验证
R6
PSCC 跨三态改造失控
中
高
显式 ACL 包 + 决策日志 + 跨域不允 > 2 跳 + 单独立项
R7
灰度切流期间回滚成本
高
高
特性开关(Apollo) + 蓝绿 1%→10%→50%→100% 每档 ≥ 7 天 + 影子流量
R8
跨云专线故障
低
高
双专线 + GTM DNS 秒级切流 + 跨云 binlog 双向
R9
关键 BC Owner 离职
中
高
强制双 Owner + ADR 沉淀 + 30 天交接
R10
多 K8s 集群同步发布失败
中
中
GitOps + ArgoCD + 镜像 SHA 锁定 + 集群差异 values-{env}.yaml
R11
BFF 引入初期调用链变深
高
低
BFF 端点合并 + 平台层批量接口 + Parallel Flux 并行化
R12
老 10 仓退役不彻底
中
中
读兼容保留 90 天 + 流量监控 + 0 流量后才物理关闭
R13
异构库 schema drift 未及时发现
中
中
Schema Registry + 每仓 DDL 入湖 + 漂移告警
R14
状态机引擎切换导致业务中断
中
中
Cola-Statemachine 灰度切流 + 状态字段双写 + 对账脚本
R15
第三方税局接口变更
中
中
channel-adapter 适配层 + 版本协商 + Mock 优先
R16
冷数据归档后查询延迟
中
中
历史查询 API + 中台缓存 + OLAP 引擎兜底
R17
SMS/邮件/IM 通道降级
低
中
通知通道多活 + 飞书兜底 + 模板分级
R18
Seata 性能瓶颈
中
中
自研编排器替代,TCC 仅用于资金场景
R19
数据合规(等保 2.0 / GDPR)
低
高
DMS 审计 + 跨境通道独立审计 + 季度合规检查
R20
重构节奏失控(团队疲劳)
中
中
季度回顾 + 节奏调整 + 阶段性庆功
12 · PSCC 跨三态专题
进-转-销三态 + ACL 防腐层
PSCC(purchase-resale-service,56 端点 + presale,1 端点)是销项域最复杂的跨态业务。
12.1 现状问题
横跨三个 Bounded Context(进项 → 转销售 → 销项),没有清晰的 ACL(防腐层),复用 inv_seller_* 表 + 进项库直查,任何一态失败需要人工 SQL 修复。
12.2 目标架构
┌────────────────────────────┐
│ pscc-orchestrator │
│ (Saga 编排 + 状态机托管) │
└─────────────┬──────────────┘
│
┌──────────┼──────────┐
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│pscc- │ │pscc- │ │pscc- │
│presale │ │resale │ │archive │
│(进项) │ │(中转+销)│ │(历史) │
└────┬───┘ └────┬───┘ └────┬───┘
▼ ▼ ▼
进项库 销项主库 归档库
(只读) (写) (只读)
12.3 ACL 包设计
com.xforceplus.seller.pscc.acl
├── PurchaseACL # 进项域 → PSCC 域字段转换
├── InvoiceACL # 销项域 → PSCC 域字段转换
├── ResaleACL # PSCC 中转态 → 销项态转换
├── DecisionLog # 跨域决策日志(审计)
├── IdempotencyKey # 跨域幂等键生成
└── VersionTranslator # 跨域版本/枚举翻译12.4 状态机托管(Cola-Statemachine)
┌────────┐ 预开票成功 ┌────────┐ 推送税控成功 ┌────────┐
│ 进项 │ ──────────→ │ 中转 │ ──────────→ │ 销项 │
│ INIT │ │ PRESOLD│ │ ISSUED │
└────────┘ └────────┘ └────────┘
│ │ │
│ 失败 │ 失败 │ 失败
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│ REJECT │ │ HOLD │ │ RED_INK│
│ 拒绝 │ │ 挂起 │ │ 红冲 │
└────────┘ └────────┘ └────────┘
12.5 PSCC 关键 KPI
| 指标 | 基线 | 目标 |
|---|---|---|
| 三态流转成功率 | ~95% | ≥ 99.9% |
| 三态平均流转时长 | ~4h | ≤ 30 min |
| 单据卡死率 | 未知 | < 0.01% |
| 跨域直查次数 | 200+/天 | 0 |
| 状态不一致率 | 未知 | < 0.01% |
13 · Anti-Goals
明确不做的事
- 不重写所有 controller — strangler + 双跑为主,仅改造最痛的 200 端点
- 不立即统一所有异构 DB — 优先 DB Proxy 屏蔽,物理收敛放到 Phase 3
- 不引入全新微服务框架 — 沿用 Spring Cloud Alibaba,避免技术栈分裂
- 不强制 BFF 必须由前端写 — BFF 现阶段由后端团队维护
- 不一次性切换 PSCC — PSCC 跨三态改造最复杂,Phase 2.7 单独立项
- 不引入 Seata 大事务 — 自研编排器为主,TCC 仅用于资金场景
14 · 配套工具
OntoOS 全家桶
| 技能 | 用途 | 使用阶段 |
|---|---|---|
ontoos-probe | 结构元数据查询、服务依赖拓扑、端点表引用 | 全程 |
ontoos-code-probe | 真实 commit 检出、AST 分析、调用链追踪 | M0.1 + 关键决策点 |
ontoos-dms-query | DMS 已纳管库 SELECT 取数 | M0+ 持续 |
ontoos-direct-probe | 中间件直连(Kafka/Redis/ES)排查 | 应急 + 治理 |
15 · 一句话总结
关键不是技术,是纪律
24 个月,3 阶段,19 域,0 盲区,2 套 MQ,4 套 DB 角色,15+ BC Owner,1 套 Helm Chart,100% 业务不中断。
五大关键成功因子
- 盲区先行 — 不消灭盲区,所有决策都是赌博(M0.1 必做)
- 平台先于业务 — config/notification/match/event-bus 四个平台不先做,后续 19 域一样是泥球
- BFF 作为缓冲 — 让前端不再"等所有仓",让后端不再"等前端"
- BC Owner 制度 — 没有 owner,19 域 = 19 个没人维护的小泥球
- 指标先行 — 不立指标,24 个月后无法证明成功
调研材料
- 01-asset-inventory.md — 资产盘点初稿
- 02-evidence.md — 多模态探查证据汇总
- 03-arch-refactor.md — 架构师方案(微服务拆分)
- 04-data-governance.md — 数据治理方案(分库分表)
- 05-stability-middleware.md — 稳定性与中间件统一方案
- 06-unified-blueprint.md — 统一重构蓝图 v1.0(终版)