sip-mac · 交互式知识图谱

伊利 SIP 微服务单体仓（Spring Boot + Spring Cloud + Dubbo）。模块级粒度 + Dubbo RPC 服务调用网。点击节点查看详情；拖拽/滚轮缩放。共 157 节点 / 167 边。红色大节点=枢纽服务(hub)。

图谱统计

模块 Module66
入口文件 File22
契约接口 Class69
RPC 调用边58
Maven 依赖边5
包含/实现边104

架构分层 (7)

业务服务层 · 30 模块
承载具体业务能力的可部署 Spring Boot 微服务
RPC 契约层 · 14 模块
定义 Dubbo 服务接口的 -rpc 模块，解耦提供方与消费方
Model/DTO 层 · 10 模块
-model 模块，承载跨服务传输的数据对象与实体定义
核心公共层 · 6 模块
core-* 模块，提供缓存/云/枚举/ODS/工具等横切能力
SDK 层 · 3 模块
-sdk 模块，对外封装的客户端 SDK（如 auth-sdk）
集成/中继层 · 2 模块
-relay 模块，对接外部系统（TTS、COS 等）的中继集成
共享 Starter · 1 模块
multi-datasource 等多数据源自动装配 starter

枢纽服务 (高依赖, 共 6 个)

sip-mac-data被 21 个服务依赖
sip-mac-promotion被 7 个服务依赖
sip-mac-receive被 6 个服务依赖
sip-mac-data-relay被 4 个服务依赖
sip-mac-openapi被 4 个服务依赖
sip-mac-report被 4 个服务依赖

引导游览 (8 步)

1. 总览：66 模块微服务单体仓
这是一个伊利 SIP 项目的大型微服务单体仓，基于 Spring Boot + Spring Cloud + Dubbo。共 66 个模块（不含第三方 datavines），编译期 Maven 内部依赖极少，运行期通过 Dubbo RPC 实现服务间调用。从网关/聚合层到核心数据、业务服务、集成中继，形成清晰的分层。
2. API 网关与聚合层
sip-mac-openapi 是面向前端的 API 聚合入口，本身也是一个可部署服务。它消费 award-distribution、data 等多个内部服务，扮演网关/聚合角色，是理解系统对外边界的起点。
3. 核心数据枢纽服务
sip-mac-data 与 sip-mac-data-relay 是被最多服务依赖的枢纽（高 RPC 入度）。data 提供基础数据与编码库服务，data-relay 提供数据同步与 COS 公共能力。它们是整个系统的数据底座，理解它们就能理解大部分业务的依赖来源。
4. 业务能力服务
promotion（促销，769 个 Java 文件，最大业务模块）、activity（活动）、award-distribution（奖励发放）、auth（鉴权）、crs（CRS 业务）、aw（AW 业务）等是可部署的业务服务，各自对外提供 REST 接口与 Dubbo 服务。
5. 集成 / 中继层
code-relay、data-relay 等 -relay 模块是集成外部系统的适配层（如 TTS 语音、COS 对象存储）。它们被多个业务服务通过 Dubbo 调用，将外部能力封装为内部服务契约。
6. RPC 契约层与解耦
14 个 -rpc 模块定义 Dubbo 服务接口（如 RpcAwardService、RpcDataRelayService）。提供方业务服务用 @DubboService 实现，消费方用 @DubboReference 引用，编译期完全解耦，这是本仓能支撑 66 模块协作的关键设计。
7. Model/DTO、核心公共与 SDK
10 个 -model 模块承载跨服务传输对象；6 个 core-* 模块提供缓存/云/枚举/ODS/工具等横切能力；auth-sdk 等 -sdk 封装对外客户端；multi-datasource-starter 提供多数据源自动装配。它们构成可被各业务服务复用的公共底座。
8. 服务入口与启动
全仓 22 个 @SpringBootApplication 启动类，对应 22 个可独立部署的微服务。每个入口是对应模块的 pom.xml 所在服务的运行起点，配合 Nacos 注册与 RocketMQ 消息构成完整运行时。

三种架构形态对比

sip-mac 属于第 ③ 种：代码集中管理，服务独立部署，运行期靠 Dubbo RPC 解耦。

① 传统单体应用 Git 仓库 单体应用 (1 个可部署) 一个进程·一个包·一起发布 ② 微服务（多仓） 仓库 A · 服务1 仓库 B · 服务2 仓库 C · 服务3 每服务一仓库·独立构建部署 ③ 微服务单体仓 Git 仓库（单仓） datapromotionauthcrsopenapirelay 代码放一起·服务分开跑 › › sip-mac = ③ 微服务单体仓：66 模块同仓管理 · 22 个独立部署 · 运行期靠 Dubbo RPC 解耦

枢纽服务单点风险

少数模块被大量服务依赖 = 架构单点。一旦故障或变更，影响面按依赖数放大。

sip-mac-data被 21 个服务依赖红心 = 枢纽服务；外圈 = 依赖它的 21 个服务；箭头指向红心 = 故障沿调用链向上游传导

为什么危险

  • 爆炸半径大：sip-mac-data 被 21 个上游服务依赖，它一处故障 / 一次不兼容变更 = 全局波及。
  • 变更牵制重：作为共享底座，任何接口改动都需协调 21 方同步回归，迭代慢、出错概率高。
  • 容量瓶颈：所有读写汇聚点，流量高峰易成性能瓶颈，且难以独立扩容。

sip-mac-data 的 21 个真实消费者

sip-mac-authsip-mac-auth-sdksip-mac-awsip-mac-award-distributionsip-mac-codesip-mac-code-accessorsip-mac-code-relaysip-mac-crssip-mac-crs-asyncsip-mac-data-relaysip-mac-data-scopesip-mac-dmsip-mac-download-centersip-mac-gatewaysip-mac-openapisip-mac-promotionsip-mac-reportsip-mac-special-activitysip-mac-warnsip-mac_dcentersip-operation-log
其他枢纽同理存在单点风险：sip-mac-promotion(7), sip-mac-receive(6), sip-mac-data-relay(4), sip-mac-openapi(4), sip-mac-report(4)。治理时优先拆最高频、最稳定的读场景。

治理建议

  • 读写分离 / CQRS：把高频读场景从 sip-mac-data 拆出只读服务，核心写库减负。
  • 缓存化（Redis）：消费方 / 网关层加缓存，data 抖动时不直接雪崩。
  • 熔断降级（Sentinel / Resilience4j）：消费方对 data 的 Dubbo 调用加熔断 + 超时，快速失败而非线程堆积。
  • 拆子域：按业务域（会员 / 商品 / 订单…）将 data 拆分为多个专项服务，缩小爆炸半径。
  • 契约版本化：data 的 Dubbo 接口变更走兼容版本号，避免"牵一发而动全身"。