核心|金融企业选择与应用分布式数据库的7个核心问题( 二 ) mysql|苏强|分布式数据库|选择

如何对国产数据库进行运维；

其他典型场景分布式数据库如何适配。

1、分布式技术栈的选择：对主流方向都有布局和应用
对于分布式技术栈的选择，目前有两个主流方向，一个是兼容MySQL，一个是兼容Oracle。

文章插图

兼容MySQL的优势是其分布式技术栈比较成熟，易于团队建设。基于MySQL的分布式协议最早来自于国外的一些互联网厂家，后逐渐引入到国内的互联网厂家，包括国内的微信支付、蚂蚁金服等几个巨头的支付厂家，其底座都是以兼容MySQL协议为主，再加上这么多年国内开发者对MySQL的研究，所以在此背景之下，金融机构的相关团队建设是比较容易成型的。
兼容Oracle的优势是对整个金融系统的改造、迁移、使用成本相对较低，有可复用的部分并且方案相对简单。

所以说这两个技术栈方向都各有优势，腾讯云因为金融业务足够大所以覆盖了这两个方向的产品，都有自己的产品线，我们现在都把它叫做分布式数据库产品线，分别是MySQL技术栈的以及Postgre技术栈的产品。
2、技术创新节奏
1）某大型银行客户的主机下移“五年计划”
了解过技术栈的选择，接下来就是考虑自身团队适合哪款产品、选择这款产品后怎么设计核心系统等。以下是某大型银行真实计划的缩影，他们给整个过程设定了五年计划原则：

技术团队：建立一支熟悉分布式数据库技术栈的技术团队；
分批改造：根据业务重要性，分批分阶段改造业务系统；
业务磨合：技术方案应在不影响宏观稳定，确保业务与数据库磨合；
技术复用：该技术应该是可以复用或容易建立的；
全量切换：应该是在完全磨合好以后，再全量切换。

并且分成四种节奏开展落地：

2018~2019年，团队招聘与培养：确定基于Oracle+MySQL实现双技术栈团队建设，并选择互联网银行业务选择开源MySQL方案打磨团队；
2020年，（试点）核心系统改造：团队对MySQL熟悉后，实现核心业务系统基于腾讯云TDSQL上线并开始运营；
2021年，新老系统并行，剩余系统改造：老业务系统不下线，数据保证实施同步回老业务系统，如果新业务系统一旦故障确保老系统可用；
2022年，最终核心交易全量切换：在运行一段时间后，确保新系统完全稳定后，再封存老系统。

2）某银行客户传统核心业务系统改造过程

文章插图
以上是另一个银行客户的案例，他们的客户规模相对于上面的银行小一些，所以进程较快。他们在2018年4月选择了某一个技术栈方向，并且开始POC测试，联合着长亮科技在2018年底到2019年初就在业务系统改造生产完成，并且在2019年上半年通过了相关专家机构的评审，正式上线。在2019年年中投产，逐步投产后运行非常稳定，而且性能较之前有较大的提升，所以2019年底整个核心系统全部下移投产。整个过程经历了差不多两年的时间，过程中整个项目团队的工作是非常紧张的，而且也借助了大量的成熟经验和长亮科技能力。
3、数据层下移的拆分策略
1）水平拆分&垂直拆分
在执行了相应的规划以后，就要考虑数据库改造中数据层下移的拆分策略。说到水平拆分就不得不提及垂直拆分，垂直拆分一般是在SOA时代，基于业务垂直拆分。

文章插图
分布式改造最主要的还是对其中一些业务核心户进行水平拆分，使其能够适应新时代新的科技金融业务的发展。但也并不是所有的系统都需要分布式改造，有些规模比较小的系统就没必要。腾讯的产品是集中式和分布式组合在一起的，便于客户只买一个产品，能满足几乎所有数据库的需求。
2）水平拆分的主要方案

文章插图
从实践来讲，数据层下移的拆分方案主要分为三种：

文章插图
第一种是按客户维度拆分：如上图所示，主要面向客户规模比较大、无明显分布性、交易金额小、笔数多等这种对私类业务，一般的拆分策略是一致性哈希。