服务视角下的云分布式数据库UDDB

近日，国内最受关注的数据库技术盛会——2017第八届中国数据库技术大会（DTCC2017）在北京举行，UCloud资深数据库开发工程师 Robert在《云时代的数据库》专场带来《服务视角下的云分布式数据库》的精彩分享。

一. 对服务的理解

这次我主要想分享作为一家有着互联网基因的云计算创业公司，UCloud是如何做公有云上的分布式数据库的。
我分享的内容是《服务视角下的云分布式数据库》。“服务”在这里的意思其实很简单，也非常具有普适性，就是指人帮人解决问题，任何人帮人解决问题的活动都可以叫做服务。而IT的本质可以说就是“服务”。从服务的视角来看，IT产品等于将问题解决方案中的数理逻辑和相关信息注入机器，让机器代替人来服务。
在云计算行业，服务有两大优点：第一，在创业初期， 服务能够弥补技术和产品的不足，有效满足客户需求，甚至为产品打开局面；第二，可以将服务过程中非标准的解决方案，逐渐沉淀为标准化的产品。
我想举 UCloud 发展初期的几个例子，来说明服务的这两个优点。
在云计算刚起步阶段， 打造用户口碑是一件非常重要的事情。同样作为创业公司，国内一家竞争对手提出了云主机资源秒级响应和计费的功能。从技术角度来看，这个功能确实很酷，但是否能获得用户口碑，则有待检验。而UCloud在同期则推出了在线问题90秒响应这个服务，短期内收获大量用户认可，如今国内每家云厂商几乎都推出了类似功能。
另一个例子也是发生在公有云起步阶段。
为了打开局面，有的厂商会从技术角度来寻求破局之道，比如用自己的技术，为大公司、大机构做主机的虚拟化，通过为其节省成本的方法找到市场和客户，但这样往往会把自身业务带到私有云方向上去。
UCloud 打破局面的方法是从“什么样的客户最需要公有云服务”这个问题着手。通过分析，我们选择从游戏行业入手，切入到公有云市场。因为游戏产品爆发力强，用户增长率不可预测，在短期内可能需要大量后台资源；同时，游戏的生命周期又相对较短，厂商持有大量硬件资源不划算。这两个问题恰好是公有云最能够解决的，因此UCloud从服务角度看待市场，从游戏行业切入，最终成功打开了公有云的局面。
服务对于UCloud来说还有另一个重要意义。作为一家创业型云计算公司，UCloud能够在巨头压力下迅速成长的关键原因在于拥有一整套产品动态生长的方法论：
1、在市场出现明显需求时，迅速推出产品进行卡位；
2、当现有产品暂时不能满足客户的需求时，基于现有产品配合人的服务，来及时有效满足客户的需求；
3、通过灰度、柔性服务和服务治理能力，确保在线服务的可靠性与稳定性；
4、通过需求提炼和产品规划能力，将服务过程中的解决方案沉淀为产品，让产品动态生长。
正是基于这一方法论，UCloud在几年内打造出一条全系列的产品线，同时在公有云的可靠性和稳定性上不输于任何竞争对手。
UCloud分布式数据库UDDB正是基于该方法论打造的产品。

二. 对分布式数据库的思考

分布式数据库当下已成为基础软件研发热点。作为UCloud的技术人员，当我们想做分布式数据库时，需要清楚的第一点就是不能为做分布式数据库而做分布式数据库。在做之前必须想清楚产品的生存之道和发展路线。
在思考的过程中，管理大师德鲁克的一句话给了我们很大启发。他说，企业家在创办一家企业时，首先要问自己，我们的业务是什么？反复思考这句话，我们也问了自己两个问题：

1. 我们的客户是谁？他们的需求是什么?
2. 我们将以什么样的方式来满足客户的需求?

（一）市场和客户分析

第一个问题就是市场和客户分析。我们按照数据规模和业务对单机数据库的依赖程度这两个维度，将客户分为4个象限：

