今天逐步谈下业务系统非功能性架构设计和高可用性方面的内容，在前面一篇谈软件架构设计的文章中，对于非功能性架构设计方面的内容我们没有太展开描述，今天将重点谈非功能性架构设计和高可用性设计。

高可用性概述

高可用性（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保其服务的高度可用性。

对于不可修复系统， 系统的平均寿命指系统发生失效前的平均工作（或存储） 时间或工作次数， 也称为系统在失效前的平均时间， 记为MTTF （Mean Time To Failure）。对于可修复系统， 系统的寿命是指两次相邻失效（故障） 之间的工作时间， 而不是指整个系统的报废时间。平均寿命即是平均无故障时间， 也称为系统平均失效间隔， 记为MTBF （Mean Time Between Failure）。

可修复产品的平均修复时间， 就是从出现故障到修复中间的这段时间记为MTTR（Mean Time To Repair） 平均修复时间。MTTR 越短表示易恢复性越好。

可用性（也称有效性） 是指可维修产品在规定的条件下使用时具有或维持其功能的能力。其量化参数为可用度， 表示可维修产品在规定的条件下使用时，在某时刻具有或维持其功能的概率。可用度(也称有效度) 通常记作A。

可用度A = MTBF/(MTBF + MTTR)。

当前我们谈的业务系统高可用性，一般的要求都是要达到4个9，即99.99%的高可用性，这个高可用性下，需要业务系统完全具备故障自动恢复能力。其年度停机时间53分钟。

在我们谈软件平台的高可用性的时候，首先要意识到高可用性是一个系统问题，不仅仅涉及IT硬件基础设施架构，也涉及到软件架构，设计和开发；同时还涉及到治理和管控体系。

对于软件平台的高可用性规划更是要以业务需求和目标驱动，标准体系和系统建设并重的思路进行。必须在从系统规划阶段开始就要考虑高可用性，而不是到了运维阶段才考虑；在规划设计阶段重点是软件应用体系架构，运行阶段重点是IT基础设施架构体系。

在文章首页图也可以看到首先是要基于业务目标驱动建立高可用性战略目标，不同的业务目标对于软件平台的高可用性要求显然是不一样的，其次是建立端到端的高可用性管理体系，这个管理体系包括了标准规范，业务流程和约束，管控制度等各个方面的内容，需要覆盖软件平台本身的全生命周期。

基于以上两点就很容易对高可用性具体工作进行分解，即包括了IT基础架构，应用体系架构，安全架构，管控架构等各个方面的内容。要想做好高可用性这些内容都必不可少。

而从流程和动态分析的角度来看，高可用性规划和建设又包括了评估，规划，设计，设施和运行五个阶段，五个阶段形成一个闭环的持续改进的高可用性规划和建设的流程。具体如下：

评估期：建立符合企业业务目标的系统可用性目标，确定提升系统可用性的机会。

计划期：制定系统高可用性发展策略并建立实施路线图。

设计期：设计企业未来IT环境及架构，制定详细的实施计划。

实施期：在保持低成本的前提下，高效快速协助客户全面提升可用性水平。

运行期：通过实施演练，发现系统风险控制的不足之处，制定进一步的提升方案。

下面对高可用性规划和建设的五个阶段做一个简单描述：

01-评估期

在评估期的重点是建立符合企业业务目标的系统可用性目标，确定提升系统可用性的机会。在评估期我们需要做如下几件事情，首先是明确业务目标和需求，业务究竟对软件平台的高可用性目标是什么?这个目标是否可以进一步量化？其次是对硬件平台和软件平台的现状进行分析和评估，现有的软硬件平台是否能够满足业务目标？现有软件平台是否能够满足业务未来几年的发展目标？如果软硬件平台相关部件失效会造成什么样的影响？(FMEA分析)。

在评估期我们会用到TPMC和业务测算模型，对需要的能力和现有的能力进行评估，并根据具体的高可用性要求确定潜在的风险点并作为规划阶段的重要输入。

02-规划期

规划期的重点是制定系统高可用性发展策略并建立实施路线图。再次说明高可用性规划是一个系统规划，包括了IT基础设施和硬件平台的规划，中间件平台的规划，软件平台和应用架构体系的规划，软件平台治理和管控体系的规划，安全规划等各个方面的内容。

