张家港行为什么要迁移核心系统？又是如何选定了国产数据库 TDSQL 的解决方案？整个迁移过程是如何做的? 迁移完成之后，效果如何？张家港行案例对其它银行核心系统改造有哪些借鉴意义？...... 为了搞清楚以上问题，我们专访了参与张家港行国产数据库迁移全过程的腾讯云 TDSQL 首席架构师——张文。

行业内通常认为银行的业务分为两部分，传统业务和互联网业务。其中，传统业务指的是和实际卡相关的业务，而互联网业务指的是与实际卡无关的业务，例如电子账户、无卡支付等业务。通常来说，针对这两种业务银行会有两套不同的核心系统，分别为互联网核心和传统核心。互联网核心大多为近几年的新系统，没有太多历史包袱，所以针对于互联网核心的数据库改造相对传统核心无论风险还是难度都小得多，并且在行业内已有成功案例。但是张家港行比较特殊，没有区分互联网核心和传统核心，而是出于业务复杂度和用户规模等等的考虑，把互联网核心放到了传统核心里面。

张文用一句话总结了张家港行的业务特点，那就是一套核心系统支撑了全行的传统业务和互联网业务。

张家港行的系统非常多，我们可以简单的划分为两大部分，核心系统和外围系统。如果把核心系统比作心脏，那么外围系统就是四肢，所有与钱相关的操作都要经过核心系统。核心系统的业务逻辑是为关键的，因为它与银行核心资产数据是直接相关的，而外围更像是一个渠道，后都要去核心系统中进行核算和清算，比较典型的外围系统：手机银行、贷款、网银、ATM 等等。

据了解，本次迁移的核心系统的数据量在 TB 级，包括了账户、账目、流水、账单、日志等数据。张家港行系统建设方长亮科技表示其核心系统主要分为两大部分，一个为交易子系统，总共有 70 多个结构，覆盖银行卡、资金管理等等；另一个为会计子系统，主要是资金的交易分离、清算总账。

综上所述，核心系统不仅本身系统结构复杂，且还与各个系统都有联系，因此它的数据库迁移是复杂、难度大的。

1.张家港行对于数据库的要求

在迁移之前，张家港行使用的是 Sybase 数据库，从业务系统到数据库的整体架构大概还是十多年前的架构，不可避免地会遇到性能瓶颈问题，尤其是在高峰时段，数据库的吞吐量低，机器负载高，业务响应缓慢，已无法满足当前的用户请求量。在张文看来，性能问题是当时张家港行当时的大痛点。

在选择数据库时，张家港行有哪些关注点呢？

• 数据一致性以及分布式事务可靠性。银行数据关系着金钱，任何一条错误数据造成的损失都无法估量；

• 性能。高峰期能否扛得住业务压力，各项业务响应时耗能否满足要求，跑批类业务能否在规定时间内完成；

• 高可用。出现故障多久可以切换，切换过程能否保证数据不丢不错；

• 稳定性。TDSQL 首先基于 MySQL 生态进行研发，MySQL 作为全世界流行的数据库之一，在全世界范围内有无数使用者，同时其背后有无数社区的开源爱好者作为强大的技术后盾；其二，TDSQL 在腾讯内部经过数十年的持续研发和验证，支撑内部海量支付交易场景，踩了足够多的坑，积累了大量的实践经验，所以稳定性有保障。

• 业务改造量。从集中式迁移到分布式，这其中的改造量必须可控，如果工作量太大超过预期时间，那么就必须考虑其它方案了；

以上是一些比较重要的关注点，除此之外，还有一些其它考虑事项，例如运营成本、员工培训、上手难易程度等等。

2.迁移方案：分布式与集中式并存

2018 年年初，腾讯云接触到了张家港行，当时张家港行的一个缴存水电费的外围系统想要尝试国产分布式数据库，经过若干轮 POC 测试终选择了 TDSQL。2018 年 8 月左右，张家港行准备对核心系统进行改造，原计划数据库采用国外某商用数据库，但是张家港行科技部考虑到目前已有一个外围系统使用了国产分布式数据库，并且运行期间非常稳定，那么这次核心改造是否也可以考虑分布式数据库？

