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

　　在前面我写过一篇关于非功能性架构和高可用性设计的文章，今天结合我们实际的ESB服务总线建设项目来继续谈下平台高可用性的建设实践情况。
　　当前虽然微服务架构盛行，但是对于传统ESB服务总线平台仍然还是传统企业内部主流的系统间接口集成方式。类似我们做的集团ESB总线集成项目，整体高峰单日的接口调用实例量3000万，分钟级调用量超过10万次，仅OSB中间件集群节点就超过40个，可以算是相当大规模的一个ESB总线平台建设项目。
　　在传统的基于ESB进行的中心化集成架构下，整体ESB总线本身的高可用性架构设计就显得至关重要了，因此本文结合项目实践来谈下高可用架构设计和其演进过程。
　　平台建设背景：平台建设基于Oracle SOA套件搭建ESB总线平台，底层采用Oracle数据库，Weblogic中间件，X86物理机和虚拟机共用，IP SAN存储和NFS存储共用。因此整体非全部去IOE架构设计。高可用性三个维度和相互关系
　　对于业务系统的高可用性，实际上包括了高可靠，高性能和高扩展三个方面的内容。而且三方面相互之间还存在相互的依赖和影响关系。
　　对于三者的关系，我们可以用下图进行描述。
　　上图可以看到高可靠，高性能和高扩展性三者之间的关系。
　　对于高可靠性来来说，传统的HA架构，冗余设计都可以满足高可靠性要求，但是并不代表系统具备了高性能和可扩展性能力。反过来说，当系统具备了高扩展性的时候，一般我们在设计扩展性的时候都会考虑到同时兼顾冗余和高可靠，比如我们常说的集群技术。
　　对于高性能和高扩展性两点来说，高扩展性是高性能的必要条件，但是并不是充分条件。一个业务系统的高性能不是简单的具备扩展能力就可以，而是需要业务系统本身软件架构设计，代码编写各方面都满足高性能设计要求。
　　对于高可靠和高性能，两者反而表现出来一种相互制约的关系，即在高性能支撑的状态下，往往是对系统的高可靠性形成严峻挑战，也正是这个原因我们会看到类似限流熔断，SLA服务降级等各种措施来控制异常状态下的大并发访问和调用。
　　对高可用性的进一步理解
　　对于高可用性，可以看到最重要的就是高可靠性，类似HA和集群都可以实现高可靠性。但是高可靠性本身需要进一步考虑在大并发，大数据量访问下仍然具备高可靠性。这就会从传统的IT基础设施的冗余架构演进到应用层的高可靠性设计。
　　其次，在高性能要求下你可以通过资源扩展来解决性能问题，但是整个扩展和解决过程本身不能影响到高可靠性，需要能够支撑动态弹性水平扩展，而不是停机中断。
　　在谈CAP原则的时候，我们经常会谈到AP和CP的选择问题。
　　即如果把AP高一致性也划归到高可靠性范畴里面，可以看到对于资源弹性集群扩展，由于增加了集群之间本身的会话，缓存，状态同步，本身反而是影响到了高可靠性的。所以高扩展本身支撑了更好的性能，但是反而是影响到系统间的稳定性和高一致性。最基础高可用-冗余无单点故障
　　对于最基础的高可用性，我们可以理解为IT基础设施架构的HA冗余设计，通过冗余设计来解决无单点故障的要求。即在整个基础设施架构中，即使任何一台服务器宕机或拔掉网线也不能够影响到整体平台的正常运行。
　　比如对于上图是我们经常会采用的一个传统架构设计方式。
　　对于数据库一般不能安装在虚拟机里面，而是采用X86物理服务器进行安装，由于采用Oracle RAC数据库，本身对IO性能要求更高，因此采用IP SAN存储形成冗余架构设计。
　　对于应用服务器中间件层，直接采用Weblogic Cluster集群，但是对于Weblogic Admin仅仅对集群进行日常的管理和监控，不负责具体的负载均衡和路由分发。对于负载均衡仍然是将所有集群节点全部接入到上层F5硬件负载均衡设备来实现。
　　对于负载均衡节点，Admin管理节点同样需要进行HA方式部署以防止单点故障。
　　集群节点的假死问题
　　对于以上部署，最麻烦的一个问题就是集群节点的假设或者叫Hang住。这个时候IP是通的，服务调用地址也能够访问到，但是服务访问请求已经不能正常处理，连接一直被占用无返回到超时。在这种情况下F5负载均衡往往无法探测，仍然会分发请求到该节点。
　　在微服务架构里面，我们看到很多服务注册中心的设计都会有关键的心跳监测功能，来探查节点是否正常工作。因此在我们在上面高可用性架构设计里面，同样需要考虑心跳监测功能，每个引擎节点需要暴露心跳监测API接口服务，当前API接口服务不能正常访问的时候，我们对相关的节点进行服务暂停并从负载均衡中摘除掉。
　　大家如果使用Ngnix进行软负载均衡通用存在这个问题，而最近看微服务架构设计方面的文章谈到，更好的方法是采用OpenRestry的方案，对于OpenRestry融合了Ngnix和Lua，可以更好的实现下沉集群节点的动态心跳监测能力，节点的自动挂接和摘除能力。解耦-平台组件拆分部署
　　对于Oracle SOA Suite套件实际可以看到包括了类似OSB，BPEL，ODI，MFT，BAM等诸多的业务功能组件，同时Weblogic中间件本身又包括了JMS消息中间件能力。
　　平台功能组件的拆分部署
　　而我们项目的实施实际上会使用到OSB，MFT，JMS三个功能组件，对于BAM我们弃用同时自己定制开发基于底层组件的SOA管控治理平台。也就是说整个应用里面实际上包括了OSB，MFT，JMS和管控四个子系统。
　　那么我们首先考虑的就是这四个子系统进行拆分部署并解耦。
　　对于JMS消息中间件本身采用本地文件系统进行JMS消息持久化，因此不涉及到数据库。即整个平台包括了三套独立的数据库RAC架构和四套独立的中间件Weblogic Cluster集群。
　　整体四个功能组件拆分后的逻辑架构参考下图：
　　整体拆分后可以看到起到两个关键作用其一是各个组件相对独立，减少功能组件之间的相互影响其二是组件本身的版本升级，部署，变更等影响范围控制到自己内部
　　因此这个和我们当前常说的大单体应用拆分为多个微服务是一样的道理。就是要减少功能组件之间的耦合性，通过解耦来降低组件之间的关联依赖和影响。
　　拆分后通过缓存和JMS消息中间件彻底解耦
　　由于各个功能组件之间本身有集成和关联，因此拆分后仅仅是彻底解耦的第一步。更加重要的就是通过消息中间件和缓存等相关技术彻底解耦。
　　在这里我们对OSB集群和管控平台彻底解耦做下分析。
　　首先对于OSB集群，实际上我们增加了日志拦截插件，对于获取到的消息报文信息需要写入到Oracle管控数据库。而这个时候我们引入JMS消息中间件来进行彻底解耦。其一是提升接口服务调用性能，其二就是通过JMS消息中间件将日志写入异步。即使短暂的管控数据库宕机本身也不影响服务的运行。
　　那么如果JMS集群本身也出现故障呢？这个时候我们又增加了JMS消息写入的异常处理，即如果发现JMS消息写入异常，我们直接将服务调用日志实例写入到本地的磁盘文件中。
　　其次，对于OSB上的服务接入，我们增加了安全校验，路由等各种插件能力，而这些插件本身又需要调用管控平台数据库获取相应的配置和元数据信息。对于这种情况，我们则是采用本地缓存的方式进行解决，即获取到的元数据在OSB集群节点进行缓存，在元数据发送变化的时候才动态刷新缓存，通过这种方式来是来实现对配置信息获取上的彻底解耦。
　　在已经实现OSB集群和JMS和管控的彻底解耦后，我们还进一步实现OSB集群和数据库的强依赖关系，对OSB集群来说即使OSB数据库宕机也不会影响到OSB服务的正常运行。也就是说OSB服务注册和接入，完成部署后相关信息也在OSB运行节点进行了缓存，每次服务消费和调用的时候都无须再访问OSB数据库获取配置。故障隔离和分域设计
　　在前面背景的时候我已经谈到，整个ESB服务总线平台需要支撑上50家的组织接入，支撑上1000个接口服务，每天3000万次的访问量。
　　因此在整个功能组件拆分部署的基础上，我还需要进一步考虑中间件集群的分域部署。这和我们做数据库规划时候的水平拆分和垂直拆分道理有点类似。
　　服务分域设计即将我们传统的一个大的OSB集群拆分为多组OSB集群，每组集群以不同的端口号进行区分，每组集群都单独接入到负载均衡设备。
　　在OSB集群拆分后，对于服务的接入和部署实际有两种思路。其一是：将服务按SLA要求分类，不同类型的服务部署到不同的OSB集群其二是：所有服务在三个集群全部部署，但是要求不同的消费方访问不同的集群
　　对于第一种方式可以看到最大的优点就是对于一些高并发，大数据量的接口服务我们可以单独集群部署，即使这些服务运行出现性能问题也不会影响到其它服务集群，实现服务间的隔离。而第二种方式好处是可以将不同的组织或消费方进行隔离，那么某一个组织出现大并发访问不会影响到其它多租户的组织。
　　而最后我们选择方式二进行部署。其原因就各个集群都部署的全部服务，这样某个集群如果出现问题，我们可以通过修改F5负载均衡配置，实现快速的将服务消费请求路由到正常集群，也就是我们说的可以快速的实现故障转移能力。
　　当然在不同的SLA要求和策略下，按租户+按提供服务系统两者可以结合同时使用，比如首先按租户进行分域，当发现租户A中的QueryCustomer客户信息并发量巨大的时候，可以将该服务再单独分域进行部署。服务运行高可用性和流量控制
　　对于服务限流熔断，我在前面专门写过文章可以参考：
　　微服务和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内存利用率进行监控，当超过某个阈值的时候直接对服务进行禁用，如果我们无法区分出来究竟是哪个服务导致的，那么就应该直接对该节点上运行的所有线程进行终止，或者直接对该集群节点进行重启。
　　后端源业务系统出现故障
　　源端业务系统出现故障，实际上有两种情况，一种就是源端业务系统本身假死，即仍然是能够接收ESB总线传递过去的访问请求，连接一直占有并保持，要到300或600秒超时才返回超时的错误。还有一直情况就是源端本身就不可用，比如端口本身就无法访问到了，这个时候会在<10秒内就报出连接超时的错误。
　　对于本身连接超时对ESB总线影响不大，即可以快速的得到源端的响应和返回，同时释放连接。而对于第一种假死情况，则影响很大，并不是占有太多JVM内存无法释放，而是大量的占有Session连接池中的会话连接，将直接导致有新的服务调用请求无法获取连接的情况，即出现大量的新服务请求无法获取连接情况。
　　对于后端业务系统访问1-2秒，而整个ESB服务返回耗时>100秒甚至更长的情况，往往并不一定是因为内存原因导致，还是有用无法从可用连接池获取连接，导致进行排队引起。如果这个假设成立，那么重点就是在于如何快速的清理和释放出可用连接是关键。
　　对于ESB总线有一个总的连接池，比如2000，那么这个线程池是公有的，如果资源全部被长连接占用完毕，那么新请求就无法获取到新连接，导致耗时很长或连接超时。
　　当发现源业务系统出现不可用，有几种操作方式，一种就是对该系统提供的所有服务取消服务授权，提示服务处于不可用状态服务访问。其次就是直接将ESB集群中部署的服务禁用掉。对于第一种情况管控可以记录日志，但是对于第二种情况则管控服务记录日志。
　　那么能否是自动去检测后端业务系统服务，如果发现服务不可用，则自动禁用服务。当发现源服务恢复后，自动对服务进行启用，如果能够做到这种方式往往是一种最佳方案。