大型集团ESB服务总线平台建设项目高可用性实践总结（201021）

在前面我写过一篇关于非功能性架构和高可用性设计的文章，今天结合我们实际的ESB服务总线建设项目来继续谈下平台高可用性的建设实践情况。

最基础高可用-冗余无单点故障

部分内容无法发送，见头条对应文章。

解耦-平台组件拆分部署

部分内容无法发送，见头条对应文章。

整体四个功能组件拆分后的逻辑架构参考下图：

故障隔离和分域设计

部分内容无法发送，见头条对应文章。

服务运行高可用性和流量控制

对于服务限流熔断，我在前面专门写过文章可以参考：

微服务和API网关限流熔断实现关键逻辑思路

对于ESB总线的服务流量控制，实际上我们考虑两个方面的内容。其一就是不要因为大并发大数据量访问调用把后端业务系统压垮同时造成微服务里面的常说的雪崩效应；其次就是不要因为大并发调用导致ESB总线本身出现内存溢出等性能问题。

后端业务服务本身不可用或性能问题导致的资源占用

首先我们要考虑解决的就是后端业务系统本身性能问题导致的资源占用，简单来说就是后端业务系统提供的API服务Hang住。即我们建立了后端服务的请求和访问连接后，连接一直保持，但是后端服务一直不返回数据，或者返回数据的过程很慢。

这就会导致整个OSB服务一直处于线程占用，JVM堆内存持续增长无法释放的情况，在这种情况下往往很容易导致JVM内存溢出。如果多个服务部署在一个JVM容器，采用同一个连接池，那么一定会影响到其它服务的消费和调用。

上面实际上是两种场景，一种是服务查询本身可能耗时比较长需要等待数据返回，还有一种情况就是源端已经宕机我们一直在等待源端正常导致耗时很长。而我们看OSB服务封装中业务服务的设置可以看到两个不同的超时时间设置，这个设置信息很重要。

ESB服务总线往往并不怕大并发量的接口访问调用，而是怕长耗时，大数据量的接口服务调用，比如一个接口返回100M以上数据，这种情况1个接口往往就可以导致整个OSB集群宕机。

因此在OSB服务接入和设计的时候，必须要考虑两个时间的设置。

连接超时：是指连接到目标系统获取到可用连接的等待，如果超过则Connection Time Out

读取超时：读取超时即等待读取数据返回设置的超时时间，如果超过则Read Time Out

对于连接超时一般不用超过10秒，而对于读取超时一般最大也不要超过5分钟。个别大数据量查询或导入的服务可以单独设置长一点。

服务流量控制

单个服务大并发引起的性能问题有两种场景，如果服务本身响应很快，这种大并发访问ESB平台支撑是没有任何问题的，真正出现问题是大并发+大数据量，或者说大并发+长耗时访问。这两者情况一个是大量占有连接资源，导致新的请求无法获取到连接导致等待状态；一种是大量消耗JVM内存，导致堆内存无法及时释放和回收。

不论是哪种情况都需要对单个服务启用流量控制，流量控制策略本身可以是并发量，也可以是数据量，都可以设置不同的流量控制策略挂接到WorkManager项目。如果要启用流量控制，对于服务部署本身需要采用独立的WorkManager，而不是系统默认的一个通用Workmanger。

而我们实际在流量控制实现中，并没有专门使用OSB的Workmanger进行配置，而是单独开发了流量控制插件进行流量控制处理。

这种流量控制中，最有用的一个就是单位时间内的服务调用数据量大小，如果超过多少我们就禁用服务一个周期，然后再重新开发。其次就是对于超过20M的服务消息，我们直接中断服务请求，并返回异常信息给消费端。

通过这种方式可以更好的控制OSB集群中的JVM内存溢出导致整个集群宕机情况。

满足高可用性下的集群扩展

对于PaaS平台我们原来谈过有集群资源节点的动态扩展能力。

基本的实现思路就是健康检查Server会实时的监控集群中每个节点的CPU和内存负荷情况，当负荷在某个计算周期里面的超过我们预先设定的一个阈值，就触发资源弹性扩展操作。如果小于某个阈值，就进行资源收缩操作。

那么在一个高可用性架构里面的资源如何弹性扩展？

对于 Weblogic Cluster OSB 集群要实现这种扩展相对来说还是比较容易的，即首先准备好虚拟机，然后在虚拟机上进行通过模板复制的方式创建 OSB Server，再将 Server 挂接到 Admin 节点，同时还需要将 Server 配置到硬件负载均衡集群上面。

什么时候应该进行集群扩展？

