高可用系统常用解决手段浅述

简介:

所谓可用性,是指 某系统能够提供正常服务的特性。

可用性的高低是使用不可用时间总时间的比例来衡量。不可用时间是从故障发生到故障恢复的时间。 比如,可用性 4 个 9 的系统(99.99%),它一年宕机时间不能超过53分钟(=365*24*60*(1-0.9999)) 。 做到高可用系统,需要尽可能的降低故障发生的次数减少故障持续的时间

出现系统不可用的原因,一种是人为的,比如发布了有 bug 的代码、不规范的发布流程导致的宕机或者网站访问量过载造成的雪崩等;另一种则是非人为的,由于外部系统和环境的变化造成的,比如硬盘老化造成的故障、机房断电、电缆中断等。我们需要在复杂的外部环境下保证系统的高可用。以下总结了常用的高可用解决手段。

1 拆分

这类解决手段不是以减少不可用时间为目的,而是以减少故障影响面为目的。因为一个大的系统拆分成了几个小的独立模块,一个模块出了问题不会影响到其他的模块,从而降低故障的影响面。手段包括:

1.1 水平拆分

系统水平拆分成三层:接入层,服务层和数据存储层。将有状态和无状态的划分开来,接入层和服务层设计成无状态的,存储层是有状态的。无状态层的服务可以平行扩展,请求落到哪台服务器都没有关系。平行扩展也有利于系统容量的扩充,快速扩容应对突然爆发流量的冲击。

1.2 垂直拆分

根据功能垂直划分,拆成相对独立的模块。有的仅是服务层做了拆分,存储层共用。更为彻底的是,拆分与该系统的业务领域模型关联,一个领域模型划分成一个模块。在数据库层面,还可以分库分表拆分,这样一个库的损坏,不会影响到其他库。分库分表需要增加路由逻辑,及保证路由规则的一致性。

1.3 读写分离

也属于垂直拆分的一种。写请求的依赖主库,读请求的依赖备库。这样做,当出现故障的时候,可以只有读请求的流量,写服务暂时关闭,从而减少了故障的影响面。但需要关注数据一致性的问题。

2 降级

这类手段不是为了避免故障的发生,而是当故障发生后,怎么减小故障所造成的损失比如,系统正常时提供的服务能力是 100%,出现系统故障后,我们有措施能让系统服务能力不直接降到了 0,而是还能提供 50% 的服务能力。

2.1 限流

限流,流量控制。当请求量超过系统的最大容量后,访问延迟就会增加,超过峰值的流量会拖累整个系统,出现宕机。因此,需要提前流量控制,对于超过峰值的流量,可以直接拒绝掉或者随机选择拒绝。限流结合业务自定义配置,优先保证核心服务的正常响应,非核心服务可直接关闭。

2.2 异步调用

系统进行拆分之后,会分成多个模块。模块之间的依赖有强弱之分。如果是强依赖的,那么如果依赖方出问题了,也会受到牵连出问题。这时可以梳理整个流程的调用关系,做成弱依赖调用。弱依赖调用通过消息中间件的方式来实现

异步调用不关心返回结果,不会传递依赖方的错误,进而避免造成更大规模的不可用。

2.3 同步调用合理设置超时时间

对于不能异步化的,采用同步调用,需要注意设置合理的超时时间。过长的超时,会延迟结果等待时间,导致整体的链路调用时间延长,降低整体的QPS。

经验值:超时时间设置成平均响应延迟的2倍

2.4 失败重试

要区分调用失败的类型。有些失败是短暂偶然的(比如网络抖动),进行重试即可。而有些失败是确定,那么重试反而会造成调用请求量的放大,加重对调用系统的负担。

经验值:重试的次数一般设为3次,再多次的重试没有好处。

2.5 兜底方案

在系统真的出现了不可用的时候,需要有兜底方案。比如一些提示安抚用户,或者有跳转链接转移用户的请求。 

3 冗余

冗余,目的是避免单点故障。比如对于接入层和服务层,可以平行扩展机器部署,这样一台机器宕机,可以将请求转移到其他机器。数据层的冗余比较复杂,增加一份备份数据,需要考虑一致性的问题。按照分布式系统的 CAP 理论三者不可用同时满足的原理,为了满足可用性和分区容错性,就必须牺牲一致性,因此考虑使用弱一致性、最终一致性的解决方案来解决(此类文章很多,略)。

冗余备份有全量和增量之分,有热备和冷备之分。冗余可以是两台机器的主备冗余,可以是多机的集群式冗余。从部署来看,可以是跨机架、跨机房到跨城的备份。多机复制部署,上层调用采用负载均衡策略,还需要注意负载均衡设备的单点问题。

失败通知和失败切换

当集群机器某台机器出现了故障,或者某个进程挂了,能够快速的发现,并且告警通知出来。路由选择器能快速的切除掉这台机器,当恢复后又能自动的加入回来。

4 灰度发布

有个观点,单点发布是可用性最大的敌人。线网出现了故障,查故障的原因,一个常用的办法就是追查下最近是否有发过版本,比较下发布前后的代码。

使用灰度发布策略,发布并且验证没问题后再全量发布。灰度发布的策略,包括搭建预发布环境,有专用的预发布机器;或者路由策略先摘除灰度发布的机器,验证正常后再加入该机器;或者采用UIN取模灰度策略,验证没问题后再取消灰度策略。尽量采用自动化发布,减少人为发布的流程。尽量选择在访问量低峰时段升级,减小影响用户群。

