目录
1.SLA与可用性
当我们谈到高可用（High Availability,HA）时，这里的可用就是指可用性。
我们知道，任何东西都有不可用的时候。线上服务器或者应用也有不可用的时候。我们没有办法做到100%的可用性，只能做到高可用（<100%）,越高的可用性，付出的代价越高。总结为一句话就是：高可用必定带来高成本、高付出。
那么我们怎么来量化服务或系统的高可用呢？"高"字比较抽象，读者很难知道高到底是什么样的程度。所以，就有了SLA（Service-Level Agreement，服务级别协议，也称为服务等级协议、服务水平协议）的概念。SLA是服务提供商与客户之间定义的正式承诺。服务提供商与接受服务用户之间达成了承诺的服务指标------质量、可用性、责任。
阿里云ECS云服务器服务等级协议如下。
|--------------------|------------|
| 服务可用性 | 赔偿代金券金额 |
| 低于99.995%但等于或高于99% | 月度服务费的10% |
| 低于99%但等于或高于95% | 月度服务费的25% |
| 低于95% | 月度服务费的100% |
SLA的计算公式：
通俗的定义：SLA=可用时长/(可用时长+不可用时长)
不通俗的定义：SLA=f(MTBF,MTTR)
MTBF(Mean Time Between Failures,平均故障间隔)
MTTR(Mean Time To Repair or Mean Time To Recovery，平均修复时间)
MTBF:平局故障间隔，通俗一点就是一个东西多长时间坏一次。
MTTR:平均修复时间，意思是一旦东西坏了，需要多长时间去修复或者恢复它。
可见，提高SLA只有两个方法：一是提高系统的可用时长，二是降低系统的不可用时长。或者说，提供MTBF,降低MTTR。
SLA又可以分为年SLA、季度SLA、月SLA及周SLA等，年SLA除了客户赔款外，本身没有太大的意义，在实际项目中我们更加看重季度SLA、月SLA甚至周SLA。
SLA在不同的时间周期所允许的宕机时间：
|--------------|--------|--------|--------|--------|
| 系统可用系性% | 宕机时间/年 | 宕机时间/月 | 宕机时间/周 | 宕机时间/天 |
| 90%（1个9） | 36.5天 | 72小时 | 16.8小时 | 2.4小时 |
| 99%（2个9） | 3.65天 | 7.20小时 | 1.68小时 | 14.4分 |
| 99.9%（3个9） | 8.76小时 | 43.8分 | 10.1分 | 1.44分 |
| 99.99%（4个9） | 52.56分 | 4.38分 | 1.01分 | 8.66秒 |
| 99.999%（5个9） | 5.26分 | 25.9秒 | 6.05秒 | 0.87秒 |
系统的SLA要达到4个9是非常困难的，因此，系统的SLA阈值设置为4个9是一个比较合理的值。
2.影响高可用的因素
前面介绍了可用性以及如何去度量可用性，现在来讲讲影响可用性的因素有哪些，到底是什么原因导致系统的可用性比较低呢？导致系统不可用的因素有很多。
可以简单地将原因分为外在因素和内在因素两种。
外在因素即系统以外的因素，比如机房发生火灾、光缆被挖断、不可抗力等。
内在因素即系统本身的原因，包括系统依赖的资源（数据库、缓存、硬件资源等），比如服务器硬件故障、系统本身故障/Bug、系统依赖的中间件存在问题、数据库/缓存等宕机、发布新应用等。
要保证系统完全高可用是不可能做到的，只能尽量提高系统的可用性。
3.高可用策略
高可用策略实在太多，比如：冗余备份、限流/熔断/降级、监控等。可以将高可用策略按照时间维度分为3个阶段：事故前、事故中、事故后。
|------------------------|----------------------|----------------|
| 事前 | 事中 | 事后 |
| 冗余备份、硬件资源、安全防护、监控、运维值班 | 限流、自动水平扩容、降级、运维值班、熔断 | 自动恢复、人工接入、运维值班 |
在系统出现异常之前，需要未雨绸缪，例如：
冗余备份：保证系统的各个节点都要做冗余备份。单节点的应用改为多节点集群，单实例的数据库/缓存改为多实例数据库以及集群，当某个节点出现故障时，其他节点可以快读接管。
监控：重要的系统在上线之前，需要提前搭建监控体系，收集监控指标，针对监控指标阈值设置相关告警（短信、邮件等）。
安全防护：系统也可能遭受黑客攻击等情况，因此需要网络应用防火墙(Web Application Firewall,WAF)来保护我们的系统。WAF是一种HTTP入侵检测和防御系统，工作在OSI七层模型的应用层，为Web服务提供全面的防护。
运维值班：对于系统中重要的服务，在重要的时间段也需要提前安排运维，开发人员三班制24小时不间断地看护。
硬件资源：对于系统地硬件资源，比如磁盘、服务器、电源，也需要定期检查。
如果该提前做的事项都做了，然后系统在上线之前做好充足的测试（功能测试、性能测试、压力测试等），正常情况下，系统是不会出现什么大问题。
针对系统在突发情况下的一些应对措施，对应的策略有：
限流：每个系统/服务也有一个最大的承受能力，当流量太大，超过系统的承受能力时，就要进行一定的限制，这就是限流。很明显，限流是一种有损操作，是系统为了保护自己不得已才做出的动作。
降级：当系统有大量的请求流量进入（大促、秒杀、双十一活动、双十二活动），往往需要保证重要的服务而舍弃非重要的服务。例如，优先保证商品下单的完整流程，下单完成后通知用户消息可以先关闭。又比如日志降级，重要服务的日志打印功能保留，暂时关闭掉非重要服务的日志打印功能等。很明显，降级也是一种有损操作。
熔断：一个应用依赖多个服务是非常常见的，如果其中一个依赖由于延迟过高发生阻塞，调用该依赖服务的线程就会阻塞，如果相关业务的QPS较高，就可能产生大量阻塞，从而导致该应用、服务由于服务器资源被耗尽而拖垮。另外，故障也会在服务之间传递，如果故障服务的上游依赖较多，可能会引起服务的雪崩效应。
自动水平扩容：如果流量暴增，就需要服务有自动扩容的能力，自动增加服务实例。对于容器化部署的服务，可以使用容器编排技术（比如k8s）对容器进行快速扩容和缩容。如果服务不是容器化部署，就需要运维人员手工创建新的服务实例，等流量降下来再手工回收服务实例，当然手工操作是非常麻烦的。
最后是事后阶段的策略：
人工接入：服务出现难以恢复的故障时，就不得不让运维人员、开发人员介入，手工去重启或者排查原因。
自动恢复：当服务出现一些小的问题，比如内存/CPU开始吃紧，服务能够自动检测，自动进行内存扩容，不需要人工介入。又比如服务超时，当服务请求变忙，出现超时情况时，服务可以自动延长超时时间，让慢请求可以正常执行。
系统可用性越高，投入成本越大。所以，高可用是费钱的。
4.高可用和高可靠
可靠性和可用性这两者之间有一定的区别和联系。两者的定义如下：
可用性（Availability）：被定义为系统的一个属性，它说明系统已经准备好，马上就可以使用。换句话说，高度可用的系统在任何给定的时刻都能及时地工作。关注的是服务总体的持续时间，系统在给定时间内总体的运行时间越长，可用性越高。
可靠性（Reliability）：指系统可以无故障地持续运行。与可用性相反，可靠性是根据时间间隔而不是任何时刻来进行定义的。一个服务连续无故障运行的时间越长，可靠性就越高。
可靠性、可用性相关的指标如下：
MTBF(Mean Time Between Failure，平均无故障时间）是指系统在规定的工作环境条件下开始工作到出现第一个故障的时间的平均值。MTBF越长表示可靠性越高，正确工作能力越强。
MTTF(Mean Time To Failure，平均故障前时间)是指系统平均能够正常运行多长时间才发生一次故障。系统的可靠性越高，平均无故障时间越长。
MTTR(Mean Time To Repair，平均修复时间)是指可修复产品的平均时间，就是从出现故障到修复中间的这段时间。MTTR越短表示易恢复性越好。
如果系统每小时崩溃1ms，那么它的可用性就超过99.9999%，但是它还是高度不可靠，因为它只能无故障运行1小时。与之类似，如果一个系统从来不崩溃，但是每年要停机两个星期，那么它是高度可靠的，但是可用性只有96%。