大规模微服务场景下的十大痛点问题定位与优化

有了流量染色的环境治理机制，测试环境数量就会小小特别多。

压测中一旦出现了慢请求，最先从哪里能够看出来呢。在微服务的接入层有API网关这一层。

在API网关中，有一个调用统计功能，可以筛选出慢请求。在压测的时候，每一轮都有一个压测结果，是一个列表，按请求时间排序。通过这个列表，可以筛选出这次压测的时候，最慢的接口都是哪一些，异常的接口(也即请求响应速度有巨大反差)有哪一些? 我们就可以针对于这些接口进行特别的排查。

在服务治理平台中，服务之间的调用也有一个统计，也有个一个排名，同样会列出来哪几个应用需要改进，重构，或者排查。

和压测匹配的一个重要的系统是全方位的性能监控。一般的监控平台仅仅会监控第一项就是服务器的性能，比如cpu，内存，网卡等。其实监控应该是全方位的，对于应用方面的，应该监控堆的内存，GC，线程，cpu利用率等。业务指标应该监控下单数，支付数，购物车请求数等。调用链路监控应该包括RT值，TPS等。应用组件应该监控连接的状态，消息积压，zookeeper节点数等。还应该有一些异常监控，例如异常的流量，Exception，报警等。这些都是在统一的一个平台上去做的。

定位问题需要深度的依赖于这个平台，一般先在这个平台上去找到大概的问题点，如果不能找到真正原因的话，就可以更加细粒度的登到机器上去看。没有统一的监控，会在大规模微服务场景下，有了问题，比较茫然，根本找不到地方。

有了统一监控平台，我们也在压测的时候，在API网关上发现了慢请求，接下来就需要逐层定位了。

高延迟的现象往往会先出现在应用层，外部的现象就是外部请求的时延高，如果顺着调用链定位下来，往往会反应到内部从一个服务集群到另一个服务集群的RT值高或者出现大量超时异常。

我们可以查看对于服务之间相互调用的监控，dubbo和hystrix我们做了集成，右下角的这个图是熔断的基本原理。通过监控我们可以发现有熔断的情况出现，我们就知道这可能是出现了问题。

一旦出现了问题，架构部一步一步来分析分析这个问题。我们的排查思路是从上层往下层，从业务层往底层层层排查，因为如果让物理网络或者虚拟网络直接去定位，会比较迷茫。

第一步：先应用层初步定位。

第一件事情，查看近期是否有新变更的发布上线，例如昨天压测的时候还正常，这次突然出现超时，很可能是新的发布导致的。

我们可以重点查看新发布的应用，甚至可以进行代码review。

如果新发布的应用没有发现问题，就需要在整条调用链路上定位问题了。这个时候应用性能监控APM可以帮上忙，他可以在整条调用链路里面，找到最耗时的那个环节，这是我们应该重点定位问题的地方。

在最耗时的环节上，如果我们发现TPS比较低，相应时间长，但是CPU使用率不高。

我们可以通过服务治理平台，查看这两个服务之间的调用是否开启了足够的线程池，当前的线程池是否已经被打满，如果满了，是否可以提高线程池的数目，这和集群所在的虚拟机和物理的核的分配是有关系的，因为核数用完了，再多的线程徒增调度成本，没有收益。如果可以提供线程池的数目，可以通过配置中心进行统一的配置这个服务集群的线程池数目。

很多情况下，性能的降低的原因在于数据库层，这一点在APM上也能看的出来。这个时候应该DBA去查看问题，可以梳理一下SQL语句，通过慢SQL分析，查看慢的原因，例如索引问题，死锁问题等，这些都可以通过Mysql或者DDB的日志找出来。

另外一个经常出现的问题就是TPS比较低，但是CPU使用率非常高。

这时候我们需要通过监控系统查看线程的状态，查看耗时的方法列表以及调用栈，看哪个线程耗时比较多，是否因为业务逻辑的Bug，是否在一直计算某个东西，或者出现业务层的死锁。

（编辑：云计算网_泰州站长网）

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