从 0 开始学微服务
胡忠想
微博技术专家
64643 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 43 讲
开篇词 (1讲)
结束语 (1讲)
从 0 开始学微服务
15
15
1.0x
00:00/00:00
登录|注册

20 | 服务端出现故障时该如何应对?

自动重启
基于RPC分组的流量切换
基于DNS解析的流量切换
降级
限流
数据一致性问题的解决方案
单机故障
单IDC故障
集群故障
单机故障
单IDC故障
集群故障
思考题
应对故障的实战经验
微服务系统可能出现的故障种类
服务端出现故障时该如何应对?

该思维导图由 AI 生成,仅供参考

在专栏前面我讲过,单体应用改造成微服务的一个好处是可以减少故障影响范围,故障被局限在一个微服务系统本身,而不是整个单体应用都崩溃。那么具体到一个微服务系统,如果出现了故障,应该如何处理呢?
首先,我先来带你回顾一下微服务系统可能出现故障的种类,主要有三种故障。
集群故障。根据我的经验,微服务系统一般都是集群部署的,根据业务量大小而定,集群规模从几台到甚至上万台都有可能。一旦某些代码出现 bug,可能整个集群都会发生故障,不能提供对外提供服务。
单 IDC 故障。现在大多数互联网公司为了保证业务的高可用性,往往业务部署在不止一个 IDC。然而现实中时常会发生某个 IDC 的光缆因为道路施工被挖断,导致整个 IDC 脱网。
单机故障。顾名思义就是集群中的个别机器出现故障,这种情况往往对全局没有太大影响,但会导致调用到故障机器上的请求都失败,影响整个系统的成功率。
在我的实践过程中,这三种故障都经常遇到,因此相应的处理手段也可谓驾轻就熟,下面就把我应对故障的实战经验分享给你,希望对你有所帮助。

集群故障

一般而言,集群故障的产生原因不外乎有两种:一种是代码 bug 所导致,比如说某一段 Java 代码不断地分配大对象,但没有及时回收导致 JVM OOM 退出;另一种是突发的流量冲击,超出了系统的最大承载能力,比如“双 11”这种购物活动,电商系统会在零点一瞬间涌入大量流量,超出系统的最大承载能力,一下子就把整个系统给压垮了。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了微服务系统可能出现的三种故障类型:集群故障、单IDC故障和单机故障,并提供了针对这些故障的处理方法。对于集群故障,建议采用限流和降级两种思路。针对单IDC故障,多IDC部署是一种常见的解决方案,作者介绍了基于DNS解析和基于RPC分组的流量切换方式,以及多IDC部署的好处和流量切换的实现方法。总的来说,本文提供了针对服务端故障的实战经验,包括限流、降级和多IDC部署等方面的处理方法,对于需要处理微服务系统故障的技术人员具有一定的参考价值。文章还提到了自动重启处理单机故障的有效办法,以及在实际故障处理中多种手段并用的情况。同时,作者提出了思考题,探讨了多IDC部署可能带来的数据一致性问题。文章内容丰富,涵盖了微服务系统故障处理的多个方面,对技术人员具有一定的指导意义。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学微服务》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(23)

  • 最新
  • 精选
  • 叽歪
    单机故障重启,这个没有说服力,故障是肯定有原因的,应该找到根本原因.故障重启不是一个资深工程师的解决问题的方法.强烈不认同

    作者回复: 单机故障有多种原因,一切以恢复线上服务为首要目标,重启后可以发邮件告警,如果有机器出现频繁重启,运维就需要介入查看具体原因

    2018-10-10
    2
    15
  • 好好学习
    单机故障,重启过于暴力,硬件问题出现ping不可达,假死可以重启,其他软件层面还是要有其他层面的分析

    作者回复: 是的,可以设置最大重启次数,超过这个就不重启了

    2018-10-06
    2
  • Liam
    能否讲讲具体的限流方法,例如有接入层限流,nginx的配置等

    作者回复: 限流有好几种算法,比如令牌痛算法,可以搜搜它的原理

    2018-10-18
  • 叽歪
    文章深度不够,能不能在深入一点
    2018-10-10
    3
    63
  • 大光头
    一致性分为弱一致性和强一致性。强一致性比如银行转账业务,就必须要求是强一致性。而对于微博评论,并不要求发出去之后立马看到,只要最终看到就可以,晚一点也没关系。 对于强一致性系统,一般都会有读写分离,读可以从多个备份中取数据,而写必须要数据同步到所有备份之后返回。 而弱一致性性,读写分离之后,写的话只写入主库就可以直接返回,然后异步同步到其它备份。这样就会出现某些请求拿不到最新数据
    2018-10-08
    9
  • 拉欧
    只能通过最终一致性保证,比如MySQL的binlog复制
    2018-10-09
    4
  • 一一
    能讲一下限流和降级具体怎么做么?现在只是理论。
    2020-01-04
    1
    3
  • Fan
    "系统能够承载的流量根据集群规模的大小是固定的,可以称之为系统的最大容量" 请问这里的"系统" , 是指整个微服务应用, 还是指单个服务器? 联系上下文看了,还是不能准确的判断作者指的是哪个..
    2020-01-03
    2
    3
  • 波波安
    一般不保证实时一致性,只能保证最终一致性。 1、两个中心中拉专线,进行数据底层同步。2、对于重要数据在做完底层同步后还可以通过消息队列再做一次异步同步来作为补偿。但是要控制好,防止数据重复写入。
    2018-10-14
    3
  • 嘿嘿😁,每逢大促,应急预案演练RPC这块也讲这些,确实不够深入,不过也能理解毕竟篇幅有限,深入还行看书。 感谢!
    2019-06-15
    1
    1
收起评论
显示
设置
留言
23
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部