其中，标黄的是我们的潜在客户，有两种：
一种是传统互联网客户，比如互娱、社交、媒体等TMT领域的客户。这类客户的数据量大，但业务对单机数据库的依赖程度不大，因为这类客户在技术上往往有足够的储备，能够自己解决单机数据库的容量或性能瓶颈。
另一种是“+互联网”的传统客户。所谓“+互联网”是指客户业务本身是传统的，但后续打算将业务在线化、互联网化，来更好地服务他们的客户或用户。这类客户技术上的强项在于复杂业务的需求分析、业务建模，但分布式上的积累可能还不太够，不能够自己解决使用单机数据库时遇到的瓶颈或性能问题。
这两类客户又各自有什么样的需求呢？在分析之前，我们需要提到2B付费业务的一条重要原则，那就是: Give the people what they NEED, but not only they WANT.
NEED就是客户必需的功能，没有这个功能，他们业务就会很痛，因此他们愿意为之付费；WANT指的是客户需要，但不是必需的功能，没有这个功能，客户会有点麻烦，但不会很痛。
为此，我们分析了两类客户的业务特点，从中厘清他们各自的NEED和WANT。 具体情况如下：
业务特点：传统互联网客户的业务轻度使用数据库，分布式问题上有技术储备，能自己解决单机数据库的问题；“+互联网”的传统客户业务重度使用数据库，分布式问题上没有技术储备，不能自己解决单机数据库的问题。
NEED：传统互联网客户需要性价比和易扩展性；“+互联网”的传统客户利用分布式数据库，能有效解决单机数据库的问题，业务不改造或者少改造，易扩展。
WANT: 传统互联网客户是易运维、可审计、更好的监控；“+互联网”的传统客户则是性价比、易运维、可审计、更好的监控。
另外，不管是传统的互联网客户还是“+互联网”的传统客户，两者都有共同的MUST，那就是数据的可靠性和系统的稳定性。
得出这些结论后，UCloud团队结合实际，展开了进一步分析：
首先，易扩展是两类客户共同的刚需，但只做这个功能肯定不够，因为易扩展也意味着低频，可能很多客户一两年才会需要扩展一次。
其次，我们不能做主打性价比的产品，而以分布式数据库的性能为卖点。 因为虽然产品性能很牛，但架不住巨头们降价。在国内公有云巨头经常以降价来“打劫”市场的环境下，产品的性价比往往会因为巨头的几次降价而改变。
最后，在“+互联网”的传统客户领域，UCloud会有很大机会。 我们完全可以利用自身数据库内核和分布式技术来服务好传统客户，帮助客户解决业务向互联网转型、升级时遇到的单机数据库问题。
所以，根据上述分析，我们认为，在服务传统客户上，分布式数据库存在巨大的机会。

（二） 技术选型

第二个问题：我们将以什么样的方式来满足客户的需求？这本质上是一个技术选型的问题，也就是说需要想清楚技术上到底选择什么样的架构？走什么样的技术路线？

1. 传统客户期望的分布式数据库

一切都要以客户价值为归依。所以技术选型也需要围绕客户来展开。先看一下传统行业的客户所习惯的单机数据库是什么样子。
对于传统行业客户来说， 数据库不仅能持久化业务数据，还能提供对数据的通用计算能力，因此数据库既是一个存储平台，也是一个计算平台。 SQL对客户来说，既是存储API，又是计算API。
从这个习惯延展出去，传统客户心目中的分布式数据库又是怎么样的？客户会觉得分布式数据库必须能够做好分布式，又是一个完整通用的数据库。它需同时满足两个方面的要求：
1.1 弹性扩展：分布式数据库的存储容量和计算性能满足弹性扩展；
1.2 功能通用：分布式数据库的存储功能和计算功能须等同于单机数据库。

2. 现阶段产品仍缺失

