负重前行—顺丰数据库运维的求变之路

作者简介：

刘力，顺丰科技 应用数据支持部负责人。2013年加入顺丰科技，数据库团队负责人，主导了顺丰科技数据库架构从非标到标准，从传统到开源，从集中到分布式的技术演进；带领DBAs，从被动到主动，从不变到求变，向人工到智能的运维模式转变。十余年大型数据库架构设计和管理经验；曾任职平安科技，负责银行业务线数据库架构设计和管理。

前言

今天主题是“负重前行—顺丰数据库运维的求变之路”，为什么说负重前行？传统的公司做互联网转型历史包袱非常重，尤其是在顺丰业务高速发展的过程中，这种转型就像在高速列车上换轮子一样，风险很高。

顺丰的业务在逐年增长，另外我们的业务领域也在不断地拓展，从快递到冷链、仓储、金融等，我们管理的数据实例量也在成倍增长。

在这种状况下，我们还要经历一系列的技术变革。

• 第一阶段：最开始的数据库类型很多，我们主动进行标准化改造

• 第二阶段：公司上层做了决策，从上自下，要从传统的领域转向互联网领域，技术栈上就是要从商用到开源领域的转型，我们也要顺应这个转型。

• 第三阶段：就是在全面开源的情况下，如何高效的管理爆发性增长的分布式数据库集群。

我今天讲的内容是：非标到的标准，传统到开源，集中到分布式，智能运维。其中会着重讲一下集中到分布式，以及智能运维的内容。

1、非标到标准

1.1 非标到标准—洪荒之年

数据库类型繁多，DBAs被技术割裂，忽略用户需求。

1.2 非标准到标准—穷则思变

面对比较繁杂混乱的状况，我们做出一些主动的改变，不然就陷入恶性循环。 第一：我们会减少DB的种类，选择当时团队技术能力比较强的商用数据库作为标准；

第二：统一基础架构 HA 和 容灾方案，避免个性化方案导致处理不熟练引发的运维异常；

第三：关注基础资源状态，存储出问题，网络出问题，主机出问题，都是我们的锅，如果不正视的话，这个锅永远存在，所以你要关注它，解决它。

第四：主动预防，我们做一个闭环，这样把一些问题通过一套系列的流程和机制全部建立起来；主动预防跑起来后，我们整个数据库的稳定性得到提升了，DBA可以从反复的扯皮中脱离出来，做真正有意义的事情。

2、从传统到开源

2.1 传统到开源—去商化

上层决策，要做互联网转型，要用开源技术，我们要顺应这种趋势，既然想在这个位置上座，就得干，我们要做大力水手，而不是鸵鸟。

我们拿核心的仓储系统做试点，仓储对顺丰来讲是非常核心的系统，当时的转型压力还是很大的，不像一般公司里找一个外围系统看一看，我们的决心很大，上就上核心系统。

另外很多公司的做法是从外面高薪招聘一些Mysql专家，来做这种变革项目，我们基本上靠自己团队完成这个转变，当然我们也从外部引入了第三方服务商。

我们最开始的思路就是，既然开源数据库的能力相对商用数据库还有比较大的差距，那么我们对开源数据库要简单用；我们要想到，关系数据库的关键和本质在哪里，我们认为数据库的最核心的地方有两点：

一是控制事务，如果不能处理事务的话，很多场景根本不需要数据库；

二是索引，关系型数据库创建索引，使用索引非常方便。

所以，我们抓住这两点：

第一，业务逻辑不要在数据库做，它只做关系型数据的容器，最后业务逻辑都上升到应用中去。业务逻辑是无状态的，应用扩容比较容易，4个不够8个，8个不够80个。

第二，控制规模，因为我们最开始是没有能力做分布式方案的，怎么办？就从业务逻辑上去拆，全部拆开；我们当时让研发，垂直拆分了8个数据源，数据耦合度不高的都拆出来了。当时也没太多办法，单个实例压力太大的话是Mysql是无法支撑的。

第三：HA方案靠SAN来解决。