在规划期的重要输入就是评估期的业务目标，现状评估和潜在风险输入。硬件平台是否具备高可扩展性？中间件平台是否足够健壮以支撑大数据量和高并发的业务要求？我们设计的软件是否有足够的容错机制和健壮性保证持续的不停机运行，这些内容都必须在规划的时候就考虑全面。规划完全可以看做是一个高端的设计，如果在规划阶段选型出现失误，很多时候直接影响到架构设计，而且在软件平台正式上线后很难再通过简单的变更进行弥补。

03-设计期

设计期是设计企业未来IT环境及架构，制定详细的实施计划。在我看来一个软件系统的高可用性设计包括了IT基础架构的设计，包括了服务器，存储，网络方面的设计；同时也包括了软件方面的设计，在软件方面的设计一方面是中间件平台的选型和设计，一个是基于中间件平台我们自主研发软件的设计。而这个软件的设计类似于软件中的架构设计，这个时候的架构设计重点又在于业务目标中非功能性需求的满足。要知道，很多时候软件平台可用性或性能出现问题，并不是硬件本身能力不足，而是我们软件本身设计和实现上存在缺陷，如选择了不适合的软件框架，实现方式和算法的问题，没有针对性能问题有单独性的设计方案等。

04-实施期

实施期重点是在保持低成本的前提下，高效快速协助客户全面提升可用性水平。如前面所说，如果是全新上线的软件系统在一开始就必须考虑高可用性和非功能性需求。而如果是对已经上线的软件系统，如何在保持低成本的基础上，提升高可用性水平就是关键问题了。

如果规划和架构阶段本身存在先天的缺陷，可以说很难在实施期显著提升高可用性水平。根据实际的经验，我们能做的就是加大对系统硬件平台的监控，通过硬件平台的监控反馈回的性能消耗数据来查找软件本身存在具体的性能问题的地方，并逐步对这些代码进行性能优化和调优。我原来写过一篇性能问题分析的文章，即使是一个性能问题，其本身也涉及到中间件平台的基础设施和调优，数据库的基础设施和调优，数据库存储过程和视图的优化，软件代码本身优化等诸多环节。

已经上线的软件系统不可能进行大改动，这个时候软件本身的稳定性已经高过一切，如果进行大的架构修改和调整，根本无精力再做全面的系统测试和回归测试。只能是逐步调优。

05-运行期

运行期的重点可以说已经在运维阶段，包括ITSM，ITIL等各种运维方面的体系和标准也都是在间接提升IT系统的高可用性问题。如果对于事件管理，问题管理和变更管理都是偏事后的分析和处理，那么对于基于软件平台，硬件基础设施的监控则是一个风险预警机制。

运行期的高可用性的重点一定是要从问题管理转化到风险管理，从报警转化到预警，从日常的运维中不断的收集硬件和软件平台的运行数据，通过数据分析找出潜在的性能问题点并有针对性的进行改进。SLA服务等级协议是关于网络服务供应商和客户间的一份合同，其中定义了服务类型、服务质量和客户付款等术语。在运行期引入SLA就是一种分级的管理策略和报警预警兼顾的高可用性管理方式。

业务系统性能测算模型

Oracle性能测算模型

在讲高可用具体架构的时候，首先还是得谈下业务系统性能测试模型。

即根据业务的非功能性需求，类似实际的业务用户数，峰值的业务并发数，业务单据本身的数据量，业务数据量发展趋势等来充分评估我们需要多少计算和存储资源才能够满足业务系统上线需要和3年左右的系统冗余扩展要求。

tpmC值在国内外被广泛用于衡量计算机系统的事务处理能力，为"每分钟内系统处理的新订单个数"的英文缩写。TPC-C使用三种性能和价格度量，其中性能由TPC-C吞吐率衡量，单位是tpmC。tpm是transactionsper minute的简称；C指TPC中的C基准程序。它的定义是每分钟内系统处理的新订单个数。

实际上性能测算包括了计算性能，存储需求，网络带宽需求多个方面的内容。在这里我们仅仅分析下性能测算方面的内容。

数据库性能估算概述

