网易马进：DDB从分布式数据库到结构化数据中心的架构变迁

导语： 本文根据马进老师在2018年5月10日【第九届中国数据库技术大会(DTCC)】现场演讲内容整理而成。

马进 网易 DDB项目负责人

来自网易杭研大数据平台组，入职以来先后参与了分布式数据库DDB，缓存NKV，网易数据运河NDC等项目，目前是DDB项目负责人，主导数据库中间件的各种项目研发。专注于分布式系统架构与数据库技术，热衷于构建高效的，高性能的分布式后台应用。

摘要：

分布式数据库DDB是网易研发最早的分布式系统，过去十几年来一直为网易各大互联网产品提供稳定透明的分库分表服务，四年前我们推出了私有云DDB，为开发和运维人员在使用DDB和弹性伸缩上提供了极大便利；一年半之前我们从DDB的在线数据迁移模块中分化出来一套平台化的异构数据库数据迁移、同步和订阅服务NDC；现今随着网易内外部应用的网络环境更加复杂，应用场景日益繁多，对DDB的易用性，平台化，面向机房和多租户的解决方案提出更多需求和挑战，这次分享将带大家一起见证DDB在向结构化数据中心进化过程中的思考和架构变迁。

正文：

DDB发展简介

DDB：一步到位的分布式数据库

 

DDB是一个分库分表数据库，管理成千上万个数据节点，并且可以支持PB级结构化数据存储。目前公司内部使用的版本基本上都是查询服务器模式，查询服务和存储服务相分离，可以分开进行水平线性扩展以及可以支持百万级的qps。此外，DDB还支持在线数据迁移的功能，可以支持每日GB-TB数据增长并且有标准化的访问协议。

DDB的在线迁移功能本质上是我们分布式数据库的一个核心需求，目前我们分库分表架构还是将它定义为运维人员需要参与的过程。业界中说我们这种方式有上一代数据库的感觉，其一是因为它还不够标准化，其二是因为数据库缩容还需运维人员的参与。但我个人觉得这属于一个设计哲学的问题，我们可以很好的解决这两个问题，但归根结底还是要看它的运维和使用成本有多低。

左边这张图是我们数据库的成本曲线。单机数据库随着数据规模和访问规模的提升，成本曲线成长很不线性。例如，我们一旦达到了商务机器成本上线，往上扩容成本就很大。如果使用分库分表分布式数据库，我们能很好的实现存储和查询功能的线性扩展，它的使用方式能达到我们的要求，自然就会得到一个理想的线性曲线。

DDB发展历程

2006年DDB第一个版本上线，当时的功能相对比较简单，就是一个简单SQL兼容和部分管理功能。概括的说，从2006年的V1版本到2010的V3版本，都是一套驱动模式，我们内部叫做DBI模式。2012年，随着私有云上线，我们开发了查询服务器，可以支持多语言，在查询服务器内部提供丰富的SQL统计功能。同时，我们在云计算的管理平台上提供云计算DDB Pass服务，可以进行一键部署和管理监控。2017年之后，我们开始研发DDB 5.0版本，逐渐简化架构并且把相关服务做了模块化的拆分，以及进一步扩充了SQL的兼容度。

DDB功能特性：数据信道

在数据信道方面，第一，我们有比较好的均衡方式，有两级映射的功能，有应用自定义配置的哈希函数。

第二，我们有比较高的标准化，SQL 92能达到90%的兼容度，5.0之后达到了95%。并且我们支持全局自增ID、explain计划，有数据标准导入导出，查询服务器兼容MySQL通信协议。

第三，我们支持分布式事务。业内很多专家人士可能会吐槽两阶段提交协议不可靠，但我认为ACID本质上是一个概率问题，两阶段提交协议的ACID功能在概率上远不如单机版的事务，但并不代表它的可靠性没有提升。另外，我们也会跟应用强调，业务场景里涉及到的敏感数据交易。并且我们分布式事务两阶段提交协议的实现对用户是透明的，内部会有一些优化措施，并不是所有的事务都是两阶段提交。最后强调一点，分布式事物两阶段提交协议在性能上还是存在瓶颈，在业务中我们也会跟应用具体强调。

