非功能性架构和高可用性设计(200731)

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

高可用性概述

高可用性（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就是一种分级的管理策略和报警预警兼顾的高可用性管理方式。

业务系统性能测算模型

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

高可用性设计和实施