转载本文需注明出处：微信公众号EAWorld，违者必究。
随着业务应用的持续发展，用户数量的增加，应用服务器无时无刻不在处理用户发起的请求。在高并发场景下（如商品秒杀，抢票等），大量的请求会涌入web服务器中。如何防止业务无法按用户预期提供正常服务的问题，提高用户的使用体验，是所有服务器中间件都要面临的挑战。提供应用在线率，出现问题快速解决，是提高用户体验的重要手段，应用高可靠性已经具有十分重要的意义。
应用高可靠有三大难点：
难点一：应用出现类冲突如何解决
比如，应用错误的引入了一个三方jar包的多个版本，或应用中不同的三方jar之中存在相同全限定名的类，这种存在的类冲突该如何解决。
难点二：应用运行时出现错误该如何定位
比如，请求响应过长，如何定位是数据库瓶颈，或是线程池沾满，或是服务器性能瓶颈。
难点三：应用黑盒，是否能够进行处理
比如，如何能够对整个应用环境进行监控，从各个维度进行服务器监控、应用服务统计、性能刨析。能够跟踪服务之间的调用流并提供清晰的视图来定位问题区域和潜在瓶颈。
本文将以运维的角度介绍如何解决普元应用服务器（PAS）在应用部署，运行时遇到类冲突问题，应用运行时出现问题如何定位，来保证应用运行时的高可靠性。
目 录
01 应用类冲突排查02 运行出错问题定位03 总结01
应用类冲突排查
类冲突本质上就是相同的全类名的类，在一个应用的类加载器链条中出现在两个以上的jar中，使得JDK层、应用服务器层、和应用层的类加载器，加载了不同版本的同名类，或分别加载了同版本的接口类和实现类，从而导致类的方法调用、强转的过程等过程中出现异常，导致类冲突问题。
下面将通过几个场景，通过普元应用服务器特性，排查与解决应用的类冲突问题。
场景一：检测应用潜在的类冲突
该场景中，当应用错误的引入了一个三方jar包的多个版本，或应用中不同的三方jar之中存在相同全限定名的类，这样会使应用存在潜在的类冲突，当程序调用冲突类的方法时，可能能回出现异常，影响业务访问，应用可靠性将极大受到影响。若问题严重时，可能导致应
针对此场景，通过使用PAS的类冲突检测特性功能，全面检测应用或与中间件是否存在类冲突。类冲突检测功能可以检测一个应用中所潜在的类冲突情况，将冲突的类和类所对应的jar包展示出来，同时生成检查报告并提供下载。
场景二：精准类冲突检测
此场景中，当应用运行期间出现如ClassDefNotFoundException、ClassCastException、NoSuchMethodException等异常时，这通常是应用中的某个类存在冲突。当应用的类加载器链条中出现在两个以上的jar中，使得JDK层、应用服务器层、和应用层的类加载器，加载了不同版本的同名类，或分别加载了同版本的接口类和实现类，从而导致类的方法调用、强转的过程等过程中出现场景异常，导致业务处理失败。
针对此场景，通过使用PAS的类资源分析功能，检测异常类，是否存在同名类而导致的错误。类资源分析功能通过一个类全限定名，检查应用，应用服务器和JDK之间，是否存在相同全限定名的多个类，来提醒用户可能存在潜在的类冲突。
场景三：调整应用类加载顺序
此场景中，当应用存在类冲突（即类全名相同的class分布在多个jar里面），无序的类加载可能导致某几次重启应用服务器，加载到错误的jar，导致加载到错误的类，引发程序运行错误，出现类冲突问题。
针对此场景，通过调整应用jar的加载顺序，解决特定场景下的类冲突问题。
PAS的WAR应用类加载器，支持两种类加载的顺序：
正向排序：按照文件名的ASCII码从小到大排序（默认排序规则）。
逆向排序：按照文件名的ASCII码从大到小排序。
场景四：排除加载应用的包
此场景中，当检测到几个jar中有类冲突问题的时候，或者需要临时不加载某些文件，需要应用服务器能够通过设置，来排除加载应用的某些jar包。
针对此场景，PAS可以针对独立实例或集群实例，将war应用中WEB－INF／lib中的jar包排除加载。当用户检测到几个jar中有类冲突问题的时候，可以通过设置将war中的WEB－INF／lib中的冲突jar排除加载，即WAR的类加载器不再加载被排除的jar包，这样能解决部分类冲突问题。
02
运行出错问题定位
服务在运行时，难免会出现内存溢出，服务无响应，服务响应时间过长等问题，当问题出现时，就需要运维人员及时了解系统、应用服务器、以及应用的运行时状态等信息，从而快速定位到问题的原因。下面将通过几个场景，通过普元应用服务器特性，辅助运维人员快速定位问题。
场景一：超长线程检测
此场景中，当客户端发起请求时，应用服务器给该请求分配一个线程来处理该次请求， 若服务内部出现故障导致请求处理耗时过长，在某些极端的场景下，大量的慢请求涌入服务端，导致线程池的工作线程被占满，后面再来的请求就会堆积在线程池的队列中，导致服务不可用。
针对该场景，通过PAS的长线程检测功能，及时发现耗时异常的业务，即时查找问题保证应用高可靠性。超长线程检测支持自定义阈值时间，当一个请求被分配线程后，线程的执行会被记录时间，当线程执行耗时超过设定的阈值时，会把超时线程的信息记录进日志中。
场景二：监控服务
此场景中，当出现突发系统性能问题或者系统故障，为尽快处理突发问题，需要了解系统、应用服务器、以及应用的运行时状态等信息，综合判断问题出现的原因。
PAS可以分别对集群的各个实例、独立实例以及域管理服务器本身进行监控。在开启了监控服务以后，可以获取各实例的系统、应用服务器、以及应用的运行时状态数据，并且将监控数据缓存并生成图表提供给管理控制台进行展示。PAS的监控服务支各个模块多种监控级别细粒度的控制，使我们能够很方便的查看监控信息，还支持展示一段时间内的历史监控数据，为分析系统性能提供了有利武器。
JVM 监控：包括内存监控，CPU 监控，FULL GC 信息和其他信息监控。
JDBC 监控：所有连接池的监控。
应用监控：包括 WEB 应用和 EJB 应用的监控。
通过监控服务可以实时显示当前系统运行时状况，判断是否出现性能问题，为尽早处理突发的系统性能问题或者系统故障做好准备。
场景三：自动内存快照
此场景中，当应用在运行时，可能因为应用并发访问量大或内存泄露等原因，造成JVM申请可用内存时，超过设置的最大值而导致程序崩溃。
面对此场景PAS自动内存快照功能可以实时监控PAS实例内存使用率，用户配置一个生成内存dump文件的内存使用阈值，当实例内存使用率高过设定阈值时，应用服务器会自动生成内存dump文件与线程栈文件，并通过预先设置好的javaMail资源，向运维人员发送告警通知。为了防止频繁生成dump文件拖慢整个系统的性能，用户可以设置一个最小生成文件时间间隔来保系统性能的稳定。
场景四：通过APM组件监控应用服务器
普元应用性能监控平台软件（Primeton APM） V6是普元信息技术股份有限公司推出的一款应用性能监控平台软件。Primeton APM V6可以协助用户基于中间件应用服务器进行应用性能分析，帮助用户更好的梳理系统拓扑。
针对中间件服务器上应用治理链路分析的困境，Primeton APM V6能够提供详细的数据协助用户了解应用全链路调用情况，服务器性能状况，可以完整显示链路请求中过滤器、EJB、JNDI、JDBC的调 用信息，协助用户查找性能瓶颈。针对目前广泛使用的国产数据库软件
Primeton APM V6也提供的监控能力，为用户后续数据库操作调优提供数据依据。Primeton APM V6依靠监控数据绘制系统拓扑图，展现中间件上应用服务的关联关系，按照接口列表的方式展现，追踪接口内部调用过程。
通过APM组件监控应用服务器－－应用监控
应用监控通过服务、端点两个维度，将监控信息汇总展示出来。
服务维度：服务维度是服务相关统计数据，包括服务请求响应时间，求成成功率，每分钟请求次数等数据。通过服务维度，可以展示应用的所有请求成功率和平均响应时间等数据。用户可以根据选择应用对查看的监控数据进行筛选。
端点维度：端点维度是应用中端点的相关统计数据，包括端点的请求数，端点请求成功率等。端点维度只会展示单个端点的请求的成功率和平均响应时间等数据。用户可以根据选择应用和服务，对查看的监控数据进行筛选。
通过服务和端点两个维度，可以直观的看到应用部署在PAS中间件后的访问情况，可以针对性的排查问题或者优化程序。
通过APM组件监控应用服务器－－数据库监控
数据库监控可以查看当前数据库的平均响应时间，访问成功率，慢查询等性能指标。当发现页面请求响应过慢时，可通过数据库监控，排查是否是数据库或sql存在问题所导致的。
服务器监控的主要信息：
1．数据库事件平均响应时间，单位ms2．数据库访问成功率，％为成功率的百分比。 3．数据库每分钟请求数，CPM为规定间隔时间内的相应请求量。
4．前N个慢查询，当sql语句执行时长超过设定值时，语句会被记录下来，方便运维定位到执行时间过长的sql语句。
通过APM组件监控应用服务器－－链路追踪
随着应用数量的增加，服务与之间的调用关系也变得错综复杂，当系统出现问题时，由于服务链路过长或过于复杂，无法快速准确定位问题。
通过分析链路追踪所记录的信息，可得到链路耗时、服务间的依赖关系等关键数据，通过结合业务日志，缩小判断故障范围，快速定位到出现错误的位置。
03
总结
上文主要通过八个场景，介绍了普元应用服务器PAS类冲突检测，类资源分析，类加载排除，超长线程检测，监控服务和自动内存快照等特性。
通过国产中间件，上述能力可以在应用部署时期，解决应用类冲突的一些问题。在应用运行时期，通过多方面的监控，了解服务器与应用的运行状态，即时发现并解决问题，保障应用高可靠性，从而保障应用的在线率，为用户提供优秀的使用体验