第四，我们提供Hint功能，可以在DDB内部实现读写分离，然后实现SQL自定义路由。

第五，我们在查询服务器层面提供丰富的统计功能，包括SQL模式统计、SQL频度统计、慢SQL 统计、多维度QPS统计。

DDB功能特性：管理信道

在管理信道方面，需要特别说明的是我们兼容MySQL管理语法，创建表等操作都跟MySQL在语法上高度一致，用户管理上也比较类似。并且，我们在线数据迁移功能提供较多的是场景化的在线迁移。前期应用在创建表的时候，如果没有选择好分区字段，我们可以在管理工具上做分区字段更改的操作，底层就会实施数据重分布。另外还有一些扩展功能，比如定时任务、悬挂事务报警。在高可用方面，我们查询服务器是一个热备的，底层的数据库也是比较经典的主从架构，内部做了自动fail-over机制。

DDB核心优势

DDB的核心优势，第一，有标准化的访问协议，有较高的SQL兼容度。第二，分布式事务能够保证数据的高一致，有较完善的图形化管理工具、在线扩缩容功能。第三，所有的组件都是高可用的。

DDB V1-V3架构：DBI模型

DDB架构过去十年的变迁：

这是V1-V3的经典架构，在这套架构里，分库分表实现在驱动层。在应用端，它们会依赖我们提供的JDBC驱动的jar包来访问DDB。DDB内部的语法解析执行计划都在驱动层做。另外，我们有一个Master组件，负责整个集群的元数据管理和同步。

但这套集群也会带来一些问题。第一，从语法解析到执行计划到最后的结果集合并，DBI内部的这些实现比较耗费CPU。第二，在这种架构里，DDB版本很难管理。第三个问题比较严重，尤其对于提量大的应用。DBI跟随应用层做水平扩展，如果我们发现体量不够，就要加应用服务器，DBI也会跟着增加，访问底层数据库节点的连接数也会随着增加，这样就很可能会导致底下数据库被打爆的问题。

这套架构也比较经典，很多小伙伴应该能看出来这套架构跟阿里TDDL比较相似。但很重要的一点区别是我们的集群管理比较独立，每一套集群都有一个单独的Master做管理。这个跟我们公司的背景也有关系，例如淘宝当初做中间件，是为了淘宝的核心业务服务的，它只需服务于一个业务。但网易不一样，从一开始网易内部就有很多不同类型的产品，比如网易考拉、网易音乐两个截然不同的应用，一个是典型的电商场景，一个是典型的读多写少场景，这就要求把不同的集群隔离开。

DDB V4架构：QS模式

DDB V4是提供查询服务器的，这套架构就相当于通过单独部署QueryServer组件，把DBI包起来，然后对应用提供一个标准的MySQL协议支持。同时在Query Server和应用之间部署LVS\HAPProxy+keepplived组合做负载均衡。

如图所示，应用发起一个请求要通过LVS、QueryServer到最后的数据库，这套架构比原来的架构多了两次转发，链路或许会有点长，但却很好的解决了之前DBI存在的问题。

首先Query Server的数量和应用的数量没有绑定关系。其次Query Server由平台的运维人员部署，我们能追踪它的版本管理和内部问题定位。

除此之外，在集群管理上我们还是沿用老一套，包括管理工具。

DDB V1-V4：小结

﹣DBI模式

• 部署简单，省机器

• 对JAVA应用较为友好

• 问题跟踪和定位成本高

• 占用比较多应用端的CPU资源

• 版本升级周期长，新功能推广困难

  ﹣QS模式

• 多语言支持，集成任意连接池和DAO

• 版本便于管理，跟踪定位问题成本大大降低

• 慢语句，TopSQL等功能便于SQL优化

• 连接收敛，连接池熔断等功能提升可用性

DDB v5：LBDriver

DDB V4虽然解决了之前DBI模式的各种问题但还是会有一些潜在问题。

