FinTech Members | 平安银行ECIF系统重构的实践——访平安银行金融科技部云数据运营中心总经理宋歌

在金融行业全面迈向自主可控与数字化转型的关键节点，底层技术架构的变革已成为银行核心系统演进的必然选择。传统集中式架构在容灾、流量分担及运维等方面存在固有局限，难以满足业务对弹性扩展与连续性保障的更高要求。平安银行在探索分布式架构转型的过程中， ECIF（企业级客户信息）系统尝试数据库层迁移到分布式数据库OceanBase的转型案例，探索出 “应用最小化改造”的平滑迁移路径，在高可用架构、资源集约部署及运维效能提升等方面取得了实质性突破。

在接受本刊记者专访时，深圳市金融科技协会网络与信息安全专委会副主任委员、平安银行金融科技部云数据运营中心总经理宋歌结合该行架构转型实践，系统阐述了其在技术选型、高可用设计、风险管控及成本优化等维度的宝贵经验。平安银行数据库从集中式到分布式的平滑迁移，再到同城双活的构建，这个过程中不仅实现了业务无感切换，系统的性能与可用性、扩展性也有较大幅度提升。同时在实施过程中吸收新技术栈优势与能力，并融入到自身现有技术架构和自动化平台工具中，也为行业提供了切实可行的实践参考。

宋歌：平安银行的数据库选型策略是基于当时应用系统使用传统集中式数据库的现状做出的系统化方案。共选型了三种数据库，分别用于满足三种典型的业务场景。三种数据库分别是集中式、分布式、分析型。其中集中式数据库用于开放架构应用和单元化及分库分表应用场景，分布式数据库主要用于对传统数据库特性有较多依赖的应用，同时又有较强的系统扩展要求的场景，而分析型数据库则用于批量和分析混合负载的应用场景。

选型一：集中式数据库主要是适配开放架构关系数据库的需求，该架构方案要求应用轻量化访问数据库，业务逻辑由应用实现，系统扩展性通过分库分表和单元化架构实现，主要依赖其较强的高可用能力，数据跨IDC强一致性能力，可实现跨IDC RPO=0，RTO<=60S。

选型二：分析型数据库，主要适配混合负载的HTAP应用，轻量化分析应用场景，是对以上场景的补充。主要依赖其不错的批量性能，强大的横向扩展能力，以及不需要应用层分布式改造成为这种场景的首选方案。

选型三：分布式数据库，主要适配传统集中式数据库架构下应用较多依赖数据库特性，系统的扩展性也需要数据库支持，以及不太容易进行应用层的分布式改造的场景。因此选择分布式数据库，是综合考量传统数据库兼容性、综合成本与系统性能后的决策，其高度兼容的语法能大幅降低迁移时系统的开发改造成本。

虽然平安银行选型的分布式数据库对传统数据库的兼容性很好，但是使用细节上，无论功能还是性能都和传统数据库有不少差异之处，为此DBA总结了详细的指引。比如遇到比较多的问题是存储过程要不要改造，虽然大部分存储过程平迁过去就能够运行，但是往往性能会下降很多，应用对性能有要求的场景就不得不改造了。加之平安银行技术栈一直是在向互联网架构和云原生转型，数据库层尽量只实现简单的存取功能，减少数据库特性的依赖、将复杂的业务逻辑上移到应用层实现是运维和开发的共识。

我国数据库发展迅猛，有很多优秀的厂商和产品，但是想要只选择一款产品就能适配所有复杂应用场景还是有点困难，因此平安银行的经验是结合具体的应用场景选择最适合的产品。没有最好的，只有最合适自身业务场景需求的。

宋歌：作为平安银行的客户数据基础核心系统，ECIF 是所有交易链路的源头，上下游系统众多。为保障关联系统平稳运行且接口不变，ECIF必须实现平滑迁移。迁移过程中面临两大主要挑战。

挑战一：数据库功能深度耦合。传统架构下，ECIF大量功能深度依赖传统数据库的存储过程、函数及触发器等底层技术，需要把应用和数据库解耦。因此项目首先实施了“数据库轻量化”战略，将原有数百个存储过程、触发器和定时任务全量上移至应用层，由应用代码实现。然后，针对新数据库重构库表对象。通过分区表改造，表组的设计等手段，使得应用接口不变的情况下新数据库性能最优。最后，全面优化SQL兼容性。建立覆盖高频交易场景的核心SQL清单；通过执行计划固化技术，确保关键SQL保持最优执行路径；对语法兼容性问题实施分级处理，确保核心交易SQL性能达标率达100%。

挑战二：缺乏成熟的迁移保障工具。针对此问题，平安银行自主研发了四个关键工具。一是自研非侵入式数据库双写组件，基于Spring Boot子容器与MyBatis插件拦截的技术实现拦截 SQL 和并行双写功能。该方案通过拦截所有写入SQL，并在子容器中实现往目标数据库的并行写入。通过这种“双写+功能开关”的设计，实现了迁移过程中的零停机切换与无感回切。二是开发基于流量镜像的API 报文差异比对功能，解决“业务逻辑等效性”验证功能。为了验证数据库双写的情况下，新旧数据库无论SQL语句是否相同，最终结果的语义都必须是相同的，为此开发了基于流量镜像的API 报文差异比对功能。三是运用流量录制与回放技术，模拟超高业务压力进行测试，提前排查并优化性能隐患，解决分布式架构下的性能下降问题。四是研发 SQL 异步并发查询框架，将串行查询转为并行执行，解决“吞吐量瓶颈”。通过对可并行化的查询操作进行池化封装与异步编排，将原本串行的 I/O 耗时转化为并行执行。这种方案显著提升了系统吞吐量，并成功使分布式架构下的系统响应达到与Oracle同等的水平。