怎么保证数据不丢失，我们退一步，当时还是用SAN来解决主机 crash 情况下数据不丢失的问题。技术本身对企业不是最新的就是最好的，而是对企业当前阶段，能解决企业问题的技术就是最好的；当然，我们也同时着手开始研发一套非SAN的自动切换方案

2.2 传统到开源—运维开发

第一，既然是去商化，SAN也是要干掉的，所以我们开始着手做自己的运维研发的转型。我们花了半年左右的时间逐步打造自己的研发团队，从外部招了一些相对经验丰富的运维研发人员，两三个，然后带着我们自己内部的大学生；因为大学生是一张白纸，一个有经验的人带着大学生往前冲，出成果的几率比资深运维转研发的几率更高。

第二，团队建立之后，我们发现其实运维主管去管研发团队，会有一些角色上的偏差。运维工作严谨性很高，按章办事很重要；研发则需要一定的创造空间；管松了，做来的东西运维不敢用，管紧了，又会限制创新。

我们做法是，让研发一定限度的接触运维工作，让他们了解运维的严谨性，研发内部的过程管理还是让有经验的研发人员控制，运维则要不断输出需求；后面我们以一线运维的需求做抓手，驱动研发往前走。

第三，我们研发团队建立之后，从最开始的整个需求、研发、测试、发布都自己玩，最后做规范化的改造，我们有自己的需求小分队，有架构师、有研发小分队，针对这个产品有自己的运维分队，把这些东西都隔离出来，各司其职。

第四，不断增加运维的参与度，现在平台开发主要是解决运维的问题，运维什么地方痛运维自己知道，所以他需要做需求分析，需要做原子操作开发，需要验收和吐槽，我们建立了吐槽机制，把研发和运维联动起来。

3、从集中到分布式

3.1 集中到分布式—单实例性能瓶颈

现在谈一下我们从集中到分布式扩展的过程。单个Mysql TPS上限是1万+，当然极限上可以跑到3万左右，但我们真正用Mysql一般控制到5000以下，尽量不超过2000，是比较安全的。

我们之前讲仓储系统，最开始从一个拆到8个，已经非常多了。但是再往下垂直拆分就拆不动了，再拆数据需要在数据库之间做大量交互，这样失去了拆的意义。

这种情况下我们进行了区域拆分，把全国的数据拆到北京、上海、广州、深圳，拆了很多出来，但这样对运维和研发压力很大。

第一：对研发来讲，他需要做应用架构改造，至少要做导流，要把深圳的导流到深圳，北京的导流到北京，前端后端都需要改造。

另外，关联数据要处理，因为不像一些业务区域性很强的公司，比如滴滴，深圳的单在深圳，北京的在北京。顺丰的运单可以从深圳寄到北京，这种关联数据需要处理，这种很麻烦。

第三：对于运维来讲，他需要部署N套应用，因为部署一套数据库就要部署一套应用，这样我们有一百套数据库就有一百套应用，而且怎么保持一致性也是运维很头疼的事情。

3.2 集中到分布式—Mysql_proxy

我们当时引入Mycat之前，也是测过多种类似的产品，包括开源和商用的；我们经过了大量测试。

结论，第一，和商用的比较，它的性能和稳定性表现良好。第二，它分片路由的基本功能满足我们主要需求了，那些读写分离的功能我们暂时都不考虑用。最终我们还是选择用Mycat来做数据库中间件的基石，还是在我们开源的思路决定的。

我们基于Mycat做了很多二次开发，以满足我们对性能和稳定性的需求；目前我们最核心的运单系统跑在这套架构下，在高峰期的TPS达到20多万，这算比较高的值，当然跟互联网公司还有一定的差距。

我们之前是基于Mycat1.5做的二次开发，其中压测以及生产中发现的影响稳定性的主要bug都close了，后面把我们一些相关的代码也上传到社区，也是取之于开源，用之于开源。

新增了几个对我们内部比较适用的功能

第一：我们做了SQL防火墙。主要解决DBA和研发反复沟通SQL质量的问题，我们把SQL审核规则逐步做到防火墙里面去。

