上一期，我们分享了Web应用接口级的故障定位方法，通过细化到接口级的定位方法，可以精准地过滤掉干扰因素。然而这种方法并不适用所有场景，过于细致的过滤有时会产生新的问题。
本文将以共享连接池故障场景为例进行说明，提出一种利用服务&接口双粒度动态拓扑进行故障定位的方法。
1 故障背景
-
**链路1：**service-b的callB接口 -> service-p的callB接口 -> service-h的callB接口
-
**链路2：**service-o的callO接口 -> service-p的callO接口 -> service-l的callO接口
其中链路1中的service-p的callB接口和链路2中的callO接口，共用了同一个Http连接池来访问下游不同的服务。
但是尽管如此，两条链路在接口级别上是没有交集的，如下图所示。
在这样的场景下，假如service-h的callB接口出现了故障，会有以下情况发生：
-
service-h的callB接口故障 -> 影响到 service-p的callB接口 -> 影响到service-b的callB接口
-
service-p的callB接口长期占用http连接 -> 共享Http连接池中的连接不够用 -> service-p的callO接口获取不到连接而等待 -> 影响到service-o的callIO接口
也就是说，尽管两条链路的接口调用没有交集，但是因为在同一个服务节点上共享了连接池的资源，链路1中的service-h服务出现故障会导致链路2中的service-o服务也出现故障。
此时，假如我们依照接口级根因定位的方法去分析链路2，就只能只能定位到service-p服务的callO接口。而真实情况是，链路1和链路2的故障根因都在service-h的callB接口。
既然接口级别的根因定位在这里无法准确定位，那应该怎么办？
答案：服务级拓扑和接口级拓扑动态结合。当接口级拓扑无法继续往下分析时，结合服务级拓扑找到答案。
下面案例中将给出具体方案。
2 实战案例
我们到RootTalk Sandbox上进行上述故障场景的复现。
RootTalk Sandbox是一个故障演练和定位的系统，可以进行多种故障场景的复现，目前开放注册。
2.1 故障注入
如上图所示进行操作，对拓扑图中的service-h::k8s 这个服务的所有实例的CallDB接口 注入耗时突增的故障。
注入后等待2~3分钟，可直接点击跳转到Databuff的故障定位平台。
2.2 故障定位
登录Databuff后可以看到完整故障树，如下图。
点击故障树底部节点，可以定位到接口。
从上面两张图中可以看到，入口服务service-b和service-o均出现告警，而根因节点都指向service-h服务，故障根因是service-h的callB接口的存在响应时间升高的问题。
我们再来详细看下对service-p服务的分析结论：
service-p的 callB接口和callO接口都出现了问题，是因为apache-httpclient_2这个共享连接池导致的相互影响。
点击页面中的链接继续下钻，可以来验证这一结论。
针对callB接口来说，客户端和服务端的平均响应时间均发生突变，一般是服务端的问题。
再看callO接口，客户端响应时间均发生突变，而服务端没有变化，这种情况可能是客户端或者网络的问题。
继续看callO接口的获取连接时间，发现耗时突增，说明连接池中的连接一直在被占用而被迫等待。
综上，我们可以得到明确的根因分析结论：
-
链路1和链路2的入口服务service-b和service-o均出现告警，故障根因是service-h::k8s服务中的callB接口存在耗时突增；
-
中间节点service-p服务上的callB接口和callO接口都出现了问题，原因是共享连接池apache-httpclient_2一直被占用而被迫等待。
这个结论和前面分析的场景以及注入的故障是匹配的。