据张文介绍，“当时张家港行有两个选择，一是集中式数据库，二是分布式数据库。大部分银行在做核心系统升级时都会选择国外集中式的商业数据库，虽然技术掌握在别人手中，但它是国内无数银行普遍使用的数据库，并且国内银行核心系统也没有使用国产分布式数据库的先例。”

在改造时，张家港行做了一个大胆的决定：同时开发两套新核心业务系统，一套基于国外某商用数据库而另外一套则基于 TDSQL，然后进行“内部赛马”，一年之后对两个系统的稳定性、性能进行对比测试，根据测试结果再决定使用哪套。张文表示：“经过整整一年的改造，无论是从性能成本，还是易用性，分布式数据库都表现出明显优势，进而终新核心系统采用了 TDSQL 分布式数据库，而之前采用集中式数据库的核心系统则保留为灾备系统。”

3.核心系统迁移遇到的挑战

相信很多人都很好奇张家港行核心系统的整个迁移过程，在采访中，张文讲到：“整个实施过程分为两个阶段，个阶段是功能性改造，第二个阶段是性能优化。整个改造过程是从简单到复杂，我们是先从高频交易入手，集中处理与高频交易相关的业务以及子系统，然后是跑批类交易，跑批与高频交易相比，SQL 相对复杂冗余但是占总交易类的比重较低。解决了高频交易其实就已经解决了 99% 的问题，这个过程积累了丰富的调优经验，这些经验再应用到其它业务系统中可以更方便迅速地解决问题。”

当然，从集中式数据库转变到分布式数据库由于数据组织方式的差异，不可避免地带来一系列问题，例如语法差异、性能差异、兼容性问题等。

• 从集中式架构转变到分布式架构，要求所有的库表都要重新设计，这是所有数据库做分布式改造时都无法避免的问题。之所以需要重新设计库表，是因为分布式数据库引入了分片关键字的概念，如何根据全局业务，选择佳的数据分布策略，是分布式改造需要面对的首要问题。即使确定了分片关键字，还需要对该分片关键字以及索引做持续优化调整以寻求佳实践；

• 兼容性差异，包括两部分：Oracle 生态与 MySQL 生态、集中式架构与分布式架构的差异，如何解决这个问题呢？针对 Oracle 支持的语法但 MySQL 不支持这个问题，TDSQL 做了大量对 Oracle 语法兼容性的优化。对于一些不太适合分布式场景下的使用特性如：存储过程、视图、触发器等，业务之所以用到这些特性，是因为将很多业务逻辑也放在了数据库中，这一定程度上导致了扩展性不足，TDSQL 团队与行方、核心系统开发商长亮科技进行了仔细的分析与评估，将更合适放到应用层的部分逻辑上移，实现了更为彻底的分布式架构，极大提升了整体的水平扩展性。

• 复杂 SQL，在集中式数据库中，由于数据集中存储在一个节点上，SQL 无需考虑跨多个节点关联问题。而在分布式数据库中，数据是打散在多个节点上的，一条复杂 SQL 可能会涉及到多个数据节点，此时会导致数据库性能急剧下降。针对复杂 SQL 问题，业务侧通过调整分片关键字和复杂 SQL 拆分两个方面做优化，让 SQL 尽可能限制在一个数据节点内。当然，必定会有一些 SQL 由于其业务逻辑的特殊性（如：银行跑批类业务），无法避免跨多个数据节点的表关联。针对这种情况，TDSQL 做了大量针对复杂 SQL 的优化，如：子查询上提、左连接消除、丰富下推逻辑以及基于统计信息的条件推导逻辑等，尽可能提高处理这种复杂 sql 的性能。

4.迁移完成之后的运行效果

2019 年 8 月 16 日下午 6 点，张家港行挂牌停业，正式开始进行新核心系统的上线工作。首先进行的是数据库割接，在割接期间完成了原有数据的倒出、TDSQL 数据的倒入以及中间数据的加工校验。48 小时之后，也就是 2019 年 8 月 18 日下午 6 点，整个改造工作结束，新核心系统成功跑在了 TDSQL 数据库上，张家港行正式对外开业。从正式上线至今已有一个多月，在这一个多月的时间里，数据库运行稳定各项指标均正常，即使业务高峰期数据库也维持极低负载。

