随着网络支付行业渗透到我国社会经济的方方面面，发红包、扫码支付等已不再是“90后”群体的专属，而成为老百姓吃穿住用行的常见支付方式。随着支付方式的便捷化，老百姓也更加关注各种支付场景下的体验和效率，如果“双11”你的女朋友让你帮助清空购物车，你难道能告诉他现在系统故障无法支付吗？你在吃完夜宵告诉老板手机支付故障了，会不会被老板当做吃霸王餐的？在你抢红包的时候能接受系统延时和中断吗？答案当然是不能！！！

对，网联也不允许这样的事情发生。老百姓的支付需求不可辜负，网联平台的可用性要求几乎是分分钟都不能中断。初期设计要求可用性必须达到 99.99%，即全年故障时间控制在52.6分钟以内。网联的特殊性要求提供服务的时间是7*24小时，这就是说网联全年没有停机维护时间、不能发布停机计划。同时在支付、红包等高峰期的“双11”、“情人节”“过新年”等等业务量可能将达到18w笔/秒。在这种高并发的业务量、这种全年无停机时间的要求下,面对各种可能出现的故障，网联是如何做到99.99%可用性？

万丈高楼平地起，首先，我们要给网联系统找一个家，这个家就是数据中心。数据中心是IT系统的地基，是为网联提供一个“恒温、恒湿、不间断用电”的运行环境，数据中心的好坏直接决定了网联平台是否可以一直健健康康提供服务。双回路市电供电、2N UPS系统、N+1制冷系统、门禁视频及入侵检测系统、消防系统、环境监控系统等都是基本的要求，确保了每一个家的可用性达到99.99%。然而这样就够了吗？

2011年3月11日，日本遭受了9级大地震，日本东京的IBM数据中心严重受损；

2015年5月27日，支付宝因光纤被挖断导致业务大面积瘫痪；

2016年1月14日，Verizon公司运营的数据中心电力中断，导致美国廉价航空捷蓝航空公司的客户旅行延误了几个小时，大量旅客滞留；

2016.7.22，支付宝华南一处机房出现故障，部分用户无法在线上或线下通过支付宝进行支付购买，持续2小时；

......

近些年此类消息层出不穷，电力、火灾、台风、地震等天灾人祸随时可以让一个数据中心、甚至整个城市的数据中心瘫痪。

传统银行提出的“两地三中心”模式，同城主备+异地灾备的模式是否可以解决这个问题呢？当发生主中心故障必然需要切换而无法7*24小时提供服务，而网联必须满足7*24小时的高可用。

这就要求网联平台不仅要有多个数据中心，还必须部署在多个城市，且各个数据中心都必须能独立提供完整的服务，网联提出“多地多活”的分布式数据中心部署方案，让网联各个数据中心独立对外提供服务，任何数据中心的故障均不影响网联平台的服务。最终网联平台按此方案安家于北京、上海、深圳，建成“三地六中心”。此三个城市分别位于我国北部、东部和南部，有效隔离台风、地震、洪水等自然灾害。每个城市设立两个数据中心，距离约40~50公里，有效隔离区域电力故障或其他城市级故障。同时此三个城市也是我国各区域人口及经济中心城市，其空间布局的合理性、可靠性不言而喻。

那么网联的三地六中心是如何实现多活对外提供服务的呢？

网联要求机构和银行采用多专线链路方式接入网联平台。对于大型支付机构和银行，网联平台提供全部六中心专线接入能力；对于区域性机构和银行，网联平台也会提供多条线路接入能力。这样的专线接入模式可以有效降低因线路故障而导致的服务不可用。

其次，这些多城市、多数据中心、多线路接入的多活方式如何协调和运转呢？网联平台独特的多数据中心渠道接入“秘笈”闪亮登场了。

支付业务一般由第三方支付机构发起，机构多条线路分别对接网联的多个数据中心，网联实时推送各数据中心健康情况，由机构自由选择进入网联哪个数据中心处理业务。当网联平台某个数据中心不提供服务时，可以通过其他数据中心更新控制代码剔除当前不可用数据中心。机构接受到指定错误代码时，重新拉取最新的控制代码，将交易平滑切流至网联其他数据中心，不影响交易的正常处理。然后网联负责选择通过哪个路由进入银行的数据中心，当银行某个数据中心发生故障无法提供服务时，网联平台根据交易健康度规则判断，可以将流量自动切换至银行的其他数据中心。做到多数据中心、多链路负载冗余。

从上面我们可以看到，网联通过多数据中心、多链路冗余等方式实现了“三地六中心”的多活架构，然而最终对外提供服务的是网联的应用系统以及后台的数据库系统，那么他们是如何设计和运行的呢？应用系统如何实现故障自动切换？数据库如何实现故障自动切换？

