信息系统和分布式数据库高可用架构分析

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

一、高可用概念与指标

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

SLA是系统可用性的一个关键指标，指在一年为单位的时间周期中，系统可正常使用时间的占比。例如，全年共计8 760 （ 365 × 24 ） 个小时，系统因各种原因有9小时无法对外提供服务， 那么，全年可用性即为（8 760-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）一般使用etcd或者zookeeper记录对数据节点和计算节点的运行状态，便于发现节点失效时的故障迁移。2）一般采用高可用的单机数据库集群（比如mysql、OceanBase等）用于记录 运行数据 和节点IP地址、用户管理等 管理数据 ，运行数据会随着时间推移而日渐增大，一般会保留一定时间窗口的数据，其他数据则迁移到大数据平台，方便用于AIOps的数据分析；管理数据的数据量较少，会始终保存到单机数据库集群。小型数据库、etcd、zookeeper等自身具有高可用，其它模块属于无状态应用，可通过云平台高可用能力保障其正常运行。当该类节点全部失效时，如果计算节点和数据节点不发生故障，则不影响数据库的整体服务。

(二) 计算节点

计算节点 主要用于解析SQL语句，将其发到数据节点，并汇总数据节点处理结果后响应客户端，通常也称为代理或者计算引擎。由于负责SQL语句的解析和处理，对计算能力要求较高且属于无状态应用，所以，易于根据压力负载对其扩缩容，可通过云平台高可用能力保障其正常运行。当该类节点失效时，只影响连接该节点的应用，不会产生数据丢失的风险，可通过软硬负载的探活机制实现快速切换，风险相对可控。

(三) 数据节点

数据节点 主要用于接受计算节点请求，进行数据的保存、查询和修改。按照数据架构，一般分为本地存储和集中存储两种模式。1）对于本地存储模式，每个数据节点保存数据到本地磁盘。为保证数据的可靠性和性能，高等级系统可采用RAID 10 ，低等级系统可采用RAID 0 。采用多副本方式保证单节点失效时数据不丢失。在双活架构中，可采用一主三从的四副本方式。2）对于集中存储模式，采用类似Oracle rac的方式，一般采用兼顾性能和速度的高端存储或者分布式存储。对于两种存储架构，可采用分级分类方式进行高可用设计。经实践证明，二者均可满足金融级的两地三中心高可用要求。

四、高可用运行机制

日常项目研发中仍然存在部分理念：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 秒