2019-11-01 15:50
很高兴今天能跟大家分享相关话题。
我们公司最早也是大量使用海外数据库的现象比较普遍，但在使用过程中，我们跟所有企业一样都遇到两个非常尖锐的问题：
1、成本，我们企业价值是给客户提供解决方案，每个解决方案都要复制很多份，如果每个解决方案里都有相应数据的话，对于我们和客户来说是比较高的，价格比较贵。
2、对于我们这家企业来说，把数据库落在解决方案时，因为场景不同，可能会需要对数据库产品有一些要求，在具体场景下有一些希望改动的地方，但这个时候如果使用商用数据的话，是很难得到支持的，国内企业基本也很难能够和知名的数据库厂家打通很顺畅的需求、产品研发，他们产品一般都是以一年的维度在发布版本。
中兴通讯和很多国内公司一样，尝试自己去解决这个问题，也会做一些自己的技术积累，也会在某个领域里提供这些产品，只不过这些产品都是在自己内部使用，我们也一样。2014年，我们和中信银行尝试在数据库领域，尤其在金融方向上做一些事情，借助中兴通讯研发力量以及银行在金融领域的积累，一起做了一款产品：GoldenDB。
2015年时就有产品上线，是一个非常简单的业务，也是一个交易属性比较弱的业务。我们不停迭代，走过五年多时间，每年都会有新的业务上线、新的业务投产，过程当中不断把简单的业务往复杂业务上做，把交易属性弱场景变成交易属性强场景上去。
2017年，我们共同做了一个决定，想往银行核心系统上去做，当时中信银行面临自己后续问题，用了IBM的中型机，能力比较强。但是随着业务的发展，如果再往下走，就比较尴尬了，可能要上大机，这也是比较严峻的话题。所以我们一起在尝试用分布式技术来解决核心业务场景里面的问题，看能否达到我们的预期，当时启动了信用卡核心改造和传统核心改造两个项目，这两个项目都在推进过程中间，目前完成投产的是信用卡核心，传统核心投产还要再往后推一段时间，也快了。
金融行业对数据库的要求，总结四点：
1、实时一致性
银行在过去几十年里经过了很长一段时间的积累和发展，已经积累了比较多的宝贵财富。银行资产是业务，不是一排一排服务器。在原有系统向新的分布式系统演进过程中，最需要考虑的是所有已经积累几十年的资产能够比较平滑地转移，而不是对业务进行重构，重新去做，这是对于金融科技来说动作太大了，需要成本也太高了。
如何做到这一步？最核心一点就是分布式数据库一定要有一致性，业务使用分布式数据库时，不需要考虑跨节点事务，怎么让业务做补偿、做管理、做跟踪。总结下来，如果这个数据库要在金融领域使用，一致性是特别重要的，会给我们客户节省大量的投入和成本。
2、高可靠、线性扩展
在银行里面的高可靠，必须要提到两地三中心，在金融领域或金融科技里，行业内最佳实践是两地三中心架构。如果我们数据库产品是整体解决方案的话，能够非常好地匹配当前两地三中心架构也是非常重要的事情。
3、智能运维
说这个话题也有点沉重，之前使用国外品牌服务器时，比如IBM等，不得不承认到现在它依然性能比较强、稳定性比较高。到了分布式架构下，决定不再使用专用服务器，使用x86架构，因为单体能力和专用服务器能力之间有差距，就会导致在实际落地过程中，每一个分布式项目里所涉及到通用的服务器数量比较多，这时候一个很重要的问题需要解决，就是一定要有很好的运维手段。让我们数据中心的专家们能比较便利的运维到系统、掌控到系统，做性能的调优，确保系统在运营过程中间有一丝一毫动静时能感知、能发现、能解决，这对我们想试图建设稳健、强大系统时，就变成了一个关键问题。
4、银行基因
我们尝试解决一些原来商用数据库在金融里面没有解决的问题或者他们不愿意解决的问题，我们也做一些努力。如很多大型银行有多法人，和多租户概念不一样，这些方面我们是否可以往前多做一步，更加符合国内金融行业的需要。
针对以上四点，我们认为是分布式数据库产品能够在银行里使用需要重点考虑的几个方向。
最近说国内新技术创新、国产化替代的话题的声音比较大，我们做这件事情或我们当前业内几家做数据库厂家做这个事情，并不是奔着自主可控需求来的，我们2014年就开始做这个事情，行业发展到这个阶段，需要新的架构来匹配它的需要。
对于金融业务来说，以前对核心业务的要求和现在核心业务要求不一样。以前去ATM上取钱，现在每个人都用手机扫码，但对银行核心业务来说，取5000元，扫0.5元的东西，走的流程基本差别不大。在新的领域里，尤其是5G逐渐商用情况下，新业务对核心业务要求越来越高，对于银行来说都面临这个问题。
想解决这个问题，原来用小机就换中型机，原来用中型机就用大型机，原来用大型机怎么办呢？这就是比较严重的问题，我们国家是数据集中的模式，但是我们人的基数又比较大，业务活跃度比较高，这个问题已经不是可以向国外去学习的地方了，别的国家暂时还没有遇到这种问题。
对于业界科技同仁来说，也面临一个生态问题的择。前在金融科技里比较多用到IBM类似这种模式或这种生态，但是在业界里发展比较迅速的，在各个行业里用的比较多的，还是开放性的技术，在x86下面通过各种技术来演进、来推进、来发展，而且得到了很多成果。现在反而对于IBM这种模式好像前景并不是那么美好，尤其是大型机CPU的发展速度或应用领域范围也越来越少。
对于金融机构来说，似乎找一个熟悉原来IBM生态的人才也变得困难了，甚至需要花很长时间培养一个对这个行业陌生的人，培养完了以后，他就离职了，这也是很大的挑战。在开放性生态里，技术发展日新月异，很多新的概念、新的技术都在不停地应用，如果我们还守在原来IBM模式里的话，业界这些创新的能力、创新的趋势也比较难用。
这种背景下，我们希望通过把数据库做分布式改造技术手段，能够实现金融核心业务转到开放生态里来，解决业务可扩展问题，解决生态活跃度问题，解决整体创新问题，也可以解决自主可控的问题，这都是可以解决的。
我们做这件事情有几个依据：
1、分布式技术在相关行业已经得到应用，有很多成功案例。
2、在2017年底我们做了一次验证，用了银行典型的交易业务，有转帐、有查询，做了测试。测试时，用了3亿个客户15亿个帐户做混合交易，测到了40000tps。整个测试过程中间，性能逐渐往上涨的，而且有故障隔离的特性，会有自己的设计，我们默认会有一台或多台机器有机器故障，机器故障时系统能正常处理，确保业务继续往下走。
在项目里建设目标很关键的一点是希望用x86开放式架构替换原来大型厂家专用服务器架构，本身也是一个科技创新，但希望通过这个动作以后，能够支撑所有业务在科技创新上有更多依托、更多土壤、更多技术使用起来。在性能指标上，希望系统容量，客户量从千万级提升至亿级。
授权交易、帐户处理、数据&应用等迁移至GoldenDB。
卡中心业务实现和总行不一样，总行用了比较巧妙的方法，用一个工具把原来IBM上跑的语言程序转化到开放式JAVA程序。卡中心是把业务做了重构，因为业务重构本身在发展中有一个计划。这次虽然是重构的业务，但对数据库要求依然没有变。这时候需要SQL兼容性。
分布式并发批处理
这和总行不一样，总行也是转过来直接用，它这边做了重新的开发。比较好的地方是很好地利用了分布式架构，可以马上每一个节点、每一个分片充分利用起来，好处是把原来集中计算的模式变成一个并行计算模式，这种模式架构下，处理时间就会很快。但这是有代价的，这种方式投入的工作量比总行工作量要大，但效果也好。
高效的数据迁移工具
业务是重构的，因为业务重构，老的系统表的结构和新的系统表的结构不能够一一对应，这种情况下，数据迁移就变成了一个稍微复杂一点的事情，和客户一起专门做了一个数据转换的工具，可以把原系统里面的数据下载以后到这里转换，转换以后，嵌入到新系统里，这个动作分全量和增量的，这和后面迁移动作息息相关。
回放跟帐
就是生产环境里，每天产生的报表都记录下来，在演练环境里有老系统的架构系统，也有新系统的架构系统，这个报文是灌进去的，所以可以控制速度，通过交易量控制，可以验证新系统能承受的业务压力是什么情况。
并行演练
跟总行思路是一样的，只是技术有点差别。并行演练过程中，把延期交易业务量，跟原来系统发一遍，再给新建系统发一遍，进行比对，新老系统承受业务基本是一样的，通过几个月模拟比对来验证新系统是否满足上线的需要。
精心组织
这是一个非常复杂的工程。最重要的投产时间是在这个线之前，完成了总共四次的数据迁移演练，然后做环境准备。投产前7天，会把各种条件准备好，并且迁移静态数据进来，D1，会把增量的数据迁一遍，然后这时候才去在半夜时把原来IBM机器停下来，还有少量增量再进行一次迁移。两次增量迁移完以后，信息系统数据就完整了，把业务启动起来。这时候外面用户还没法用，通过白名单方式在网关上把用户放进来做各种测试。一直到第二天下午3点钟，所有业务都全部投产使用了，从运营情况来看，目前都还挺好。
分布式数据库历经近九个月跟帐测试，四轮切换演练，最终率先在大型银行核心业务投产，率先践行金融核心至国产分布式数据库改造，达成预期目标。
谢谢大家！