项目背景及目标
近年来，相关监管机构高度重视金融机构信息系统风险管理，相继出台了相关政策方针和指引。中国银行业监督管理委员会于2010年4月底发布了《商业银行数据中心监管指引》，该指引对数据中心的设立与变更、风险管理、运行维护、灾难恢复及对方管理等方面提出了明确要求，其中：

第五条指出：商业银行应于取得金融许可证后两年内，设立生产中心；生产中心设立后两年内，设立灾备中心；

第七条指出：总资产规模一千亿元人民币以上且跨省设立分支机构的法人商业银行及省级农村信用联合社应设立异地模式灾备中心。

一直以来我行对科技建设十分重视，按照我行灾备中心“先同城、后异地；大同城、小异地”的总体建设方针，我行于2015年和2016年先后启动了重要信息系统的同城、异地灾备建设项目，目前已陆续完成。为了把各灾备中心闲置资源充分利用，保护科技投入，我行开展了两地三中心应用系统多活的建设。

项目方案
完成三地多活数据中心建设。在技术层面，不仅涉及到服务器/虚拟机之间的集群协同，还包括数据一致性的数据的复制与同步以及跨数据中心的网络互联互通。示意图如下：

1．网络架构设计
1.1全行网络拓扑图及关键网络资源冗余性设计 

我行业务网总体网络架构为“两地三中心”架构，包括位于北京市内的亦庄数据中心、空港数据中心以及位于上海的异地灾备中心。三中心将构成骨干的承载网络。

我行在亦庄数据中心、空港数据中心、月坛总行办公大楼、花乡办公大楼、元亨办公大楼等地之间通过DWDM技术建立裸光纤环网，从裸光纤中复用出多条GE或10GE光通道链路，满足各中心之间对业务数据多重链路的需求。节点间光纤发生故障，可通过环网迂回；在光纤环网上建设城域网，每个节点放置两台思科高端路由器进行冗余备份，保证业务连续性。北京市亦庄数据中心、空港数据中心与上海异地灾备之间采用100M的MSTP链路连接，满足业务带宽需求。

在亦庄、空港两地数据中心建立城综网，每节点布放两台思科高端路由器进行冗余备份，总行机构以及全行管辖行、网点分别放置主备两台路由器，通过两条不同运营商线路，分别接入两地数据中心城综网的四台路由器，再上联接入两地数据中心。同时，在上海择机建设我行4G连接备份网络，将各网点及总行重要生产机构在上海进行异地4G连接备份。

1.2路由规划
空港及亦庄数据中心之间运行BGP路由协议，各AS之间建立E-BGP邻居关系交换路由信息，各AS内部两台城域网接入路由器之间建立I-BGP邻居关系交换路由信息。通过路由协议属性制定策略实现路由选择，达到主备或负载均衡的目的。另外，北京的分支机构也作为一个独立的AS自治域，通过BGP分别连接数据中心和同城灾备中心，建立E-BGP邻居关系，AS内部四台城综网接入路由器之间建立口子型连接，建立I-BGP邻居关系。从而实现在无需人为干预的情况下，核心骨干网对链路震荡和协议震荡的自动容错和修复能力。

2.操作单元封装
操作单元封装是指针对需要在三地数据中心进行的业务操作，封装成独立的业务操作单元。同时这些业务操作单元是需要在三地数据中心之间确保一致性。

如果要把用户操作封闭在一个单元内完成，关键的是数据。跟冷备相比，异地多活大的风险在于，它的数据会同时在多个地方写，冷备则不存在数据会写错的问题。如果多个地方在写同一行数据，那就没有办法判断哪条数据是正确的。

为了实现该操作单元封装，必须确定数据的维度。银行除了用户本身的信息以外，还会有相关业务产品的数据、账户信息等数据。操作单元化时，走向异地的就是业务的核心链路，所以我们选择了个人储蓄这个维度。但是这样自然会带来一个问题，当操作操作其他单元数据时，就无法封闭了，因为这时一定会出现需要集中到一个点去写的现象，所以操作单元封装必须要在路由一致性以及业务数据维度都已完全具备的条件下开展。
    

3.数据一致性

 数据一致性依靠数据库、存储和网络技术等要素来支撑，其中存储同步复制提供应用对于本地存储的有效访问，并解决数据中心之间进行远程数据同步的问题。

鉴于我行目前营业网点及客户主要分布在北京市，异地数据中心带宽较低的情况。在三地多活的存储应用中，目前我行使用建立“一主两个从”的存储机制，即三地共同使用同一数据库，确保同步复制的正确性和***性。当一地数据库故障，或发生灾难性事件时可切换其他可用数据库保障业务持续运行。

三地数据中心配备我行专职运维队伍，包括现场负责、系统、网络、应用及运行支持等人员，承担日常现场运维工作。各灾备中心监控、操作、变更等各项管理要求和操作流程纳入运行维护中心一体化管理。


项目创新点
1.全局负载均衡设计
全局负载均衡根据站点的健康状况和用户的就近将访问请求智能地解析到不同的数据中心和线路，用户根据解析的IP地址访问业务，将业务可以比较均衡地分摊给多个数据中心，同时还可以根据实际业务承载能力根据比例划分各中心分配权重。

当某个数据中心出现故障，或者某条运营商线路出现故障的时候，通过健康检查可以探知，后续请求将不再解析给问题站点/线路，当故障恢复后，将重新把业务分发给它们。

