国产化可不是复制粘贴

大家都叫金融系统，但不同系统的需求差异性还是极其明显的。比如说银行系统作为 7*24 小时全程实时在线的系统，对可靠性的要求极其严苛，RPO、RTO 就是核心两个关键指标，为了更好的风险把控也能接受更多的容灾成本，但反过来，银行业务流相对稳定，高并发下的弹性扩缩容可能不是第一优先级；

与此同时，证券系统在非交易时间可以完成很多离线的分析工作，可靠性需求相对低一些。但同样的，证券系统的系统核心难点主要在于数据源问题，相比于银行系统以帐号为核心，结构相对简单，证券侧数据源包括个人、公司、基金公司之类，数据分层可能是它最高的要求。

但相对而言，国有大行因为其资金量大、覆盖面广、可靠性要求高，以及说相对历史沉淀比较深，是迁移难度最大的核心系统，业内将其戏称为“皇冠上的明珠”，只有摘下“明珠”才有资格坐上“系统迁移”的大玩家桌上。

前段时间看到阿里云公众号讲述了一个保险公司的数据库迁移案例，它主要特点体现在大，关联系统多，相对对迁移的效率提出了要求。

而前段时间在新的一期《腾讯云工具指南》中看到其介绍了一个银行信用卡系统利用 TDSQL 分布式改造的案例，而这个案例主要体现的是不中断，应该说各有千秋，在腾讯这个案例里可以看到它在细节把控上的优势。

首先是这个案例的背景，跟很多大银行一样，他的传统架构是集中式的，在软件层存在较大的依赖性，维护成本高、创新能力受到底层服务框架的极大制约，旧核心的关系型数据库以 Oracle 等传统集中式数据库为主，MySQL、PostgreSQL 等为辅，在业务快速发展、数据量和系统负载爆发式增长的背景下，IT 核心系统单纯靠垂直扩展已经无法满足时效和性能要求——所以既然要迁移，希望说是一套业务交付灵活且有弹性的方式。

整个迁移过程很长，这里面我就说几个点设计挺有意思：

1）架构上，它是基于私有云和 PaaS 平台建设，实现了应用微服务化，通过拆分解耦，提升了快速创新能力。采用 DSU 单元化分布式架构方案，提高了系统的并发处理能力、隔离故障能力和灵活扩展能力。

这种云原生架构，能够保证未来的弹性，也可以支持横向扩容和纵向的在线扩容。

2）运维上，每家云厂商都会有自己的自动化运维平台。腾讯云的叫做“赤兔”。这个分布式运维平台集统一管理、智能监控、容量管理、多租户管理、容量管理为一体，具备一键切换、资源扩容、数据同步等功能。

但其实我最关注的，是它开放接口的能力，与原有运维平台的对接与打通，包括核心的发布工具、比对工具等。

3）DBA 层面，这主要是对我们打工人更加友好。TDSQL 有一套智能诊断平台“扁鹊”。他最大的特点就是以应用为中心，通过业务标签快速定位整个业务流哪个环节出了问题。

尤其是微服务架构下，端到端链路更长了之后，以前以数据库为中心的形式，一个应用上百个 sql 语句，定位就要消耗很多的时间。以“扁鹊”来定位速度会大大地提高，也极大的避免了老板们的讳疾忌医。

整个迁移完成后，新核心系统实现了信用卡系统支持 10 亿级交易账户和 10 亿级日交易量的目标，也保证迁移过程业务不停滞。

其实数据迁移本质并不会影响服务中断，是迁移完成后的切换可能涉及服务终端，而腾讯云通过周全的前期准备与应用层的重连机制把切换速度压缩至秒级别；在此基础上，TDSQL 为该信用卡系统打造了“交易级账户”、“立体化额度管理”、“多租户运营”三大核心业务能力；技术体系支持敏捷开发、灵活创新和稳定运行。

更重要是长期的成本下降。根据实际的测算，以 5 年为周期，新核心系统相比老系统成本节约近 70%，节省费用超 10 亿。在可靠性方面，通过可视化分布式调度平台，支持金融级高可用，同城双活异地灾备，故障场景下秒级切换。

而在性能上，TDSQL 能够支持 10万+ 业务作业统一处理、跨地域分布式调度以及可视化管理，满足金融级核心系统的要求，支持 10 万 TPS 交易高并发，相比老系统的交易处理能力提升了数十倍，日终业务批处理小时级时效，并具备无限横向扩展能力。

金融系统的迁移方案虽然道理都很简单，就是满足迁移过程的平滑，迁移结果的完整安全，以及迁移后系统的稳定及可持续。但具体到每个金融系统，每个不同的银行，甚至每个细分的业务都需要不同的前期评估，工具匹配，各种应用侧的兼容测试。

在最新一期《腾讯云工具指南》中，腾讯云介绍了数据库 TDSQL 在信用卡系统迁移的应用之外，还包括面对复杂租户体系的私有云部署；用存算分离如何替代 CDH 大数据系统，以及说很多制造、能源企业最关心的，CentOS 停服后，底层操作系统的迁移方式等具体的实践部署案例，有兴趣的小伙伴可以下载瞅瞅，没准可以找到你工作中对应的痛点问题。

👇点击图片即可获取最新指南👇