我与SLA(服务等级协议)的爱恨情仇

#创作灵感#

• 要面试了，看了一下面试的需求，他们的那个岗位有说要熟悉SLA。
• 以前听说过SLA，但是没有具体去了解过，今天突发奇想百无聊赖的看了一些文章的自我感想

前几年一直能够听到云厂商进程说我们的服务能达到几个九这类的，我当时就很好奇这几个九到底是什么意思，但是吧，我懒。不过现在我重新拾起了这个概念，一方面是为了应付这个面试，另一方面是以前我很迷茫，当时就相信未来的我一定会，没想到未来的我也一样懒，所以不要轻易相信未来的自己一定会怎么样，要脚踏实地的亦步亦趋才行。

其实这里的几个九就是说的SLA(服务等级协议),这个协议是用来衡量一个服务的可靠性可用性的指标。

所谓的高可用性HA就是这个系统必须是有冗余(也可以说是集群化的)+failover(故障自动切换),比如像Mysql的MHA，这就是一个高可用的架构，能够实现主库故障的自动切换，如果再加上keepalived绑定一个vip，让vip进行漂移的话，就可以实现用户无感知很丝滑的故障自动切换failover，因为用户只需要固定访问这个vip就可以了，其他的她不用管，内部流量是怎么切换的，故障是怎么自动摘除的由MHA这个软件来做即可。

说回来这个几个九，比如之前生成我们的服务能到达4个九，就是服务的可用性是99.99%,此时我们可以利用小学数学计算可以轻松的得出来52.56分钟(365*24*60*0.1%)也就是说这个所谓的四个九的服务一年的时间她的故障时间不能超过52分钟，超出这个时间云厂商就会对此进行赔付了。

那么为什么前几年一直在吹捧SLA能达到多少个九，为什么要做高可用呢？（自问自答)

可以看一下我下面这个链接说的文章 《支付宝三年光棍节高可用系统架构的演变》

https://wenku.baidu.com/view/444baa0ace2f0066f433221e.html?_wkts_=1726582897590

简而言之就是传统的架构是一台机器用来响应用户的请求，这个会出现什么问题呢，当我们的QPS，就是吞吐量大的时候，并发量大的时候，这一台机器不一定能承受的住这泼天的流量

一个人哪能承受的住这泼天的富贵呀！！！此时流量一旦大起来了，机器顶不住就容易出现宕机。

这就是SPOF问题(单点故障),为了解决SPOF问题，所以引入了高可用的架构思想，比如mysql的mha，redis的setinel，mongodb的副本集，nginx负载均衡都是高可用架构思想的落地实践，都是为了服务它的。

为了处理单点宕机问题，技术人员研究出来了高可用的架构思想。

精密机器在运行之前，会有技术人员对每一个零件进行检查，因为当这个机器高速运转的时候，一个零件的损坏可能就会导致整个机器连锁反应全部雪崩，这就是所谓的牵一发而动全身。互联网上的用户业务也是一样的，现在流行微服务这种概念，将业务拆分成多个小业务去运行，一个小业务如果运行出现了问题可能会导致整体的业务收到影响。

所以对于我们服务的高可用保障是非常必要的，但是也是需要投入大批量的人力和物力，也许有机房的建设，机房要做两地三中心，异地多活这样的高可用策略，同时天气热起来了，机房散热降冷需要电力来维持，又是一笔巨大的开销。后来云厂商的出现，将这些都交给云厂商来做就可以了，我们只需要把我们写好的代码托管到云上即可。

接下来我们谈一谈如何保证服务的可用性，应该从那些方面考虑？(又是自问自答)

---

从服务架构方面来说：1. 可以根据节点分布考虑是否使用多活两地三中心，异地多活这种容灾的机房部署方式 同时机房部署的过程中需要考虑可用区Zone不同可用区要使用不同的电力系统和网路系统防止非机器本身因素导致的故障

2.避免SPOF问题，至少要做双机热备

3. 防止代码之间相互干扰，避免稳定的代码和频繁更迭的代码放到了一起，可以做业务代码和功能代码的分离处理

4.数据库最好要做缓存，防止出现雪崩效应

从运维人员角度来说： 运维人员要对业务做好监控cpu，内存，磁盘，io负载，网络带宽等方面的监控，可以根据不同级别告警类型实现不同的告警内容推送，发版的时候变更的时候最好灰度的去做。

从开发人员角度来说：代码编写过程中要多思考想到各种会出现的异常并做好异常处理的代码逻辑的编写，确保代码异常不会导致整个服务崩盘，同时需要保证服务是可以支持水平扩展的