业务问题：服务接口拓扑的校验
看起来，通过接口调用 metric 来串联调用链路是一种通用的方式，但是其生成结果显然存在如下的问题：
已生成的数据缺少校验方式。由于数据是业务方代码上报的，即使引入了通用的SDK，caller-func 信息也只能依赖于代码调用时主动传入。从实践经验来看，caller-func 的漏传错传问题比较明显。
调用关系校验、生成成本高昂。依赖业务代码上报，意味着代码需要遵循相当的规范。较为核心的调用链路，推动代码的变更相对容易，业务配合度较高。但非核心的调用链路或已经稳定运行许久的遗留项目，代码的规范化变更是较难推动的。而手动添加则需要对项目进行人工梳理，对于存在近千个调用的链路而言，没有实际操作空间。
上述两个问题是使用 metric 串联业务接口拓扑时常见的问题。
以滴滴可观测的实践来看，当核心链路的复杂度达到以千计的量级，即使有专门的团队推动业务调用链路的 metric 接入治理，也会有相当比例的调用关系缺失或者错误。
————————————————
版权声明：本文为CSDN博主「滴滴技术」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/DiDi_Tech/article/details/132893327