背景:
在现代大型互联网公司的微服务架构中,服务之间的调用关系错综复杂,往往会形成庞大的调用网(有向图)。近期安全团队发现核心的“支付网关(Payment_Gateway)”服务存在一个底层安全漏洞。为了评估漏洞的影响面,我们需要查出所有直接或间接调用过该服务的下游微服务。为了排除历史废弃链路的干扰,我们仅关注在2025年内新建立的活跃依赖关系。
表结构和字段说明:
-
表名:services(微服务信息表)
- service_id:整数类型,微服务的唯一标识ID,主键
- service_name:字符串类型,微服务的英文名称
- owner_team:字符串类型,微服务所属的研发团队名称
-
表名:service_dependencies(微服务依赖关系表)
- caller_service_id:整数类型,主调服务ID(即发起调用的服务/依赖方)
- callee_service_id:整数类型,被调服务ID(即接收调用的服务/被依赖方)
- first_call_date:日期类型,这两项服务首次建立调用关系并产生流量的日期
3. 问题
请编写一条 MySQL 查询语句,查询所有直接或间接依赖于服务名为'Payment_Gateway'的微服务,仅统计依赖建立日期(first_call_date)在2025年(包含2025全年)的调用关系。
要求返回以下字段:
- service_id:主调服务ID
- service_name:主调服务名称
- dependency_depth:依赖深度(直接调用Payment_Gateway的深度为1,间接调用依次递增)
- dependency_path:依赖路径(格式为Payment_Gateway->中间服务名->...->主调服务名)
排序规则:
结果须按依赖深度(dependency_depth)升序排列;若深度相同,则按主调服务ID(service_id)升序排列;若主调服务ID也相同(说明该服务通过多条不同路径依赖了目标服务),则按依赖路径(dependency_path)的字典序升序排列。
4. 示例数据表
services(微服务信息表)
| service_id | service_name | owner_team |
|---|---|---|
| 100 | Payment_Gateway | Core_Pay |
| 101 | Order_Service | Trade_Biz |
| 102 | User_Wallet_Service | Asset_Biz |
| 103 | E_Commerce_BFF | Frontend_Arch |
| 104 | Analytics_Job | Data_Tech |
| 105 | Legacy_Report | Data_Tech |
service_dependencies(微服务依赖关系表)
| caller_service_id | callee_service_id | first_call_date |
|---|---|---|
| 101 | 100 | 2025-01-15 |
| 102 | 100 | 2025-02-20 |
| 103 | 101 | 2025-03-10 |
| 104 | 102 | 2025-04-05 |
| 105 | 103 | 2024-12-01 |
5. 示例数据查询结果表
(注意:主调服务 Legacy_Report (105) 因为依赖建立日期是 2024 年,所以该分支的递归被截断,不出现在结果中)
| service_id | service_name | dependency_depth | dependency_path |
|---|---|---|---|
| 101 | Order_Service | 1 | Payment_Gateway->Order_Service |
| 102 | User_Wallet_Service | 1 | Payment_Gateway->User_Wallet_Service |
| 103 | E_Commerce_BFF | 2 | Payment_Gateway->Order_Service->E_Commerce_BFF |
| 104 | Analytics_Job | 2 |
Payment_Gateway->User_Wallet_Service->Analytics_Job |
