三、服务降级服务降级：简单地说 ， 就是如果服务异常 ， 停掉不重要的服务 ， 只返回部分数据 。
比如说 ， 一个用户信息接口 ， 包含以下三个字段：
{"id": 111,"nickName": "hhq","userLogo": "https://www.test.com/test.jpg"}如果头像暂时获取失败 ， 如果返回默认头像用户可以接受 ， 那么就降级返回默认的头像 ， 这样既不会使得整个接口失败导致无法进行后续的操作 ， 也不会影响用户体验 。
四、服务熔断熔断：这个概念参考电路的保险丝 ， 如果电力负载过高 ， 达到保险丝熔断 ， 保险丝就会自身熔断切断电源 ， 保护电路安全运行 。而互联网中的服务熔断 ， 是指依赖服务由于各种因素变得不可用或者响应过慢 ， 业务方为了整个服务的稳定性 ， 不再继续调用目标服务 ， 直接返回 ， 如果依赖服务恢复了 ， 则恢复调用 。
注意 ， 熔断和降级看似很相似 ， 但却是不一样的概念 ， 应该理解为从属关系：
1、服务降级有多种降级方式 ， 如限流降级、熔断降级
2、熔断是降级的其中一种方式
在熔断降级的实践中 ， 笔者用到最多的是 Hystrix 。
五、 服务发现服务发现：自动检测一个计算机网络内的设备机器提供的服务 。
服务发现有一个服务中间者维护服务与业务方之间的关系 ， 服务将地址注册到服务中间者 ， 业务方从服务中介中查找需要调用的服务的地址 。
上面提到 ， 最初开始做灾备是通过nginx的负载均衡来实现 ， 这种方式在服务部署和扩容时需要修改配置文件 ， 需要自己维护网络中的机器 ， 一旦不小心配置错误 ， 整个服务就崩了 。如果使用服务发现 ， 由服务发现的中介维护服务地址 ， 配置时只需要知道服务发现的域名和服务名称即可 ， 不需要关心具体的机器是哪一些 。
实践过程中 ， 用到的服务发现组件有：Zuul和spring-cloud 。
六、演练如果以上的步骤都完成了 ， 那么就完成灾备了吗？并不是的 。
现实情况下 ， 很多时候是因为出现了单点故障 ， 才会想到要去做灾备 。或者其他服务出现了故障 ， 自身的服务也要检查并完成灾备 。那么怎么检查自己的服务已经完成灾备了呢？总不可能等待下次的故障到来才去验证 。这种情况下 ， 需要多做服务的灾备演练 ， 根据已做的灾备要点 ， 逐步演练 ， 如果发现遗漏点 ， 重新梳理 ， 继续业务灾备 ， 重新演练 。不断循环 ， 直到随时演练都能快速恢复并最小地影响业务或者业务完全无感知才算完成了灾备 。
踩过的坑以上的这些理论是多次反复实践得出的总结 ， 以笔者自己做灾备的经历 ， 给大家分享我遇到过的两个比较大的坑 。
真的只是重试就完了吗？流量暴涨 ， 拖垮服务接口A ， 依赖服务B ， B依赖服务C ， 部署情况如下：
文章插图
当时做了双活+网关重试+负载均衡的部署 ， 出现的情况是B->C超时 ， 导致A接口响应太慢 ， 这里B->C有两次重试 ， A->B也有两次重试 ， 接口超时时间太长 ， 网关判断接口失败 ， 于是也做了两次重试 ， 最终的结果是 ， 同一个接口 ， 有 2*2*2=8 倍的流量 ， 导致服务C的请求量暴涨 ， 于是将服务C的进程池耗尽 ， 服务499了 ， 最终接口A一直都是失败 ， 直到B->C之间的网络恢复才正常 。
这次的故障得出的结论是：
1、重试不能单纯加上就完事了 ， 需要看下游的依赖是否满足重试
2、重试多次失败后就需要加熔断降级
3、重要的接口 ， 除了重试以外 ， 还可以做部分数据降级提高接口高可用性
机房服务“孤岛”有接口A ， B、C两个服务 ， A-B之间通过外网相连 ， B-C之间通过内网相连 。异常情况是B-C之间网络不通 ， 外网流量通过接口A进入到B ， B依赖C ， 但是B-C之间不通 ， B调用C会不断重试 ， 直到全部重试都失败了 ， 才会返回网络错误 。这样一来 ， 接口A并不知道B服务失败 ， 用户侧体验是一直等待 ， 然后显示失败 。理想的做法是希望能在B-C网络不通的情况下将后续到来的流量拒绝掉 ， 快速响应失败的结果 。
推荐阅读
- 茶园灌溉新渠道,康记古树中山渠道服务商隆重开业
- 淘宝买家消费者保障服务在哪里 淘宝支持卖家
- 怎么入驻淘宝 淘宝服务商怎么入驻
- 聊聊DOS操作系统中的文件系统FAT12
- 服务器被DDoS攻击最佳解决方案是什么？
- 天猫价保服务规则 天猫规定保价多少天
- 淘宝服务商代运营靠谱吗 淘宝店铺代运营公司靠谱吗
- 服务器基础知识
- 数据库服务器主机重启故障诊断分析
- 淘宝开通信用卡支付怎么收取费用 淘宝店铺开通信用卡支付服务费是多少