转载

ESB平台性能和高可用性03(5.15)

高可用的基础是高可靠，而谈高可靠的时候重点是IT基础部署架构设计，数据库和中间件的可靠性保证，即不能有任何的单独故障，确保部署架构是高可靠的。其次高可用性更加强调的是在大并发，大数据量的访问情况下，整个IT基础架构设计仍然能够保证足够的高可靠性，而不是崩掉。

要解决这个问题当然是两个思路，其一就是对输入进行控制即我们常说的限流，包括对并发量进行限流，对大数据量的输入进行限流。对于OSB服务我们可以启用流量控制策略进行限流，对于JMS分发服务接口，我们可以启用JMS本身的数据量控制进行限流。

其二就是大并发，大数据量我们仍然放到中间件容器里面来，那么这个时候就需要考虑如何解决的问题？其中就包括了集群的动态扩展能力，缓存能力，目标端的快速响应能力，中间件启动时候JVM的内存规划和调优，线程池的规划调优和监控，连接的管理和快速释放等。这些都需要考虑进去，否则你很难真正应对大数据量和大并发量的访问场景。

对于JVM启动参数的调优

这个前面有专门的文章谈过，重点还是对于堆内存的设置不适合太大，太大了垃圾回收起来也是麻烦事，包括各类内存启动参数设置，回收机制设置等。这个设置不好在大数据量和大并发调用下将很容易如此JVM内存泄露，或者管道破裂的错误日志。

对于Log日志记录项和Debug参数项设置

在测试环境可以打开更多的Log日志记录项，也可以尽量打开Debug参数，但是在迁移和切换到生产环境后，在环境运行正常的时候，能够关闭的Log日志记录，Debug选项压尽量都关闭掉。以进一步的提升性能。

异常日志监控查询和分析

按道理对于大型的IT基础架构集群部署，除了Weblogic本身提供的日志查看能力以外，最好是能够单独启用一个日志采集和分析工具来进行日志的分析。简单来说当前的Weblogic OSB和JMS的Log日志分析文件，我们要打开用txt文本查看工具分析还是很困难的，快速的查找和定位到具体的异常和错误也不容易。

日志分析工具一方面是帮助我们快速的查找到具体的异常和错误日志信息。更加重要的是建立一种各个Server间的Log日志异常关联跟踪分析能力。举例来说一个服务运行异常，中间会经过Admin Server, OSB Server，JMS Server，Oracle DB等。那么正规错误链如何串联起来才是关键。比如表面看是一个服务超时问题，但是实际影响的根源如何快速定位才是关键。

原来Weblogic专门提供有一个Jrockit工具进行日志的分析和性能监控，但是当前最新的12c版本好像取消了，暂时不清楚具体的原因是什么。

从IT网管监控到业务监控

从最基础的硬件资源，中间件资源监控发展到业务监控是必然趋势。因为业务监控本身更加容易第一时间发现业务运行异常和故障，同时将问题快速匹配和定位到业务组件或业务功能。而不是等到数据库都已经出现问题还在反向追溯究竟是哪个业务引起的。

在当前APM应用性能分析工具来说，最重要的就是对于业务前端操作和调用，能够完整的监控到经过的各层关键组件，包括每层组件耗费的时间和错误异常信息。而对于涉及到OSB服务的时候，重点是在业务监控的时候能够监控到具体涉及到调用哪些服务，服务本身的耗时，也就是我们常说的在业务监控中具备了服务链监控的能力。一个业务响应慢能够快速的定位到究竟是哪个业务服务响应变慢导致的。

监控来讲本身应该分为三个层面，即：

1. IT网管类监控：监控当前的服务器，虚拟机，CPU和内存，IO，磁盘存储等是否正常。

2. 中间件监控：监控数据库，应用中间件本身的线程，Session，JVM内存，连接等是否正常。

3. 业务监控：主要监控业务模块或服务处理时间和耗时，监控具体的错误日志链，监控服务链。

对于OSB本身提供的性能和高可靠性能力

这个在前面的架构设计里面其实很多内容都已经谈到过，在这里再简单做下总结。第一是缓存能力，可以配置对查询类服务进行缓存，可以设置缓存失效时间。第二是重试能力，这个重试是在连接保持的情况下进行重试，可以有效的防止目标端业务系统网络闪断的情况。第三，对于JMS消息分发，配置为消息持久化机制，可以确保消息在中间件服务器宕机的情况下能够持久化到数据库或本地数据文件，确保消息数据不丢失。

流控能力在前面多次讲，在这里不再进行重复。

对于目标业务系统，如果业务系统本身没有提供负载均衡和集群，注意这个时候是可以在OSB上面配置多个服务地址的，同时OSB本身在发现服务地址A无法访问的时候自动进行故障转移去访问服务地址B。

原文 http://blog.sina.com.cn/s/blog_493a84550102xesn.html

正文到此结束