服务的容灾与容错
引子
先介绍几个概念,同步一下认知:
容灾:是指系统冗余部署,当一处由于意外停止工作,整个系统应用还可以正常工作。
容错:是指在运行中出现错误(如上下游故障或概率性失败)仍可正常提供服务。
可用性:描述的是系统可提供服务的时间长短。用公式来说就是A=MTBF/(MTBF+MTTR),即正常工作时间/(正常工作时间+故障时间)。
可靠性:描述的是系统指定时间单位内无故障的次数。比如:一年365天,以天为单位来衡量。有天发生了故障,哪怕只有1秒,这天算不可靠。其他没有故障的是可靠的。
稳定性:这个业界没有明确的定义,我的理解是:在受到各种干扰时仍然能够提供符合预期的服务的能力。
从要求的严格程度上:可用性<可靠性<稳定性。
可用性和可靠性更侧重于容灾,而对稳定性同时包含容灾和容错。
服务的容灾
服务容灾的解决方案就是冗余。多几个备份来切换。常用的有N+1容灾和两地三中心。N和中心实际上都是机房的意思。所谓中心就是数据中心。N是数据中心的电力配置部分。电力配置有市电和备用发动机供电,但是一般互联网公司是不支持备用发动机供电的。所以一般一个机房就是一个N。
N+1容灾就是要多出一个机房做容灾。而两地三中心,是提高了安全级别,除了同城两个中心外,在异地再多出来一个中心。如果整个地区市电都不供电了,还有个备份。
这个备份的冷备和热备不同于数据库的冷备和热备。数据库的冷备是离线备份,就是不接收新流量的情况下备份。热备是一边接收流量一边备份。
而通常服务的冷备是服务还没有接收流量。而热备是指备份数据也在接收流量,比如负载均衡或者master-slave模式的slave承担读流量的副本。这些热备由于一直在运行所以避免了要切换前的服务检查等步骤,可以快速切换。
服务的容错
道
Everything fails!
法
服务容错的难点在于存在未知和不可预测。所以对服务容错要处理两个问题:发现和解决。
可以自下而上和自上而下两个角度来发现问题。自下而上主要是根据海因法则,从根本上解决遇到的每一个问题,以避免引起更大的问题。自上而下是系统化的思考,根据已知和可预测的,推演出未知和不可预测的。
在解决问题方面,衍生出很多派系。比如调研到阿里那边更倾向于从流程上做把控:
术
隔离术
1>领域拆分解耦 ACL防止损坏层 有界上下文提炼核心、支撑和通用域 分层架构 CRUD增删改查简单架构
CQRS命令查询隔离
依赖消弱控 2>服务部署隔离 环境拆分 机房隔离 通道隔离 单元化 泳道 热点隔离 读写隔离 容器隔离 拆库拆表 动静隔离 非核心流量隔离 3>服务间交互隔离 熔断降级 4>服务内资源隔离 线程池隔离 信号量隔离
风险巡检术
慢查询
超时治理
依赖治理:消除依赖、弱化依赖、控制依赖
系统破窗户
废弃代码资源治理
系统异常治理
告警治理
数据一致性治理
稳定性设计术
请参考《稳定性三十六计》
器
超时重试:推荐spring-retryer
熔断:推荐hystrix
限流:推荐Guava RateLimiter
spring cloud提供了超时重试、熔断、限流的综合解决方案
- 使用Hystrix实现微服务的容错处理
- Spring Cloud Hystrix 服务容错保护
- 7.Spring Cloud:服务容错保护(Hystrix依赖隔离)【Dalston版】
- 使用Hystrix实现微服务的容错处理
- 微服务架构之「 容错隔离 」
- 15. Dubbo原理解析-集群&容错之目录服务Directory
- 服务容错保护断路器Hystrix之一:入门介绍
- 服务容错保护断路器Hystrix之四:turbine集群监控
- Hystrix服务容错降级使用
- Go微服务容错与韧性(Service Resilience)
- 今日头条在消息服务平台和容灾体系建设方面的实践与思考
- 基于.NET CORE微服务框架 -谈谈surging的服务容错降级
- 使用Hystrix实现微服务的容错处理
- 微服务下的网关与容错
- Spring Cloud构建微服务架构服务容错保护
- Spring Cloud架构教程 (十四)服务容错保护(Hystrix服务降级)【Dalston版】
- 16. Dubbo原理解析-集群&容错之router路由服务
- 容灾系统的云中嬗变-【软件和信息服务】2013.12 推荐
- Spring Cloud构建微服务架构:服务容错保护(Hystrix服务降级)
- Dubbo服务集群,常见容错机制:failover ,failsafe,failfase ,failback,forking