接口性能优化的一些总结

微服务下，调用链追踪能很容易的定位到是链路上的哪个环节出现问题。从而确定是别人接口把你的拖慢了，还是自己接口内代码有问题；且调用链反映的是线上真实数据，比跑线下测试数据更有说服力。

这里以A->B->C举例，简单说一下调用链常用的几个参数：

• TraceID ：一个完整链路的唯一ID。本例中，TraceID是在A、B、C中传递的，ABC中记录的链路日志都用这个唯一的TraceID，不会变。
• BindingID ：一个线程内的ID。本例中，A记录的链路日志中，有唯一的BindingIDA，同样B、C中各有BindingIDB、BindingIDC
• ConversationID ：一个会话的ID。本例中，A调用B，A生成一个ConversationID，传给B，B在返回结果前，记下日志，A在收到结果后记下日志。这两条日志有唯一的ConversationID。
• VirtualPath ：用于标识微服务路径
• Component ：用于标识组件，或者微服务名称
• CostInMilsecond ：记录一次会话耗时。Client端发起前开始计时，收到后记入日志、Server端返回前记入日志。

明白这几个参数后，再看看具体使用。我们公司是用Kibana作为查询统计工具的。那么，我的分析步骤有如下几步：

1. 确定该请求的最长耗时（用于重点优化）、耗时中位数（用于全面优化）：

需要用到Kibana的Visualize功能，指定一个Metric为中位数、一个Metric为Max，再按照服务路径聚合即可. 统计其子链路耗时：

用Visualize可以统计出平均每个线程中，每个子链路的被调用次数、总耗时。然后看看在主链路耗时的占比情况。如果占比比较大，说明链路有问题了。比如我最近优化的几个接口，在链路上能看到数据库存储过程执行次数多且慢，那么肯定可以定位是数据访问的问题。

（编辑：宁德站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!