网联核心的转接清算业务采用分布式。分布式应用无状态特性使得单个数据中心部署的应用无单点风险。推广到多个数据中心时，各数据中心的应用集群互为备份。当发生数据中心级甚至城市级故障时，网联平台的业务均可被其他数据中心接管。并且，网联平台在处理性能上保有足够冗余，当一个城市发生灾难时，其余两地的数据中心可以接管和支撑全部流量。

网联平台采用集群方式部署数据库，且最大程度提高库级冗余。网联平台采用“一主三从”模式部署数据库集群，即同机房一主一备。同机房数据库出现故障时，集群自动切换，防止出现因主库故障而导致不可用和数据丢失的问题。同时，在同城和异地分别再备份一份增加可靠性。再结合应用路由设置，任何一个数据库节点故障时，应用均可以切换到其他可用数据库节点继续处理。数据库集群各节点之间无影响。

此时网联的三地六中心多活高可用方案已具备外形，让我们一起进入一个数据中心内部，看看各个硬件模块的性能，会不会成为故障点而降低整个平台的可用性。

进入数据中心后，我们看到了一排一排整齐机柜，大量的服务器、网络设备疯狂闪烁着的指示灯标志着他们在全力处理业务，所有设备均是双电源、双引擎的冗余模式，冗余模式可保障单台设备99.99%的可用性，然而当网联成规模的几千台服务器在线运行，设备故障则不是小概率事件了。那么网联是如何在这种情况下提升服务可用性的呢？

网联平台采用虚拟化技术构建应用服务器资源池，采用KVM虚拟化技术实现了x86服务器CPU、内存和硬盘等硬件资源的虚拟化，并以开源的Openstack为框架建设各个数据中心。各个数据中心独立成云，在每朵云里，应用采用随机策略分别部署到资源池的不同的逻辑区域内（称之为“可用域”）。同时在网络层面，虚拟化内核支持标准VxLAN封装的分布式虚拟交换机，实现了虚拟网络与物理网络的解耦。使得虚机可以自由的运行在资源池中的任意服务器上。加之负载均衡等高可用设计，当一台或是多台服务器、一个或多个机柜模块、甚至是一个或多个可用域故障时，应用仅会损失部分计算能力，整个服务的可用性不受影响，即单台设备的故障不会对应用可用性造成影响。

自此，网联平台自上而下的高可用设计就介绍清楚了，让我们回顾一下看看网联是不是有遗漏的地方。

服务器故障了？

我们通过虚拟机化、资源池化提升了资源池的可用性，单台物理机故障不会影响资源池的可用性。

网络设备故障了？

我们所有网络设备均是多机热备、自动切换流量。

应用系统故障了？

我们所有应用采用负载均衡+分布式部署，业务流量自动由其他健康的应用支持；

数据库故障了？

我们的数据库集群自动故障转移，“一主三从”，应对各种故障场景。

光缆被挖断了？

路由自动切换到冗余链路，机构和银行都是多条链路接入的哦。

啥？整个机房掉电了？火灾了？整个数据中心没了？

我们渠道业务自动通知机构选择其他数据中心处理业务。引流到健康的数据中心。别说是单个机房故障了，就是某个城市发生地震、洪水等自然灾害摧毁一个城市的两个数据中心，我们也能自动把流量转移到其他可用的数据中心。

网联的可用性设计都敢和大自然抗衡了，你还害怕抢不到红包吗？你还害怕不能清空女朋友的购物车吗？宵夜随便吃，随便几点都能手机支付，别把手机丢了就行。

最后，我们用专业的说法再总结一些吧。我们用下图金字塔模型把各层设计要点归纳起来： 图：网联平台高可用金字塔模型

高可用金字塔是分层解耦的，也就是说，每一层故障概率是独立的。自下而上，故障等级越来越高，但是故障概率越来越低。这种设计确保了整个网联平台的“不可用”取决于金字塔的最顶层故障概率。很显然，城市级（乃至全国性）灾难的概率和中彩票的概率差不多。因此，从理论上讲，网联平台是不会垮的（RTO=0）；平台应用“多点多活”，数据跨城市冗余，业务数据接近零损失（RPO≈0）；可用性可以达到99.99%甚至更高。当然，实证情况下，再完美的系统执行业务切换和流量分流也需要复杂的路由判断和必要的操作时间。因此，网联平台重点建设的，就是更稳定可靠的云化数据中心，更灵活弹性的专线接入，更智能敏捷的路由切换系统。

网联平台建设的每一个参与者都在提高平台的整体可用性，切实履行国家级金融基础设施重要职能而努力奋斗。