服务的容灾与容错

引子

先介绍几个概念，同步一下认知：

容灾：是指系统冗余部署，当一处因为意外中止工做，整个系统应用还能够正常工做。

容错：是指在运行中出现错误（如上下游故障或几率性失败）仍可正常提供服务。

可用性：描述的是系统可提供服务的时间长短。用公式来讲就是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提供了超时重试、熔断、限流的综合解决方案