对于业务连续性要求比较严苛的金融行业，系统高可用是一项重要挑战和课题。本文作者将结合金融行业十多年实战经验对其课题进行浅析。

　　前言

　　根据我国十四五规划，推动高质量发展，必须立足新发展阶段、贯彻新发展理念、构建新发展格局，将“新”贯彻规划始终，以“新”推动我国经济和社会高质量发展。加快新型基础设施建设是“新”的重要组成，统筹推进与传统基础设施等建设，共同打造现代化基础设施体系。在云计算时代，不论应用架构还是基础设施架构，都采用分布式架构方式构建。对于业务连续性要求比较严苛的金融行业，系统高可用成为一项重要挑战和课题。本文将结合金融行业十多年实战经验对其课题进行浅析。

　　一、高可用概念与指标

　　高可用 ( High Availability ) 指通过尽量缩短计划之内的日常维护操作和计划之外的软硬件故障所导致的停机时间，以提供系统和应用得可用性。系统高可用的本质要求是指通过各种手段保证系统服务的业务连续性，尽量降低对客户的影响。

　　SLA是系统可用性的一个关键指标，指在一年为单位的时间周期中，系统可正常使用时间的占比。例如，全年共计8760 （ 365 × 24 ） 个小时，系统因各种原因有9小时无法对外提供服务， 那么，全年可用性即为（8760-9 ）/ 8760 ≈ 99.9% ，即业界所谓的3个9（见文章后说明） 。为提高系统SLA，容错的架构设计在分布式系统中尤其重要，因为开放平台相比于主机的本质特点是软硬件均可能发生故障，均不可靠。

　　对各种原因引起的单次故障，采用RTO和RPO两个指标衡量。RPO（Recovery Point Objective ) 指对应用数据而言，信息系统的生产数据可恢复到故障发生前多久的时间点；RTO （ Recovery Time Objective ） 指灾难发生后，系统服务从故障时点到重新提供服务的时间点。二者均以时间作为单位，RPO侧重故障发生前丢失数据的最多时长，RTO侧重故障发生后恢复服务的最快时长。故障恢复过程也包括应用数据恢复，在故障抢修时需综合衡量RTO和RPO。例如，金融业的数据更加重要，当无法立即恢复服务时需先完成数据恢复，即RPO优先于RTO。有部分场景（比如支付渠道类）需要保证RTO优先于RPO。这其实是一种系统服务时间（应用层级）和业务信息数据（数据库层级）的平衡判断。

　　二、高可用设计思想

　　各公司的高可用设计不尽相同，但设计理念却存在相似和相同的地方，主要如下：

　　(一) 在内部设计方面，通过组件冗余设计有效避免单点故障。

　　在机房方面，将应用部署到多个AZ（采用互相独立的供电、网络、冷却等基础设施），金融行业核心系统多采用两地三中心，甚至三地三中心；在服务器方面，网络设备存在冗余线路、多路端口等，服务器配置双路电源、双网卡、双路CPU、磁盘阵列RAID等；在中间件方面，通过IaaS和PaaS云计算资源，提供多应用服务实例。

　　系统的核心资产是数据，因此数据库高可用尤其重要。受光速等物理规律限制，距离一千公里的两地数据同步性会受限，RPO难以保证为零，这是任何数据库都面临的挑战。由于两地同时故障概率很低，Oracle的far sync就基于该理念设计，通过将数据库日志同步传到近距离的异地城市来优化RPO。传统数据库（如Oracle）采用高可用SAN存储、ADG数据库复制等方式提升数据可靠性；分布式数据库则大多采用多份数据副本的方式提升数据可靠性；hadoop等多种大数据软件亦采用该方式，当然也存在部分产品采用存算分离，将数据存储到一体化分布式存储产品中。

　　(二) 在外部关联方面，通过服务降低方式及时避免外部因素影响。

　　再完善的设计都难以预料系统所在关联环境遇到的各种风险和故障。当系统遇到流量陡增、关联系统故障等各种故障时，可采用“有所取舍”的策略进行服务降级来保证系统可用性，限流和熔断是两种常见的处理方式。

　　限流是指采用固定窗口、滑动窗口、令牌桶等算法对多业务维度限流保证系统可用性。金融行业多采用对省市代码、交易码、上游系统等多种方式限流保证核心系统不被瞬时业务高峰冲垮。熔断是指通过监控等方式感知到关联系统问题时，关闭对其调用来保证自身不因雪崩效应被影响。金融行业多采用对部分交易熔断来保障关键核心交易的可用性。这是丢卒保帅的思路保证了系统的整体可用性。

　　限流是避免上游消费方系统对自身的影响，熔断是避免下游服务方系统对自身的影响。二者处理过程中均需优化因服务降级带来的用户体验，比如，在秒杀场景中，抢购请求可能未到达真正服务器就因被随机选中而拒绝返回，但用户并不感知背后所发生的实际情况，而是感觉自己可能因运气差、用户多等原因而未抢到。

　　三、高可用运行机制

　　日常项目研发中仍然存在部分理念：1）采用高可用的分布式数据库就能保证系统高可用；2）采用高可用的架构设计就能保证故障发生时的系统高可用。前者忽略了数据库只是系统的一部分，忽略了部分和整体的关系，后者没有意识到“实践是检验真理的唯一标准”。为保证系统的高可用，笔者认为：

　　在组织级方面，建立一系列企业级高可用保证运行机制，建立完善的配套监控和应急容灾机制。1）只有建立完善的监管控工具，才能通过交易数量、响应时间、交易成功率等全方位监控指标及时发现系统异常，保证后续的人工操作，甚至通过工具进行自动化操作，或者通过AIOps及时发现尚未发生的故障，真正做到防患于未然。2）只有建立完善的应急机制，才能保证检测到系统运行指标异常后有一二线人员及时介入处置。金融行业在日常生产运维中有“战时”应急响应，但部分故障恢复仍需数小时，一般企业的应急响应可想而已。

　　在系统级方面，通过研发企业级混沌工具、沉淀系统级测试案例等对系统高可用性进行主动验证。随着分布式和微服务架构的日渐流行，系统复杂性剧增，传统的测试方法已难以覆盖各种潜在故障。混沌工程的核心理念是在控制爆炸半径的前提下在生产环境创建各类故障以实际检测系统高可用。金融业可能因各种原因短期内不会在生产演练，但可在灰度环境和测试环境演练。

　　综上所述，系统高可用是保证系统业务连续性的核心需求，需投入大量人力和软硬件等资源，需贯穿项目研发和生产运维全过程。在架构设计和运行机制设计上需按照系统重要性进行分级分类管理，综合衡量资源成本和业务收益，保证故障处置时的取舍与平衡。这是一项系统性的工程设计，绝非使用了高可用的分布式数据库就可以做到的事情。

　　全年可用性说明

　　1 ）3个9（99.9% ）：8760 × 0.1%=8760 × 0.001=8.76小时

　　2）4个9（99.99% ）：8760 × 0.01%=8760 ×0 .0001=0.876 小时= 52.6 分钟

　　3）5个9（99.999% ）：8760 × 0.001%=8760 ×0 .00001=0.0876 小时= 5.26 分钟

　　4 ） 6 个9（99.9999% ）：8760 × 0.0001%=8760 ×0 .000001=0.00876 小时= 31.536 秒