分布式信息系统的高可用架构设计解析.docx

前言

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

一、高可用概念与指标

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

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

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

二、高可用设计思想

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

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

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

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

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

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

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

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

三、高可用运行机制

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