下午好，我叫杨祥合来自网商银行架构部，过去没有分布式数据库的时候，业界往往用类似MYSQL这样数据库做分库分表，把一个大库拆成很多小库。通过分库分表提升我们数据库的扩展能力。当拆完之后发现主库和备库之间搭建master-slave的架构，当主库出问题，如果备库拉起来就会丢失(部分主库)数据。如果备库不拉成主库，就会损失新的业务。这样就陷入难以决策的麻烦。随着分布式数据库的发展，给了我们解决这些问题的方式。
随着移动互联网、大数据、云计算以及新兴技术的蓬勃发展，诞生了互联网金融，传统银行在往互联网模式转型。
网商银行在移动互联网、大数据、云计算等新兴技术之上服务于小微企业、三农用户、大众消费者以及中小金融机构提供普惠金融服务，我们建行之初提出了低成本、高可用、高弹性的要求，银行作为强监管行业，银监会和人行在不同场合提出了自主可控的要求，在这种背景下，我们使用了自主研发的分布式数据库OceanBase来作为我们核心的数据库。
先看一下oceanBase的核心特性，每年双十一大促是全民的双十一也是OceanBase的双十一，OceanBase去年的数据每秒32.5万笔/秒，这是从性能方面说。从单表数据量来看，单表数据量已远超过3200亿，3200亿是两年前的数据。
可扩展性方面，单机群达到百台服务器以上。每年双十一有可能建设新的机房，利用 OceanBase本身的弹性能力，把一部分数据弹到新的机房去。
在高可用方面，oceanBase是用Paxos协议，提供多副本的协议，RTO=0，RTO<30秒。高可用方面，给大家的感知就是我们的系统到底怕不怕挖掘机的问题。
(据媒体报道)6月2日，AWS(中国)中断了十多个小时。(网商银行)我们希望为用户提供高可靠的服务，那需要付出一定的成本，这个后面去谈。
我们提供了多租户的能力，前面几位老师提过不同业务之间担心相互干扰，多租户提供了这样的隔离能力。
易用性方面兼容MYSQL和Oracle语法，可以让应用免修改代码直接使用。许多现有业务，可直接运行在oceanBase数据库上。
从架构方面来说，OceanBase集群是分布式的多副本架构，我们建议使用三个副本以上，每个副本分布在一个zone里面，每个zone分布在一个机房里。对于金融行业来说，我们是这么看分布式数据库的，我们说它拓展了单机数据库的容量，提供了机房级、地域级容灾及异地多活等能力。
回顾网商银行的架构发展史，创新能力一直是网商银行架构发展的一个驱动力。在网商银行整个4年的架构发展当中，我们经历了数据库的版本升级、拆库拆表、秒级弹性数据源建设。很多时候传统银行要向分布式数据库上转型可能会面临着把单机数据库通过拆库拆表拆成成多个，从而提高极端情况下的可用性。对比传统银行有ATM，有物理网点，现在因为大家都有了随身携带的手机，我们希望网商银行手机APP能够为大家随时随地的7×24小时的服务，为了这个(目标)我们不遗余力。
网商银行的架构发展从5库10表发展到百库百表并且建立秒级弹性数据源，下面一起看一下。先说数据库的迁移和拆分，这个可能是传统银行要上到分布式数据库需要经历的，我们通过如上图一种架构，在我们内部叫OMS的一站式数据迁移平台，它具备的能力是什么？
当我们有一个老的库比如OB0.5，从老的库OB0.5迁移到OB1.0，我们一定想使用生产数据做验证、生产的流量做验证，因为线下人力测试验证远远赶不上线上数据真实而且复杂。在这种情况下，我们通过分布式的数据访问组件或者数据流量录制能力把流量录制下来，把流量转发到双写测试库当中，双写测试库是一个1.0的库。通过这样的验证知道SQL性能是否OK和语法是不是兼容。
在迁移切换中有增量全量同步并且提供秒级数据校验，分钟级切换和回滚，整个过程一键完成，通过OMS平台构建了异构数据库之间进行互相迁移。
去年做的第二个创新点，上了秒级弹性数据源，当一套数据库集群不能满足我们要求的时候，我们想着加更多数据库集群上来，网商银行实现了在一个应用数据源上挂多个数据库集群。我们实现了大一百个数据中心同时为提供服务，任何一个业务都可以跨100个数据中心，这就是我们架构创新带来的扩展能力。
通过这样一个能力，比如我们的生产库如果耗时达到一定的阈值，会自动切换到新的FO(故障切换)库，是实现了不同数据库集群自动化容灾。(尽管分布式数据库足够稳健)，这是在非常极端的情况下数据库出现问题会自动帮你完成切换。
前面谈了我们在分布式架构上的创新，不同的分布式数据源为用户提供了高可用的服务。现在谈谈三地五中心，我们三地五中心加分库分表分集群的架构设计目的不仅对抗挖掘机(挖断单机房网络)而且对抗城市级故障。一个城市出了故障之后我们不希望用户感知到，希望把它消化掉，所以我们在三个城市建立五个副本这样的能力。
接下来我们谈谈逻辑架构，我们的经验是分库分表分集群在分布式数据库时代依然是需要的。
分布式数据库集群也有很多内部事件、外部事件，内部事件，比如说数据库集群有可能存在累积性的问题，或者内部的定时任务，还有一些自动维护性的操作; 外部性事件比如集群要灰度、版本要升级、还有备份，每天跑的全量备份。另外三地五中心，分库分表分集群，对我们单元化构建异地多活的架构，也是非常重要的，因为异地多活之后，比如全国有10个机房，我们可能会在不同机房里边分配不同的集群，每个集群都是三地五副本的。
网商银行的架构发展从原来的两地三中心发展到现在的三地五中心，我们就是想解决城市级故障，大家都说城市级故障概率很低，我们不这么认为。我们觉得三地无副本的成本投入是对用户体验的极致追求，对银行信誉的极度珍视，这才是我们认为有价值的地方。
给大家看一下我们数据库redolog在异地多活是怎么跑的，我们看到003区主在IDC机房，这个主同步到IDC 2、3及其他的节点；看到31号分库的主在IDC 2; 99分库在IDC3机房，通过交叉部署提供机器资源利用率降低了成本。
一起看下逻辑架构的示例分布图，我们采用分库分表分集群，每个集群都可能会做灰度升级、变更。通过表级别看，红色是表的主节点；每个集群里边承担不同数量的表；多个集群共同支撑业务流量。
下面是机房或者城市级故障时候表级别的分布如图，OceanBa’se内部有选主优先级的概念，同一个城市的优先级高。同一个城市两个机房都挂掉了，则距离最近的城市优先级高，通过这样一种能力可以在30秒内自动恢复业务。不论是挖掘机挖断的还是人为弄断的。我们定期断网演练，因为没有办法分析出来这么多系统能不能满足容灾能力。不如就去真正的断网演练，看一下能不能自动恢复。
三地五副本是成本降低了还是升高了？我是这么认为的，对于用户的体验的标准如果不一样，就没有办法衡量哪个成本高哪个成本低。单机数据库，城市级挂了之后就不可用了，这和三地五中心支持城市级容灾不在一个层次上。
建立了三地五副本之后，我们在成本降低上创新，通过历史库的方案，有两个点，
1、用Sata盘换掉SSD盘，Sata盘成本是SSD的1/10。
2、历史库假定是只读的，这样冷数据库(历史库)备份只需要存一份全量备份(而不是多个全量备份)，从而降低了备份的成本。网商银行去年仅机器成本一项就节约了几百万。
每一家企业或者每一家银行从小到大的发展历程，做数据库架构，开始的时候集群资源特别少，做架构比较难，多集群资源共享，慢慢银行业务发展大一点，实现租户级共享，再到每个业务专享集群，是这样一个发展历程。那如何提供架构的弹性？
虚拟化提升了数据库架构的弹性，假设有一套硬件，我们虚拟出多个集群，当我们有了更多集群的硬件资源之后，只需要做一个虚拟机的迁移，就可以把它迁到更多机器资源硬件上。当每个集群分布在不同的硬件之上，降低了单集群的容损率，也就是单集群挂掉之后对业务的影响。通过提升数据库架构弹性，数据库架构很容易从原来几十台、几百台机器扩展到几千台机器，这提升了但集群容损率，从而让架构有了更高的弹性。
分布式数据库的能力越来越强大、越来越健壮，我们觉得数据库的能力只是数据库这个视角之上的。数据库前端关联着业务，而业务跟我们公司的战略目标、业务连续性、用户的体验极其相关，我们希望全面看待分布式数据库的调度等等，从各种视角，把各种资源、各种数据打通，不断用创新的能力驱动更加智能的调度，从而实现好、最优的业务、最关键的用户体验得到保障。
回过头来，整个金融行业向分布式数据库转型，我们希望能和同仁们一起努力开拓创新、不断进取，不断拓展分布式数据库的应用边界，不断提升用户的体验，为我们的社会做出更大的贡献。谢谢！
相关阅读：
热门专题
