共同探索企业级数据库架构之道路

[2018云栖大会南京峰会企业级互联网架构专场，阿里巴巴高级数据架构师黄欢欢带来题为企业级数据架构探索之路的演讲。主要从企业数据库的发展现状、存在的问题以及企业级架构的需求开始谈起，针对其存在的问题提出了对应的解决方案,最后对企业级产品的架构以及满足企业及架构的需求问题做了详细的分析。
数十款阿里云产品限时折扣中，赶快点击这里，领券开始云上实践吧！
直播视频请点击
以下为精彩视频及ppt内容整理：

企业数据库现状

说起企业级数据库架构体系，在2010年阿里巴巴还没有一个完整的数据库架构体系且存在着很多问题，问题大致可以分为一下几点:

业务快速发展，如何才能做到弹性扩展、且性能满足要求:单体的IOE架构已经不能满足业务快速发展的需求，所以需要我们去做弹性的扩展，也就是既可以弹性扩容也可以弹性缩容的。
数据是最重要的资产，但数据孤岛却是现状：现如今应用都在做服务化，应用做服务话以后在每个地方都存在自己的数据，那么数据之间是如何流通的呢？以及怎样避免数据孤岛等问题值得思考。
稳定和高可用，已经成为企业数据库系统的最大挑战：对于企业级来说，这是一个普遍的问题，数据库的稳定性、高可用性是企业级数据库最基础的一个功能。
业务的多样化，单一的数据存储无法有效满足需求：我们发现业务正逐渐的多元化，单一的数据库已经不能很好的满足业务发展的需求，那么我们在统一化的支撑和个性化的支持下如何做权衡也是我们要考虑的问题。
研究人员众多，数据安全、效率、规范的挑战很大。
企业级架构的基本诉求

结合以上问题，总结了企业及数据库的一些基本诉求：

_1

1）可扩展性：可扩展性与容量的扩展并不完全相同，更多指的是架构上的可扩展以及弹性的需求。
2）稳定可靠:系统的稳定性和高可用。
3）高效：可分为两层含义理解，首先企业级架构数据库之后，我们如何高效地、自动地去运维数据库；其次，研发的人员越来越多，如何利用自己的平台去提升研发效率是我们需要考虑的问题。
4）安全：数据安全是企业的生命线，安全问题绝不能够在出现问题之后再去考虑安全问题。
如何提升系统的扩展性

提升系统扩展性或者提升系统的容量有很多方法，比如可以去做Scale Up，也可以升级数据库版本以及数据库硬件的配置，但是这是有限的。所以要进一步结合业务做一些垂直拆分，例如应用做服务化，那么商品的应用、交易的应用或者库存的应用需要拆开来，其对应的数据库也需要拆开来，这样做垂直拆分以后，对于单个应用来说我们需要做更进一步的扩展性，慢慢我们发现会遇到瓶颈，尤其是在写上面的扩展性。这时就需要做Scale Out,也就是说水平拆分线性的扩展。需要注意的是水平拆分的线性扩展不是一次性的，对系统进行扩展以后需要对弹性的缩容。

Scale Out解决方案

_2

利用DRDS进行水平拆分，线性扩展：
弹性的扩容能力
超高性能，满足业务极致需求
Scale Out解决方案现在最成熟的技术就是分库分表的解决方案，当一张物理库或一张物理表已支撑不了业务写入的时候，我们就对它按照不同的维度去做水平的分库分表拆分。DRDS所做的事情就是在分库分表表的基础上，把它揉合成逻辑库和逻辑表的概念，其优势在于进行分库分表后，对于用户来说看到是还是一张逻辑库或逻辑表。
弹性扩展解决方案

利用云上计算资源，轻松应对业务高峰
按需使用云资源，高峰结束后快速释放
一站式服务，简单易用
SDM混合数据管控所做的事情就是实现一键的数据库弹到云上去，之后做一个云上与云下混合的数据库，通过统一的管控平台，对云上的和云下的数据库进行统一的管理。
_3

如何保证系统的稳定可靠

提供多种数据库容灾方案：考量：RPO，RTO，成本，扩展性。
覆盖数据库容灾的各种需求：容灾建设，监控，容灾演练，容灾切换，数据校验及修复。
构建数据库异地容灾的完整体系
多层级高可用方案：
1）备份上传：采用单点写入方式，RPO为最后一次成功上传的备份的时间点到崩溃时间，RTO为小时级甚至天级，通过常规的数据库备份，将备份集上传至云端OSS存储。
2）DBS备份上云:采用单点写入方式，RPO为秒级，RTO为小时级，通过捕获数据库变化日志持续将数据库增量备份到云端，保有数据库最新的数据。
3）单向实时同步：采用单店写入方式，RPO为小于1秒，RTO为秒级到分钟级，其特点在于持续增量同步数据变化到容灾端数据库，容灾端数据库为读写打开状态，但逻辑上不接受应用写入。
4）异地多活：采用多点写入方式，RPO为小于1秒，RTO仅应用流量切换时间，多活架构，数据多点写入，数据变化双向复制。需要做多点间数据写入的隔离，防止记录在多点被更新。
对于现在阿里的数据库架构来说四种方案均能够支持，并且主要采用异地多活的方案。对于前面所提到的应用做了服务化这个问题，一些数据是需要依赖其他数据的，这时候如何实现数据之间的相互实时流转，且满足业务需求的，这时候就需要数据同步来实现。

_4

让数据成为架构的动脉

针对数据自由流转这个问题，列举了几个典型的实践案例：
1）上云迁移：（同异构）数据在云上和云下自由流转。
2）在离线：在线的数据库同步到离线，进行实时分析。
3）多活同步：单元之间的实时双向同步，满足异地容灾需求。
4）下游消费：通过订阅实时增量消息，满足搜索等下游业务。
5）实时大屏：在线数据，流经实时计算，大屏展示。

_5

兼顾数据安全和效率

保证数据安全的前提下，怎样保证效率是每个研发者所要考虑的问题，DBA已经成为瓶颈。我们所做出的解决方案是通过DMS企业版平台，此平台主要解决两个问题，第一个就是研发效率的问题，让研发者对数据库的操作不在成为瓶颈；第二个问题就是数据安全问题，我们会对权限进行非常精细以及明确的管控，我们对权限定义的力度可以细化到某一个库、某一个表或某一个列的程度。
接下来简单介绍下DMS数据库平台，现如今数据库类型众多，但DMS平台支持多种数据库类型，在数据库控制层之上有一个安全控制层，也就是前面所提到的数据安全。若没有数据安全，我们会遭受很多风险与挑战。此外还有核心功能层，面向研发时对数据库的操作全部通过自助的方式来实现，用户则更多的是面向研发同学、运营以及后台同学来看的。

_6

在解决数据安全和效率的问题之后，我们还面临着另一个问题，即业务个性化的权衡问题，对于数据库的管理人员来说，更希望一个数据库能够支撑所有的业务，在统一化、规模化运维的时候是最方便的。但实际上业务需求是很多元化的，这时一种数据库就很可能无法包含整个业务。例如淘宝上有上千个应用，有些文档型的应用结构定义常常会发生变化，又比如有一些IOT的用户，在IOT场景下很多时候是偏向时序的分析，时序数据分析的时候或日记类的数据分析的时候我们把这些数据放到哪里呢？为了解决这些问题我们提供了多种数据库引擎，如下图显示。
_7

虽然提供了很多数据库类引擎，但是在统一运维上面也并没有做太多的妥协，数据库引擎众多，但数据库中台是能够很好的包容这些产品的。
产品总结

为了满足企业架构的需求，我们采用分布式数据库Scale Out实现弹性扩展，此外还有多样化存储引擎满足业务需求，让每个数据库都能发挥它最大的作用；同时通过数据流转，打通任督二脉；以及多层级的容灾保证系统高可用性，提出了高效的数据库DevOps和数据安全方案。请添加链接描述](http://click.aliyun.com/m/50076/)