基于上述的实践考虑才形成了“整体平替+局部优化”迁移思路，可以说这既是追求应用自主可控的主观需要，也是实际替换过程中不断积累经验的具体实践。近两年平安银行加速了自主可控的替换进程，基于前期的经验积累，通过准确分析替换过程中的实际需求和潜在问题，建设了全线上化的迁移改造工具，涵盖技术选型、方案评审、测试验证、数据迁移、增量同步、一致性校验、双写验证、灰度流量切换等一系列流程。正确的方法论和较为完善的线上自动化工具平台，使得保质保量地完成大量系统的平滑迁移。

宋歌：严格意义上来说平安银行是“两地三中心”同城“双活”的架构，还没有做到“两地三中心”多副本“多活”的部署，当然这是平安银行正在追求的目标。双活和多活都面临一个相同的挑战，如何平衡数据一致性与交易性能？平安银行的解决思路，是通过架构设计与技术优化实现两者的平衡。

首先，通过就近访问策略降低跨机房延迟。在应用层实现了基于机房的流量路由，将业务请求优先路由到本地机房的数据库节点，避免跨机房访问。

其次，通过读写分离优化交易性能。将读请求优先分发到同城备节点处理，写请求则发送到主节点，再通过复制同步到备节点。这样既保证了写操作的强一致性，又通过读请求的分流降低了主节点的压力，提升了整体性能。

再有针对交易敏感场景，团队还进行了针对性优化。例如，在客户开户、信息变更等核心交易中，放弃分布式多节点的计算能力，采用单元化架构切分应用，每个单元的数据库层依旧采用主备方案，确保写请求在单个主节点，避免数据库产生分布式事务。

要实现真正的应用“多活”架构，可能应用需要做更多的改造，比如应用关联调用需松耦合、异步化，减少单个请求与数据库的SQL交互数，交易的幂等性设计，数据由强一致改造为最终一致性等。

宋歌：从集中式向分布式架构转型，最直观的感受是运维对象数量和复杂度的指数增长，顺利的完成转型需要的不仅是技术更替，更是运维思维与组织效能的升级，在多方面带来深刻变革。

一是变革IT技术体系：从依赖硬件冗余转向软件高可用，实现快速故障恢复、降低故障影响。二是升级运维平台：传统集中式运维像“放牛”，单机强、易管理；分布式运维像 “赶鸭子”，节点多、协同难，必须搭建专业化平台实现高效管控。三是提升观测能力：要快速在众多“鸭子”中找到捣乱的那只。持续加强观测能力，落地基于流量和日志的全链路观测，包括东西向业务链路、南北向资源链路，以及事前、事中、事后基于运维数据的复盘。四是进阶自动化能力：平安银行大部分自动化能力都是团队自研，但转型分布式后，自动化已经不够用，变成必须依赖AI。五是演进团队能力：运维人员从专精单一技能向全栈工程化升级，逐步掌握分布式、云原生与自动化能力，实现向SRE全栈工程师的转型。实际上，行业对运维的传统定位往往偏中后台，需要发声，推动运维能力更加前台化——即所说的“左移”。

宋歌：智能运维作为平安银行未来三年规划的重点工程，部分领域已经开始有一些探索和实践。以与分布式数据库融合为例，已经做了下面几个探索：依托机器学习搭建智能巡检模型，通过分析实时运行数据，提前预判节点异常、慢SQL等隐患，实现自动告警并给出优化建议；针对分布式数据库告警种类众多，正在研究通过AI帮实现告警降噪，同时对于复杂故障，尤其是缓慢加重的故障场景，让模型能够提早发现，早做应对。对于已经发送的告警，通过完善知识库和处置SOP，希望能够实现一键诊断，在此基础上，正同步探索AI驱动的故障根因定位与自愈能力，为实现“1-5-10”运维目标构建核心能力支撑。

AI技术发展日新月异，业内普遍对AI的整体大方向已形成共识，但具体的技术实现路径仍在快速迭代、时刻变化的过程中。对运维而言，万变不离其宗，首先需要把数据和知识准备好。内部有一个比喻，数据是AI的燃油。因此，运维工作的当务之急是做好数据治理，让数据具备被AI消费的能力。

AI在运维中的应用还有非常关键的一点，防止AI从“一本正经的胡说八道”，变成“一本正经的胡作非为”。因此，在最关键的环节做到“human in loop”。平安银行现在正在建设数字员工，对这些数字员工的权限管理，必须进行全面的重构和梳理，这类工作都要先于具体AI技术应用的前面做好准备。

在具体应用场景上，各家银行会有各自的侧重点，比如容量预测、智能巡检、智能变更、智能审计等。今年，云数据中心的工作重点聚焦于根因分析、故障定位、容量预测三大方向。此外，还将借助AI提升智能审计的覆盖度。