金融行业核心系统如何进行分布式改造？( 二 )

微众银行数据库平台负责人胡盼盼
谈到具体的落地实践，微众银行数据库平台负责人胡盼盼表示，分布式数据库的应用提高了微众银行整体IT架构的可靠性与容灾能力，目前，微众银行的TDSQL数据库规模有近3000个实例，数百个核心系统。整体架构采用TDSQL3+2五副本， TDSQLNoShard模式，实现了高可靠与高可用，同城IDC之间RPO=0 ， RTO秒级。
分布式改造怎么改?
银行等金融机构对于核心系统的改造都非常谨慎。光大银行数据中台团队负责人王磊介绍，核心系统改造有两种选择，一种是从应用层开始整体性进行分布式架构改造，涉及范围广，改动大，改造后业务响应更快速，整体更灵活;另一种不需进行系统性改造，应用分布式数据库，这样应用侧改造少，推进快，较为平滑。

光大银行数据中台团队负责人王磊
与会专家指出，如何改造还要根据企业组织的业务发展需要，不能为了分布式而分布式，比如，大型银行进行分布式改造，多是为了对越来越复杂的业务进行划分，有的小体量银行可能会面向未来，为了适应业务的增长需求而进行分布式改造。
如果决定了做分布式改造，保证业务连续性始终要放在第一位，田清波总结从技术层面来看，核心系统数据库替换时一般会考虑以下五个方面：
一是业务迁移。数据能否平滑迁移，迁移效率以及同步性能。迁移后数据一致性的校验，需要有成熟的迁移工具和迁移方案;
二是安全合规。满足金融监管要求，实现金融级数据安全，降低数据泄露风险;
三是可靠性、可用性。在各种故障灾难下，保障客户数据零丢失，保证99.999%的可用性。四是兼容性。更换数据库引起的业务SQL改造，兼容性适配的额外开发工程;
五是运营风险，数据库故障时自助定位解决问题的能力，响应时间，排查效率。
在进行核心系统改造时一般分为四个步骤，
第一步，引入云数据库，应用垂直拆分解耦，将业务解耦、数据解耦，底层使用分布式架构，增加容错率，整体业务的稳定性不会有单点风险;
第二步，单体实例垂直扩展。当数据库处理能力不满足现状时，可以弹性实例扩容;
第三步，单实例水平扩展，当数据库垂直扩展或者读写分离遇到瓶颈时，可以进行分布式扩展，应用适当调整。
第四步，进行单元化改造。据悉，微众银行的核心系统之一进行了单元化改造，可以在某单元里做灰度发布，某个单元里发生故障也不会影响整个系统。
如今国产数据库百花齐放，竞争激烈。银行在选型时除了关注数据库厂商的产品与技术，还会关注生态建设情况，如数据库周边生态，迁移工具等，行业ISV生态、软硬件厂商生态等。腾讯云数据库自研的数据库迁移工具DBbridge可以解决Oracle数据迁移工作，已经有了很多落地实践。
田清波介绍，目前一些大行和股份制银行更倾向于进行单元化改造。而一些城商行更多选择分布式改造。他认为核心系统分布式改造应该遵循“先跑通再优化，先高频再跑批，先简单再复杂”的原则，其中高频交易占了总交易量的90% ，要优先集中解决高频交易问题。
在讨论的过程中，有专家指出规模不大的小银行没有必要进行分布式改造，集中式可能更为合适，分布式所带来的网络开销等成本需要一定的规模化才可以覆盖。不过也有专家认为，受自主可控以及相关政策影响，银行会选择使用分布式国产化数据库，规模不大可以进行单节点部署，未来随着业务的增长也可以随时灵活扩展。值得一提的是为满足不同企业组织的不同需求， TDSQLforMySQL和TDSQLforPG均支持分布式和集中式部署。