北京银行系统运营中心副总经理（主持）宗勇涛

引言

国家发布的《经济和社会发展第十四个五年规划和2035年远景目标纲要》指出，“稳妥发展金融科技，加快金融机构数字化转型。”

中国人民银行发布的《金融科技（FinTech）发展规划（2019-2021年）》提到，“建立健全我国金融科技发展的‘四梁八柱’，进一步增强金融业科技应用能力，实现金融与科技深度融合、协调发展。”

从相关政策文件看出，金融科技建设、金融数字化转型已上升至国家战略高度，对筑牢现代经济中的核心地位、驱动国民经济发展、深化金融供给侧结构性改革具有重要意义。

随着云计算、大数据、人工智能、区块链等信息技术的快速迭代，极大地促进了金融科技的创新，加快了金融数字化转型的进程。多年来，北京银行积极探索金融数字化转型建设的发展方向，围绕金融业务安全，从业务线上化、服务智能化、运营自动化等方面入手，打造稳定、可靠、高质量的金融服务。

本文将分享北京银行在多数据中心业务连续性、保障业务安全、实现业务多活建设等方面的工作思路、方法与经验。

金融科技ICT架构面临的挑战

1.多数据中心容灾场景面临的技术挑战

业务系统数量众多、互访逻辑复杂、犬牙交错是银行信息系统的主要特征。在基于IP的业务交互模式中，IP与业务强关联，牵一发而动全身，一个业务系统的某台服务器发生地址变更，整个业务链条甚至周边业务系统均需进行配合改动。因此，基于IP的业务交互模式，在实现多数据中心的主备切换和业务多活时存在诸多问题。IP地址的唯一性、灵活性不足、变更导致的路由重新指引等问题让灾备切换变得极为复杂、充满风险，RTO时长无法接受。

2.北京银行数据中心现状

北京银行已建成同城双活数据中心+异地灾备数据中心的“两地三中心”架构。为了实现平滑的业务容灾，打破IP业务强关联带来的局限性，经过多方位的技术论证与验证测试，最终确定了全网业务系统域名化改造方案，改变业务交互的基本方式，由IP指向变为域名指向；同时构建冗余、智能、灵活的域名服务体系，支撑业务交互基于域名实现容灾、流量牵引、精准调度，更好地实现多中心间的负载均衡、灾备业务迁移，保障银行业务的高可用性。

业务系统域名化改造经验分享

域名化改造是实现IP与业务解耦的关键环节，也是实现基于智能域名解析调度全网流量的前提。北京银行历时1年完成了各区域业务系统的域名化改造，涉及5个业务区，总体域名化率为100%（见图1）。

图1系统间域名化互访示意图

从最初在外围系统的探索到后期逐步深入核心，域名化改造历经多个阶段和环节，北京银行也总结出一套金融业务系统域名化改造的方法论。现将北京银行改造经验分享如下。

1.域名化改造难点分析

域名化改造工作牵扯业务交互过程、软件调用方式的改变，是一项涉及人员众多、跨部门的系统工程，需应用、网络、运维、业务、安全等多方面人员共同参与协商、齐心协力方能完成。因此完成该项工作的主要难点为跨团队的协调、制定改造计划、制定技术方案和时间表，需要克服改造过程中大量的技术、非技术问题。

2.域名化改造的四个阶段

阶段一：预调研。

该阶段需进行域名空间顶层设计、空间规划、管理规范、规章制度，容灾场景规划、定义业务的容灾等级，以及DNS服务设施架构确立等。

阶段二：可行性评估。

一是信息梳理。在确定了灾备、双活场景原则后，需梳理相关业务系统及应用信息，包括业务系统的英文简称、应用容灾等级、重要程度、交互情况、承载平台类型等信息，作为下一步域名改造计划和进度把控的决策依据。

二是改造可行性评估。对需做域名化改造的业务系统进行评估，评估其改造为域名交互方式的可行性，如是否支持域名调用方式、是否需二次开发适配等。

该阶段工作基于梳理的信息，需开展跨团队的技术讨论，评估改造的技术可行性，输出域名化改造进度规划、测试计划及生产上线批次时间表。

阶段三：测试与验证。

一是测试内容。在测试环境开展一系列DNS域名改造的相关测试工作，全面验证DNS在相关业务系统中应用的可行性，并基于测试结果修订生产改造方案和时间进度计划。

二是编制详尽的操作文档。基于测试结果编制详细的生产环境割接操作文档，文档中包括变更时间、操作过程、回退方案等，须有具体责任人和复核人员。

阶段四：正式实施。

生产环境改造进度安排，遵循如下原则：先非实时业务、后实时业务；先外围业务、后核心业务。前期改造外围业务系统，积累经验，发现未知问题，后期改造核心业务系统。

人员调配：开发、应用、网络、安全、三方厂商现场技术保障；业务人员留守，进行改造后的业务验证。

DNS基础设施建设及应用情况

