介绍
在进入主题讲高可用架构之前,想让大家先思考几分钟,到底「什么是高可用」。
高可用性(英语:high availability,缩写为 HA)指系统无中断地执行其功能的能力,代表系统的可用性程度。是进行系统设计时的准则之一。
其实理解起来很简单,就是保证服务不间断的运行。比如,在百度上随时能进行搜索,在淘宝上随时能购买商品。
度量方式
根据系统损害、无法使用的时间,以及由无法运作恢复到可运作状况的时间,与系统总运作时间的比较。
计算公式为:
A(可用性),MTBF(平均故障间隔),MTTR (平均修复时间)
衡量指标
可用性是网站架构设计的重要指标,对外是提供服务的承诺,对内是相关团队的 KPI 考核指标,所以需要对可用性时间范围有一个清晰的认知
通俗说法 | 可用性 | 年故障时间 |
---|---|---|
6 个 9 | 99.9999% | 32秒 |
5 个 9 | 99.999% | 5分15秒 |
4 个 9 | 99.99% | 52分34秒 |
3 个 9 | 99.9% | 8小时46分 |
2 个 9 | 99% | 3天15小时36分 |
比如百度搜索,在业内高可用这块做的还是非常不错的,目测可用性至少达到 5 个 9 的标准 ( 99.999% )。
所以有时候当自己电脑网络出现问题时,通过下面这条命令来判断网络是否通畅,这本身也是对百度搜索高可用的一种信任
ping www.baidu.com
基本原则
高可用既然这么重要,那么做架构设计的时候,是不是有什么设计原则参考呢?
无状态设计
一般对于业务服务都会设计成无状态服务。每个无状态服务是相对隔离和平等的。
当出现某台无状态服务出错,比如宕机之类的。我们就采用故障转移方式,通过负载均衡策略,将流量划走到其他无状态服务上。
冗余设计
冗余设计针对某个服务通过多服务器或者多机房的要求来达到冗余的目的。无状态服务故障转移过程中,需要服务做成冗余设计才能实现。
当系统的 SLA 较高的时候,还需要考虑都机房的策略。比如微信、支付宝采用多机房的设计达到冗余的效果。
超时机制
服务超时主要是在调用方中设置,一般发送 Http 请求时候,都会设置一个 超时时间 Timeout ,比如 3 秒。当服务提供方没有在 3 s 内返回调用结果,调用方就根据自身业务逻辑来进行容错处理,选择继续走下来还是进行重试操作。
服务降级
生产环境中服务,一般可以分为核心服务与非核心服务。当我们出现资源瓶颈的时候,主要目标是保证核心服务的稳定性,非核心服务的接口或者页面可以直接关闭,以释放服务器资源。
比如京东大促的时候就降级了非核心服务
- 商详页不显示特色服务icon、促销信息等
- 实时统计和报表禁用
- 使用通用内容代替个性化推荐内容
- 评价列表禁止10页之后的翻页
上述挪列些基本原则,具体实现方面的内容,会在后续高可用架构服务层中着重描述。
总结
大家肯定听说过:「我出 100 万,帮我做个淘宝或者京东出来」
有些土豪觉得淘宝、京东不就这么点功能嘛,做出来有这么难吗? 其实纯功能方面倒是不难,难的是当用户量级增长 10 倍、甚至 100 倍的时候,系统的困难就会产生质变。
看完这些,最后让我们都扪心自问一下,你还敢说你的系统是高可用的了么?
下期主要讲高可用架构演变之路,敬请期待。