【小红书】使用递归 CTE 追溯微服务依赖链
JOIN 连接路径分析面试真题
题目描述
来源:小红书 SQL 面试真题
在大型互联网公司的微服务架构中,服务之间的调用关系会形成复杂的有向图。安全团队发现核心的 Payment_Gateway 服务存在底层安全漏洞,希望评估所有直接或间接调用过该服务的下游微服务。
为了排除历史废弃链路的干扰,只关注 2025 年内新建立的活跃依赖关系。
数据表
services 微服务信息表
| 字段 | 类型 | 说明 |
|---|---|---|
| service_id | INT | 微服务唯一编号,主键 |
| service_name | VARCHAR(100) | 微服务英文名称 |
| owner_team | VARCHAR(100) | 所属研发团队 |
service_dependencies 微服务依赖关系表
| 字段 | 类型 | 说明 |
|---|---|---|
| caller_service_id | INT | 主调服务 ID,即依赖方 |
| callee_service_id | INT | 被调服务 ID,即被依赖方 |
| first_call_date | DATE | 首次建立调用关系并产生流量的日期 |
业务规则
- 只统计 first_call_date 在 2025-01-01 至 2025-12-31 之间的依赖关系。
- Payment_Gateway 的直接调用方 dependency_depth = 1,继续向上追溯一层则深度加 1。
- dependency_path 从 Payment_Gateway 开始,沿依赖关系写到主调服务,格式为 Payment_Gateway->中间服务名->主调服务名。
- 同一微服务如果通过多条不同路径依赖 Payment_Gateway,需要保留多行。
输出要求
查询所有直接或间接依赖于 Payment_Gateway 的微服务,输出:
| 字段 | 说明 |
|---|---|
| service_id | 主调服务 ID |
| service_name | 主调服务名称 |
| dependency_depth | 依赖深度 |
| dependency_path | 从 Payment_Gateway 到主调服务的依赖路径 |
排序规则:
- dependency_depth 升序。
- service_id 升序。
- dependency_path 字典序升序。
数据样例
| service_idPKINT | service_nameVARCHAR(100) | owner_teamVARCHAR(100) |
|---|---|---|
| 1 | Payment_Gateway | Payment Team |
| 2 | Order_Service | Order Team |
| 3 | Checkout_Service | Checkout Team |
| 4 | Order_API | Order Team |
| 5 | Risk_Service | Security Team |
| 6 | Mobile_API | Mobile Team |
| 7 | Data_Orchestrator | Data Team |
| 8 | Legacy_Service | Platform Team |
输入数据显示 8 / 13 行
SQL 编辑器正在保存草稿...
Ctrl + Enter 运行
正在加载 SQL 编辑器...
运行你的 SQL 查询后,结果将显示在这里