2.操作单元封装
操作单元封装是指针对需要在三地数据中心进行的业务操作，封装成独立的业务操作单元。同时这些业务操作单元是需要在三地数据中心之间确保一致性。

如果要把用户操作封闭在一个单元内完成，关键的是数据。跟冷备相比，异地多活大的风险在于，它的数据会同时在多个地方写，冷备则不存在数据会写错的问题。如果多个地方在写同一行数据，那就没有办法判断哪条数据是正确的。

3.数据一致性
数据一致性依靠数据库、存储和网络技术等要素来支撑，其中存储同步复制提供应用对于本地存储的有效访问，并解决数据中心之间进行远程数据同步的问题。

技术实现特点
1.全局负载均衡设计
全局负载均衡根据站点的健康状况和用户的就近将访问请求智能地解析到不同的数据中心和线路，用户根据解析的IP地址访问业务，将业务可以比较均衡地分摊给多个数据中心，同时还可以根据实际业务承载能力根据比例划分各中心分配权重。

1.1互联网全局负载均衡
在亦庄数据中心、空港中心、上海中心互联网出口处分别部署全局负载均衡。通过互联网线路对亦庄数据中心、空港中心、上海中心的业务地址进行检测，根据一定的负载均衡策略，将互联网用户的访问请求解析到健康状态良好的站点。

1.2内网全局负载均衡
在亦庄数据中心、空港中心、上海中心内网分别部署全局负载均衡。并且按照用户离数据站点就近访问原则以快的速度让用户体验对外发布的业务信息；再有就是各个站点之间需要实时探测对方健康状态，如发生某一侧站点丧失服务能力时存活的站点需要把业务自动全部接管过来。这个功能通过DNS域名智能动态解析实现。

2.操作单元封装
操作单元封装是指针对需要在三地数据中心进行的业务操作，封装成独立的业务操作单元。同时这些业务操作单元是需要在三地数据中心之间确保一致性。

如果要把用户操作封闭在一个单元内完成，关键的是数据。跟冷备相比，异地多活大的风险在于，它的数据会同时在多个地方写，冷备则不存在数据会写错的问题。如果多个地方在写同一行数据，那就没有办法判断哪条数据是正确的。

为了实现该操作单元封装，必须确定数据的维度。银行除了用户本身的信息以外，还会有相关业务产品的数据、账户信息等数据。操作单元化时，走向异地的就是业务的核心链路，所以我们选择了个人储蓄这个维度。但是这样自然会带来一个问题，当操作操作其他单元数据时，就无法封闭了，因为这时一定会出现需要集中到一个点去写的现象，所以操作单元封装必须要在路由一致性以及业务数据维度都已完全具备的条件下开展。

3.数据一致性
数据一致性依靠数据库、存储和网络技术等要素来支撑，其中存储同步复制提供应用对于本地存储的有效访问，并解决数据中心之间进行远程数据同步的问题。

鉴于我行目前营业网点及客户主要分布在北京市，异地数据中心带宽较低的情况。在三地多活的存储应用中，目前我行使用建立“一主两个从”的存储机制，即三地共同使用同一数据库，确保同步复制的正确性和***性。当一地数据库故障，或发生灾难性事件时可切换其他可用数据库保障业务持续运行。

项目过程管理

本项目历时2年。前期调研考察1年；基础设施建设3个月，各个设备安装调试9个月。

项目运营情况
目前我行5个重要业务实现同城两中心双活，柜面应用系统实现两地三中心多活。

项目成效

 一是建立起“两地三中心”的数据中心运行模式，进一步增强了我行信息系统业务运行的连续性、可靠性。相对于灾备中心冷备的模式下，如果生产数据中心瘫痪，需要两个小时、甚至更长时间才能启动灾备中心，在启动灾备中心的时间里，用户交易会严重受损。“三中心多活”在强化了应用层面的容错和故障处置手段之后，在主数据库故障时，应用可快速把主数据库切换到其他机房的从数据库。理论上任何一个数据中心中断都不会导致业务中断，切换过程也非常快捷。

二是灾备中心建设的投资巨大及每年运维成本极高，如果资源处于闲置状态，资源是相当浪费的。三中心多活的运行模式把闲置的资源整合，充分利用资源，避免了灾备数据中心常年处于闲置状态而造成浪费。

经验总结
该项目在实施过程中，逐个实施路由一致性、操作单元一致性以及数据一致性，对于我们来讲带来了三大成果：
一是以业务数据为维度的操作单元划分。对业务数据维度的分析，形成业务操作单元是所有多活技术的基础，在单元化可以宣告能力基本成熟的阶段，就可以起用距离在1000公里以上的另外一个数据中心，然后在数据中心是多点部署； 

二是有极强的水平伸缩能力。在单元的情况下，一组单元就是多大的能力，然后只要按照单元扩充就结束了，整个伸缩能力会比以前强大非常多。而且每个单元都是写自己的数据库和存储层，包括cache自动写入，这个时候伸缩规模是可控的，不像以前不断加，数据库有可能抗不住。在抗不住的时候可能会做分布等等，但其实也是比较复杂的，现在我们改变了伸缩力度的模式；

三是三地多活的应用故障应对。对全行近两百套应用系统进行全面梳理和服务水平分级管理，形成了各应用系统的三地多活规划设计方案，比如DNS等等，我们会按照这个对每个业务，然后就知道每个业务当出现故障时整个应对能力是怎样的。

本文由2018年度农村金融科技创新优秀案例评选组委会授权发表，转载请注明出处和本文链接。