【IT168 技术】腾讯云基于QQ、微信、腾讯游戏等海量业务的技术锤炼，从基础架构到精细化运营，从平台实力到生态能力建设，腾讯云将之整合并面向市场，使之能够为企业和创业者提供集云计算、云数据、云运营于一体的云端服务体验。
10月31日，在第十一届中国系统架构师大会（SACC2019）现场，腾讯云数据库负责人林晓斌进行了以《大规模云数据库系统挑战和演进-易用性篇》为主题的演讲，深入浅出地介绍了腾讯云数据库系统在如何实现更高易用性方面的设计思考与实践。
一、数据库系统的基本要求
说到数据库系统基本要求，我们认为前面三项——可靠性、可用性、安全性，是及格线。
一个数据库系统天然要有可靠性，数据一定要有跨城市的冷备，保证不会丢。可用性是，在系统运行时正确存取所需信息，当系统遭受意外攻击或破坏时，可以迅速恢复并能投入使用，例如每一次主机故障最多影响60秒。安全性是指所有的操作都要有审计，可以防止信息的泄露和被盗。腾讯云数据库的安全技术提供跟微信支付同一套相同级别的安全能力，所以用户都不担心会有第三方窃取数据，比较关注我们怎么做到云上的运维工程师、运维方提供的安全性。
说到这三点，大家知道哪一个优先级更高？那肯定是安全性，数据不能丢也不能被偷走。下一个是可靠性，要保证每次写下去的数据一定能读出来，写下去的数据一定不被丢掉。下一个是可用性。如果发生冲突，比如可靠性跟可用性出现冲突时，应该选哪一个？当然是可靠性。比如主备切换时，主库瘫痪，如果判断备库有丢数据的可能，那我就不切，我一定要保证没丢再切。怎么保证没丢？多等一会儿或者多做验证，比如多花一分钟做验证，这时候拿可用性换可靠性，这些是基本要求。
性能和成本属于性价比，算是80分线。
说实话这十年以来数据库性能的优化和成本的降低主要得益于硬件的发展，比如磁盘读写能力，机械硬盘的iops是几百，现在都是按几十万来的。当然软件技术也在革新，不过最主要的原因还是硬件在发展，适配这个发展，数据库系统的设计思路也发生了很多改变。
真正把一个系统做到成熟了指标是什么？是易用性。在我看来，易用性是服务成熟度的标志，大家过了60分线跟80分线以后，拼的是易用性。
在制定目标时，在易用性方面通常都是说超出预期。那么一般我们说超出预期的时候，应该超出谁的预期？当然是超过用户诉求的预期。
二、超出用户诉求的预期
谁是用户？做一个数据系统，DBA就是我们的用户吗？实际上不止，我们认为一个系统的用户有很多，DBA是主要使用的人，研发和到服务端的售后一线也是这个系统的用户，还有云自己的运维工程师也是用户。
我今天站在云数据库系统开发者和设计者的角度上进行分享，怎么让所有的用户都做到超出预期——跟超出预期相反的是不及预期。每一类客户有多少诉求，我会挑最重要的三点来讲；每一类诉求做的不好是怎么样的，做的满足预期或者超出预期又是怎么样的。
1、客户DBA要什么？
客户的DBA希望：第一，维护成本低一点；第二，弹性能力好一点；第三，解决问题速度快一点。
1.1）关于维护成本
当你在做一个系统的时候，要先想到维护成本。我用三个颜色来表示满足预期的程度，最上面的是不及格情况，中间是满足预期的情况，下面这个是超出预期的情况。还有一个隐藏的，我们还可以再往前一步，不过没有列出来。下面我们慢慢分析。
从运维的角度来看，最不喜欢的就是封闭生态。大概在六七年前我碰到一个做自研系统的专家领军者，他说我们这个系统做得这么厉害、这个数据库做得这么厉害，不需要兼容开源协议，我自己搞，客户一定会跑来用我的。结果后来过了两年，市场就教育他了，后来他开始做MySQL兼容，过一段时间做Oracle兼容。
封闭生态意味着高学习成本和维护成本。客户DBA会想着自己构建的技能树在市场上的价值，对自己成长有要求的DBA，可能会提出系统至少要兼容开源协议。现在大家都知道，不管国内国外自研的数据库，都会或多或少的兼容开源的协议，大概也是经过了这个市场的教育，做得更好一点。
是不是兼容协议就算融入生态？不是，兼容协议是可以用客户端连上查询，就没了。备份迁移工具能不能直接使用现有的开源体系？如果可以，我们觉得这个系统做到超出用户预期。听上去像是全新的东西，但是我用原来市场上找到的、几乎大多数人用的技能树进行简单学习就可以维护这套系统，这是维护成本。
维护成本还有一个很重要的点，你能不能做到更方便的维护？腾讯云数据库有个天然的好处——微信，我们会把一部分运维操作在移动端上进行支持，所以在DBA外面遇到突发状况时可能不用掏出电脑，只用手机就可以操作。这种事情经过一两次，大家会觉得体验还不错，但是做的时候要想到这件事儿。
1.2）关于弹性能力
弹性能力做得不好的情况是需要手动操作，或者说每一次有什么扩容的操作都需要业务来配合，这样的话DBA会接受很大的挑战。因为所有没有状态的应用层都可以快速水平扩展，当出现问题的时候数据库系统就很可能变成整个弹性系统的瓶颈。当然，完全没办法扩容应该也不至于，只是说做得差一点，得上去各种手操，体现非常强的专业性。这看上去好像体现了很强的专业性，实际上处理问题速度慢，而且风险很高。
能满足预期的情况是什么？可以做到产品化以及小时级别的扩容，稍后我们会说一下这种架构大概是怎么做到小时级别。你说小时级别够不够？小时级别还行。比如电商尤其是互联网的业务，很多都可以支持预先预估，比如双十一快到了、还有618，各种平台都有。运营的人知道什么时候高峰期会来，可以提前做扩容，所以小时级别也够。
超出预期的是分钟级扩容。比如两分钟内做一个无节点，真正做到这样是挺厉害的。能不能说秒级？一会儿我们会说一下，当然秒级不是纯粹靠数据库层能做的了。
我们看一下没有扩展能力系统是什么样。不是完全没有扩展能力，最开始是支持简单的业务，一主一从的数据库，中间Proxy是为了客户切换时方便一点。很多数据库创建连接时成本很高，有了Proxy做连接保持，连接成本会低一点。扩容怎么做，登陆服务器执行各种工具和脚本，速度很慢。
但是这个已经是很多年前的了，现在能够达到大家的要求大概是（上图）这样两种架构，左边是一写多读的情况，一般也可以做到快速的，提前业务扩容，可以支持读的水平扩展，如果再多就得做读能力的扩展。右边是做写能力的扩展，我们系统看上去好像右边明显比左边好很多，如果全面碾压是不是左边不存在了？其实不是，一旦做了分片，有些业务请求需要做跨库操作，中间Proxy这一层需要做数据的操作，比如做排序、分组等等数据库逻辑的操作。这种架构很难保证100%兼容后端数据库，比如假设下面的master和slave是PG，左边架构就可以告诉你，100%兼容PG协议。
右边这种写是可以扩展的，但是一定会有兼容性的问题。一般如果你从单写集群迁移到多写集群，我们一定会建议业务同学要去做业务的回归，赶紧把所有的业务全量回归一下。真正有不兼容，中间Proxy是可以改的，Proxy不难改，有特殊语句我们照这个语句把逻辑写进去就是了。
如果能做到这样的排序能力也还不错，这个架构应该是2012年开始慢慢有人做。这几年围绕这个架构创新，比如基于右边的这种多写节点两PC的事务，如果觉得不够想再快一点，在几个Master之间做连接做分布式协议，让底层来实现分布式的事务，这样的话Proxy工作量可以小一点，系统一致性也更强一点。
这些都算是或大或小的创新，但是这些创新都绕不开一个硬伤，刚才说扩展一定是小时级别的，我们说小时级别是数据量大一点的情况，库很小不用。举个例子，一个节点有一个TB，这时开一个只读节点，把数据拷下来解压追日志，别的不说，下载过程很可能就要一个小时了。右边也一样，如果做数据分片拆分也一样，先拷备份然后进行数据同步。现在业务越来越大，拷数据时间越来越长。这一套方案用得很好的原因是，有很多业务可以提前做预估。大家知道后天要做活动，今天开始扩容，所以小时级别是够的，因为有两天时间让你做。但是这是电商类的、社交类的很难说，事件很可能是临时发生的，不能提前准备。
这个架构只是说满足预期，像数据库、CDB、TDSQL、Mongo、PG都支持小时级别的扩容。差别是CDB没有Proxy这一层，但是没有关系，比如左边读写，没有Proxy我们就可以用域名或者VIP，当然了像左边这种架构如果没有Proxy的话，你会拿到两个IP，一个主实例IP还有一个所有读节点读群IP，这是满足预期的操作。
怎么做到分钟级别？能否在不拷数据的情况下加能力呢？刚才说了历史上大家都在原来的架构上做一些或大或小的创新。2014年亚马逊搞了一个大创新，真正能解决拷数据的问题。最明显的特征是读节点和写节点之间共用数据，这意味着你到现在是一主一从，如果我现在压力大了，想再扩四个从怎么做？不用拷数据了，加四个计算节点就可以了，一两分钟可以扩一个，而且可以并行，这个首创者就是亚马逊Aroura。
腾讯云CynosDB目标是做成这个效果，可以实现分钟级，但不是秒级。首先拉起需要时间，接过来以后里面什么都没有，需要读数据，很重要的工作是要预热内存，还有Master跟Slave之间要同步信息。
分钟级别再往前能不能做秒级，或者一发现就马上做呢？我刚才说了不是在数据库系统内部做的，而是在周边。其实也没有什么系统需要说平时跑100%，只要监控它的增长曲线就可以了。比如一小时前50%，正常线一般就这样了，半小时前70%，20分钟前80%、95%了，非得等跑到100%才扩吗？可以提前扩，需要一到两分钟时间，但是我们可以通过分析系统的压力、趋势去提前预知有可能需要额外的增加，通过这种方式来提前扩容。
客户DBA要什么？简单一点，别让我上火，这是客户DBA的诉求。我们刚才说了能够有这样的一套架构，再加上不管你用成本来做还是提前扩容，这样在扩容方面是做到满足100分的线了。当然这个模式是单master写入，如果真正能做到多点写入大概可以做一些颠覆。目前读写节点磁盘阵列对网络要求也非常高，目前大家都在单可用区里做架构。跨可用区架构怎么办？基本跟上面的方案配套，每个可用区分库。
1.3）关于解决问题的速度
做的最不好的系统就是靠猜，把所有的可能性都处理一遍，比如运维一上去看现象，可能的解决方法有三十几个，每个都试，试完之后高峰期都过了。所以做的不好的就是靠猜，什么都没有日志，很多自研系统容易进入这样的模式，基本上不怎么打日志，或者打的日志都看不出什么东西。
做得好一点就靠专家，靠专家什么意思？日志打得足够详细，专家一来通过丰富的经验、监控数据、日志数据大概能够推测出问题原因，研发照着这个去改一下发现就好了，专家的价值是得到了很好的体现。
所以你要怎么提升一线的闭环能力？我们还是说是因为系统做的不好，后端黑盒，前线什么都不知道。你要依赖于售后一线同学比客户研发更厉害，这甚至可能是个伪命题。
第二个是最常见的FAQ&专业培训。真正解决问题的方法是让通用型的人才用一套专家系统能够变成专家，这个才能真的解决问题。我可能是普通的一线，每个产品都了解一下，一旦遇到数据库的问题，我用这套系统去解答的时候，我的客户认为我是DBA专家，要有这样的系统赋能这样的能力，这个闭环能力才能做起来。这样的话，前端客户也满意、老板也满意，后端也满意了。后端是专门做数据库的专家，我们作为构建这套系统的人，我们要了解他们的诉求是什么。
4、云运维要什么？
对于云运维人员来说，第一点，日志要准确，如果日志出错了就没得搞。本来数据库系统内部有很多错误，你写一个系统把人家做的很好的返回错误的信息屏蔽了，专家上来也懵。第二，监控要实时。
第三是Release note要准确。能做到让Issue跟Release note一样已经不错了，真正做得好的是什么？我们每一次发布都要告诉后端跟一线，说我这里加了这些功能，这些功能干什么用的，这些功能在什么场景会触发什么样的效果，在哪些场景效果好，哪些场景负作用，要把案例讲清楚。这样的话，这些专家才能够有用武之地，我知道你这个系统详细是什么样，客户来问题才能够解决。
三、小结
最后做一个小结。从下往上，首先是不管做什么，我们都要有服务意识。做云服务的，服务意识是基础能力，而且要知道服务的是谁。我们刚才说，这一套系统做出来服务好多层，客户DBA是我们的客户，一线、前端、开发是我们的客户。把信息透明出去逐层交付，DBA做专家系统让一线能力更强，一线让业务的DBA更强。再往上就是专家系统。
所以DBA团队说，用了云服务我是不是没价值？我会不会没饭吃？从逐层交付想法就知道，这个系统做得再好，还是有专家的发挥空间。我能帮你做智能诊断等很多功能，但是一定有很多新情况解决不了，这时我们退一步，把所有信息展示给你，你来解决系统不能自动解决的问题。客户的DBA再去做针对自己业务的专家系统，再去逐层交付，交付给客户研发。在下层系统做得更好的情况下，用好这个系统，才能提供更好的服务。
电话咨询
在线咨询