第二：做了大数据汇聚的功能。一旦有大数据汇聚的SQL，需要全分片扫描的情况下，而且扫描数据比较大，比如一两百万，这个Mycat就很容易crash，因为它的内存被撑爆了，这样对生产运维还是有很大影响的，所以我们做了大数据汇聚的功能。

3.3 集中到分布式—大数据汇聚

这里讲下，大数据汇聚的功能。我们把大排序从堆内移到堆外，从堆外移到文件系统。在正常的业务系统里面，不应该有这么大的排序。我们做完之后，经过测试可以实现上亿数据的聚合，可以有效避免OOM。目前生产OLTP系统用到这个功能的频次不高，主要是用于大数据平台做数据抽取。

3.4 集中到分布式—SQL防火墙

为什么做SQL防火墙，因为文档和培训永远赶不上研发人员迭代的速度，不断有新的研发加入和离开，另外，外包变迁也是非常频繁的事情，很多情况下要保证规范能够落地，靠人事实证明效果并不好，只能靠平台了。所以我们要把规范和要求全部落地到平台上去。

比如最简单的，Mysql的表不建索引，这个事情要能从开发环境卡住，让它报错，研发人员为了解决报错，总会把问题解决掉。SQL优化的事情，需要和研发反复沟通，沟通成本在我们工作里还是占了很大比例，所以我们也希望通过平台方式把它降低。

这个主要部署在开发环境中，生产环境目前不敢开这个功能，因为对性能会有一定的影响，目前生产环境只做了信息搜集。当然在应急的情况下，可以做异常SQL的拦截。

4、智能运维

面对膨胀的DB数量，运维复杂度大幅提升。我们需要解放DBA双手，需要做我们自己的自动化运维平台。

对外，主要提供服务自助和信息透明化，把DBA对外的沟通成本降低

对内，我们主要做Mysql资源池化的动态管理；通过库存管理来实现硬件资源的动态管理，资源池内通过监控数据和容量预估数据，在不同OS节点之间动态调整实例分布，实现均衡分布。

4.1 智能运维—联合作战

我们目前内部做的一个自动化管理平台就是叫Thinkdb，基础架构内部有一系列的基础功能性平台来做底层支撑。

• 配置平台：以应用系统和组件2个维度做配置数据的自发现；

• 监控平台：组件状态实时数据采集；

• 容量平台：日常容量管理，高峰容量预测。

• 硬软件实验室：这个是今年开始做的，主要是在基础架构底层做优化，同一硬件设备如何通过硬件参数，OS参数，应用参数的调整，能够支撑更多的应用实例，或者相同的应用压力下，资源消耗更小，响应更快。

• 交互平台：面向用户的，自助环境交付。

• 容灾平台：面向容灾场景，批量的自动容灾切换。

• 恢复平台：主要是处理逻辑错误，指定时间点进行自动恢复。

4.2 智能运维—解放双手

下面我对thinkdb的关键功能做下介绍。首先是配置管理，其实配置管理大部分公司都有做，但怎么样做到配置信息的百分之百准确？1%的不准确，都有可能导致部分数据库实例变更的失败，进而导致生产故障。

我们通过3个维度来保障准确性，第一：thinkdb会接入外部配置平台的数据，第二：thinkdb内部会通过jdbc轻量级的获取相关数据，这两方面的数据互相校验，要求耦合度100%，第三：是在所有命令下发之前，会实时校验实例状态，一定要保证此时此刻的实例状态和实际情况一模一样。

其次谈下HA的自动管理，我们建立运维研发体系，第一个目标就是开发自己的HA架构，达到去SAN的目的。我们底层数据一致性是通过MGR来保障，这个功能推出的时间不长，我们通过POC可以满足我们的基本需求，就大胆的用起来。对数据库一致性的要求高的系统，我们通过MGR+OS/DB双心跳确认+服务恢复，来自动恢复服务。

对数据一致性要求没那么高了，我们通过半同步+OS/DB双心跳确认+服务服务恢复，来恢复服务。

另外，发生HA事件后，HA状态会自动恢复。自动重建异常结点，并恢复同步，容灾节点自动和新节点建立同步关系。避免DBA因为主机异常需要不断人工修复HA的状况。

