共计 1805 个字符，预计需要花费 5 分钟才能阅读完成。
导读：做性能剖析听到最多的歪理就是，服务做程度、垂直扩容、分表分库、读写拆散、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 调用次数
下面👆🏻的两处的解决目前也只能精确度到以后 HTTP 申请有哪些 PRC 接口申请？每个 PRC 接口申请耗时多少？作为外围服务不太会去关系业务服务的接口细节，如果须要针对 PRC 接口的主服务做提高性能剖析即可。
因而还须要提高统计出所有 RPC 接口的总耗时和次总次数。
通过“线程变量”传递 RPC 接口的申请的次数。记得先前有相似前途过服务之间的认证问题也是通过申请头传递。《Spring Cloud 中如何保障各个微服务之间调用的安全性?》
累计完申请数量持续传递上来，以此类推来统计 RPC 接口的申请总数
这里做了简略阈值限度，背景不难想到：如果一个接口频繁调用另外一个服务超过 20、30 次此时，咱们就应该思考服务之间数据同步或者映射问题。
所以在计算 RPC 接口的申请总次数加了阈值限度，若 RPC 调用次数超出范围则输入正告日志
▐ 链路追踪日志革新 – 链路日志统计展现
至于链路追踪日志的展现，本人应用就不必太关注图形化款式问题，这里倡议间接应用 Thymeleaf 模板引擎进行渲染展现，也就有了文章结尾的图片
三、总结
对于问题剖析咱们首先能遇到的总是一个较大的问题，在算法中咱们常会用分治算法。一言以蔽之：将一个难以间接解决的大问题，宰割成一些规模较小的雷同问题，以便各个击破。
回顾整个解决思路
- 微服务日志埋点解决，记录链路日志并统计
- 监听 HTTP 申请后，记录微服务服务之间 RPC 接口耗时
- 监听 HTTP 申请后，记录 RPC 接口深度(申请次数)
记录 RPC 申请总总耗时与总占比
至此算是实现了咱们做链路日志剖析的第一步：统计分析 HTTP 申请所触发的内部服务的性能耗费。
码农架构：专一于零碎架构、高可用、高性能、高并发类技术分享
原文地址：微服务架构 | 如何利用好日志做性能剖析？