共计 2676 个字符,预计需要花费 7 分钟才能阅读完成。
导读 | 可用性的高低是使用不可用时间占总时间的比例来衡量。不可用时间是从故障发生到故障恢复的时间。做到高可用系统,需要尽可能的降低故障发生的次数和减少故障持续的时间。 |
所谓可用性,是指 某系统能够提供正常服务的特性。
可用性的高低 是使用 不可用时间 占总时间 的比例来衡量。不可用时间 是从故障发生到故障恢复的时间。比如,可用性 4 个 9 的系统(99.99%),它一年宕机时间不能超过 53 分钟(=365*24*60*(1-0.9999))。做到高可用系统,需要尽可能的 降低故障发生的次数 和减少故障持续的时间。
出现系统不可用的原因,一种是人为的,比如发布了有 bug 的代码、不规范的发布流程导致的宕机或者网站访问量过载造成的雪崩等;另一种则是非人为的,由于外部系统和环境的变化造成的,比如硬盘老化造成的故障、机房断电、电缆中断等。我们需要在复杂的外部环境下保证系统的高可用。以下总结了常用的高可用解决手段。
这类解决手段不是以减少不可用时间为目的,而是 以减少故障影响面为目的 。因为一个大的系统拆分成了几个小的独立模块, 一个模块出了问题不会影响到其他的模块,从而降低故障的影响面。手段包括:
系统水平拆分成三层:接入层,服务层和数据存储层 。将有状态和无状态的划分开来,接入层和服务层设计成 无状态 的,存储层是 有状态 的。无状态层的服务可以平行扩展,请求落到哪台服务器都没有关系。平行扩展也有利于系统容量的扩充,快速扩容应对突然爆发流量的冲击。
根据功能垂直划分,拆成相对独立的模块。有的仅是服务层做了拆分,存储层共用。更为彻底的是,拆分与该系统的业务领域模型关联,一个领域模型划分成一个模块。在数据库层面,还可以分库分表拆分,这样一个库的损坏,不会影响到其他库。分库分表需要增加路由逻辑,及保证路由规则的一致性。
也属于垂直拆分的一种。写请求的依赖主库,读请求的依赖备库。这样做,当出现故障的时候,可以只有读请求的流量,写服务暂时关闭,从而减少了故障的影响面。但需要关注数据一致性的问题。
这类手段不是为了避免故障的发生,而是 当故障发生后,怎么减小故障所造成的损失。比如,系统正常时提供的服务能力是 100%,出现系统故障后,我们有措施能让系统服务能力不直接降到了 0,而是还能提供 50% 的服务能力。
限流,流量控制。当请求量超过系统的最大容量后,访问延迟就会增加,超过峰值的流量会拖累整个系统,出现宕机。因此,需要提前流量控制,对于超过峰值的流量,可以直接拒绝掉或者随机选择拒绝 。限流结合业务自定义配置, 优先保证核心服务的正常响应,非核心服务可直接关闭。
系统进行拆分之后,会分成多个模块。模块之间的依赖有强弱之分。如果是强依赖的,那么如果依赖方出问题了,也会受到牵连出问题。这时可以梳理整个流程的调用关系,做成弱依赖调用。弱依赖调用通过消息中间件的方式来实现。
异步调用不关心返回结果,不会传递依赖方的错误,进而避免造成更大规模的不可用。
对于不能异步化的,采用 同步调用,需要注意设置合理的超时时间。过长的超时,会延迟结果等待时间,导致整体的链路调用时间延长,降低整体的 QPS。
经验值:超时时间设置成平均响应延迟的 2 倍。
要区分调用失败的类型。有些失败是短暂偶然的(比如网络抖动),进行重试即可。而有些失败是确定,那么重试反而会造成调用请求量的放大,加重对调用系统的负担。
经验值:重试的次数一般设为 3 次,再多次的重试没有好处。
在系统真的出现了不可用的时候,需要有兜底方案。比如一些提示安抚用户,或者有跳转链接转移用户的请求。
冗余,目的是避免单点故障。比如对于接入层和服务层,可以平行扩展机器部署,这样一台机器宕机,可以将请求转移到其他机器。数据层的冗余比较复杂,增加一份备份数据,需要考虑一致性的问题。按照 分布式系统的 CAP 理论三者不可用同时满足的原理,为了满足可用性和分区容错性,就必须牺牲一致性,因此考虑使用弱一致性、最终一致性的解决方案来解决(此类文章很多,略)。
冗余备份有全量和增量之分,有热备和冷备之分。冗余可以是两台机器的主备冗余,可以是多机的集群式冗余。从部署来看,可以是跨机架、跨机房到跨城的备份。多机复制部署,上层调用采用负载均衡策略,还需要注意负载均衡设备的单点问题。
当集群机器某台机器出现了故障,或者某个进程挂了,能够快速的发现,并且告警通知出来。路由选择器能快速的切除掉这台机器,当恢复后又能自动的加入回来。
有个观点,单点 和发布 是可用性最大的敌人。线网出现了故障,查故障的原因,一个常用的办法就是追查下最近是否有发过版本,比较下发布前后的代码。
使用灰度发布策略,发布并且验证没问题后再全量发布。灰度发布的策略,包括搭建预发布环境,有专用的预发布机器;或者路由策略先摘除灰度发布的机器,验证正常后再加入该机器;或者采用 UIN 取模灰度策略,验证没问题后再取消灰度策略。尽量采用自动化发布,减少人为发布的流程。尽量选择在访问量低峰时段升级,减小影响用户群。
出现问题后,能有有效的回滚机制。涉及到数据修改的,发布后会引起脏数据的写入,需要有可靠的回滚流程,保证脏数据的清除。
除了发布流程外,还应该在其他开发流程上做规范,比如代码控制,集成编译、自动化测试、静态代码扫描等。
切换之前需要做好监控。监控应该是贯穿于上述所有手段的。比如业务某个模块访问量要监控,依赖的调用方出问题要监控,某个机房故障了要监控,发布了服务要监控等。监控既包括系统层面的(比如 CPU、内存、网络、IO、进程),还包括业务层面的(请求量、错误率、耗时)。监控的间隔需要支持到分钟级甚至到秒级的。
监控不是目的,监控没法保证高可用,切换才是目的,从故障的系统切换到正常的系统才能保证可用性。比如监控某台机器硬盘出问题了,那么会告警出来,然后使用一台新的机器替换。
切换可以是自动的,也可以是人工的。人工切换会有延迟恢复的问题,但能做到准确。自动切换,会比较快速,但必须要确保切换源是正常的,否则可能会引起更加严重的事故。切换后,要有实时的效果反馈。
高可用手段远不止本文说述的。本文仅是个人经验总结,浅谈了一些常用的解决手段。本文只具有理论指导意义,实际实现高可用的系统,需要结合实际业务场景和所使用的开发框架来完成。
![post-qrcode](https://www.xgss.net/wp-content/uploads/2023/07/二维码-微信公众号256x256.jpg)