简介： 云上专属 自主可控 最省成本
作者：陈招尚（胜通）
一、自建数据库需要考虑的问题
自建数据库需要考虑的问题：
第一，搞定数据库高可用问题。
第二，提升数据库资源利用效率问题。
第三，资源瓶颈。提升利用效率的同时，解决资源瓶颈问题。
第四，运维幸福感。运维数据库需要解决运维幸福感问题。
第五，为公司节省成本。随着公司业务发展越来越强，对节省成本要求更多。
总结：DBA把数据库管理好，是基本岗位要求。“妆成有却无”，我们把妆画好了，但是别人却看不出来。我们数据库产品没有什么问题，并且每年为公司节约成本，对公司管理层来说，是DBA管理工作者的基本功。
但是数据库能否正常运行，受很多因素影响，有问题时DBA可能会背锅。因为应用瓶颈，大多用扩机器解决，但有的时候扩机器无法解决数据库问题。还有DBA人数和研发人数比例失调，一位DBA对应的服务有100位~200位研发人员。对支持业务与解决运维问题之间需要平衡，支持业务多一些，运维投入就少一些，DBA常常疲于支持业务与运维间平衡，两者相互制约。
自建数据库需要考虑的问题很多，在过去很长一段时间里面，经常面临各种选择问题。比方为了提升业务幸福感，如果晚上挂了启用延迟处理机制等。
二、阿里巴巴内部数据库的部署历史
阿里巴巴内部数据库的部署历史，10年前MySQL版本还比较低，没有大规模应用于大型系统中。
1）第一种部署很简单，如图所示：所有主部署全部在一台机器，所有备部署全部在一台机器。
在这种情况下，随着公司的业务高速发展，后端运维岗位投入、IT资本投入都比较大。从DBA团队角度来说，稳定性压倒一切，所以选择这种部署方式。比如部署三个实例，这三个实例同时提供服务，只要这台机器的利用率资源够用就可以满足。
那个年代在平时是没有问题的，但是在双11业务压力突然上涨的环境下，会有连接数问题：连接数很多，如果压力不够，对数据库响应时间会很长。
比如一台数据库实例，前面服务200台应用服务器，平时连到数据库只有5个连接数，正常情况下实例只有1000个，可提供1000个连接服务。如果在双11高压场景情况下，应用服务器从200台扩冲1000台，为了抗住压力，连接数会设到20~40，数据库系统里面的连接很可能会达到10000或者超过10000。
我们当时面临的情况是，应用数据库各个方面都没有异常，但是应用响应时间特别长。MySQL在当时5.1版本，业务压力增大的情况下，连接数是很大的问题。
第二个问题是：主机宕机问题。如果有一台主机挂了，主机内的三个实例全部需要切到新的一台机器上去。切换硬件相对的影响很大，三个实例可能包含公司1/3的业务，那么1/3的业务都会受到影响。为了减小这种影响，要求备库能够百分百支撑起这台主机挂掉的情况，所以主库和备库的配置需要保持一致，那么对备库的投入成本与对主库的投入成本也一样多。
2）第二种部署
因为业务发展太快，硬件达到指数级往上投入，公司要求DBA进行成本优化，如下图所示，实现主备交叉部署，主实例相对用到更多的资源，备实例用于复制备份场景，使用的资源会少一些。
这种部署下，我们面临的第一个问题是：部分超卖，堵运气。举例说明，比如主机部署了64核，感觉是部署了96核。DBA实行了部分超卖，这个时候就是堵运气。左边主机如果挂掉，两个主部署会全部切到右边的主机上面，左边实际达不到64核物理上CPU总数，这是第一个面临的问题。
第二个问题是读写分离。如果主备交叉部署时，还想要提升资源利用效率，自然会想到会将备部署利用起来，做读写分离，会把一些读请求放到部署上面，这种情况下，左侧的主机有流量，右侧的主机也有流量，利用率更高。当然这样做也有堵运气成分在，在大型促销场景下，需要把主备部署自动切换关掉，相信尖峰时刻机器不会挂掉，另外业务上把很多机器切开，影响面会比较小，所以当时以这种方式应对。
3）第三种部署
开始构建集群型的方式，兼顾成本与稳定性，如下图所示：
第一个提升是将不同的机器充分进行打散，引入现在还在用的内部系统叫移山系统，进行资源调度，根据监控每台机器的资源利用效率，及时触发条件，将整个集群里面的实例进行资源调度。相当于整体实例利用率水平保持在比较均衡的状态。
第二个提升是备库预热，如果突然主备切换，备库如果没有承担读会是冷启动，备库需要有一个预热的过程，否则如果流量很大，那么可能会出现备库被烫死的情况，对此我们做了备库预热。
第三个提升是读写分离的问题，我们也考虑到读流量。
4）第四种部署
重要系统和非重要系统交叉部署，如下图所示：
在前面三种模式下，核心系统和非核心系统分成两个集群处理，核心系统更会往稳定性部署，而非核心系统会更向成本优化角度部署。这时出现一个情况，就是我知道哪个系统是核心系统，哪个系统是非核心系统，但是如果出现非核心系统突然变成核心系统的情况，在认为的非核心系统里面咨询，非核心系统用到的资源会增强。为应对这种问题，我们增加了重要系统，锁定资源，不被争抢的功能，锁定资源不会增强。
非重要系统：大量混合部署，资源随时弹性，移山及时再平衡。比如做大型活动，流量上涨，可以根据资源CPU跟IOPS利用效率把机器上其他资源移走，实现资源利用效率整体平衡。
三、经验分享
经验1：主备交叉部署，一种伪超配的降成本方案
如下图所示，实际上一台机器用到了96核，但是主机上是64核，因为主资源备交叉部署，利用的效率并没有达到满负载。
收益：
- CPU资源利用效率整体上达到70%。
- 连接资源被有效利用。
- 更低成本。
注意点：
- HA机制要灵活，什么时候自动切，什么时候手动切。如尖峰时刻手动断开主备库的连接，以应对高流量咨询问题。
- 主机问题监控，核心资源打散。比如双11的时候，后端资源保障上都会资源打散，大家千万不要让主机满载运行，如果主机满载运行的话，一旦挂掉就会出现雪崩的情况，因为切到备库，备库也会挂掉，这是我们的一个经验。
经验2：应用分级，保障粒度差异化
应用分级，以不同的分级保障不同粒度差异化，比如分为一般性业务或重要性业务。一般性业务，可以利用交叉部署获得更多资源利用。重要性业务，更偏向稳定性方案，一定要有对外SLA保障。因为很多一般性业务依赖于中小型的业务，做应用分级，可以提升整体利用效率，提高可用性。如下图所示：
两种不同等级业务的数据库资源模式
两种不同等级业务的数据库资源模式，需要通过三个阶段的隔离实现:
- MySQL实际上是吃内存性的，比如内存有64g基本上会把64g内存用完，超卖在内存这块是做不到的，所以开始从内存隔离，隔离过后，在一台机器上使用内存大家不会抢单。
- 如果在非重要的集群里面，业务流量突然上涨，非重要变成了重要，就把CPU绑定，实现 CPU的隔离，使其不会被争抢。
- 如果重要性上升到公司的核心业务，这时可能会把它独立出来，进行物理机隔离，进入第三个阶段。
经验3：两种抽象的资源部署方案
无论是数据库，还是应用部署，资源调度对最底层的分配方式只有两种：均衡分配与紧凑分配。
均衡性分配，如下图所示，离散型数据库实例分布，优先在更空的主机上继续分配实例，资源主机的利用率相对比较均衡，整体性能表现也会相对比较稳定。
紧凑性分配，如下图所示：堆叠型数据库实例分布，优先在更满的主机上继续分配实例，资源主机的利用率会更高，各主机性能表现不一，成本更优。
紧凑型和均衡型交叉应用场景
典型应用场景，比如一开始是紧凑性分配，更关注成本。大促的时候，增加了机器，变成均衡分配，实现资源均衡综合调度。大促做完之后，再回归到紧凑性分配，把机器空出来用到需要的地方。这种资源挪腾可以是自动化的，也可以人工手动方式进行挪腾。平时紧凑分配使资源利用率更高，成本更低，大促时使用均衡分配，稳定性更高。如下图所示：
经验4：资源弹性，消除业务流量评估焦虑
业务流量评估焦虑：
- 评估过程：业务指标–业务QPS/TPS–全链路压测–数据库准备。
- 标准上线流程：提前资源报备，详细部署监控，SQL审核，深夜值班观察表现。
- 三种结果：没抗住是因为没评估好，抗住了是应该的，资源利用率不高是因为没评估好。
如上图所示，业务方心目中的每一个数据库都非常重要，业务是他的全部。但是DBA实际操作时会区分出哪些是核心业务，如右图红色部分；哪些业务是非核心业务，那些业务运行一段时间就下线了等。
所以从DBA角度看，数据库地位实际上是有差异性的，为应对这种差异性，我们在内部专门做了混合性集群，这种模式下，DBA开始时不需要评估流量大小，可以直接放入集群中。如果业务突然涨上来，可以迅速地弹上去，然后立刻锁定CPU，使其不会再增强，保证一段时间内的重要性地位。如果业务持续增长，再把其转移到专门为其设置的集群里面，这个过程保证了数据库的稳定性和可用性。同时减少了因DBA评估错误出现的问题。
四、云数据库专属集群产品介绍
云数据库专属集群 部署架构图
针对阿里的实践，在云上推出了云数据库专属集群，这种专属集群与PaaS平台区别是什么？
PaaS平台买的都是实例，专属集群买的是主机，客户可以自己构建一整套专属集群模式，构建专属的一套技术管理业务，好处还包括能够超配、客户自己管理、可以实现主备交叉部署提升资源利用率、可以实现在不同机器之间资源调度、资源再均衡、资源迅速攀升和收缩等各个方面的能力。
以上是专属集群的产品简介，总结：第一它是云上专属的数据中心；第二是自主可控；第三是因为DBA对业务更了解，可以实现成本最优化。
云数据库专属集群 能力建设进展
PAAS服务有的功能，云专属数据库都有。混合部署在研发中，其他我们都已经实现支持了。原数据库 PasS能力都有，包括高可用、高可靠性能等方面。
另外我们还新增了资源调度功能，包括紧凑型、均衡型、通过移山进行资源均衡、资源的弹性扩缩等等。云数据库专属集群是以主机的形式在管理数据资源，不再像PaaS平台是以实例的形式管理。