首先就是之前提到过的链路长的问题。其次，LVS通过连接做负载均衡存在弊端。第一，在低峰期活跃连接数比较少的情况下，无法保证这些活跃连接数均匀分散到每个Query Server上，如果使用云计算部署查询服务器，这种不均衡容易导致CPU使用率飙升。另外一点，使用LVS做负载均衡，在应用端cancel语句或query timeout情况下，创建临时连接执行kill query指令的时候，可能创建的临时连接落到另外一个QueryServer上，这样如果这个节点上没有一样的connection id，那相当于cancel或timeout没有实现，如果有connection id，相当于错误的kill掉了一个连接。

因此，我们给应用提供了一套全新均衡方案：在应用端的连接池和驱动之间开发了一个loadbalance driver组件，这个组件包装了JDBC驱动，对连接池提供逻辑连接，并与各个QueryServer的物理连接实现映射。在连接池使用连接的过程中，它会按照SQL请求做负载均衡，这样首先解决了LVS不能够按照请求去均衡的问题。其次，在连接超时的情况下，能够拿到底层的真实物理连接，并通过它复制临时连接来执行kill指令。

最后，我们的lLBDriver不会给应用带来迁移成本，因为它本身就是一个JDBC驱动，应用使用lLBDriver时 ，只需要配置里更改下driver名称和URL就可以了。

DDB V5：去master

这是DDB V5的架构。除了通过LBDriver做负载均衡外，我们还去掉了Master组件。原因第一是出于省成本考虑。第二，Query Server本身是一个我们自己去掌控的服务端，所以完全可以用它去做一些管理上的功能，QueryServer之间本身互为热备，在实施了master的部分功能集成到QueryServer上后，在多个QueryServer之间选择一个leader作为管控节点，这样同时解决了我们管理功能的高可用问题。

DDB V5：面向租户的WEB管理工具

DDB V5版本还提供了面向租户的WEB管理工具。因为之前实践私有云的Pass服务时，最大的感触就是，面向租户的管理方式能够很大程度上减少运维人员在运维上的开销和代价。除此之外，我们还在这套WEB管理工具里还提供了SQL统计，审核，报表和大屏服务等。

DDB V5：NDC服务拆分

DDB V5还做了服务拆分。我们把DDB以前的在线数据迁移组件拎出来独立做了一套NDC服务，全名Netease Data Canal，直译为网易数据运河系统。它除了可以做DDB在线数据迁移之外，也可以把MySQL的binlog独立拉出来做一些复杂的ETL，这样我们中间件产品栈就会更加丰富。

DDB V5：面向IDC的解决方案

最后，我们在DDB V5里面提供了面向IDC的解决方案。DDB V5做的最大的改进就是架构精简化。我们一般怎样评价一个分布式系统是一个好分布式系统呢？例如Hadoop，它给我们最大的感受就是复杂。但它会提供 Standalone模式，通过一台机器和一些简单的指令就可以拉起一个系统，这是所谓的重中有轻，我们DDB也希望做到这一点。

我们最简单的一个QueryServer集成了分库分表和相关管理功能，这样我们只需要部署一个QueryServer和数据节点，分布式数据库就能建立起来，并且具有DDB整套功能集。后面这些管理工具、组件都是选装的，即便没有它，DDB也可以使用。

DDB的WEB管理工具通过DDL向QS管控节点发起管理操作，可以把它当做更加丰富的上层功能。值得一提的是，这个管理功能可以跨IaaS，一套集群里它既可以有物理部署也可以在云端部署。我们提供了可插拔的接口，可以在上面做不同的IaaS层适配，好处是在不同的物理平台或云平台上我们可以用统一的界面去运维和使用它。

DDB V5：小结

﹣降低各种成本

• 架构精简，去master，降低学习和部署成本

• 以LBDriver替换LVS，提升可用性，降低使用成本

• QS兼容MySQL DDL，向标准化更加迈进一步

• 面向租户的平台化方案，降低部署和运维成本

• 通过平台化的NDC支持在线数据迁移和同步

﹣从软件包到解决方案

• 面向IDC的解决方案，通过NDC实现异地同步