但很遗憾，目前还没有满足这种需求的产品，具体原因分析如下：
我们梳理过去二十年出现的各种分布式数据库产品可以发现， 从系统架构的角度，这些产品可以归为shared-disk架构（比如oracle rac、aws aurora）和shared-nothing架构（如数据库中间件、NewSQL）两种，但不管是哪一种，都在弹性扩展和功能通用两方面做了取舍和折衷。
比如，shared-disk架构是牺牲弹性扩展能⼒，选择了对SQL更好的⽀持； 而shared-nothing架构是选择更好的弹性扩展能⼒，但牺牲对一部分SQL的⽀持度。
目前热门的NewSQL有没有希望成为大型通用的分布式数据库产品？
对于这个问题，我的判断是很难。我认为现阶段要冷静看待NewSQL。
NewSQL的价值是值得肯定的，其优点有两个：
第一，在于将关系型数据库代码完全重写，从而摆脱了传统关系型数据库在分布式问题上的历史包袱，比如数据拆分、水平扩展、容灾等，能做到更好的使用和管理体验；
第二，NewSQL的存储层针对新型硬件(⽐如大容量内存、读密集型SSD)做了优化，在存储和简单计算的性价比上，相比RDBMS会有一定优势。
但是，NewSQL并没有提出创新性的理论或架构，能够在数据拆分之后还能对各种关系演算进行支持，同时在性能上满足业务需求。
举个例子：
假如我们仍然按照单机数据库的习惯去建模， 为淘宝网的用户、商品、订单三种对象各建一张表，那么这条sql就是一个简单的三表join问题。 但是在三表均做数据拆分的情况下， 不管你怎么优化NewSQL的join算法，都比不上目前大数据分析平台，将三种对象合为一种，然后把过去一年的记录，都扫一遍快。
所以， 目前并没有纲领性的技术，或者银弹级别的产品， 能够一次性的解决分布式数据库的问题，技术主导的方式并不可行。

3. 技术结合服务的解决之道

再回到传统客户的NEED上来。虽然传统客户期望的分布式数据库现在还没有，但客户的NEED还是在于能够解决单机数据库存在的瓶颈、业务不改造或少改造以及易扩展这三点上，同时还必须做到数据高可靠和系统高可用。
因此，满足客户上述需求还是有办法的。其中，最合适的是以数据库中间件+关系型数据库为基础来构建一款分布式数据库，在有必要的时候结合人的服务来改造业务，最终有效解决客户的单机数据库问题。
作为UDDB研发团队，选择数据库中间件有以下优点：
3.1 可靠且稳定: 复用成熟的关系型数据库作为存储层，⽽⾃身则没有状态，数据可靠性有很好的保证，数据库中间件有⼗几年历史，该踩的坑也都踩过了，⼤量前人经验可以复用；
3.2 能够迅速推出产品并快速迭代: 短期内能够推出基于数据库中间件的产品 ⾃身⽆状态，不落存储，能够快速迭代，无缝升级；
3.3 存在的短板有把握填补: 基于中间件，有信心在技术上让功能不断靠近单机数据库。
技术和服务相结合是UCloud的一个传统优势。在服务过程中，我们还可以将服务的非标准方案逐渐沉淀为标准化的产品，UCloud有一系列方法论和大量经验。
更重要的是，目前其实已经有很多同行基于这条路线做分布式数据库，而且取得了不错的效果。

三. UDDB的实践

最后一部分内容分享一下UCloud团队在UDDB这款分布式数据库上的实践，分为技术、产品和服务三部分内容。

（一）技术

技术上，分为两部分，第一部分是架构设计，第二部分是如何在技术上填补传统数据库中间件的技术短板。

1. 架构

首先我们来看架构设计。