对于传统的TPMC业务模型测算可以看到的是该测算模型既包括了应用服务器也包括了数据库服务器，那么两者之间应该是如何去分配比例？这是一个问题。其次该文可以看到的是可以单独去估算数据库的TPM和TPC值。则首先要搞清楚的是一笔交易本身涉及到多少次数据库事务操作，每笔交易的复杂度是多少？最难的点还是在这里。这里又是一个经验数据。

其次估算考虑两个问题。

一个是数据库CPU利用率应该在70%左右为最好，太低了硬件估算过于偏大导致无必要投入，太大了CPU负荷太高影响系统高可靠性。

第二个问题仍然是3-5年的硬件的可扩展性，3-5年业务并发的增长量情况究竟如何。

最后我们估算的时候一定是要考虑峰值的时候的场景，找到业务交易峰值的天和峰值的时段数据。

TPC-C测试基准主要用于测试主机服务器每分钟能够处理的联机交易笔数，测试产生的单位结果是TPM值（Transaction Per Minute，即每分钟处理的交易笔数）。

TPC-C虽然客观的反映了各个计算机厂商的系统处理性能，并且测试基准也在不断完善以更加贴近现实应用的交易环境，但是仍然无法与纷繁多样的各类实际应用完全吻合；而且参加TPC测试的主机系统都做了适当程度的系统优化。因此，在实际业务应用系统选择主机服务器乘载体时，必须考虑到多方面的因素，以最大程度的做到适合应用系统的生产需求。

以下计算公式是IBM公司给出的在金融综合业务系统的实际应用中总结的经验方法论，基本反映了金融业务特点对主机处理能力的需求：

TPM=TASK x 80% x S x F / (T x C)

其中：

TASK：为每日业务统计峰值交易量

T：为每日峰值交易时间，假设每日80%交易量集中在每天的4小时，即240分钟内完成：T=240。

S：为实际银行业务交易操作相对于标准TPC-C测试基准环境交易的复杂程度比例。由于实际的金融业务交易的复杂程度与TPC-C标准测试中的交易存在较大的差异，须设定一个合理的对应值。以普通储蓄业务交易为例，一笔交易往往需要同时打开大量数据库表，取出其相关数据进行操作，相对于TPC-C标准交易的复杂度，要复杂很多；根据科学的统计结果，每笔交易操作相比较于TPC标准测试中的每笔交易的复杂度比值可设定为10~20。

C：为主机CPU处理余量。实际应用经验表明，一台主机服务器的CPU利用率高于80%则表明CPU的利用率过高会产生系统瓶颈，而利用率处于75%时，是处于利用率最佳状态。因此，在推算主机性能指标时，必须考虑CPU的冗余，设定C=75%。

F：为系统未来3~5年的业务量发展冗余预留。

综上所述，为保障联机业务处理性能要求，我们可推算得出主机所需的处理能力，据此得出相应的机型和配置。

数据库性能估算案例

下面针对XYZ行的网上银行业务的需求，我们进行数据库服务器的选型分析。

由于目前XYZ行只有17个分行开通了网上银行业务，据我们估计，按照目前的客户数量，全部分行都开通网上银行业务后，总的客户数量可以达到10万。考虑INTERNET在我国的迅猛发展，客户数量的年增长率按照50%计算，那么，3年后的客户数量将达到10万×（1+50%）3≈34万。

这些客户当中，至少有一半是个人客户，另一半是企业客户。企业客户的交易频率比较高，我们按平均每个企业客户每天做1.5笔交易计算；个人客户常用的交易是查询、取款、存款，并且每个月还要交电话费，因此我们假定个人客户平均每个月做4次交易；

那么，每天的交易量就是：34万×50%×1.5+34万×50%×(4÷30) ≈28万笔

假设网上银行的交易复杂度达到15，那么，每天的数据库操作数达到：28万×15=420万次

高法诉讼费缴费：

由于诉讼费的增长量不大，我们按年递增率5%计算。根据XYZ总行的统计，全国共37家分行，缴费量比较大的分行可以达到25000笔每月，占分行总数的20%；缴费量中等的省可达到15000笔每月，占分行总数的30%；缴费量小的省可达到7000笔每月，占分行总数的50%；按一个月20个工作日计算。

这样，三年后每天的交易数量可以达到：

（25000×20%+15000×30%+7000×50%）×37÷20×（1+5%）3≈28740笔。

我们假设高法诉讼缴费的交易复杂度达到13，那么每天的数据库操作达到：28740*13=373620次

