线上70%的问题都是因为它

超时，没错就是它，或又称为延时。

超时再细分，又分为DB超时，缓存超时，RPC超时。下面是一个统计分析图，尤其是RPC超时所占比重最大，这是因为分布式系统架构的思想已植根于每位程序架构者的思维，而RPC是分布式乃至微服务环境中不可或缺的一个因素。

为什么经常发生超时

现在处在一个各种分工的年代，打车可用用滴滴，吃饭可以叫外卖，寄快递可以用京东物流，需要依赖。系统分工下来也一样，存储数据需要数据库，提高响应速度需要用缓存，分布式结构化需要RPC调用等等。就连叫外卖还有可能因小哥路上堵车而耽误了呢。系统的环境也一样，网络带来了不确定性，还记得脑裂问题吗，在一个高可用的且有服务状态的系统中如果因为网络问题当正常通讯的多个节点之间突然断开，就会形成不再有通讯的相互独立的节点，比如我们常配置的MySQL主从复制，如果发生这种脑裂问题就会影响数据读取的准确性。CAP不能同时满足的最大的根源之一实际上也是网络超时造成的。

RPC调用的分类有多种，比如从通信协议层面看有基于http协议的调用，基于二进制协议的调用，更多的基于tcp协议的调用，以及还有单语言RPC(如RMI等)和跨语言平台的RPC(如google protobuffer等)，但无论哪种类型及是否跨语言平台，从RPC的调用链上看，网络都牢牢的把握住了客户端和服务端的联系，发送和接收数据都绕不开它。当然RPC的超时还有其它原因，比如序列化超时、服务端接口性能以及可能的服务端机器负载，甚至还有GC的耗时长短都会影响RPC调用。

我们如何做

加超时设置，报警阈值要调整得当。对重要同步调用需要分组线程池隔离，甚至分开部署，做到局部不要影响全部。需要深刻明白局部稳定不等于整体稳定，系统稳定也不等于业务稳定，比如举一个例子来说，有时候系统监控没有任何异常报警，可能你的监控只是应用层级的，说具体点就是Nginx或者Tomcat这个层面，如果因为服务商域名解析导致用户调用超时，原先现有的系统监控则没有办法监控到，会仍然认为业务运行良好，实际则只能干粑粑的等待用户反馈。当然这种情况可以结合其他方面规则监控一定程度避免。总之意识要清晰，对超时这类问题。

具体定位方法：(参考《架构修炼之道》第6章内容)

1.首先第一想到的就是要分析网络情况，看是否网络延迟严重，是否有TCP重传，TCP重传次数不能太大。

2.分析服务端和调用端的运行情况，看是否压力较大，比如cpu使用率，cpu负载，内存占用大小等。

3.看传输对象是否很大，很复杂，请尽量简单，这个对序列化有很大影响。

4.如果服务端有队列，试着减少队列，或者改为固定线程池，线程特别多，可以试试减少线程大小。

5.控制cpu使用率不要太高，尽量不超80%，不行该扩容就扩容。另外大部分业务都是I/0密集型，并非计算密集型。达到80%的时候一定注意负载是否有问题了，要么线程阻塞，要么就赶紧扩容吧。

6.有可能的话，可以以单次耗时为准，查看下单次耗时的差距，从而看看是否是某些参数的请求导致耗时比较长。

7.看看服务端是否有full gc，你懂的。STW。如果频繁yong gc也不是好事儿，无论yong还是full都会STW，只是耗时长短问题。如下图所示采样一天时间内的fg次数，这是一个比较正常的情况，但如果平均耗时较大肯定会响应当时的调用响应时间。

8.排除了以上种种因素，还没有定位到原因，那么就需要尝试如下方法了：可在服务端通过tcpdump抓包，用wireshark分析rpc请求在服务端耗时，定位是服务端还是调用端耗时长，然后进一步确定原因。

延伸

针对超时再延伸一些内容，就这次618备战过程中梳理出的几点内容分享如下：

1、 在代码review的过程中，我们对如何写一段好的的代码，仍然要缜密，比如，对方法粒度的控制上，如何做到小方法解决一个功能，粒度控制的不好。想对某一个单一的功能D增加ump监控，往往却包含了A、B、C功能。

2、 外部资源依赖等，这些资源的监控，还是有遗漏的，务须做到外部调用必有监控（包括DB、缓存、RPC等所有依赖资源）。

3、 日志异常打印信息不丰富，只输出了异常栈，当然比没有强的多了，但还是不够，我们需要把入参打印出来，让前后文信息丰富起来，才能更快的定位问题。

4、 Jvm的报警我们没有添加全面，比如GC次数报警，单位时间内GC次数报警过多肯定不是好事情，另外一次GC的时间也要关注。

5、 方法的报警我们没有添加全面，比如方法调用次数监控，以及时间粒度要做到1分钟的粒度，如果超过1分钟在遇到线上问题的情况下就是一个等待，这个成本太大，会对排查造成延迟。

6、 对可降级的点，我们梳理的，只能说，仍然不够到位。我们要的场景是这样，既然是应对措施，那么将来发生的问题，在我们的应对措施里面如果碰到，我们直接点击出去，降级就好了，达到一种这样的效果，当然后来都已经补充。

7、 大家对问题的敏感度，求知欲不强，线上一旦有风吹草动需要有足够的嗅觉意识，看到异常的蛛丝马迹需要纠个明白，比如性能突然上来又下去，需要考察背后的原因，不能只看看就了事。

8、 我们在架构升级和需求之间徘徊不定，像部署结构及拆解方案，我们也都之前有碰过，但需求永远是做不完的，每个人站在自己的立场考虑问题，也是正常的。但是咱们技术人员肯定要知道自己的真实情况，其实真有了必要改造系统的感觉的时候，可以每次迭代改造，比如10%这样的进度往前走。

9、 对线上问题处理的思路和方法，还是要持续锻炼，像ump它不仅仅是简单的一个让你看看tp99就好了，里面的对比查看，按机器维度查看，高级搜索条件使用，如何结合cap系统等，这些光靠培训只是让你知道而已，甚至培训的过程中知道的还不是那么贴切，还是需要大家积极的参与到值班，实际解决问题中，进行实际的操作锻炼。

毕业季两句话，上大学是为了什么？两件事情最为重要：一是掌握学习的能力，二是养成合作的习惯。--某位大咖

写文章就是要写文章，发的时间不分休息日和工作日，看到是一种缘分。--我说的 ?