UDDB的架构分为三层，最下面是存储节点，也就是MySQL实例，负责存储数据；中间是数据库中间件，负责SQL的路由。一个UDDB实例的中间件最少有两个， 为此在中间件之上，还有一个负载均衡和IP收敛层，负责将中间件节点的IP收敛为一个，并对中间件做SQL请求的负载均衡。
整个架构的设计原则是尽可能简单，要充分复用UCloud平台的成熟产品。因此，在存储层上直接复用了成熟的高可用UDB产品来做存储节点，可以做到底层存储无单点和高可用，存储节点下面还可以挂只读实例，来做读写分离，只读实例采用的普通UDB产品；在负载均衡层则复用了成熟的ULB产品。通过充分利用公有云积木式开发优势，我们团队可以将精力聚焦在中间件的研发上，从而集中精力打造精品。

这是一张更详细的系统体系结构图，可以分别从右往左和从左往右来理解这个体系结构。
从右往左是通过UCloud官网控制台，创建和管理UDDB的流程；从左往右是客户业务程序访问UDDB的路径。
其中，分布式中间件是我们团队集中力量打造的一块。一个UDDB实例至少有两个中间件节点，每个中间件节点下面有routerd和mgrd两个模块，都跑在一个docker里面。不同租户之间的docker都是网络严格隔离的， UCloud的SDN来保证隔离性。
routerd负责SQL的路由，mgrd负责一些管理工作，如添加节点、数据迁移、修改读策略等。一个UDDB实例下面可能有多个中间件节点，也就可能有多个mgrd，但这些mgrd会通过zookeeper集群的选举机制推举出一个mgrd来进行工作，其他则处于slave模式，不工作，除非主mgrd挂掉。
对DDL语句的处理是由routerd和mgrd联合负责的。routerd先介绍DDL语句，然后将DDL语句经zookeeper集群转发到主mgrd，由主mgrd负责提取DDL中的元数据信息，并将DDL操作广播到多个存储节点（如果需要的话）。DDL执行完成后会通知各routerd刷新元数据缓存，元数据信息会保存到专门部署的高可用UDB实例里面。

2. 填补传统中间件的技术短板

总的来说， 传统中间件有三大技术短板：
1) 不支持DDL，分表规则靠配置；
2) 无分布式计划执行能力，只能支持简单的SQL路由；
3) MySQL代码都是多年前的设计，在对最新硬件的利用，和SQL的性能优化上，不如每一行代码都重写的NewSQL。
解决短板1靠的是大量码代码。UCloud几乎完整重现了MySQL的DDL语句，包括语法解析和语义解析层。功能涵盖创建/修改库表、创建/修改索引、创建/修改视图、用户、权限管理等。
同时，UDDB创建水平分表的方式充分复用了MySQL水平分区表的语法，具体使用方法可以在官网产品文档看到。
mgrd在处理DDL时会将数据库表等对象的定义都保存在中间件的MetaDB中，中间件需要时可以获取任何一个库、表、字段以及索引的详细信息，从而为SQL优化打下基础。
另外，UCloud在中间件层实现了一整套MySQL用户创建和权限管理功能，相关SQL语法和MySQL完全一致，从根本上解决了使用中间件但又无法做到分用户、分权限管理分布式数据库的烦恼。
传统数据库中间件的短板2体现在没有完善的分布式计划上。由于没有分布式执行计划这个数据结构，SQL只能是依据语法树进行简单的路由，因而对聚合类SQL（Order by、Group by等）支持不好，对分布式Join、分布式事务则无法支持。对于这个问题，我们参照经典关系型数据库的内核代码结构，打造了一款数据库中间件：

在中间件内部，SQL处理流程和关系型数据库一致。生成SQL语法树后，通过执行计划生产器生成分布式执行计划，然后交由执行器执行。目前执行器内置两个功能，一个是根据执行计划生成SQL并下推，另一个是对MySQL返回的结果进行聚合。我们已经做到了对单表聚合类SQL的全面支持，分布式Join、分布式事务功能正在开发中，预计今年年内将推出。
对于传统数据库中间件的短板3，分布式SQL性能的优化目前还无法做到。一方面，分布式Join、分布式事务功能还在开发中，所以性能优化还无从谈起；另一方面，相比PG社区的greenplum等产品，MySQL社区尚无这方面的先例，还没有可借鉴的样本。不过，相信随着基于众多中间件的MySQL产品逐步向前推进，社区的力量将会显现出来。