在性能方面，迁移后的核心系统也有了很大的提升，张文列举了一些性能方面的具体数据指标：

• 高频账户类交易耗时在 300 毫秒之内

• 查询类交易耗时在 100 毫秒之内

• 20 秒内可以完成 1 万笔批量代发代扣业务

• 日终跑批耗时 14 分钟

• 存款结息耗时 11 分钟

• 贷款结息耗时 3 分钟

张文表示：“批量业务进行时，数据库负载均保持在 10% 以下，这样的性能完全可以满足张家港行未来五到十年业务发展需求。TDSQL 还能发挥分布式数据库在线横向扩展的优势，如果后续业务发展有需要时，只需加入硬件资源，便能够自动水平扩展化解性能瓶颈。”

在成本方面，张文表示不太方便透露具体的数据，但是他给我们算了一笔账，“张家港行在硬件层面采用传统的 X86 服务器，取代了大型机、小型机。以近期上线核心系统的某商业银行为例，传统的商业数据库都得用大型机、小型机，综合硬件成本大概在 4000 万 -5000 万，系统处理能力大约为 8000 TPS。而张家港行这边的硬件成本不到 1000w，综合降低成本 75% 以上，吞吐量达到了 6200 TPS，并且支持横向扩展。”

张家港行的案例对于其它银行有哪些借鉴意义呢？张文表示：“重要的一个经验就是先跑通再优化。”具体来说，就是先要跑通兼容性问题，兼容性问题解决后再攻克性能问题，并且从兼容性到性能是一个持续优化的过程，同时也是一个寻找分布式数据库佳实践的过程。根据 TDSQL 团队的经验，按照从高频交易到批量业务的顺序来解决问题是效率高的，问题的复杂度会逐步降低。

核心系统与外围系统在重要性、业务逻辑复杂度等方面有很大的差异，因而也决定了其改造难度的不同。从重要性来讲，核心系统是所有系统的心脏，所有和钱有关系的操作都要经过核心核算、清算，因而核心系统出现问题会导致全行业务中断甚至瘫痪；相对来说外围系统一般都只关联一个特定业务，其故障一般不会造成全行业务的瘫痪；从业务逻辑来看，由于外围系统一般只涉及特定的业务对其改造只需考虑对应业务即可，而核心系统是所有系统的中枢，对其改造需要梳理所有和其相关的业务；从兼容性来看，外围系统相对来说新系统居多，没有太多的历史包袱，可以从零开始而不需要考虑太多兼容性问题。而核心系统就没有这么简单，例如张家港行核心从集中式平滑过渡到分布式数据库过程中需要考虑无数兼容性适配问题。

针对银行核心系统的数据库，通常银行的做法是沿用、并存或者替代，目前大部分银行的数据库战略是沿用、并存，而地方性股份制银行可能走得更快一点，在沿用、并存的基础上尝试国产化替代。对此，张文表示：“核心系统是银行业务系统的心脏，而核心系统的数据库就是心脏中的心脏，针对核心系统的数据库进行改造的难度无异于做一次心脏更换手术。在国有自主可控的大背景下，再结合性能、成本考虑，银行试水互联网公司的分布式数据库已经成为一个趋势。性股份制银行，相比于地方性股份制银行步子迈得可能稍微慢一些，但是也是为了更稳一些，因为大行相对而言历史包袱更重，迁移工作量和难度更大。当然，我们也看到越来越多的大型银行机构也在积极参与，积极探索核心系统数据库的国产化改造。这是一个循序渐进的过程。”

张家港行核心系统数据库改造案例公开之后，很多行业工作者认为这是个标志性事件。对于标志性，张文是这样理解的：“首先，这个案例证明了在银行核心系统中，长期被国外所垄断商用数据库是可以被替换为国产分布式数据库，并且替换后带来更强劲的性能指标，更低廉的软硬件成本以及更符合中国人操作的用户习惯；其次，对于腾讯云来说，这也是一个具有代表性的案例，未来可能会将该模式复制到其它银行客户中。”