对于ESB平台本身的性能和高可用性，我曾经专门写过比较系统的文章进行总结，对于在整个架构设计和性能调优中的一些关键点，我准备用这个标题做系列化的记录，以方便自己备查。
平台性能和高可用性的关系问题
平台如果出现性能问题一定会影响到整个平台的高可用性，比如出现服务器假死，宕机，JVM内存溢出，CPU和内存超负荷而导致响应缓慢等一系列问题。但是高可用性本身还包括了高可靠性和可扩展性等方面的内容，因此非性能原因，如服务器或中间件本身出现硬件或软件故障也会影响到平台的高可用性。
在原来我们谈高可用性的时候更多的是谈高可靠性，即整个部署架构设计中不应该存在任何的单点故障，确保在单个物理资源出现问题的时候不影响到整个平台。而现在我们谈高可用性，更多的是谈的和性能相关的时候平台如何高效提供服务能力，也就是在大并发或大数据量下平台本身如何保证健壮性的问题。
整个基础各应用组件间应该尽量独立
这个在我们一开始的部署架构设计的时候就参与该思路进行，即将osb，jms，mft，bpel等各个应用组件拆分到不同的服务器资源里面进行独立部署，减少相互之间的影响。但是为了管理方便还是采用一个domain和AdminServer进行管理。但是这样虽然管理方便，如果AdminServer本身出现问题仍然会影响到所有的应用。因此我们进行进一步的架构调整，即将AdminServer也进行拆分，确保各个应用组件完全独立。
划分不同的集群并进行分域处理
分域类似于ESB平台的多租户，我们可以让不同类型的租户使用不同的应用域，这样可以减少租户之间相互的营销。比如租户A出现大并发的调用不会影响到租户B。除了按租户分域，我们还可以按服务进行分域，即将不同业务系统提供的服务部署到不同的集群或服务域中，这样可以确保提供业务服务的各个业务系统间相互不受影响，比如当CRM系统提供的服务性能出现瓶颈的时候不会影响到其它系统提供的服务。
在不同的SLA要求和策略下，按租户+按提供服务系统两者可以结合同时使用，比如首先按租户进行分域，当发现租户A中的QueryCustomer客户信息并发量巨大的时候，可以将该服务再单独分域进行部署。
单个服务大并发引起的性能问题
再次，我们必须要考虑由于单个服务大并发引起的性能问题，这里又两种场景，如果服务本身响应很快，这种大并发访问ESB平台支撑是没有任何问题的，真正出现问题是大并发+大数据量，或者说大并发+长耗时访问。这两者情况一个是大量占有连接资源，导致新的请求无法获取到连接导致等待状态；一种是大量消耗JVM内存，导致堆内存无法及时释放和回收。
不论是哪种情况都需要对单个服务启用流量控制，流量控制策略本身可以是并发量，也可以是数据量，都可以设置不同的流量控制策略挂接到WorkManager项目。如果要启用流量控制，对于服务部署本身需要采用独立的WorkManager，而不是系统默认的一个通用Workmanger。
业务服务提供系统本身出现的性能问题或不可用
这里面也是同样的道理，如果出现性能问题，那么服务调用长耗时，同样导致大量连接被占用而无法及时释放。如果多个服务部署在一个JVM容器，采用同一个连接池，那么一定会影响到其它服务的消费和调用。其次源端业务系统不可用，那么在这种场景下面同样导致大量连接等待，无法及时释放的问题。
上面实际上是两种场景，一种是服务查询本身可能耗时比较长需要等待数据返回，还有一种情况就是源端已经宕机我们一直在等待源端正常导致耗时很长。而我们看OSB服务封装中业务服务的设置可以看到两个不同的超时时间设置，这个设置信息很重要。
1. 读取超时：读取超时即等待读取数据返回设置的超时时间，如果超过则Read TimeOut
2. 连接超时：是指连接到目标业务系统获取到可用连接的等待时间，如果超过则Connection TimeOut
负载均衡和集群分发
对于OSBCluster集群，重点只是做实际的集群节点监控和服务动态部署和管理。而实际的负载均衡分发是通过上层的负载均衡设备进行的。因此对于负载均衡的策略就很重要，这里有一个关键点，就是是否需要启用Session会话保持，如果启用会话保持策略最大的问题就是消费端的业务系统会被作用一个Session处理，导致所有的会话都会分发到同样一台机器上，而这种策略显然是有有问题的。
由于WS服务本身是属于服务无状态，因此最好的方式是最启用四层负载均衡，不启用会话保持。在这种模式下可以获取到最好的性能，存在的问题就是在启用四层的时候无法获取到目标端业务系统状态，同时也无法进行实际的心跳检查。