再谈下资源池管理，我们设计了一个资源池管理的逻辑，通过Pctfree/Pctused来控制资源使用率的上下限，超过上限，定期触发实例自动搭建在低于下限的节点上，并自动切换和原节点下线。

除了日常容量的自动平衡，我们也会对接容量平台，获取高峰期的容量预估数据，通过将库存资源补充到大资源池，触发动态平衡，以满足高峰期容量需求

最后讲下我们对SQL代码质量的控制。

在开发环境，主要通过Mycat内嵌的防火墙拒绝不合理的SQL；

在版本发布流程中，有个SQL代码审核的过程；

在生产环节，除了通过主动预防不断推动SQL优化外，我们会按照业务系统群对其当前的SQL质量做整体的打分，打完分之后，会做一个排名榜，给到对应的研发老板。

也不用谈具体哪个系统哪个SQL有什么问题，按业务系统群做整体排名，来推动研发从上至下的优化SQL代码。

4.3 智能运维—业务支撑

这里讲一下我们Thinkdb在顺丰的运用情况，目前我们多套核心应用都纳进去了，包括微信下单，运单系统，收派系统等等，然后新实例上线，会自动接入Thinkdb平台。老实例逐步改造，加入Thinkdb管理，目前覆盖率40%。

想压力比较大的运单系统，一共100多个分片，双11高峰TPS 20多万，整个高峰运行平稳。

4.4 智能运维—放飞大脑

大部分要介绍的都介绍完了，作为一个DBA老鸟，想谈谈关于DBA的一些心得。首先，一个优秀的DBA，刨去技能本身，他的沟通协调和逻辑思维能力是很强的，有了这2项基本素质，然后开放心态，要敢于尝试的上下游技术领域。

现在我们团队有数据架构师，有运维开发，还有需求分析师、产品经理。 整个研发团队虽然不大，但是五脏俱全，什么都有，运维DBA也愿意去尝试新角色，天天窝在一个技术圈子里大家也会觉得太腻。

4.5 心得交流—运维转型

最后讲讲如何做好运维工作。做运维不能仅仅关注自己的一亩三分地，想运维稳定，你需要把上下游的灰度地带都管理起来，当你把问题都看成自己的时候，你的边界会在不断扩展，你的基础就会越牢固。

我们最开始比较惨，五年前我们的故障可能每年有20多个，有DB本身的问题，也有底层硬件或者上层SQL导致的问题，但是对于用户来说，就是DB不可用或者慢。

随着我们把应用的问题以及OS的问题，存储问题等变成自己的问题后，发现这些问题逐渐在消失，因为你如果觉得是自己的问题就会不断推动去改，DBA在这个过程中他的技术视野也扩大了，综合素质也提升了。

通过主动预防工作的推进，我们从五年前的故障20次，3年前10次，最近三年的故障已经控制在0次。这整个过程是在业务量快速增长以及不断技术变革中完成，还是非常不容易的，一方面DBA团队有很多付出，另一方面研发有愿意帮忙做应用层的改造和优化。

这也从上自下的思维的改变，从传统向互联网转型除了技术变迁，最重要的是思维变迁，包括运维和研发的思维变迁，除非大家一起做到，不然整个变革很难成功。

运维是有原罪的，因为运维是做减法的，传统意义上看，零故障情况下就到顶100分了，你做不到120分，但研发做项目可以做到120分、200分。

但是换个角度看，如果你把基础运维做扎实，这100分就拿到手了，其他任何创新都是加分项。

而对研发来讲，创新是他的KPI，是应该完成的事情。这种情况下，你可能更容易比研发拿到高分。有着稳定的生产环境，然后基础技术领域的不断创新带来的成就感，这样一来，运维也是能够给人带来快乐的工作。

谢谢大家！

国内首家 AIOps 企业峰会（ AIES ）震撼来袭！

读完本期高效运维社区

有关数据库运维转型的分享

你有什么想对我们说的？

智能运维已经悄然来到我们身边

“对着破电脑，一调一下午”的时代

或许会一去不复返

那就来AIES 大会吧！

本次大会的三大亮点▽

更多大会详情，请扫码关注▼

点击阅读原文，进入购票官网