导读：做性能分析听到最多的歪理就是，服务做水平、垂直扩容、分表分库、读写分离、XX中间件、资源静态化等等但是归根到底这些方案都是为了尽可能减少对数据库的访问以及堆栈的释放，提高数据库IO的读写速度和程序的运行效率。
系统都是逐渐演进的，一个系统在运行中必须是根据场景逐渐地提高优化性能。高并发就是对资源的节约的考验，这种考验除了更换优秀和先进的技术，优化架构，还在于从小处出发，对尽可能节约的资源进行节约。
而在一个系统的数据访问中，系统的瓶颈往往是来自于数据库，因此我们要尽可能减少对数据库的访问！
一、背景
最近一段时间粉丝可能留意到，技术号一直没有更新多少技术文章。因为近期都在做一直在做性能优化。
在业务模块在并发量起来以后，接口的性能瓶颈就愈发变得明显。
配置解析和函数路由服务接口性能堆栈分析
本篇主要针对配置布局资源文件过大，导致接口耗时过长问题分析解决。
二、日志链路追踪
排查性能如果从代码层面出发少不了堆栈分析，但是目前大部分服务都为了便于服务扩容、升级都做了微服务处理，日志分析排查免不了通过链路ID追踪日志《微服务分布式架构中，如何实现日志链路跟踪？》
▐ 链路追踪日志改造 - RPC接口
在《链路日志追踪》中提到通过restTemplate、Openfeign的形式访问其他服务的接口时，就会携带起始位置生成的traceId、spanId到下一个服务单元。但是没有详细实现，这里做下简单补充便于后面理解与使用。
阅读Spring-Web源码，对于远程接口的调用拦截可以实ClientHttpRequestInterceptor
拦截客户端 HTTP 请求。这个接口的实现可以注册到RestTemplate ，以修改传出的ClientHttpRequest和/或传入的ClientHttpResponse 。拦截器的主要入口点是intercept(HttpRequest, byte[], ClientHttpRequestExecution) 。
计算RPC接口耗时与日志记录，这样在做接口分析的时候可以针对性能较差、耗时高的接口有针对性性排查分析。
远程服务的接口性能暂时不做分析，目前很明确耗时：1528ms 应该存在很大的性能问题。
▐ 链路追踪日志改造- 传播线程变量
但是目前只统计出远程接口耗时是远远不够的，我们需要知道接口总耗时以及对堆栈分析才能精准定位到问题。
记录HTTP监控信息
这里需要补充下不是所有的接口我们都需要捕捉和统计分析，我们可以统一接口规范。如页面请求统一以/data/开头，RPC接口统一以/api/开头这样可以分别区分两则的统计信息，避免记录错乱。
▐ 链路追踪日志改造- 统计RPC调用次数
上面
