谈服务运行监控-性能分析模型(8.10)

最近1到2周都在分析服务运行性能分析，特简单总结如下：

服务运行时长的分析

从服务运行时长分析入手，现在有最大时长，最小时长和平均时长，我们一般会先看平均时长，如果平均时长过长那么一般都有问题。对于平均时长过长原来我们没有筛选服务超时失败错误，这样的话对于超时的服务一般时长都是600秒，一平均下来这个值就很大。因此时长分析需要增加服务运行状态条件，只先分析成功运行的服务，如果平均时长过长，那么一般有问题。

定位到平均时长过长的服务，查询详细的服务日志实例，再查看每个服务的ESB耗时，原时长耗时，如果是大部分时间损耗都在源端业务服务提供，那么就继续分析耗时长的一些其它原因。

时长一般会和数据量有关系，因此还需要抽查长耗时服务本身消息报文的数据量，如果消息报文数据量比较大，比如>5M以上的报文，在1分钟调用完成往往也可能是正常的，如果消息报文小而耗时长，那么基本可以确定是源端业务系统有性能问题，需要进行性能优化。

平均时长正常，但是服务最大时长很大，而且是成功调用的服务，对于这种场景也需要分析。看是单次偶尔现象还是存在某种规律，比如用哪种查询条件查服务的时候响应就慢，导致的调用时长就长。即需要对最大时长的多条数据来出来分析，看下报文输入上有啥共同特征，来定位具体的时长损耗的问题点在哪里。

运行时长数据不孤立存在，需要和并发数，数据量三者结合起来一起分析，往往才容易快速定位可能存在的性能问题点在哪里。因此我们说的分析模型实际上主要体现在这三者之间。

服务A运行时长 = f(平台整体并发数，服务A并发数，数据量，网络带宽情况，时长基准值）

我们可以基于上面的模型对提取服务运行时长，整体并发数，该服务并发数，数据量的数据，然后进行回归拟合，以确定运行时长和以上数据之间的一个对应关系。当这个模型建立后，即如果实际的评价运行时长朝出了我们模型计算时长的某个阈值，我们才需要真正去监控和预警，并分析响应缓慢的原因。通过这种方式，可以大量排除由于短暂的大并发，大报文调用导致的短暂调用时长偏长的问题。

服务运行次数的分析

对于ESB平台往往逐步会转为服务实时调用模式，因此基于业务实时性要求，服务出现大并发调用往往是一种正常的情况。我们需要关心的还是在服务调用数据落地下导致的服务运行次数大量调用问题。这种问题注意包括了如下可能的几个方面：

1. 对于定时调用类进行数据同步服务，调用间隔过短，导致的性能问题。

2. 对于实时服务调用，调用方法不对（比如可以一批调用的而去循环调用等）。

3. 大量重复相同调用，而这类调用本身是可以在消费端进行缓存的。

4. 本身数据变化缓慢的基础数据，本身可以落地存储的，而采用实时调用的方式。

对于以上情况都需要进行重点分析，以找到可行的优化方法对大并发服务调用进行优化。除了以上外，我们最需要关心的仍然是在出现大并发调用后，服务调用时间和服务数据量之间的勾稽关系。

如果大并发调用，服务响应仍然很短，那么这类调用可以暂时不作为分析重点。时间响应短则代表连接和JVM内存都能够得到快速释放而不会产生大问题。

如果大并发调用，响应时间长，那么就必须关注，这个实际在服务运行时长分析的时候也会分析到。对于这类服务务必还要看实际的平均报文数据量，如果数据量也大，那么对ESB总线本身的性能影响是相对大的，很可能出现连接占满或内存溢出等各种情况。

而实际上对于上面这个场景，ESB总线并没有太多的优化方法，可以考虑的也就是对于JVM启动参数的优化，如增加JVM启动堆内存容量，启动并行垃圾回收，增加OSB上的最大并发线程数设置等。但是这些实际都不是解决问题的最好方法。

如果大并发，大报文的场景的场景真实存在，为了缓解ESB总线本身的性能和内存压力，最好的方法还是将同步WS服务，转变为异步的JMS消息服务。通过JMS消息解耦后，可以使得后端目标系统的压力得到快速的缓解，并通过排队方式来逐步释放并发压力给后端系统。

服务调用数据量分析

对于服务调用数据量，首先要有一个基准的数据，即调用时长和数据量之间的关系，调用时长和并发+数据量的关系。我们可以先在测试环境进行测试以获取一些基准数据值。

比如对于用户查询服务，当返回1000条数据(4M左右）耗时是5秒，而返回3000调数据时候(10M)耗时是10秒，在返回5000条数据的(20M)的时候耗时是50秒。那么我们可以大概建立一个数据量和耗时之间的关系，同时也会知道当调用数据量超过多少M的时候，往往会引起服务调用性能快速下降。

ESB总线往往并不允许大数据量调用，正是这个原因，我们往往会对大数据量调用场景进行分页处理，对查询类服务进行分页，每页最多1000条数据。对导入类数据也进行分页，每一批导入最多500或1000条数据等。通过这种方式来控制每次处理的数据量。

对于多层结构的业务对象，比如采购订单，往往复杂的采购订单一个订单就有2000个明细行，报文容量在5到10M的样子，对于这种业务报文往往已经是最小粒度单位，不能再进行分页处理，因此对于ESB服务总线往往也需要支持这种业务单据的导入。当然，为了减少这类大数据量，大报文调用对整个ESB服务总线的性能影响，我们可以考虑对这类服务单独起一个OSB域或容器来进行部署和发布。