总的数据库操作次数是：4200000+373620=4573620

假设每天的交易的80%集中在4小时内发生，那么高峰交易时间内每分钟的数据库联机交易次数为：4573620×80%÷（4×60）≈15250

要为将来陆续加入的应用预留40%的处理能力；另外，考虑到CPU的繁忙时间低于70%时，系统的性能较好，我们把这个比例定在65%。

所以系统的TPC-C值应达到：15250÷（1－40%）÷65%≈39000

内存容量需求分析：首先根据数据库容量算出所需的数据库缓存大小，再估计出操作系统、系统软件等所需内存，合计即是所需的内存容量。

高可用性的目标和关键要素

对于业务系统的高可用性，实际上包括了高可靠，高性能和高扩展三个方面的内容。而且三方面相互之间还存在相互的依赖和影响关系。

对于三者的关系，我们可以用下图进行描述。

上图可以看到高可靠，高性能和高扩展性三者之间的关系。

对于高可靠性来来说，传统的HA架构，冗余设计都可以满足高可靠性要求，但是并不代表系统具备了高性能和可扩展性能力。反过来说，当系统具备了高扩展性的时候，一般我们在设计扩展性的时候都会考虑到同时兼顾冗余和高可靠，比如我们常说的集群技术。

对于高性能和高扩展性两点来说，高扩展性是高性能的必要条件，但是并不是充分条件。一个业务系统的高性能不是简单的具备扩展能力就可以，而是需要业务系统本身软件架构设计，代码编写各方面都满足高性能设计要求。

对于高可靠和高性能，两者反而表现出来一种相互制约的关系，即在高性能支撑的状态下，往往是对系统的高可靠性形成严峻挑战，也正是这个原因我们会看到类似限流熔断，SLA服务降级等各种措施来控制异常状态下的大并发访问和调用。

高可用性需求分析和现状评估

高可用架构设计本身也属于非功能性架构设计里面的一部分内容。

简单来说我们需要整理当前的非功能性需求，当前架构本身存在的高可用相关的问题点，然后进行相应的差距分析并给出初步的高可用性技术解决方案。

一个高可用性的评估，包括了高可靠，高性能和高扩展三方面的评估。

对于高可靠性本身又包括了IT基础设施部署架构的高可用性，也包括了IT软件程序本身的健壮性，简单来说就是要确保整个IT架构系统不要出现任何的单点故障。

比如我们常说的数据库和中间件，既可以采用HA架构，也可以采用集群扩展架构，目标都是没有任何的单点故障。

在类似HA架构实现的时候，最初我们的设计可能是节点A出现故障后需要手工切换到B节点，那么这个架构设计就不满足高可用性要求，必须要做到自动的故障转移切换才行。

数据库层面的高可靠性设计由于涉及到持久化存储，往往比应用中间件实现困难。如果采用的本身是类似SAN这种集中化存储，那么问题比较简单，仅仅是切换计算资源即可。但是如果采用的本次磁盘进行数据存储，那么高可靠性设计就必须要考虑到数据库本身的数据实时同步。

比如我们在去IOE架构的时候用到的mysql dual master架构，其核心就是通过binlog日志的实时同步复制来解决数据同步问题。

由于是整个基础设施架构完全无单点故障，简单来说就是你把一台机器关机或者拔网线都不影响到整个业务系统的正常运行。因此对于部署架构中的负载均衡设备同样需要采用HA架构来确保冗余。即所有的硬件节点都需要冗余设计。

业务需求和问题驱动高可用设计

在进行高可用现状评估的时候，我们需要分析当前整个IT架构出现的各种非功能性需求和问题，并评估这些问题本身需要我们是可靠性，性能，扩展性哪个方面的技术能力需要提升。同时提升这些技术能力是通过IT基础架构设计来完成，还是通过架构优化调整和代码层面来完成。

由于我做SOA项目建设和实施比较多，可以看下SOA规划建设中高可用评估的一些参考。

高可用性设计和实施

在前面我一直在强调，不要简单将高可用性设计理解为全部是IT基础设施的高可用性。一个好的高可用性除了IT基础设施外，还包括了我们的应用架构和代码实现的高可用性，治理管控高可用性，运维监控的高可用性等多方面的内容。