如果仅仅是检测 CPU 和内存利用率往往容易引起误判，比如说某个服务本身非法出现大数据量的调用，这个时候出现内存负荷大增，但是处理方式却应该对这个服务进行限流。或者比如说由于后端系统本身异常，导致处理长耗时而带来 CPU 和内存利用率升高，这个时候也不应该去扩展集群。因此对于集群扩展完全动态并不一定是一个最好的方式。

而实际上是否需要进行集群扩展，更加重要的观察指标包括：

• 监控虚拟机资源池的 CPU ，内存利用率，监控 OSB Server 本身的 JVM 负荷情况。
• 监控服务运行并发次数，服务运行平均时长，数据量的增长量和变化趋势。
• 监控服务运行 ESB 时间损耗的变化趋势

以上信息需要经过综合分析和判断后往往才能够得出更加有价值的资源扩展方案。

从资源高可用到APM性能监控

首先对前面的内容做下总结。高可用的基础是高可靠，而谈高可靠的时候重点是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服务的时候，重点是在业务监控的时候能够监控到具体涉及到调用哪些服务，服务本身的耗时，也就是我们常说的在业务监控中具备了服务链监控的能力。一个业务响应慢能够快速的定位到究竟是哪个业务服务响应变慢导致的。

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

• IT网管类监控：监控当前的服务器，虚拟机，CPU和内存，IO，磁盘存储等是否正常。
• 中间件监控：监控数据库，应用中间件本身的线程，Session，JVM内存，连接等。
• 业务监控：主要监控业务模块或服务处理时间和耗时，监控具错误日志链，监控服务链。

通过JVM内存利用率监控优化流量控制

前面已经谈到，我们可以基于服务调用并发数，服务访问时长，服务调用的消息报文量等设置相关的限流熔断规则，然后进行服务限流和整体熔断处理，以确保ESB总线的可用性。而实际上这个往往是一个事后的处理操作，即使配置了限流熔断，往往仍然会出现OSB集群JVM内存溢出。

这种情况的出现实际我们分析后原因是大数据量的接口服务调用。

在出现一次类似超过100M的大数据量接口调用的时候，集群某个节点出现JVM内存持续增长，同时频繁的进行Full gc操作，但是堆内存无法降低下来。在这种时候Weblogic集群本身触发了故障漂移操作，这本身是一种很好的冗余和保护措施。但是在这种情况下，大数据量的请求或数据又漂移到其它节点，直接导致其它集群节点也陆续出现内存溢出和重启。

因此在这种情况下，真正最佳解决方案是持续对JVM内存利用率进行监控，当超过某个阈值的时候直接对服务进行禁用，如果我们无法区分出来究竟是哪个服务导致的，那么就应该直接对该节点上运行的所有线程进行终止，或者直接对该集群节点进行重启。

后端源业务系统出现故障

源端业务系统出现故障，实际上有两种情况，一种就是源端业务系统本身Hang，即仍然是能够接收ESB总线传递过去的访问请求，连接一直占有并保持，要到300或600秒超时才返回超时的错误。还有一直情况就是源端本身就不可用，比如端口本身就无法访问到了，这个时候会在<10秒内就报出连接超时的错误。

对于本身连接超时对ESB总线影响不大，即可以快速的得到源端的响应和返回，同时释放连接。而对于第一种Hang情况，则影响很大，并不是占有太多JVM内存无法释放，而是大量的占有Session连接池中的会话连接，将直接导致有新的服务调用请求无法获取连接的情况，即出现大量的新服务请求无法获取连接情况。

对于后端业务系统访问1-2秒，而整个ESB服务返回耗时>100秒甚至更长的情况，往往并不一定是因为内存原因导致，还是有用无法从可用连接池获取连接，导致进行排队引起。如果这个假设成立，那么重点就是在于如何快速的清理和释放出可用连接是关键。

对于ESB总线有一个总的连接池，比如2000，那么这个线程池是公有的，如果资源全部被长连接占用完毕，那么新请求就无法获取到新连接，导致耗时很长或连接超时。

当发现源业务系统出现不可用，有几种操作方式，一种就是对该系统提供的所有服务取消服务授权，提示服务处于不可用状态服务访问。其次就是直接将ESB集群中部署的服务禁用掉。对于第一种情况管控可以记录日志，但是对于第二种情况则管控服务记录日志。

那么能否是自动去检测后端业务系统服务，如果发现服务不可用，则自动禁用服务。当发现源服务恢复后，自动对服务进行启用，如果能够做到这种方式往往是一种最佳方案。