金融应用系统高可用建设，兼顾应用层设计与基础架构实践。从冗余、限流、熔断到多地多中心容灾，旨在确保核心业务连续性，守护市场稳定。
原文标题：聊聊应用系统的高可用建设
原文作者：牧羊人的方向
冷月清谈：
文章从“应用群集”的视角阐述了业务系统的可用性，强调高可用建设需以“广义的应用群集”为核心，即涵盖交易链路中的所有上下游系统，并据此进行多活部署架构设计。业务场景和交易链路分析是基础，通过可视化链路图识别强弱依赖，对关键服务确保高可用，对弱依赖服务则通过异步、隔离、降级等方式处理。基础支撑类应用（如配置中心、消息队列、API网关）的自身高可用性设计同样关键，并特别指出运维支撑类平台（如监控、切换平台）自身的高可用性往往被忽视，可能在关键时刻失效，导致应急效率低下。
在应用层高可用设计方面，文章提出了多项具体策略，包括：冗余设计以消除单点故障；限流、降级和熔断机制以应对流量冲击和下游故障，防止雪崩效应；异步化和消息解耦以提高吞吐量和容错性；合理的超时与重试机制；通过Token、唯一流水号实现幂等性设计；以及全链路监控与追踪、业务开关和预案等，确保应用对故障具备自我保护和快速恢复能力。
基础架构层高可用建设是应用可用性的基石，其容灾能力决定了系统可用性的天花板。文章详细对比了从单机房高可用到异地多中心容灾等多种架构：从设备级、机柜级冗余的单机房高可用，到同一数据中心内物理隔离的单中心多可用域（AZ）高可用；再到同城两个独立数据中心对等承载流量的同城双活，以及更强的同城多可用域部署；最后是应对城市级灾难的异地灾备（RPO通常分钟级至小时级）和最高级别的异地多中心容灾（如三地六中心），后者通过区域性流量分发和数据拆分，实现业务连续性的最大保障。不同架构对应不同的RTO、RPO能力和建设成本，需结合业务重要性综合考量选择最佳方案。
怜星夜思：
2、如果让你为一家刚起步但业务增长迅速的互联网金融公司规划高可用架构，资金和技术团队规模都有限，你会如何平衡文章中提到的应用层和基础架构层的高可用策略，并优先选择哪几种技术方案组合？
3、文章特别指出运维支撑类应用（如监控、切换平台）的高可用性常被忽视。万一这些“救命稻草”自己先“溺水”了，会引发哪些连锁反应？有没有便宜又好用的“B计划”来应对这种极端情况？
原文内容
金融行业的业务连续性对于维护市场稳定、保障客户权益和推动经济发展具有重要意义。通过应用系统的高可用建设可以降低业务中断的风险，提高应对突发事件的能力，从而提升应用系统的稳定性和可靠性。本文从应用群集的角度介绍了业务系统的可用性，并从应用层设计和基础架构层高可用建设来阐述应用系统的高可用建设。
1、应用系统高可用建设的总体目标
应用系统在生产环境持续稳定高效的运行是运维人员的主要职责。尤其是在金融行业，作为经济运行的核心支柱，其系统高可用性直接关系到金融稳定、客户信任以及业务体验。因此，在金融行业应用系统高可用建设的核心目标是：最大程度地减少或消除计划外停机时间，确保核心金融服务在任何情况下（包括软硬件故障、局部灾难、甚至区域性灾害）都能持续、稳定、可靠地对外提供服务，以保障客户资金安全、交易顺畅和业务连续性。
-
高可用性指标： 年度系统故障时间控制在分钟级（例如，99.99%可用性对应年停机约52分钟，99.999%对应约5分钟）。
-
快速恢复时间目标： 故障发生后系统能够快速恢复，实现RTO时间从秒级到分钟级不等。
-
低数据丢失容忍度： 故障发生后允许丢失的数据量极小，核心系统通常要求RPO=0（零数据丢失）。
-
容灾能力： 具备应对单点故障、机房故障、站点级故障甚至城市级灾难的能力。
-
弹性伸缩： 能够快速应对业务高峰（如秒杀、大促）带来的流量冲击，保持服务稳定。
-
用户体验一致性： 在故障切换或容灾过程中，用户应尽可能无感知或感知极小，提升用户体验。
围绕着业务连续性的总体目标，衍生为如何确保业务系统的可用性，从应用层面和基础架构层面如何去设计高可用架构、推演极端场景下的应急逃生机制和故障恢复能力，确保系统故障时能够及时发现并快速地恢复业务。
2、业务系统的可用性
应用群集从狭义上说是一组承载相同业务功能的应用实例，作为一个整体对外提供无缝、不间断的服务集群。狭义上的应用集群通过负载均衡实现流量分发、基于云化的部署实现资源的弹性扩缩容、通过服务注册与发现的方式自动感知应用实例的状态变化实现故障自动转移。
但是更广泛的意义上的应用群集是这一类关键业务场景上的上下游系统作为一个整体对外提供服务。比如一笔手机上的支付消费需要考虑到终端类、支付类渠道和核心业务系统整个交易链路涉及到的应用系统。如下图所示，支付系统接收网关发来的支付请求，将业务信息转化为支付指令分别与“客户系统”、“收银台”、“支付引擎”进行交互完成最终的支付。[1]
因此在系统高可用建设的时候需要以广义上的应用群集的视角去考虑，建立应用群的多活部署架构，包括应用层、网络层和基础设施层。当单中心故障时候，应用能够快速的进行流量切换，将业务影响将至最低。
业务场景和交易链路分析是从具体的业务需求和交易流程出发，确保系统在不同场景下都能稳定运行。
-
在高可用建设中需要对关键的业务场景和交易链路进行梳理与可视化，形成端到端可视化的交易链路流程图，明确涉及的所有系统、服务、数据库、中间件。这是故障定界和问题定位的基础，通过可视化的交易链路图和拓扑结构图，能够快速定位到出现问题点。
-
对服务之间的强弱依赖进行分析，梳理出业务流程中对哪些服务是强依赖的，当该服务不可用时，核心的业务功能必将失败，比如交易的授权服务、系统的登录验证服务，对于强依赖的服务则需要确保高可用性。对于一些弱依赖的服务，只影响业务的辅助功能或者用户体验的，在出现故障时通过异步、隔离或降级等方式处理。
通过对业务场景和交易链路的分析解剖，并结合应用设计制定不同的策略，如冗余设计、服务熔断或限流降级、全链路监控等措施，提升系统的韧性和快速应急响应能力。
基础支撑类应用是业务系统运行的技术平台基础，广义上而言又分为两种：一种是为业务系统提供基础技术支撑的，比如配置中心、缓存中心、消息队列等；还有一种是基础运维平台的，比如监控和全链路平台、切换平台和各种基础软件的管理平台，包括网管、云平台和数据库管理平台等。对于前一种基础技术平台，在应用系统架构设计时统一考虑组件自身的高可用性，不限于以下组件：
-
配置中心如Nacos提供权限控制、版本管理、灰度发布能力，通过集群的部署方式，结合客户端本地缓存配置，当 配置中心本身短暂故障时业务应用仍可使用本地缓存配置运行，不影响业务功能。
-
消息队列如Kafka实现业务功能的异步解耦，通过Broker集群和多副本的机制，当部分节点异常时能够保证消息服务不中断，数据不丢失。在高可用设计上确保异步任务、事件通知、数据同步等关键流程可靠执行，实现最终一致性。
-
API网关：支持动态路由、负载均衡、熔断降级、限流、认证鉴权、监控等，通过集群部署和负载均衡方式实现高可用。
但是对于运维支撑类的应用，往往因为资源或者其他原因在建设的时候没有考虑到平台本身的高可用性。当故障出现尤其是站点级故障的时候，可能会出现监控不可用导致告警不能及时发现、应急切换平台不可用导致既定的应急流程无法下发执行。在依赖平台和工具的运维时代，诸如此类的故障场景下平台工具本身已经无用武之地了，影响到应急的效率和业务恢复的时间。
3、应用层高可用设计
应用层在架构设计过程中，基于基础组件的能力实现应用层的高可用，提升应用系统的鲁棒性、消除单点故障，比如通过API网关实现服务降低和熔断限流、针对服务间的依赖强弱关系进行策略化的降级等。
-
冗余设计消除单点故障： 确保业务链路中每个环节（如接入网关、应用服务、关键下游接口、数据库、消息队列）都具备冗余能力（通过集群部署或主备切换）， 避免一个点故障导致整条链路瘫痪。
-
限流 (Rate Limiting)： 结合网关（如Spring Cloud Gateway, Kong）在系统入口或关键服务入口实施限流（如令牌桶、漏桶算法），防止突发流量或恶意请求压垮系统。
-
降级 (Degradation)： 当系统资源紧张或某些依赖不可用时，主动关闭非核心功能、返回兜底数据（如缓存、默认值）或简化流程，保证核心功能可用。根据服务间的依赖关系定义不同的策略，如功能降级、依赖降级和流量降级，确保在系统压力过大或部分依赖故障时，牺牲次要功能和体验，力保核心业务主流程可用。
-
熔断 (Circuit Breaking)： 借鉴电路熔断器思想（如Hystrix, Sentinel，当调用某个服务的错误率或响应时间超过阈值，熔断器打开，后续调用直接快速失败，避免资源耗尽。熔断可以防止因单个下游服务故障耗尽调用方资源（线程、连接），引发雪崩效应，保护上游核心链路可用。
-
异步化和消息解耦： 将非实时强一致性的操作异步化（如发送通知、记录日志、更新非核心状态），通过消息队列解耦调用方和被调用方，提高系统吞吐和响应速度，增强对下游故障的容忍度。
-
超时与重试 (Timeout & Retry)：为所有外部调用（DB、缓存、服务、API）设置合理的超时时间，避免线程长时间阻塞。对可重试的失败（如网络抖动）实施有策略的重试（如带退避策略的指数退避重试）。
-
幂等性设计 (Idempotency)：通过Token机制、唯一流水号、数据库唯一索引/乐观锁，将核心接口（特别是写操作如支付、扣款）设计为幂等，即使用相同参数重复调用，结果一致。
-
全链路监控与追踪： 整合全链路追踪（Trace）、指标监控（Metrics）、日志聚合（Logging）数据，对核心链路的关键指标（成功率、耗时、错误码、流量）进行端到端监控，设置精细化告警，快速定位性能瓶颈和故障点。
-
业务开关和预案： 预置业务开关（配置中心动态下发），可快速手动关闭问题功能模块或切换降级策略，并制定详细的故障应急操作手册。
通过以上应用层的可用性设计，实现应用的自我保护和故障快速恢复的能力，避免局部故障的快速扩散引起雪崩，提升系统整体的稳定性和韧性，为上层业务连续性提供直接保障。
4、基础架构层高可用建设
基础设施是应用系统运行的载体，基础架构的高可用是应用可用性的基石，其高可用架构设计决定了应用容灾能力的天花板。其最终目标是通过基础设施冗余、地理分散和智能调度，应对不同级别的故障（单设备、单机柜、单AZ、单数据中心、城市级灾难），保障业务连续性和数据安全，实现极低的RTO（恢复时间目标）和RPO（恢复点目标）。不同重要程度的应用系统对基础设施的可用性要求也不同，这种不同也决定了基础设施包括机房、网络、服务器和数据库层面如何制定高可用部署策略，因此在高可用建设的过程中需要根据不同的应用进行分类和取舍。如下表所示，在金融领域各重要级别的应用系统在RTO、RPO、可用性等关键指标要求。
单机房的高可用是确保在单个机房内，通过消除关键组件的单点故障，实现设备级、机柜级别的高可用。
-
网络冗余：交换机、防火墙以及负载均衡设备实现双机热备，关键链路上实现物理双路由，防止网络设备单点引发的故障。
-
应用部署：应用采用集群部署的方式分散在不同的服务器或容器节点上，同时虚拟化层在宿主机硬件层实现反亲和设计，确保同一个应用下的服务节点分散在不同的宿主机或服务器上。
-
存储冗余：集中式存储如SAN/NAS采用双控制器、多路径访问、RAID保护；分布式存储利用多副本机制（通常3副本）保障数据高可用，节点或磁盘故障自动恢复。
-
数据库冗余：利用数据库自身的高可用机制，如主备节点或分布式集群部署，当主节点故障时候能够自动切换。在服务器层能够实现反亲和部署，同一个数据库的主备实例分散在不同的宿主机或服务器上。
单机房内的高可用主要是实现设备级和机柜级别的冗余，适用于业务重要性相对较低的非核心系统，或者作为更高级别的容灾架构中单个站点的本地高可用基础。
单中心多可用域AZ高可用部署，是在同一个DC内部划分为多个物理隔离的故障域（Availability Zone, AZ）。每个AZ具备独立的供电、制冷、网络基础设施，关键应用和数据跨AZ部署，实现AZ级别的容灾。
-
AZ划分：明确物理边界，如不同楼层、不同电力区域、不同网络汇聚区。确保单一故障事件（如某楼层漏水、某配电柜故障）不会同时影响多个AZ。
-
网络互联：AZ间通过数据中心内部高速低延迟网络（通常≤1ms）互联，带宽充足。
-
应用部署：应用集群部署在多个AZ域，通过负载均衡将流量分发到不同的AZ
-
数据库部署：数据库主备节点或分布式节点主备副本分布在不同的AZ。
-
存储部署：分布式存储跨AZ放置数据副本；集中式存储通常通过跨AZ的同步复制实现冗余。
跨AZ部署可以应对AZ级别的故障，当出现机房级的故障时，能够将业务流量快速切换到其它AZ，从而确保业务的快速恢复。
同城双活是在同城的两个独立数据中心（DC1和DC2），两中心同时部署应用并承载生产流量（读写），两个数据中心地位对等（Active-Active），互为备份。一般而言是在应用层实现双活，但是数据库层较难实现。
-
高速低延迟互联： 两地数据中心通过裸光纤+波分复用(DWDM) 或运营商专线互联，保障网络延迟稳定<2ms，带宽充足（通常≥10Gbps）。
-
全局负载均衡：基于DNS，根据域名、数据中心健康状态、负载情况智能路由用户请求到最优数据中心入口，站点级故障时能够快速进行流量切换。
-
应用层：应用在双中心同时部署，两中心对等，通过DNS进行流量的分发和调度。
-
数据库层：应用层实现了同城双活，但是同城中心的应用是要写回生产的数据库主节点，依赖数据库层的数据同步保证同城站点的数据一致性。当生产站点数据库出现异常或者站点级别异常时，通过自动或者手动的方式切换到同城站点。数据库层也可以通过应用的单元化部署实现部分双活。[2]
同城两个数据中心的双活架构，实现数据中心级别的容灾，资源利用率能够达到100%，故障切换秒级完成，满足金融核心系统严苛要求。适用于金融行业核心交易系统、核心账务系统等对高可用和连续性要求极高的场景。
同城多可用域可以看成是单中心多AZ的扩展，将同城划分为一个逻辑上的超大数据中心，但是物理设施分布在多个严格隔离的园区，每个园区具备独立的供电、制冷、网络核心等基础设施。
-
站点级隔离： 园区间有足够的物理距离和基础设施独立性，能应对比AZ更大范围的故障（如单个园区停电）。
-
网络互联： 园区间通过裸光纤或高可靠专线互联，延迟通常<5ms。
-
应用部署：无状态实例跨多个园区部署，通过DNS实现流量分发。
-
数据库部署：数据库集群/分布式数据库节点跨多个园区部署，利用Raft/Paxos等协议保障跨园区数据一致性（RPO≈0）。
-
存储部署：存储副本跨园区放置。
同城多可用域高可用具备比单中心多AZ更强的容灾能力，在业务访问上优先保证同一用户的请求在处理过程中尽可能集中在一个园区内（减少跨园区调用），但具备跨园区容灾能力。非常适合于TiDB、OceanBase等这样的原生的分布式数据库基于Raft/Paxos一致性协议构建高可用部署架构。
异地灾备是在异地（几百公里外，网络延迟通常几十毫秒）建设一个或多个灾备中心，以应对城市级的重大灾难（地震、洪水、大规模停电、战争）。生产中心运行业务，灾备中心同步数据但是不能确保RPO≈0，应用部署上也不完全对等，只有一些关键核心业务系统，在定位上主要用于灾难时切换或容灾演练。
-
网络互联： 依赖运营商长途专线带宽成本高，存在较大延迟（>30ms）和网络抖动。
-
全局流量调度： 通过DNS根据域名、中心健康状态、负载进行智能路由，生产站点故障时屏蔽故障中心，并将流量路由到灾备中心。
-
应用部署： 灾备中心部署与生产中心相同的应用，但通常和生产非对等部署或不承载生产流量或者一些白名单业务。
-
数据复制： 数据库层主库到备库的异步复制（RPO分钟级至小时级）；存储级异步复制。
异地灾备应对核心业务系统的监管要求，以及必要的灾备站点切换演练计划，建设成本相对较高。
异地灾备是在异地（几百公里外，网络延迟通常几十毫秒） 建设一个或多个灾备中心，以应对城市级的重大灾难。多个异地中心都承载生产流量（读写），通常是区域性流量（如用户就近访问）。
-
网络互联：依赖运营商长途专线带宽成本高，存在较大延迟（>30ms）和网络抖动。
-
全局流量调度： 通过DNS根据域名、中心健康状态、负载进行智能路由，生产站点故障时屏蔽故障中心，并将流量路由到灾备中心。
-
应用部署： 应用在每个中心独立部署，服务本地及邻近区域用户。应用在设计上需要单元化部署思想，尽量让一个用户的所有请求和数据操作在一个中心内闭环（减少跨中心调用）。
-
数据复制： 数据库层通过数据库日志（Binlog）进行异步数据复制。应用在设计上需要考虑数据的冲突检测与解决机制，如时间戳最后写入优先、业务规则合并和向量时钟来解决数据的最终一致性问题。
以三地六中心架构为例，在3个城市建设6个数据中心，每个城市分布2个同城双活数据中心，这种一般适合于大型金融机构，建设成本相对较高，对系统可用性达到极高的要求。在接入层根据地域、业务场景进行分流，比如京津冀地区、长三角、大亚湾地区等；应用层多地多中心部署，没有单点故障风险；数据库层在每个城市互为主备，实际上是在业务层做了数据拆分，这部分的读写业务数据在A站点、另一部分的读写业务数据在B站点。基于多地多中心的部署架构，能够最大限度的保障业务连续性，不会出现全局性的业务不可用的问题。[3]
如表所示，不同的高可用架构对应了不同的RPO和RTO能力以及成本。对于金融级别的重要应用和业务场景而言，需要结合业务系统的可用性要求，梳理出关键的业务场景和交易链路，综合可用性和成本考量选择部署合适的高可用架构，以应对极端故障场景下的故障恢复要求，提升业务的连续性。
参考资料：
1、“万字长文，四句口诀搞懂支付交易”，刚哥白话
2、，牧羊人的方向
3、，牧羊人的方向