比如我们常说的应用架构高可用性，这里就涉及到我们关键的技术架构设计，类似事务处理，缓存机制，消息中间件使用，大并发大数据量的请求处理等，都可以纳入到整个应用架构的高可靠性设计中来。而具体需要哪些技术，仍然是我们的非功能性需求目标驱动。

当然，对于架构的优化，本身也会涉及到硬件架构和软件架构两个方面的内容。这个在我上篇文章性能问题分析诊断里面其实有谈到。

其次，任何高可用性不仅仅是前期的规划和设计，也包括了后续的高效应用监控和运维监控。通过运行监控来发现各种高可用性问题，从问题驱动真正转变为风险驱动。

当我们监控到任何一个性能问题的时候，我们都需要去分析究竟是硬件原因，中间件原因，还是我们程序本身有缺陷导致，并制定相应的策略去优化改进。

即我们需要高可用性驱动来构建我们整个闭环的运维监控体系流程。

正如上图我们在SOA项目建设实施中构建的运维监控体系一样。

我们需要通过相应的硬件，软件应用监控来发现问题，同时去分析导致问题的具体原因，制定硬件软件优化方案，调整SLA服务策略，以持续保证平台的高效运转。

对于ESB服务总线项目高可用性案例分析

下面以ESB服务总线平台建设项目为例来说明下我们对高可用性架构设计的一些思考。

ESB总线平台如果出现性能问题一定会影响到整个平台的高可用性，比如出现服务器假死，宕机，JVM内存溢出，CPU和内存超负荷而导致响应缓慢等一系列问题。

但是高可用性本身还包括了高可靠性，高性能和可扩展性等方面的内容，因此非性能原因，如服务器或中间件本身出现硬件或软件故障也会影响到平台的高可用性。

在原来我们谈高可用性的时候更多的是谈高可靠性，即整个部署架构设计中不应该存在任何的单点故障，确保在单个物理资源出现问题的时候不影响到整个平台。而现在我们谈高可用性，更多的是谈的和性能相关的时候平台如何高效提供服务能力，也就是在大并发或大数据量下平台本身如何保证健壮性的问题。

整个基础各应用组件间应该尽量独立

这个在我们一开始的部署架构设计的时候就参与该思路进行，即将osb，jms，mft，bpel等各个应用组件拆分到不同的服务器资源里面进行独立部署，减少相互之间的影响。

但是为了管理方便还是采用一个domain和AdminServer进行管理。但是这样虽然管理方便，如果Admin Server本身出现问题仍然会影响到所有的应用。因此我们进行进一步的架构调整，即将Admin Server也进行拆分，确保各个应用组件完全独立。

划分不同的集群并进行分域处理

分域类似于ESB平台的多租户，我们可以让不同类型的租户使用不同的应用域，这样可以减少租户之间相互的营销。比如租户A出现大并发的调用不会影响到租户B。

除了按租户分域，我们还可以按服务进行分域，即将不同业务系统提供的服务部署到不同的集群或服务域中，这样可以确保提供业务服务的各个业务系统间相互不受影响，比如当CRM系统提供的服务性能出现瓶颈的时候不会影响到其它系统提供的服务。

在不同的SLA要求和策略下，按租户+按提供服务系统两者可以结合同时使用，比如首先按租户进行分域，当发现租户A中的QueryCustomer客户信息并发量巨大的时候，可以将该服务再单独分域进行部署。

单个服务大并发引起的性能问题

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

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

业务服务提供系统本身出现的性能问题或不可用

这里面也是同样的道理，如果出现性能问题，那么服务调用长耗时，同样导致大量连接被占用而无法及时释放。如果多个服务部署在一个JVM容器，采用同一个连接池，那么一定会影响到其它服务的消费和调用。其次源端业务系统不可用，那么在这种场景下面同样导致大量连接等待，无法及时释放的问题。

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

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

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

负载均衡和集群分发

对于OSB Cluster集群，重点只是做实际的集群节点监控和服务动态部署和管理。而实际的负载均衡分发是通过上层的负载均衡设备进行的。因此对于负载均衡的策略就很重要，这里有一个关键点，就是是否需要启用Session会话保持，如果启用会话保持策略最大的问题就是消费端的业务系统会被作用一个Session处理，导致所有的会话都会分发到同样一台机器上，而这种策略显然是有有问题的。

