新浪微博数据库资源调度设计万级实例精细化管理

　　本文根据张磊老师在deeplus直播第263期线上分享演讲内容整理而成。（文末有获取本期PPT回放的方式，不要错过）
　　张磊
　　新浪微博基础平台资深DBA前必要商城、每优鲜、达令家级DBA，负责数据库资源的常维护和治理，完成从0到1数据库动化运维平台的建设，推进数据库资源架构标准化和分布式使姿势落地；前担任新浪微博资深数据库程师，负责微博数据库资源的运维保障和动化运维平台的重构、优化和完善。
　　今天分享的主题是微博数据库资源调度平台的架构实践，是我们内部启动的个项。主要实现的功能有两个：个是资源的智能调度，个是成本优化。都是常实的场景。
　　会我会从4个来做下具体介绍：
　　项启动的背景。
　　包括微博当前数据库资源的规模现状和运维员配，我们对资源治理的期望和标，以及我们对资源调度的理解。
　　然后介绍下这个调度平台的宗旨和使命。
　　就是我们希望通过这个平台达到什么的，希望它解决我们哪些痛点。
　　再重点介绍下平台的架构选型、实现式、逻辑设计和核功能。
　　最后分享两个案例。
　　来说明我们是如何通过这个调度平台实现应对热点事件和成本优化的。
　　一、背景
　　1、微博资源规模现状
　　先来看下微博资源规模的现状：
　　从两个维度来看：个是整体资源体量，个是资源使的种类。整体资源体量上，服务器规模还是较的，全服务器达到了万台平，总实例数近10万个，总访问量在万亿级别，资源使的种类也较丰富多样，关系型数据库有MySQL、PostgreSQL，缓存类有Redis、Memcached，消息队列有Kafka、MCQ、Qservice等等。
　　运维员配常低，或者说均运维实例数常多，差不多每个要管理1500个实例，这个数量已经常了，如果没有借助动化、标准化的运维段，是很难管理好这么多实例的。
　　2、如何做好资源治理
　　如此规模下如何做好资源治理是我们每天都在考虑的问题。
　　资源治理是个较抽象、概括的说法，我们需要拿很多东界定它才能让它具像化。家可以按照这个思路来捋下：
　　1）资源具体指什么（定义）
　　服务器，MySQL、Redis等这样的服务，服务发现、域名，Agent代理
　　资源治理的标是什么（标）
　　稳定性保障
　　快速暴露问题，快速解决问题
　　挖掘潜在隐患，制定应对预案
　　可控性保障
　　资源SLA可控
　　资源调度可控
　　资源容量位可控
　　2）怎么治理（法论）
　　通过资源调度实现
　　3）怎么衡量资源治理的好坏（SLA）
　　满业务的SLA
　　资源治理也包含很多细分领域和模块，如数据采集、指标决策等等。这些问题都找到答案后，我们对什么是资源治理就有个概的轮廓了。
　　3、什么是资源调度
　　上提到资源调度是资源治理的具体实现，我们要想做好资源治理，就要做好资源调度。
　　我们常对资源的很多操作，都可以抽象成对资源的调度。如：切主、升级、迁移、扩容、缩容等等。资源调度的核是服务愈。只有服务愈覆盖范围够，资源运维的规模才可能够，服务访问质量才可控，资源治理才可以真正落地。我们均运维的1500个实例，就像运维15个实例样，因为99的情况都被服务愈覆盖了。
　　今天要介绍的这个资源调度平台叫Shanks，它把我们常运维中遇到的资源和操作都抽象成标准化的类，然后和周边态起保障资源治理有序进。周边态有很多，如恢复中、资源云、指标决策系统等等。
　　Shanks资源调度平台
　　1、Shanks整体架构
　　现在介绍下Shanks的整体架构，可以分成四个部分：
　　其中ShanksServer和ShanksAgent的代码是放在个程下的，上线的时候，会同时成ShanksServer和ShanksAgent两个进制包。然后ShanksServer会部署在指定的服务器上，ShanksAgent会部署在所有服务器上，所有服务器上的Agent都是样的。
　　ShanksAgent负责metric指标采集、上报给ShankksServer和指标决策系统（采集包括服务器本身的指标，还有上服务的指标）。指标决策提供监控看板和基于采集指标的分析数据。同时，ShanksServer下发的命令，可以通过Agent直接执。
　　ShanksServer是主要的资源调度者，调度的接通过HttpAPI暴露出来，Agent收到Server的指令后，实施具体的调度内容。如迁移某个实例，Server会发出迁移指令，然后Server先执找机器逻辑，找到标服务器。让标服务器上的Agent执新实例部署，搭建主从关系，上线。然后让源服务器上的Agent下线实例，迁移结束。
　　2、五个主要功能
　　下要介绍的是Shanks的五个主要功能：
　　其中弹性调度可以从两个维度来理解：个实例维度，个配置维度。
　　实例维度是指当某个具体实例冗余度不的时候，弹性调度会通过扩容实例个数来增加冗余度。
　　配置维度是指，当某个具体实例已内存快达到配置的最内存的时候，弹性调度会通过修改配置增加最内存。
　　案例分享
　　当某个资源实例触发了报警事件，这个实例就会被打标，我们通过标签就可以检索出哪些实例触发了报警阈值，哪些指标有问题。
　　成本优化还是从两个来把控：个是提资源利率，降低冗余度；个是提资源智能调度的能或者弹性扩缩容的能。这两点做好，就能把成本优化到很理想的状态。
　　上就是这次分享的全部内容。谢谢家。
　　QA
　　Q1：若干个计算任务如何分配给若干个服务器，使得所用的服务器数量尽可能少？
　　A1：对于计算任务的调度和我们今天分享的对于资源的调用有点类似，都是通过调度逻辑合理利用已有的物理资源（CPU、内存、存储等等）。我们采用的策略是预分配策略，根据agent采集上报的指标信息，我们很容易知道当前物理资源的占用情况，我们可以根据这个情况，来对需要调度的资源进行调度，但是调度采用预先分配的策略，比如我计划把资源a（这里的资源可以理解成具体的服务，比如mysql、redis，或者具体的计算任务）部署到物理空间B上，这个资源a需要多少物理资源我是预先在物理空间B上标记好，下次再进行调度的时候我看到物理空间B的资源（CPU、内存、存储）剩余就是已经减去资源a的了。对于计算任务也是类似的场景。这个策略的迁移是需要做好资源隔离。
　　Q2：听完分享，感觉shanks很像servicemesh，方便说下选择自研的考虑吗？
　　A2：servicemesh是这几年比较新的东，servicemesh里面涉及到的服务发现的场景确实和今天谈到的服务发现很像。提供这种功能的工具确实有很多，比如consul、etcd，我们选择自研的原因很简单，一是本身实现起来不难，二是我们运维的资源类型很多，有些定制的需求，自研可能更容易实现。
　　Q3：服务效率的评价标准应该怎么定呢？
　　A3：服务效率可能从投入产出比来说会好些，比如我投入10个人，开发了3个月，做出了这套调度系统，我们利用这个调度系统，每年可以节省非常可观的开销，这中投入产出比或者服务效率是容易让人接受的。如果我投入10个开发了2年才做出了这套系统，我们利用这个系统，每年节省的开销很有限，那我们就认为服务效率不够好。我们在项目启动的时候确实衡量过这个成效，原则就是尽可能快的做出能覆盖80、90的场景。然后快速迭代。
　　Q4：请问下老师有哪些常用的资源调度策略？优缺点可以简单说一下吗？
　　A4：模式大体可以分为两种，一种是隔离类的资源调度，比如资源绑定，资源容器化；一种的非隔离类的调度，比如我把很多资源部署在一台物理服务器上。调度策略上，我们大体有几个原则：一是平衡策略，一是近地缘策略。平衡策略就是，把资源使用率高上面的服务调度到资源使用率相对低的地方。近地缘策略是指，优先选择同机房、同可用区的服务器作为目标服务器。我们在选择目标服务器的时候有一套打分机制就是基于上面的策略来做的。
　　Q5：跨云怎么进行统一资源调度？
　　A5：跨云的场景现在已经很常了，我们也同时用了多个厂商的云资源。每个厂商都会提供通用的API来实现相应的功能，所以从调度上看没什么区别，唯一的区别是跨云的网络延时会有点，控制好这个就ok了。
　　Q6：你们团队的组织架构能否介绍下哈？
　　A6：我所在的部是基础平台，里面可以分为应用运维、资源运维、大数据运维、基础组件这几个大的方向。
　　Q7：请问老师，如何划分资源粒度呢？
　　A7：一个资源实例或者一个进程是我们调度的最小资源粒度，比如一个mysql实例。比资源实例大一个级别的是一组实例，比如一个mysql集群，里面可能有几个实例，比一组实例大一个级别的是一类资源，比如全网所有的mysql。
　　获取本期分享PPT，请添加群秘微信号：dbachen