谈服务运行问题排查(8.8)

对于ESB总线上注册和接入服务的问题排查，首先分为两类来谈，第一是出现服务运行故障的情况，即服务运行或调用失败的情况，第二类是服务运行缓慢的性能问题排查。

服务运行故障的情况

任何一个接入和注册到ESB上的服务，都经过了ESB总线和原业务系统，那么如果服务运行出现故障最可能的就是总线本身或原业务系统。要明白，即使时候原业务系统提供的原始业务服务出现故障，最终表现出来还是会是调用ESB服务总线上的服务运行失败。

第一步：确定基础的问题边界在哪里

当ESB服务运行失败的时候，首先就是要确定基础的问题边界在哪里？究竟是ESB出错了还是原始服务本身出错了，因此最简单的方法就是首先去测试和调用业务系统提供的原始业务服务，如果原始业务服务本身也报相同的错误，那么可以快速定位到是业务系统本身的问题，直接通知业务系统去解决即可。

还有一种情况就是调用ESB服务报错，但是调用原始服务本身是OK的。在这里首先要检查Soap Fault，Could not parse stream的错误，而直接调用原始服务又OK，如果出现类似这种情况，首先要检查原始服务提供处理的WSDL文件和我们当时提供的WSDL文件是否一致，包括Service，Port端口的名称，命名空间等，因为我们是基于WSDL结构契约先行开发，在OSB中导入的资源也就是提前下发的WSDL文件，如果WSDL文件本身出现不匹配，那么一定会出现上述问题。

第二步：排查是否是ESB总线到集成平台网络路由原因

首先对于这种情况，比较明确的就是能够在错误日志里面看到类似Connect Time Out的超时错误。因此当看到这个信息的时候首先要确定业务系统的原始服务本身是否可用，能否测试通，如果业务系统原始服务本身也是正常的，那么要检查ESB到业务系统的网络路由是否正常，是否是由于网络策略没有开通的原因导致无法访问或服务访问超时。

第三步：定位到ESB总线去排查具体的问题和原因

如果业务服务本身访问OK，WSDL契约格式也是我们下发得标准WSDL，同时网络路由也没有问题。那么这个时候就需要去排查ESB端封装后得服务哪里出现了问题。在OSB上进行代理服务封装的时候，实际上并没有增加太多的业务规则处理逻辑，数据映射，更多只是做简单的代理，增加了相应的安全校验拦截，日志记录拦截等。因此如果是ESB侧出现问题，可以按如下步骤进行检查。

1. 首先确定当前OSB总线，Weblogic Server和OSB Server本身当前的状态是正常的。

2. 检查Server本身的CPU，内存，包括App Server的JVM内存使用是否是正常的？是否出现内存溢出？

3. 检查当前的并发线程是否正常，是否出现了大量线程堆积和等待的情况，是否存在线程无法释放情况。

以上的所有检查一方面是要在Admin Console，OSB Console上进行，一方面是需要直接提取和查看OSB Server的运行日志，看下是否有相关的告警或Error信息，一般来说出现问题，首先就会在日志上面有所体现。

如果上述检查后仍然没有看到明确的问题，那么接着就需要进一步分而治之的分解排查，即需要对原来封装的OSB服务进行插件注释，如先去掉安全校验，日志拦截，先保留最基本的代理看是否有问题，如果没有问题再逐步增加相应的拦截器，来最终确定问题究竟出现在哪个组件上面。

服务运行性能问题的排查

对于服务性能问题的排查，大体思路和服务运行故障和问题的排查思路是一致的，只是具体关注的内容点上会有差异，确定问题边界，排除网络原因，分析OSB本身性能，分析服务运行次数，时长统计数据等仍然是最基本的性能问题分析方法。

第一步：确定基础的问题边界在哪里

同问题排查，首先要确定是原始服务本身性能慢，还是说服务接入和注册到ESB总线后，由于多了ESB总线一层导致了过多的性能损耗而使服务运行变慢。如果是服务本身性能就慢，那么就需要通知业务系统自己去优化和改进服务运行性能。

因此对于ESB服务总线的运行日志，我们一般会记录两个关键的时间消耗，一个是业务系统提供原始服务本身的服务运行时间损耗，一个是服务经过ESB后总的服务运行时间损耗。通过这两个时间能够很快速的确定究竟服务运行慢在了哪个地方？

第二步：分析网络性能影响

如果ESB中运行时间，业务系统运行时间本身都不慢，但是实际业务用户在访问的时候明显感觉到慢，那么更多的问题往往出现在网络环节。比如ERP系统将10M消息数据传递到ESB总线，往往都是在一个数据中心内部完成的，网络1000M带宽性能很快。但是如果客户端是接的无线网络，或者还是远程访问，那么要传递10M数据往往就需要花费更多的时间才能够完成。特别是遇到大数据量传递的服务接口的时候，一定要考虑网络带宽影响。

第三步：ESB侧的性能问题分析和排查

如果业务系统本身提供的服务不慢，而是ESB总线代理后服务运行变慢。那么就需要排查ESB总线本身的性能问题。在这里注意首先要排查ESB总线当前的CPU，内存，线程资源池，线程数，线程释放情况，JVM内存分配，JVM内存使用情况，堆内存回收情况，服务调用会话连接的占用和释放情况。

以上的所有检查一方面是要在Admin Console，OSB Console上进行，一方面是需要直接提取和查看OSB Server的运行日志，还有就是需要通过JStat等工具对实时的JVM内存情况进行跟踪。ESB上运行的接口服务最适合的就是大并发量，但是消息报文很小<100k的接口服务，如果对于1M以上的报文性能会出现明显下降，同时ESB本身的性能负担也增加，将大量消耗JVM内存。

对于两种情况会特别影响到ESB服务总线的运行性能

1. 长耗时的调用 ，一个服务本身运行输入和输出的消息量都很小，但是耗时很长，比如超过1分钟，那么在这60秒的时间这个连接是同步保持而无法释放的，因此在这种情况下会大量的消耗掉ESB总线的连接池资源，在连接出现不够的情况下，就会出现等待和排队的情况。

2. 大数据量调用， 如果服务调用中传递的消息数据量很大，再加上调用耗时长的话，对ESB服务总线的性能影响最大，一个是连接占用，一个是JVM堆内存占用，在这种情况下大消息报文占用的内存长时间都服务释放，JVM也无法进行垃圾回收或执行Full GC操作。如果大并发+大消息报文同时出现，那么很容易如此OSB服务总线上的类似PipeLine管道破裂或JVM内存溢出的问题。

对于OSB服务总线本身的性能调优，我在前面已经专门有文章谈到过，在这篇文章中不再单独说明。