域名化改造是实现基于域名进行业务流量走向精准控制的基础，DNS服务则是具体承载域名解析和流量调度的重要基础设施。DNS作为容灾调度的核心指挥，尤其在完成域名化改造后，所有的业务交互均依赖于DNS。因此DNS的建设需充分考虑高可用性、智能性，确保在各种极端情况下DNS始终可作为流量的总导航，服务不中断。

北京银行充分考虑了DNS服务的自身健壮性、业务容灾场景支撑能力等多方面因素，规划建设了一套高度冗余、灵活智能、运维便捷的域名服务体系。

1.DNS基础设施架构介绍

北京银行DNS基础设施的设计采用了管理与业务分离的架构，分为管理平面和服务平面。

管理平面：承担全网DNS解析节点的管理功能，实现配置的统一下发、DNS服务状态的实时监控、日志数据的收集统计与展示，实现运维管理的可视化、平台化、自动化。

服务平面：面向PC终端、服务器提供域名解析服务，同时感知业务系统的健康、负载状态，按照预设策略智能调整解析结果，精准控制业务流量走向，支撑业务灾备、多活场景。

2.北京银行DNS架构IP ANYCAST技术应用实践

（1）北京银行IPANYCAST技术应用介绍。在三个数据中心内部，部署了2套DNS解析集群，面向终端、服务器提供域名解析服务，每套集群均采用IPANYCAST技术架构，终端和服务器将两个集群做作为主备DNS，交叉互指。架构如图2所示。

图2内网域名解析集群架构图

（2）ANYCAST优势介绍。主要体现在如下几方面。

就近访问：位于某数据中心的服务器、终端的域名解析请求均会由集群中路径最佳的节点承载，即本数据中心就近解析。

高可用性：当集群中某节点故障后，随即自动退出ANYCAST集群，由集群中的其他节点承载服务。

负载分担：解析节点之间实现轮询式的业务负载分担，解析性能*N。

便捷扩展：当集群的解析性能出现瓶颈时，可便捷地扩展解析节点。

3.基于智能DNS实现灾备快速切换

在进行域名化改造之前，应急灾备切换演练是一项极其复杂的工作，网络和应用开发的负责人员需进行长时间的准备，编写地址变更脚本、核对切换方案、调整网络路由等，涉及人员众多，过程漫长，极易出现疏忽、遗漏导致切换失败的风险。

当完成域名化改造后，业务系统的数据流量全部基于DNS指引进行交互，通过制定合适的健康探测手段，结合多级的调度策略，即可便捷地实现手动或自动的灾备切换操作，极大地缩短了RTO时间。

北京银行目前正在大力开展双活业务的建设，主数据中心、同城数据中心将利用智能DNS的GSLB全局负载功能，感知应用健康状态，实现自动化的流量负载和灾备切换（见图3）。

图3故障场景系统切换示意图

互联网业务的多活应用实践

1.网银业务的多活负载：基于权重的比例负载调度模式

位于北京的主数据中心和同城数据中心均可面向互联网提供网银业务访问，根据同城两大数据中心的角色和服务能力的不同，通过配置解析策略，互联网用户在访问网银业务时，DNS根据权重比例调度用户的请求流量，主数据中心与和同城数据中心的业务承载比例为2：1，即主数据中心承载全部网银业务的65%，同城数据中心承载35%。

未来网银业务也将同时在异地灾备数据中心启用，实现三活，届时解析调度策略将作出适当调整。

2.基于用户来源属性优化网银业务的访问体验

国内存在多运营商的现状，各运营商独立组网，网间结算的成本较高，因此跨运营商的网络访问，存在延迟高、体验差的问题。北京银行的网银业务考虑了相关因素，在制定DNS解析策略时，通过判断来源用户所属运营商、地理位置的不同，进行合理的资源分配，避免用户跨网访问，提升用户业务访问体验。

3.健康探测与冗灾切换

常态下基于权重、地理位置和所属运营商进行流量调度，但在灾难场景下，DNS需要能感知到业务系统的健康状态，并基于感知的结果调整解析策略。在北京银行的全部互联网业务场景中，采用了智能DNS的宕机切换功能，实现灾难情况下的业务自动应急切换。

总结

后疫情时代，金融科技的重要性进一步提升，数字化转型进程大幅提速，科技力量从过去的支撑保障从属地位，向着引领和重塑的驱动地位转变，已成为金融行业最重要的核心竞争力。但同时我们也要清醒地认识到，科技在为金融业务带来高效率和高质量的同时，也面临着巨大的风险与挑战。在此背景下，金融机构业务系统快速可靠的容灾能力、业务转型的支撑能力、业务上线的交付能力，均是构成金融科技这座大厦的根基。

北京银行围绕筑牢金融科技根基，进行了一系列IT架构的技术改进与尝试，在保证金融业务连续性、优化金融业务服务体验等方面取得了一定成效。未来，北京银行将在金融科技领域继续积极探索，为中国金融科技的发展贡献自己的力量。