由于WS服务本身是属于服务无状态，因此最好的方式是最启用四层负载均衡，不启用会话保持。在这种模式下可以获取到最好的性能，存在的问题就是在启用四层的时候无法获取到目标端业务系统状态，同时也无法进行实际的心跳检查。

流量控制和服务禁用

如果出现异常的服务大并发调用我们完全可以进行流量控制。如果是后端业务系统处理不过来，我们可以进行出口端流控，如果是ESB总线本身处理能力跟不上，我们可以进行出口端流量控制。但是流量控制的前提本身是ESB和后端业务系统本身没有问题，只是性能处理能力跟不上。

而另外一种场景是业务系统本身出现故障问题，在前面我们也说了可以直接设置ESB服务的连接超时时间，而且这个时间设置不能太长，因为太长就会导致大量连接等待而无法返回到连接池，导致后续新的服务请求无法快速的获取到连接。

为了保障整个平台的高可靠运行，最好的方法应该是实时检测后端业务系统提供的WS服务是否正常，如果出现了异常或无法访问，则实时通过API接口操作，将ESB上部署的服务设置为禁用状态。虽然设置为禁用后消费系统无法再访问和调用服务，但是可以确保ESB平台本身的稳定性。

对于限流熔断请参考：微服务和API网关限流熔断实现关键逻辑思路

满足高性能下的集群弹性扩展能力

在讲PaaS平台的时候一定会讲到资源池的弹性扩展能力，同时这种能力是动态弹性扩展，即发现资源池能力不足的时候动态弹性扩展。而PaaS平台假设是资源池能力的不足最终都会反映到CPU和内存利用率和负荷上，因此须实时检测CPU和内存利用情况，当超过某个阈值后就启用动态弹性扩展。

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

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

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

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

监控虚拟机资源池的CPU，内存利用率，监控OSB Server本身的JVM负荷情况。

监控服务运行并发次数，服务运行平均时长，数据量的增长量和变化趋势。

监控服务运行ESB时间损耗的变化趋势

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

分布式JMS集群和高可靠性

对于JMS消息中间件集群，Weblogic的JMS集群如果配置为分布式集群的话是不支持Topic主题订阅模式的，这个询问过Oracle的技术顾问。当前对于JMS集群的高可靠性设置只有采用HA架构模式，或者启用JMS集群的节点漂移功能。

漂移功能简单来讲就是当JMS Server节点发送故障无法处理请求的时候，JMS或自动漂移到集群中的其它可用节点上面，类似于故障转移机制。以确保JMS本身能够正常访问和使用。

对于Weblogic 的JMS消息分发，基于Topic的消息发布订阅，最近经常出现的消费分发长耗时，订阅本身的超时和事务回滚等很多问题。最终潜在的原因可能是网络原因，其它大并发服务运行影响，跨越安全信任设置问题，启用了JMS XA分布式事务处理，主机域名设置等多方面原因因此，实际的最终原因还是没有完全确认清楚。

SLA预警规则设置

对于Osb Server在进行设置的时候，还可以设置具体的服务预警规则。具体可以监控的指标主要是服务调用次数，错误次数，成功率和错误率。而对于这些监控指标相对来说还是偏少的。对于服务运行中的监控预警功能，最好的是对于服务运行次数，运行时间，运行异常，数据量几个关键维度指标都能够进行性能监控，即可以是单维度的触发规则，也可以是多维度的组合触发规则。

注意监控预警的目的是及时的发现风险和问题，如果是服务非法调用或源业务系统问题就及时跟进处理，包括进一步进行限流设置等。如果是资源本身无法满足性能需求，就进行资源扩展。

面向高可靠性设计

高可用的基础是高可靠，而谈高可靠的时候重点是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内存，连接等是否正常。

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

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

这个在前面的架构设计里面其实很多内容都已经谈到过，在这里再简单做下总结。

第一是缓存能力，可以配置对查询类服务进行缓存，可以设置缓存失效时间。

第二是重试能力，这个重试是在连接保持的情况下进行重试，可以有效防止目标端业务系统网络闪断的情况。

第三，对于JMS消息分发，配置为消息持久化机制，可以确保消息在中间件服务器宕机的情况下能够持久化到数据库或本地数据文件，确保消息数据不丢失。