回滚机制

出现问题后,能有有效的回滚机制。涉及到数据修改的,发布后会引起脏数据的写入,需要有可靠的回滚流程,保证脏数据的清除。

除了发布流程外,还应该在其他开发流程上做规范,比如代码控制,集成编译、自动化测试、静态代码扫描等。

5 切换

切换之前需要做好监控。监控应该是贯穿于上述所有手段的。比如业务某个模块访问量要监控,依赖的调用方出问题要监控,某个机房故障了要监控,发布了服务要监控等。监控既包括系统层面的(比如CPU、内存、网络、IO、进程),还包括业务层面的(请求量、错误率、耗时)。监控的间隔需要支持到分钟级甚至到秒级的。

监控不是目的,监控没法保证高可用,切换才是目的,从故障的系统切换到正常的系统才能保证可用性。比如监控某台机器硬盘出问题了,那么会告警出来,然后使用一台新的机器替换。

切换可以是自动的,也可以是人工的。人工切换会有延迟恢复的问题,但能做到准确。自动切换,会比较快速,但必须要确保切换源是正常的,否则可能会引起更加严重的事故。切换后,要有实时的效果反馈。

原文发布时间为:2017-04-05

本文来自云栖社区合作伙伴“Linux中国”

相关文章
|
2天前
|
存储 弹性计算 安全
带你读《从基础到应用云上安全航行指南》——万字干货教你如何保证业务数据全流程安全(2)
带你读《从基础到应用云上安全航行指南》——万字干货教你如何保证业务数据全流程安全(2)
29 0
|
2天前
|
存储 弹性计算 安全
带你读《从基础到应用云上安全航行指南》——万字干货教你如何保证业务数据全流程安全(1)
带你读《从基础到应用云上安全航行指南》——万字干货教你如何保证业务数据全流程安全(1)
33 0
|
2天前
|
存储 弹性计算 安全
带你读《从基础到应用云上安全航行指南》——万字干货教你如何保证业务数据全流程安全(3)
带你读《从基础到应用云上安全航行指南》——万字干货教你如何保证业务数据全流程安全(3)
22 1
|
1月前
|
缓存 监控 负载均衡
系统健康长期“三高”:实现高性能、高可用性和高稳定性的关键要素
大家想必都知道在人类健康领域,我们常常警惕“三高”带来的风险,三高是一个不健康的意思,而在数字化世界中,恰恰相反,系统的高性能、高可用性和高稳定性代表着系统的健康和卓越运行,是一个健康的概念。作为开发者怎么能让我们开发的系统保证长期“三高”,那么本文就来简单讨论一下如何让系统长期维持理想的“三高”标准,以及“三高”在实际业务场景中的真实性,并探索一下在技术负责人角色中使用“三高”来评价系统开发工作的可行性等内容,欢迎大家在评论区留言交流。
33 1
系统健康长期“三高”:实现高性能、高可用性和高稳定性的关键要素
|
5月前
|
运维 监控 容灾
建设强大系统:提升高可用、可靠性和稳定性的秘诀
建设强大系统:提升高可用、可靠性和稳定性的秘诀
|
10月前
|
存储 运维 监控
经典好文:银行业IT服务连续性体系与灾备自动化切换经验分享
经典好文:银行业IT服务连续性体系与灾备自动化切换经验分享
154 0
|
存储 缓存 容灾
语音聊天开发,提升系统稳定性的容灾设计
语音聊天开发,提升系统稳定性的容灾设计
|
SQL 缓存 安全
如何做好大促时的系统高可用
面对大促不确定的流量,我们需要做好全方位的流量控制与防护能力,确保我们的系统始终工作在预期的范围之内。首先我们需要有流量的实时监控以及水位诊断分析能力,确保我们知道当前系统所处的一个状态;在业务的链路入口,我们需要做好链路入口的容量评估以及峰值流量的限流配置、同时需要开启热点隔离能力,防止黑马商品、黑产刷单等不确定因素造成的稳定性影响;在微服务内部我们需要配置单机流控,针对微服务内部异步的流量我们可以配置流量平滑能力做到削峰填谷的效果;针对下游依赖的服务以及组件(数据库、缓存等),我们可以通过慢SQL发现以及熔断、慢调用隔离、热点探测等手段保障稳定性。
如何做好大促时的系统高可用
|
存储 缓存 监控
提升陪玩平台源码可靠性和可用性,可以采取的方式
提升陪玩平台源码可靠性和可用性,可以采取的方式
|
存储 缓存 运维
高可用互联网系统稳定性建设实践指南
自己以及带领团队曾经负责较多不同的互联网服务系统,如几十万应用数&亿级流量的云计算平台、年营收将近千亿的广告系统、亿级用户千万级日活的用户系统、亿级交易额的交易系统、算法在线离线工程系统等相关系统或子系统,整体而言无重大故障,达到定级故障数也很少,线上稳定性保障在一个不错的水位上。阶段性总结下我自己从团队技术负责人视角做好稳定性建设的实践性思考和简要思路,为感兴趣的技术同学提供一个实践指南。 我的团队稳定性建设思路包括了3大技术要素:良好的系统架构和实现、完备的团队研发运维流程机制、技术同学良好意识和能力,以及1个业务要素:良好的研发项目管理。
高可用互联网系统稳定性建设实践指南

相关产品

  • 云迁移中心