（二）产品

聊完技术，我们来看看产品。

1. MySQL兼容

目前，在MySQL的兼容性上，UDDB原生实现了MySQL协议，支持MySQL命令行和各种语言的MySQL API。
在可视化管理工具上，支持Navicat，即将支持phpMyAdmin；
单存储节点读写分离模式下，已做到100%和MySQL兼容；
垂直分库模式下，即将做到100％和MySQL兼容（5月底上线）；
水平分表模式下，支持对单表的所有操作，包括Group by、Order by等聚合操作。
另外，UDDB还实现了对Load Data语句的支持。

2. 系统管理

在系统管理上，延续了UCloud产品一贯极简、易操作的风格。在一个页面，只用一步即可创建出UDDB实例；存储节点扩容、中间件节点调整、只读实例调整等均可一步操作完成；控制台内置中间件和数据库核心指标的监控。

3. 平滑扩容

在平滑扩容上，UDDB只需要一个按钮即可发起存储节点的扩容/缩容，在扩容/缩容期间，业务访问不受影响，只会在路由切换时有几毫秒左右的业务中断；同时，提供中止水平扩展功能，可以在扩展期间随时撤销扩展操作，撤销操作几秒内即可完成。

（三） 服务

UDDB团队的工作核心就是给客户提供优质服务，帮助客户有效解决单机数据库的问题。对于我们而言，服务是目的，技术是支撑， 资源是基础。技术和资源方面的工作都是围绕服务这个目的。具体来说，在服务过程中会有两个方法。
第一个方法是不仅把客户当做自己人，更重要的是把自己当做客户的人，要把自己当做客户的基础运维和基础架构部门，深入到客户业务细节一起制定数据库的分布式解决方案。
第二个方法是有效把握客户需求和服务中出现的问题与解决方案，将服务中的解决方案沉淀为产品，让产品基于服务动态生长。
作为研发人员，把客户当做自己人，首先是要跟客户交上朋友，但这可能是每天埋头干活的研发人员所欠缺的。对这个问题，UCloud平台刚好可以很好地解决。UCloud拥有数百人的销售和架构师团队，能够为客户提供一对一、面对面的技术咨询服务。他们是客户的顾问和朋友、IT行业的观察者、云计算价值的传播者。UDDB的研发人员通过客户经理和架构师这张网络，可以轻松地与客户成为朋友。
UCloud可以为客户提供以下服务：

1. 一对一地为客户梳理分布式数据库领域各种概念和技术，分享最新进展；
2. 一对一地协助客户改造数据库和业务架构，以及业务接入方案；
3. 系统测试全程陪同，业务接入全程守护；
4. 线上问题90秒响应；
5. 专业DBA帮助解决MySQL疑难杂症。

总结

基础软件领域，除了大教堂模式和开源市集模式，公有云的兴起产生了第三种模式——基于在线服务，服务先行，将服务沉淀为产品，让产品动态生长。
服务沉淀和产品动态生长的过程如同一个小孩通过试错而获得成长，一座花园通过修剪而不断美化，本身是很自然的一个过程。但要真正做好却不是那么容易，所以基础软件的传统做法都是大教堂式的，拥有严格而缓慢的开发、测试、产品发布流程。
互联网的兴起有可能改变这一点。过去十多年，互联网领域的产品动态生长理念已获得了众多成功和广泛认可。我们认为，公有云服务是互联网的进一步延伸，是传统IT行业+互联网。虽然，UCloud 在IAAS产品上五年的实践也证明动态生长理念在IAAS上有着巨大优势，但是在数据库研发领域，基于公有云这个平台是否也能够收获成功，则有待进一步观察和实践。