大型ESB服务总线平台服务运行分析和监控预警实践( 二 ) _ESB服务

对服务传输的数据量及报文大小进行流控。
对服务本身的并发量进行流控。
对某个服务最大能够使用的资源量进行流控，防止单服务占满所有资源。

服务运行指标勾稽关系分析服务运行指标相关之间的关联分析是我们进行服务运行问题排查，异常告警问题根源分析的基础。在前面谈SOA治理管控平台中，我们曾经画过一个图来说明，服务运行过程中的基础物理资源，数据库和应用服务器中间件资源，服务运行KPI和SLA设置之间的关联关系，如下：

文章插图

基于上图，我们进一步做下扩展分析，先做下基本的关联关系判别：
JVM内存持续增加不释放，一个是服务并发量增加同时服务调用时间增长，其次是出现大数据量，长执行时间的服务调用，导致服务连接和内存无法快速回收。CPU使用率高升，但是内存利用率一般，一般为出现大并发量的服务调用，其次对于服务调用过程中有过多的数据映射，转换等处理导致CPU利用率增加。
服务调用运行时间长，首先要分析是否是原始服务本身调用时间就变长，如果不是，则一般是在ESB服务调用上出现大量长周期服务调用，但是连接不能快速是否，线程池满一直排队的情况。
如果JVM内存溢出，首先要通过Jstat工具监控下内存GC回收的情况，究竟是新时代，老生代，还是PermSize出现溢出。如果是PermSize需要进一步分析是否是程序本身有问题。
如果没有做流量控制，单个服务本身的大并发，大数据量调用往往会侵占所有资源，对整个ESB上其它运行的服务都造成性能影响。
对于ESB总线本身的等待线程数增加一定会涉及到内存持续增加，涉及到服务调用响应周期增加。如果是服务调用超时，则需要分析具体是在哪段引起的超时，是原始服务本身超时，还是在ESB中间件上进行服务处理的时候超时。
对于服务告警和预警，前面也讲到过，再强调下具体场景包括

服务单位时间运行次数明显增加，我们可以设置一个阈值，只要超过了就进行报警。
服务运行时间明显增加，我们可以设置一个阈值，只要超过了就进行报警。
服务单位时间数据量明显增加，我们可以设置一个阈值，只要超过了就进行报警。

注意对于服务告警策略可以是针对所有服务，也可以是针对某个具体的服务，对于阈值可以是一个百分比数，也可以是一个绝对值。接下来我们再看下服务运行各个指标本身之间的一些关联关系：

服务传递数据量大，一定带来内存增加
服务运行时长增加，同时更加容易引起服务调用超时。
服务调用并发量增加，服务调用时长一般也会增加，如果时长增加明显，则一定导致内存持续增加。单个服务本身的并发量增加，会引起ESB上线程排队增加，导致直接影响到其它服务调用性能。
单个服务调用本身的数据量增加，容易引起JVM内存持续增加，导致JVM内存溢出。
如果是后端服务本身性能下降，最明显的就是占有连接，资源不释放，导致ESB本身性能下降。

而对于整个ESB中间件的性能监控和分析，从最底层的IT基础设施，存储和服务器，到ESB中间件资源池，再到具体运行的服务运行包，相互之间存在密切的关联，需要达到的效果往往是第一时间反馈出预警。并且通过预警去采取后续的行动措施和SLA策略设置等。
1. 从资源池监控发现的CPU和内存异常第一时间找到非法调用服务？