• 跨IaaS的支持，物理环境和云环境混合部署

结构化数据中心——DDB以及NDC规划和瞻望

这是我们比较经典的一个多机房数据库和缓存的架构。单机房内部一般会有应用层、缓存层以及数据库层。传统架构一般是应用层在执行数据库操作之后，由它们去负责更新缓存。但如果我们把这种模式迁移到多机房场景，另一个机房的cache就很难维护。另外，它还可能导致数据不一致。

一个比较好的方法就是通过binlog方式，把每一个机房的binlog拉出来，由NDC数据订阅功能去执行缓存的淘汰或更新。这种场景下我们可以把NDC当做DDB的一个跨系统的触发器。这个在业界算是一个较成熟的方案，在很多的互联网公司得到了广泛应用。

在这套架构里，DDB和NDC可以看成一个有机整体，如果我们把NDC当成DDB的一个触发器来看，它就可以被当做成一个系统来用。

以NDC为总栈的架构

这是一个更加复杂的架构，除了在不同的机房之间做数据同步之外，在一个机房内部也可以通过NDC做异构的数据库在线迁移。同时，我们可以用NDC做一些同机房内部的数据订阅满足一些下游应用的解耦。

这套复杂的架构里还存在很多可以被挖掘的点。例如，在不同的系统之间做数据同步，首先每一个系统要配合一个管理界面，然后需要把每一个系统之间的用户权限打通，由运维人员配NDC任务。但这个过程中会有很多管理上的壁垒，我们做一个简单的需求总结：

﹣ODMP潜在需求

• 各个数据系统之间管理方式有壁垒

• 缺乏统一的资源划分，认证方式

• 各个系统间权限不通，需要人工同步

• 没有统一的监控，部署平台

• 传统的工单流程容易造成资源浪费

﹣ODMP（在线数据管理平台）

• 可插拔，可扩展，易集成，面向IDC的数据系统管理平台

• 集成租户管理，权限同步，资源池管理，报警监控，自动部署

• 基于NDC实现异构系统和IDC间数据同步（核心实现）

这是我们最终想要达到的效果。其实我们内部已经实现了这些功能，但都是彼此独立不相同的。我们希望建立一个统一标准进行统一维护，这样就能很大程度降低运维和使用成本。

两个问题

一路下来我们总结出这两个问题。其一：为什么我们在做应用的时候团队越大，DEVOPS门槛越高？

随着我们应用发展、团队成长、规模扩充，面临的业务场景越加复杂，需要做的技术选型越来越多，开发人员从调研到测试、从部署开发到最后运维，长期处于这样的循环里。一套成熟的系统进入到一个比较正规的运维流程往往需要一个很长的周期。

其二：在这个过程中做中间件，怎样做可以降低成本？

第一，尽可能自动化，减少工单流程。第二，尽可能挖掘出平台运维的角色，即我们开发人员，开发人员本身就是DBVOPS，可以直接面向应用开发，这样可以省去运维人员的介入。第四，注意各个平台和系统之间的串联，这一点也是ODMP的本质问题。

ODMP：hybrid console

hybrid console相当于一个DDB的命令行工具，可以选择访问QueryServer的节点。我们可以对这个功能进行这样的一些展望：在选择节点之前是否可以选择要访问的系统，是否可以在同一界面进行这些操作，具体访问了哪个系统是否可以隐藏起来。目前，业界很多产品都在朝这个方向发展，hybrid这种访问方式或许会成为未来的主流趋势。

总结

﹣DDB十年架构变迁

• V1-V3：驱动模式，满足JAVA应用所需

• V4：代理模式，多语言支持，增强可用性和运维能力

• V5：平台模式，精简掉lvs和master，面向租户和IDC的解决方案 

﹣ODMP展望

• 脱胎于DDB和NDC对平台化的理念

• 核心价值：打通异构在线数据系统的壁垒，实现统一的部署，监控， 租户认证，权限打通，使大团队中DEVOPS成为可能

• 核心实现：基于NDC实现异构系统和IDC间数据总线